Почему «чуть поправили промпт» — тоже релиз

В ИИ-сервисе результат зависит не только от кода. На ответы влияют инструкция, модель и её версия, параметры генерации, поиск по базе знаний, шаблоны данных, инструменты агента и правила передачи задачи человеку. Любое изменение способно поменять то, что получает клиент или сотрудник.

Поэтому обновление промпта нельзя считать безобидной правкой текста. Например, просьба «отвечай подробнее» может улучшить консультации, но одновременно увеличить стоимость, добавить лишние обещания или заставить помощника увереннее отвечать там, где документов недостаточно. Чем важнее действие модели, тем меньше оснований выпускать изменение сразу на весь поток.

У небольшого бизнеса при этом нет необходимости копировать процессы крупной платформенной команды. Нужен компактный, повторяемый контур: зафиксировать текущую версию, проверить кандидата на типовых и рискованных примерах, включить его на ограниченной доле задач, наблюдать за результатом и иметь простой откат.

Начните с результата процесса

До тестирования сформулируйте, что именно должно стать лучше. «Ответы должны быть качественнее» не помогает принять решение. Операционное требование должно описывать наблюдаемое поведение и цену ошибки.

Для помощника отдела продаж это могут быть такие критерии:

  • не выдумывает наличие товара и сроки поставки;
  • отвечает по актуальному прайс-листу и указывает, когда данных не хватает;
  • не раскрывает сведения о других клиентах;
  • передаёт менеджеру нестандартный запрос;
  • укладывается в приемлемое время и бюджет на одну обработку.

Для агента, который создаёт черновик заявки, добавьте контроль формата, обязательных полей и запрет на отправку без подтверждения сотрудника. Для поиска по внутренним инструкциям проверяйте не только полезность формулировки, но и наличие опоры на нужный документ.

Разделите критерии на три группы:

1. **Критические запреты.** Утечка данных, выдуманный финансовый факт, действие без разрешения. Один такой провал может быть достаточной причиной остановить выпуск.
2. **Качество.** Полнота, релевантность, правильная маршрутизация, понятный отказ.
3. **Эксплуатация.** Время ответа, доля эскалаций, число повторных вызовов, стоимость и нагрузка на сотрудника.

Это не обязательно превращать в универсальную сумму баллов. Сначала зафиксируйте пороги для критических ошибок; средний балл не должен скрывать опасный единичный случай.

Соберите небольшой, но честный тестовый набор

Возьмите реальные типы обращений или документов из процесса и обезличьте данные. Начать можно с 30–100 примеров, если это позволяет увидеть разные сценарии; это практический стартовый диапазон, а не статистическая гарантия. Включите обычные случаи, редкие исключения, неполный ввод, опечатки, конфликтующие сведения и вопросы вне компетенции помощника.

Для каждого примера сохраните:

  • вход и нужный контекст, который система должна была найти;
  • ожидаемый результат или список обязательных признаков;
  • метку риска: обычный, чувствительный, требующий передачи человеку;
  • критерий проверки и, где нужно, короткое объяснение эксперта.

Не делайте эталоном только один «идеальный ответ». В поддержке формулировка может меняться, а факты, ограничения и дальнейшее действие — оставаться правильными. Для таких задач удобнее проверять конкретные свойства: есть ли ссылка на источник, не обещан ли несуществующий срок, заполнены ли обязательные поля, корректно ли выбрана очередь.

Для точных полей используйте программные проверки: формат даты, допустимые значения, наличие обязательных данных. Для смысловой оценки можно применить экспертную проверку или отдельного оценщика, но автоматическая оценка тоже ошибается. Периодически сверяйте её решения с человеком, особенно на спорных и рискованных случаях.

Сравнивайте кандидата с текущей версией

Сначала прогоните один и тот же набор через действующий вариант и кандидата. Сравнивайте не только общий процент успешных ответов: смотрите каждый важный критерий и отдельные группы сценариев.

Полезная таблица результата выглядит просто:

| Проверка | Сейчас | Кандидат | Порог |
|---|---:|---:|---:|
| Критические нарушения | 0 | 0 | строго 0 |
| Правильная маршрутизация | 91% | 94% | не ниже текущего |
| Ответ с подтверждением источником | 86% | 88% | не ниже 85% |
| Средняя стоимость задачи | 7 ₽ | 9 ₽ | не выше лимита |
| Передача сотруднику | 12% | 16% | разбирать рост |

Цифры здесь лишь пример формы сравнения, не отраслевой норматив. Важно оценить, стоит ли улучшение качества дополнительных затрат и не покупается ли оно ухудшением безопасности.

Сохраняйте набор проверок и версии рядом с релизом. Если позже появится ошибка, команда сможет понять, какое изменение предшествовало регрессии. Документация OpenAI по eval-процессу описывает постановку цели, подготовку данных, критерии и повторное сравнение как основу оценки. Инструмент можно выбрать любой подходящий: таблица с ручной проверкой, собственный скрипт, тестовый стенд или специализированная система.

