Тактика складання запитів здебільшого зосереджена на точності та повноті інструкцій. Найбільше покращень у робочих системах дає підхід, за якого сам діалог стає основною проблемою дизайну.
Наміри у форматі «умова — дія» підказують моделі, як ухвалювати рішення, замість того щоб нав’язувати їй сценарій, за межі якого вона не може вийти. Позиція в запиті сама по собі є інструкцією. Спочатку задають ідентичність, посередині — нюанси поведінки, наприкінці — жорсткі обмеження, а все справді критичне розміщують і на початку, і в кінці.
Одна з найдієвіших змін — писати запит у потрібній манері, а не описувати її.
Найбільш цілісні агенти мають запити, у яких різні моменти розмови розглядаються як окремі взаємодії з доречною для кожної формою, але незмінно впізнаваним голосом.
Іноді відокремлення агентів, які мислять, від агентів, які говорять, дає цілісніші й обґрунтованіші відповіді та не дозволяє внутрішнім міркуванням просочуватися в них.
Раніше ми представили нову парадигму складання запитів, засновану на напрацюваннях лінгвістики та когнітивної психології. Ми писали про важливість створення чіткого й обмеженого простору завдань, у якому може діяти агент, а також про те, що цей простір має охоплювати метазавдання діалогу, властиве клієнтському ШІ.
Тепер розглянемо кілька практичних змін у наших запитах, які виникли під час упровадження цих принципів у робочі системи.
Після сотень ітерацій запитів у робочих клієнтських системах ми побачили, що найбільше покращень дали не додаткові інструкції, численні приклади чи дотримання типових норм тактики складання запитів. Натомість їх дало визнання діалогу основою проблеми.
У процесі постійних досліджень і випробувань з’явилася низка дієвих методів. Ми змінювали запит і спостерігали, де розмова була вдалою, а де ні, простежуючи зв’язок помилок з ефективністю настанов, структурою запиту й використаною мовою. У результаті ми отримали кілька відтворюваних шаблонів, які змінюють те, як агент розуміє свою роль у розмові, вибирає наступний хід і послідовно зберігає голос у мінливих контекстах.
Далі викладено не універсальну систему й не твердження, що проблему складання запитів уже «розв’язано». Це п’ять шаблонів, які витримали перевірку в робочих системах, коли метою була не лише функціональна точність, а й кращий діалог: цілісні, природні та достатньо послідовні відповіді, здатні передавати голос бренду.
Агентну систему можна структурувати багатьма способами, однак оркестровані багатоагентні процеси залишаються популярними. Саме в таких системах найстабільніше покращення дало відокремлення агентів, які мислять, від тих, які говорять.
Оркестрація намірів, класифікація, отримання знань і використання інструментів — усе це внутрішні операції. Відповіді клієнтам належать до зовнішньої частини. Коли один агент виконує обидві функції за один хід, внутрішні міркування й логіка можуть просочуватися у відповіді. Відповіді стають непевними, перевантаженими застереженнями або будуються навколо логіки процесу, а не потреб людини.
Це єдине обмеження дає напрочуд вагомий результат. Воно прив’язує відповіді до фактичної розмови, запобігає скиданню контексту й дає результат, ближчий до того, що ми називаємо «наданням лише різниці». Тобто агент додає лише мінімум нової інформації, який справді допомагає користувачеві просунутися далі.
Важливо також вирішити, який тип відповіді надати. Ми виявили, що прохання до агента-співрозмовника спочатку вибрати тип ходу — відповісти, уточнити, переспрямувати чи попросити зачекати — стабільно зменшувало найпоширенішу помилку в розмові: не невдалий текст, а цілком неправильну відповідь.
Варто зазначити, що за належних умов новітні передові моделі вже ставлять під сумнів вихідну передумову цього шаблону. Утім, із різних причин багато розробників досі покладаються на менші чи старіші моделі. У таких випадках ми однозначно радимо розділяти внутрішні та клієнтські функції.
Для моделей без міркування підхід із кількома прикладами дієвий, адже приклади конкретні, швидкі у використанні й добре сприймаються моделями. Проблема полягає в перенавчанні. Отримавши приклад, модель чіпляється за його слова, ритм і структуру та раз у раз створює дуже схожі відповіді, навіть коли ситуація вже змінилася.
Ви мимоволі написали сценарій, за межі якого модель не може вийти.
Наміри реалізації, або евристики, — надійніша альтернатива. Замість того щоб показувати моделі, що сказати в конкретних ситуаціях*,*, ми задаємо ширшу пару «умова — дія»: якщо відбувається X, зроби Y.
Головна відмінність у тому, що ми не звужуємо X і Y приклад за прикладом, роблячи їх дедалі жорсткішими, а встановлюємо для кожного чіткі межі настільки точною інструкцією, що приклади стають зайвими. Так агент реагує на реальне розмаїття розмов, а не підганяє їх під шаблон.
На практиці це радше готові до виконання правила, ніж приклади:
If a key detail is missing, ask one clarifying question.
If the answer isn’t supported, say so directly and offer the best available next step.
If the request hits a guardrail, decline briefly and redirect without ceremony.
Це не надто ефектно, зате значно надійніше за бібліотеку зразків відповідей, адже навчає модель ухвалювати рішення, а не повторювати готове.
Розташування інформації в запиті визначає її вагу. Ми послідовно спостерігаємо цю закономірність у різних моделях і впровадженнях. Початок і кінець запиту мають непропорційно велику вагу. Посередині розміщують нюанси — саме там їм і місце.
З огляду на це ми й структуруємо свої запити. Роль і самоідентифікацію агента розміщуємо на початку, щоб передусім визначити його ідентичність. У середині викладаємо подробиці поведінки: імовірний перебіг розмови, евристики для формування відповідей і спектр ситуацій, із якими має впоратися агент. Жорсткі та безумовні обмеження розміщуємо в кінці, де вони залишаються «на першому плані».
Усе справді критично важливе ми розміщуємо і на початку, і в кінці. Окреме правило щодо результату — наприклад, жорстка вимога до пунктуації чи форматування — часто губиться, якщо згадати його лише раз усередині насиченого запиту. Якщо повторити його наприкінці, воно виконується.
Щодо ефекту недавності варто зазначити: якщо ви використовуєте структуровані результати, вони фактично стають останньою інструкцією у вашому запиті. Поля опису у структурованих результатах якісно впливають на відповіді, формуючи жорсткіший контракт результату, ніж решта запиту.
Ми зрозуміли, що й для тону спілкування не варто використовувати підхід із кількома прикладами. Це одна з найдієвіших змін, які ми внесли до роботи наших клієнтських агентів.
Натомість ми пишемо весь запит у потрібній манері. Не описуємо її й не перелічуємо приблизні характеристики, а від першого до останнього рядка пишемо повноцінний текст саме в цій манері. Сам запит стає демонстрацією. Ми називаємо це «антисценарністю»: модель наслідує вхідний текст, але може використовувати ширший спектр мовних засобів і фраз у тій самій стилістичній площині, що й сам запит.
Так ми спонукаємо модель урізноманітнювати відповіді, зберігаючи цілісну манеру спілкування. Це частина нашої стратегії: зробити діалог основою завдання для будь-якого агента без зайвих прямих інструкцій, кількість яких ми намагаємося мінімізувати.
Якщо ми й наводимо прямі приклади тону спілкування, то лише щоб показати, «як робити не слід». Наприклад: “No em dashes. Ever. No clichés. No policy dumping. No over-explanation when a single sentence will close the loop.” Негативні обмеження водночас точніші й менш жорсткі, ніж позитивні настанови, адже вони називають типові помилки, до яких найімовірніше схилятиметься модель.
Форматування теж важливе: воно задає тон відповіді. Запит із численними списками, заголовками та інструкціями в дужках спрямовує модель до впорядкованішої та сухішої відповіді. Якщо відповідь має нагадувати розмову, вхідний текст не повинен виглядати як стислий технічний документ.
Більшість настанов щодо тону зводяться до особистості. Агенту задають перелік характеристик, які мають описувати його манеру спілкування. Тепла. Професійна. Приязна, але лаконічна. Ці характеристики не хибні, однак сприйняття голосу в розмові насправді визначає регістр: те, як той самий персонаж поводиться в різних соціальних ситуаціях.
Проміжне повідомлення під час опрацювання запиту не має звучати як остаточна відповідь. Відповідь, продиктована захисними обмеженнями, не повинна мати тієї самої емоційності, що й невимушена бесіда. З розчарованим клієнтом не варто спілкуватися так само дотепно й невимушено, як із тим, хто просто переглядає пропозиції.
Саме цим голос бренду відрізняється від дизайну розмови. Голос бренду часто описує персонажа, а дизайн розмови визначає, як той поводиться за різних обставин. Правильний підхід означає, що ми не просто копірайтери, які працюють над результатами ШІ. Ми проєктуємо те, як голос веде розмову.
Як бачите, жоден із цих шаблонів не є технічно складним. Частково в цьому й полягає суть. Архітектура агентної системи важлива, але для якісної розмови доведеться приділити багато часу проєктуванню та вдосконаленню запитів.
Розрив між суто функціональним і справді розмовним ШІ долає не технічний дизайн, а чіткіше розуміння ролі мови й уваги в людському діалозі та визнання діалогу основою простору завдань для ваших агентів.
У клієнтському ШІ команди продуктів, інженери й дизайнери взаємодії мають приділяти дизайну розмови не менше уваги, ніж технічній досконалості. Для людей по той бік розмови немає ні моделі, ні взаємодії кількох агентів, ні виклику інструментів — є лише взаємодія, яка або сприймається природно, або ні. Вона або зміцнює довіру, або руйнує її.
Зрештою, ніхто не взаємодіє з архітектурою. Люди взаємодіють через розмову.
Розмова і є продуктом.