Асистент вигадує відповіді там, де промпт мовчить про джерела і про межу. Робочий промпт - це контракт на пів сторінки: мета, джерела, тон, заборони і момент, коли асистент передає розмову людині.
Керівник відділу продажів показує мені промпт асистента, над яким команда працювала два тижні. Дванадцять сторінок: історія компанії, опис усіх товарних груп, витяги з сайту, правила спілкування, список конкурентів. Поруч відкритий Telegram, де клієнт питає, чи можлива доставка в суботу, і асистент впевнено відповідає, що так, і навіть називає час. Доставки в суботу в компанії ніколи не було. У дванадцяти сторінках про це жодного слова, а ще там бракує найважливішого речення: що робити асистенту, коли відповіді в джерелах немає. Тому він робить те, що вміє найкраще, і дописує правдоподібний текст.
Ця сцена показує головну помилку в написанні промптів. Люди думають, що вигадки лікуються обсягом: чим більше розповісти асистенту, тим менше він домислить. Працює зворотне. Довгий промпт розмиває увагу моделі, і ключові заборони тонуть серед описів. Короткий контракт на пів сторінки, у якому кожне речення виконує роботу, тримає асистента в межах краще за будь-яку wiki. І контракт цей складається з п'яти частин: мета, джерела, тон, заборони, передача людині.
Коротко
- Вигадки з'являються там, де промпт мовчить про те, звідки брати відповідь і що робити, коли її нема.
- Робочий промпт асистента вміщається на пів сторінки і складається з п'яти частин.
- Мета формулюється двома реченнями: що асистент робить, для кого і де закінчується його роль.
- Джерела названі поіменно, і кожна відповідь спирається на них, а не на загальні знання моделі.
- Заборони і правило передачі людині важливіші за опис компанії.
Чому довгий текст не рятує від вигадок
Модель читає промпт так, як людина читає пам'ятку на робочому місці: перші рядки уважно, середину по діагоналі, кінець швидко. Якщо заборона називати строки доставки, яких немає в таблиці, стоїть на дев'ятій сторінці після опису історії компанії, шанс, що вона спрацює в потрібний момент, невеликий. Опис компанії при цьому взагалі рідко потрібен: асистенту важливо знати, що відповідати клієнту, а не в якому році заснована фірма.
Є і друга причина. Довгий промпт створює у команди відчуття, що все вже описано, і тому за асистентом перестають дивитись. Короткий контракт, навпаки, всім видно і всім зрозуміло: менеджер може прочитати його за хвилину і сказати, чого там бракує після конкретного випадку з клієнтом. Промпт, який команда здатна прочитати і виправити, живе. Промпт на дванадцять сторінок лежить.
Спокуса зробити з промпту wiki зрозуміла: у компанії є база знань, і здається логічним просто віддати її асистенту. Але база знань і промпт виконують різну роботу. База знань відповідає на питання, що є правдою про компанію. Промпт відповідає на питання, як асистент має поводитись, коли клієнт щось питає. База знань може лежати окремим файлом, до якого промпт відсилає як до джерела. Сам промпт при цьому лишається коротким набором правил поведінки, і саме ці правила, а не обсяг знань, вирішують, чи асистент вигадає відповідь.
Мета: два речення про роботу асистента
Перша частина контракту відповідає на питання, що саме робить асистент і для кого. "Ти асистент відділу продажів компанії, яка постачає будівельні матеріали. Ти відповідаєш на питання клієнтів у Telegram про наявність, ціни і строки поставки за прикріпленим прайсом і таблицею залишків." Два речення, і модель вже розуміє свою роль.
Тут корисно дописати межу ролі, бо вона прибирає цілий клас вигадок. "Знижки, відтермінування оплати і технічні консультації щодо монтажу лишаються за менеджером." Кожна з цих трьох тем у реальних чатах породжує імпровізацію: клієнт питає, чи можна подешевше, і асистент, якому ніхто не окреслив межу, придумує п'ять відсотків.
Джерела: звідки брати відповідь і що робити без неї
Друга частина найважливіша, і саме її найчастіше пропускають. Асистент має знати, які документи є правдою для його відповідей, і ці документи мають бути названі поіменно. "Ціни береш лише з файлу прайс_поточний.xlsx. Наявність береш лише з таблиці залишків. Строки поставки береш лише з розділу Доставка в прикріпленому документі умов." Слово "лише" тут працює як стіна між джерелами компанії і загальними знаннями моделі, у яких вона може знайти будь-яку правдоподібну цифру.
І далі речення, якого бракувало в тих дванадцяти сторінках: "Якщо відповіді в цих джерелах немає, скажи клієнту, що уточниш і повернешся, і передай питання менеджеру". Це речення варте більше за весь опис компанії, бо саме воно перетворює вигадку на передачу. Модель без нього заповнить прогалину, модель з ним зупиниться.
Корисно також попросити асистента показувати джерело в самій відповіді, хоча б у внутрішній версії для менеджера: "біля кожної ціни вкажи рядок прайсу". Так менеджер за секунду бачить, чи число прийшло з файлу, чи з повітря.
Джерела мають бути актуальними, інакше правило про них працює проти вас. Асистент, який чесно бере ціни лише з прайсу, називатиме ціни з весни, якщо у прайсі досі весна. Тому поруч із контрактом має бути одна людина і один день тижня, коли файли джерел оновлюються, і рядок у промпті, що робити, якщо в файлі стоїть дата старша за два тижні: попередити менеджера замість того, щоб відповідати клієнту.
Тон і форма відповіді
Третя частина коротка, але без неї асистент пише або як юрист, або як реклама. "Пишеш українською, звертаєшся на ви, відповідаєш у два-три речення, без вигуків і без емодзі. Якщо клієнт пише розмовно, лишаєшся ввічливим і діловим." Достатньо додати один живий приклад хорошої відповіді, взятий з листування найкращого менеджера компанії, і асистент підхопить манеру точніше, ніж з будь-якого опису.
Тут же варто зафіксувати форму для типових ситуацій. Питання про ціну отримує відповідь з ціною, одиницею виміру і фразою про актуальність: "ціна дійсна на сьогодні за прайсом". Питання про строки отримує строк з документа умов і уточнення міста. Коли форма задана, асистенту немає де імпровізувати.
Тон при цьому має бути вашим, а не середнім по інтернету. Модель без прикладу пише так, як пише більшість, тобто гладко і трохи безособово, і клієнт це відчуває вже з другої відповіді. Один абзац із реального листування, де ваш найкращий менеджер відповів на складне питання коротко і по-людськи, дає асистенту більше, ніж десять прикметників у описі тону. Якщо в компанії є фраза, якою завжди закінчують відповідь, або звичка називати клієнта на ім'я, це варто записати одним рядком, бо такі дрібниці і роблять асистента схожим на команду.
Заборони і момент, коли кликати людину
Четверта і п'ята частини йдуть разом, бо вони описують межу. Заборони формулюються конкретно і коротко, і їх має бути мало, п'ять-сім. "Не називай ціни, яких немає в прайсі. Не обіцяй строків, яких немає в умовах. Не називай імен співробітників. Не погоджуй умови оплати. Не відповідай на питання про конкурентів." Кожна заборона в цьому списку народилась із реального випадку, і саме так список і має рости: сталась помилка, з'явився рядок.
Передача людині описується як подія, а не як побажання. "Передай розмову менеджеру, якщо клієнт питає про знижку, про повернення, про претензію, якщо він пише роздратовано або якщо ти двічі підряд не знайшов відповіді в джерелах. При передачі напиши клієнту одне речення, що менеджер відповість протягом години, і залиш менеджеру резюме розмови на три рядки." Момент передачі, описаний так, працює як запобіжник: асистент знає, де закінчується його робота, і перестає дописувати за людину.
Показовий випадок стався в компанії, яка продає запчастини. Клієнт у Telegram написав, що деталь прийшла з дефектом, і асистент, у промпті якого про претензії не було жодного слова, почав ввічливо пояснювати порядок повернення, який сам і придумав. Клієнт діяв за цим порядком, а на складі про такий порядок ніхто не чув. Один рядок у правилі передачі, що претензії йдуть до менеджера одразу, закрив цю дірку назавжди. Саме так і виглядає нормальне життя контракту: він росте рядками після реальних випадків, а не сторінками наперед.
Як перевірити контракт за один вечір
Промпт перевіряють на реальному листуванні. Візьміть з Telegram двадцять останніх діалогів із клієнтами, приберіть імена і прогоніть кожен через асистента з новим промптом. Дивіться на три речі: чи всі ціни збігаються з прайсом, чи є хоч одна обіцянка, якої немає в документах, і чи передав асистент людині ті розмови, де мав передати. Кожна знайдена помилка стає одним новим рядком у заборонах або в правилі передачі. Через два-три такі вечори контракт стає робочим, і при цьому лишається на пів сторінки, бо ви додавали рядки, а не сторінки.
Що робити далі
- Скоротіть чинний промпт асистента до пів сторінки, прибравши історію компанії і описи, які не впливають на відповідь клієнту.
- Напишіть мету двома реченнями і одразу окресліть межу ролі: які теми лишаються за менеджером.
- Назвіть джерела поіменно і додайте правило: якщо відповіді в джерелах немає, асистент повідомляє про уточнення і передає питання менеджеру.
- Складіть п'ять-сім заборон з реальних помилок і опишіть передачу людині як конкретну подію з резюме для менеджера.
- Прогоніть двадцять реальних діалогів через новий промпт і за кожною знайденою помилкою додайте один рядок.
Про цей матеріал
Текст написаний з досвіду налаштування асистентів для відділів продажів українських компаній. Приклади промптів узагальнені, назви компаній і клієнтів прибрані.