Выпускайте по ступеням, а не одним переключателем

После тестового набора проверьте кандидата в staging или на копии процесса. Синтетические примеры полезны для проверки формата и крайних случаев, но не заменяют обезличенные реальные запросы. Убедитесь, что тестовая среда не может отправить клиенту письмо, изменить заказ или записать данные в рабочую CRM.

Затем используйте ограниченный запуск:

  • **Теневой режим.** Кандидат готовит ответ параллельно, но пользователю отвечает старая версия; человек сравнивает результаты.
  • **Малая канарейка.** Кандидат обслуживает небольшой сегмент низкорисковых обращений, например часть внутренних запросов.
  • **Расширение.** Доля растёт только после проверки качества, ошибок, затрат и нагрузки на сотрудников.

Если система выполняет действия, а не только предлагает текст, начните с рекомендаций или черновиков. Отправку письма, изменение реквизитов, возврат денег или запись в учётную систему оставляйте за человеком, пока процесс и полномочия не проверены.

Не смотрите только на среднее. Отслеживайте долю ошибок, эскалаций, пустых ответов и исправлений сотрудником; задержки и стоимость на завершённую задачу; жалобы и случаи, когда модель действовала без достаточного основания. Сравнивайте сегменты отдельно: общий показатель может скрыть, что новая версия хорошо работает на типовых обращениях и проваливается на возвратах или гарантийных вопросах.

План отката должен быть короче плана совещания

До выпуска назначьте владельца решения, срок наблюдения и условия остановки. Укажите, кто и как возвращает прежнюю версию промпта, модели, параметров или маршрутизации. Проверьте откат заранее в тестовой среде. Если версия хранится отдельно от кода, зафиксируйте точный идентификатор и способ переключения; если всё находится в конфигурации приложения, сохраните предыдущий проверенный пакет.

Остановите расширение или вернитесь назад, если:

  • проявилась критическая ошибка или нарушение доступа;
  • качество по важному сценарию упало ниже заранее установленного порога;
  • выросли затраты либо время так, что бизнес-процесс перестал быть приемлемым;
  • человеку приходится исправлять больше результатов, чем до изменения.

Порог должен зависеть от процесса. Для черновика внутреннего ответа допустима одна терпимость к ошибке; для начисления суммы или изменения договора — совсем другая. Откат — не признание поражения, а штатный механизм контроля изменений.

Где здесь промпт-менеджмент

Если инструкции меняются часто, храните версии отдельно от прикладного кода и связывайте их с результатами проверок. В Langfuse, например, версии промптов имеют историю, а метки могут указывать на staging и production; возврат к прежней версии выполняется переназначением метки. Это иллюстрация подхода, а не обязательный выбор продукта: тот же принцип можно реализовать в Git, конфигурационном хранилище или внутреннем сервисе.

Для локальной модели схема не меняется. В тесте укажите точную версию весов, квантование, шаблон чата, системную инструкцию, параметры генерации и версию поискового индекса. Если поменять модель и промпт одновременно, при неудаче будет трудно понять причину. Лучше менять по одному фактору или явно сравнивать комбинации.

Учитывайте и задержку распространения конфигурации: кэш или долгоживущий процесс могут ещё использовать прежний промпт. Проверяйте фактически применённую версию в журнале обработки, а не только то, что написано в панели управления.

Экономика небольшого контура

Владельцу процесса не нужна дорогая платформа, чтобы начать. Минимум — человек, который отвечает за бизнес-критерии; разработчик или администратор, который умеет переключить версию; обезличенная выборка; журнал с идентификатором версии и итогом проверки.

Учитывайте полную стоимость изменения:

  • подготовка и разметка примеров;
  • вызовы модели при тестировании и в работе;
  • ручная проверка и исправление;
  • повторные запросы и эскалации;
  • поддержка набора тестов и инфраструктуры.

Оценивать нужно стоимость успешно завершённой задачи, а не цену одного вызова модели. Дешёвый кандидат, который чаще передаёт запрос человеку, может оказаться дороже. И наоборот, более дорогой ответ оправдан, если он заметно снижает риск ошибки или экономит время специалиста — это следует подтвердить измерением.

План на первую неделю

  • Выберите один процесс и владельца результата.
  • Опишите 3–5 критичных критериев и пороги остановки.
  • Соберите и обезличьте небольшую выборку типовых и рискованных случаев.
  • Сохраните текущую версию как контрольную точку.
  • Сравните кандидата и действующий вариант на одной выборке.
  • Проведите теневой запуск и разберите расхождения с сотрудником.
  • Расширяйте применение постепенно; заранее проверьте откат.

Итоговый принцип прост: не спрашивайте «стал ли ответ красивее?». Спрашивайте, выполняет ли система нужную задачу при приемлемом риске, цене и объёме ручной работы — и сможете ли вы быстро вернуть прежнее поведение. Так выпуск изменений в ИИ становится управляемым процессом.