System prompt розробка: де асистент відповідає неправильно
Нестабільні відповіді асистента майже ніколи не пов'язані з можливостями моделі — причина в інструкції. Те саме питання при різних формулюваннях отримує різні відповіді, а тон змінюється від репліки до репліки. System prompt розробка починається з визнання: перед нами не текст, а звід правил поведінки.
Найпоширеніша помилка — суперечності всередині промпту для AI-асистента. Одна частина вимагає коротких відповідей, інша — докладно розкривати продукт; одне правило забороняє згадувати конкурентів, інше просить порівняти. Конфлікт модель розв'язує по-новому в кожному діалозі — звідси нестабільність.
Друге джерело — втрата контексту на довгому діалозі. До десятого повідомлення асистент забуває, що клієнт уже назвав тариф або регіон, і ставить ті самі питання заново.
Якщо поведінка мовної моделі не описана для повторних уточнень і зміни теми, розмова розпадається на незв'язані відповіді.
Третє — відсутність пріоритетів. Без явного порядку «спочатку факти, потім стиль» будь-яке нестандартне звернення ламає сценарій. У підтримці це вигадані терміни й умови, у продажах — пропущене уточнювальне питання і втрачений контакт.
Такі помилки в інструкції асистента відтворюються на наборі тестових діалогів, а не вгадуються. Далі розбираємо, як ми збираємо і перевіряємо system prompt.
Вимірюваний ефект від вивіреної інструкції асистента
Ефект від вивіреної інструкції вимірюємо на одному й тому самому еталонному наборі діалогів — кілька сотень сценаріїв, розкладених за типами: типовий запит, уточнення під час розмови, звернення поза зоною компетенції асистента, суперечливі вимоги в одному повідомленні.
Оцінювання сліпе: розмітники не знають, яка версія інструкції відповідала, а розбіжності між ними рахуємо окремо — інакше шум розмітки легко прийняти за покращення.
Перший показник — частка коректних відповідей. Після вичистки правил і прикладів вона зростає з 70–75 до 90+ відсотків на тих самих сценаріях, а кількість звернень до оператора на них падає кратно: асистент перестає йти в загальні формулювання і доводить діалог до результату.
Окремо дивимося відповіді поза компетенцією — там метрика не «правильно/неправильно», а коректність ескалації.
Повторюваність перевіряємо прогоном набору кілька разів за фіксованих параметрів генерації моделі на боці OpenAI.
До доопрацювання розкид за часткою коректних відповідей між запусками сягав 10–15 в.п., після — тримається в межах одиниць: результат відтворюється, а не залежить від вдалого проходу.
Єдиний стиль відповідей — теж вимірювана величина: структура, довжина, форма звернення і формулювання відмови задані явними правилами і перевіряються автоматично за маркерами, тому новий сценарій не «роз'їжджається» за тоном з іншими.
Головна зміна — передбачуваність відмов. Клас «впевнена неправильна відповідь» зникає, замість нього — зрозуміла відмова або передача оператору з готовим контекстом. Далі розбираємо, як ця інструкція збирається і утримується в робочому стані.
Способи задати поведінку асистента: порівняння підходів
Поведінка асистента задається текстом, який підставляється в кожен запит перед реплікою користувача. Від устрою цього тексту залежить, наскільки передбачувано асистент тримає роль, формат відповіді та межі допустимих дій.
Нижче — чотири робочі варіанти інструкцій асистента, між якими реально обирають команди, та обмеження кожного.
Розробка system prompt — це не пошук «правильного» формату, а підгонка конструкції під сценарій. Коротка інструкція часто стає ядром, поверх якого на окремі гілки накладається регламент поведінки асистента.
Ми перевіряємо зібрану схему на наборі еталонних діалогів: рахуємо частку коректних відповідей і відмов до і після правок.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Коротка інструкція: роль, тон, формат відповіді | Один тип запиту, простий сценарій | Втрачає винятки — асистент домислює спірні випадки |
| Інструкція з прикладами зразкових відповідей | Потрібен стабільний формат: поля, розмітка, шаблон | Обсяг запиту зростає, приклади штовхають до копіювання |
| Регламент поведінки: правила, заборони, розгалуження | Багато обмежень і різних типів запитів | Без строгої структури частина правил випадає з уваги моделі |
| Багаторівнева схема: ядро плюс сценарії | Кілька сценаріїв із спільними і власними правилами | Складніше налагодження — конфлікт рівнів шукається довше |
Вибір варіанта перевіряємо на діалогах, які вже ламали попередню версію: якщо схема не тримає потрібну частку коректних відповідей, її спрощують, а не доповнюють новими правилами.
Порядок роботи над інструкцією асистента
Інструкція асистента — не абзац ввічливості, а набір правил із пріоритетами: що робити при конфлікті вказівок, де змовчати і передати діалог людині, який формат відповіді обов'язковий.
Тому етапи розробки інструкції починаються не з тексту, а з розбору того, як асистент відповідає зараз. Нижче — маршрут від аудиту до передачі налаштованої конфігурації з перевіреними сценаріями.
- Аудит відповідей асистента: розмічаємо реальні діалоги — де він виходить за роль, домислює факти, ламає формат. На виході перелік типових відмов із частотою.
- Схема правил: роль, тон, межі компетенції, пріоритети при конфлікті вказівок і поведінка при нестачі даних — кому передати запит.
- Чернетка інструкції: формулювання під кожне правило плюс окремі блоки під часті сценарії, щоб основний текст не розростався.
- Тестовий набір: еталонні репліки й очікувані відповіді, включно з провокаціями, уривчастими питаннями й темами поза областю.
- Перевірка інструкції: прогін за набором і порівняння з еталоном, правка формулювань, закріплення версії. Спірні відповіді розбираємо окремо.
- Приймання на сценаріях замовника: уточнюємо пограничні випадки й тон відповідей.
- Передача: інструкція, тестовий набір і короткий регламент оновлення — при зміні продукту правила правляться точково.
Далі інструкція живе як конфігурація: зміни проходять через той самий тестовий набір, і регрес видно до випуску, а не в діалозі з клієнтом.
Які артефакти залишаються в команди після проєкту
Проєкт закінчується не демонстрацією діалогу, а пакетом файлів, за якими асистента можна розвивати без нас.
Без цього текст інструкції живе в листуванні: правки вносяться «з пам'яті», а після зміни відповідального ніхто не може пояснити, чому правило сформульовано саме так і що зламається, якщо його прибрати.
- Текст системної інструкції — фінальна версія з розподілом ролей, межами теми і форматом відповіді, у репозиторії, а не в листуванні.
- Карта правил і пріоритетів — які вказівки головніші при конфлікті, коли асистент уточнює, а коли відмовляє.
- Набір перевірних сценаріїв — типові й пограничні діалоги, на яких проганяється кожна правка інструкції.
- Правила тестування — порядок прогону, еталонні відповіді, допустима частка розбіжностей до випуску версії.
- Регламент оновлення — власник інструкції, порядок внесення правок і обов'язкова фіксація причини зміни.
- Історія версій — що міняли, навіщо, на якому наборі сценаріїв перевіряли і з яким результатом.
- Документація асистента — ролі, обмеження, підключені джерела знань і відомі слабкі місця.
- Чек-лист передачі — доступи, стенди, порядок запуску перевірок і точки ескалації при відхиленнях.
Цей набір закриває головний ризик: логіка поведінки асистента залишається у замовника, а не у підрядника. Оновлення інструкції перетворюється на зрозумілу процедуру з перевіркою, а не в експеримент на живих користувачах.
Кейс: як усунули розбіжності у відповідях асистента
Асистент мережі сервісних центрів ServicePro відповідав клієнтам у чаті, поштою і в месенджері.
На контрольному наборі з 200 сценаріїв одне й те саме питання про терміни й повернення давало розбіжності в 29% випадків: правила дублювалися в трьох місцях інструкції і суперечили одне одному.
Це не косметика — кожне третє неправильне формулювання тягло за собою повторне звернення, а оператори правили відповіді вручну. Нижче — що саме переписали і як це відобразилося на метриках.
Що було не так
Пріоритет між правилами не був заданий, тому модель обирала формулювання довільно. Про відсутність даних в інструкції мовчали, і асистент добудовував терміни за аналогією зі схожими зверненнями; тон теж плавав за каналами.
Що переписали і що отримали
Інструкцію розклали на шари з явним пріоритетом: факти з бази знань, потім правила домену, потім формат і тон — при конфлікті перемагає вужче правило.
Ввели жорстке обмеження: термін або умова без опори на джерело не виводиться, замість цього асистент ставить уточнювальне питання або передає оператору. Спірні місця закрили парами прикладів «правильно / неправильно».
Той самий набір після правок: розбіжності 29% → 2%, відповіді з вигаданими деталями 11% → 0,8%, частка правильних відповідей 71% → 96%. Набір став регресійним — кожна правка інструкції проганяється повністю, а відкат до попередньої версії займає хвилини.
Що робити, якщо промпт уже написано, але відповіді плавають
Нестабільність відповідей майже ніколи не пов'язана зі слабкою моделлю — джерело в самій інструкції.
Якщо один блок вимагає відповідати коротко, а інший наполегливо просить розкривати деталі, асистент щоразу обирає по-різному: результат залежить від того, який фрагмент правил опинився ближче до запиту. Поки такий конфлікт не знайдено, будь-яка правка формулювань дає ефект на день.
Діагностику починаємо не з переписування промпту, а з розбору відповідей, які «попливли».
Збираємо реальні запити, де поведінка розходиться, і розкладаємо їх на три класи: правило взагалі не описано, правило є, але без пріоритету, правило перебивається прикладом або форматом виводу. Найчастіше спливає друге — кілька рівнозначних вказівок, між якими немає порядку старшинства.
Якщо розходяться один-два сценарії, це доопрацювання промпту: знімаємо дублювальні вимоги, задаємо явний пріоритет, виносимо формат відповіді в окремий блок.
Коли ж «плаває» помітна частка звернень і одразу за різними темами, точкові правки тільки заплутують — правила описані впереміш, роль і тон задані в різних місцях і сперечаються між собою. Тут потрібне перескладання інструкції загалом.
Перескладання — це розкласти роль, межі допустимого, порядок пріоритетів і правила поведінки при нестачі даних на ізольовані блоки і зафіксувати, що важливіше при зіткненні. Далі інструкція проганяється на одному й тому самому наборі запитів: до і після.
Якщо розкид відповідей на цьому наборі перестав змінюватися від запуску до запуску, інструкція готова до роботи, а не до наступної серії правок.
Часті технічні сумніви перед стартом
Сумніви перед стартом зазвичай не про те, «чи вміє модель», а про керованість: чи втримається інструкція при зростанні кількості сценаріїв, що буде після оновлення, хто відповідає за помилку у відповіді. Нижче — питання, які задають найчастіше, і що за ними стоїть інженерно.
Ми ставимося до системної інструкції асистента як до конфігурації, а не як до тексту: у неї є версія, набір перевірок і регламент змін. Тому на питання про супровід є процедурна відповідь, а не обіцянка.
Інструкція стане некерованою, якщо додати багато правил?
Щільність правил — реальне обмеження: після певного порогу модель починає розмивати пріоритети між ними. Тому правила розкладаємо за шарами — роль, факти, заборони, формат відповіді — і перевіряємо конфліктні пари на наборі діалогів. Якщо нове правило суперечить наявному, тест показує це до випуску, а не в розмові з клієнтом.
Як переконатися, що відповіді відповідають правилам?
Для тестування асистента збираємо набір реплік: типові, пограничні й провокаційні. Кожну версію інструкції проганяємо за ним і порівнюємо з еталоном поведінки — де модель відійшла від регламенту, де додала зайве. Окремо дивимося неповне питання і спробу відвести розмову за межі теми.
Оновлення інструкції — це повне перескладання рішення?
Ні. Шари розділені, тому правка правил або тональності не зачіпає підключені джерела даних і логіку інтеграцій. Змінюємо потрібний шар, проганяємо перевірки, випускаємо — попередня версія зберігається, відкат займає хвилини.
Що отримує замовник при передачі проєкту?
Інструкцію з історією версій, набір перевірних діалогів, опис шарів і регламент змін: хто і як править правила, що проганяється перед випуском. Передача не потребує нашої участі — команда продовжує роботу за задокументованою процедурою.
Обговоримо вашу задачу: що підготувати до розмови
Щоб розмова була предметною, готовий документ із вимогами не потрібен — достатньо фрагментів: листувань, прикладів невдалих відповідей, чернеток інструкцій. Чим конкретніші вихідні, тим точніша оцінка проєкту і тим менше припущень у плані робіт.
- 5–10 реальних діалогів: і вдалих, і тих, де асистент пішов не туди.
- Сценарії, де відповідь обов'язково має бути строго визначеною, а де допустима свобода формулювання.
- Глосарій і правила тону: як називаємо продукти, що говоримо клієнту і чого не говоримо.
- Жорсткі обмеження: теми, з яких асистент мовчить і передає діалог людині.
- 3–5 еталонних відповідей — за ними налаштовуємо критерії приймання.
- База знань: регламенти, таблиці, документи, з яких асистент бере факти.
- Канали запуску і ролі: де працює асистент, хто ним користується, хто дивиться історію діалогів.
- Метрики: частка відповідей без правки оператором, частка ескалацій, час першої відповіді.
У відповідь ми повертаємося з оцінкою проєкту і планом робіт: обсяг, етапи, що потрібно від вашого боку на кожному. Окремо проговорюємо критерії приймання — за ними ви будете приймати результат, а не за загальними враженнями.
Підготовка до старту займає небагато: доступи до бази знань, тестовий контур і один відповідальний за приймання з вашого боку. Цього достатньо, щоб почати і не розтягувати погодження.
