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 эталонных ответов — по ним настраиваем критерии приёмки.
- База знаний: регламенты, таблицы, документы, из которых ассистент берёт факты.
- Каналы запуска и роли: где работает ассистент, кто им пользуется, кто смотрит историю диалогов.
- Метрики: доля ответов без правки оператором, доля эскалаций, время первого ответа.
В ответ мы возвращаемся с оценкой проекта и планом работ: объём, этапы, что потребуется от вашей стороны на каждом. Отдельно проговариваем критерии приёмки — по ним вы будете принимать результат, а не по общим впечатлениям.
Подготовка к старту занимает немного: доступы к базе знаний, тестовый контур и один ответственный за приёмку с вашей стороны. Этого достаточно, чтобы начать и не растягивать согласования.
