A/B тесты промптов агентов: как не сломать продакшен

Вы поменяли одну строчку в системном промпте агента поддержки — добавили «отвечай кратко» — и залили в прод. Через неделю жалоб стало больше: клиенты пишут, что бот теперь обрывает ответы на середине. Стало хуже или это случайность? Без замера ответа нет. Промпт — это конфигурация поведения продукта, и катить его без проверки так же рискованно, как деплоить непротестированный код. Разница в том, что для кода у вас есть юнит-тесты, а для промпта — интуиция.

Почему промпт нельзя катить «на глаз»

Изменение в промпте не бинарно. Новая формулировка редко ломает всё — она сдвигает распределение ответов. Часть запросов обрабатывается лучше, часть хуже, и суммарный эффект виден только на объёме. Плюс LLM недетерминированы: один и тот же вход при temperature выше нуля даёт разные выходы. Поэтому «я прогнал десять примеров, вроде норм» — не доказательство, а иллюзия контроля.

A/B тест снимает этот вопрос. Вы пускаете часть трафика на вариант A (текущий промпт), часть — на вариант B (новый), и сравниваете метрики на живых пользователях. Ключевое слово — живых: датасет из офиса никогда не покроет всё, что придумают реальные клиенты.

Промпт без метрики — это мнение. Промпт с метрикой и достаточной выборкой — это решение. Всё остальное — вера в то, что «так лучше звучит».

Что вообще измерять

Главная ловушка — мерить «качество ответа» абстрактно. У агента почти всегда есть бизнес-задача, и метрику надо привязывать к ней. Разложите на два слоя.

Продуктовые метрики

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

Технические метрики

• Стоимость на диалог — токены на входе и выходе умножить на цену модели. Новый промпт на 300 слов длиннее старого — это прямые деньги на каждом запросе.
• Латентность — время до первого токена и полного ответа.
• Доля успешных вызовов инструментов — если агент дёргает API, считайте, сколько вызовов прошли без ошибки формата.
• Частота отказов и галлюцинаций — здесь без выборочной ручной разметки или отдельной модели-оценщика не обойтись.

Как устроить сам эксперимент

Схема повторяет классический продуктовый A/B, но с поправками на природу LLM.

1. Зафиксируйте гипотезу и метрику заранее. «Новый промпт поднимет решаемость с сохранением стоимости» — проверяемо. «Ответы станут лучше» — нет.
2. Разбейте трафик по стабильному ключу. Делите по идентификатору пользователя или сессии, а не по каждому запросу, иначе один человек в одном диалоге получит разные версии бота.
3. Держите остальное неизменным. Одна и та же модель, те же настройки семплирования, тот же набор инструментов. Меняете только промпт — иначе не поймёте, что дало эффект.
4. Наберите выборку до значимости. Малые сдвиги метрик требуют тысяч диалогов. Останавливаться на первом «кажется, B выигрывает» — способ обмануть себя.
5. Логируйте всё. Полный вход, выход, версию промпта, использованные инструменты. Без логов вы не разберёте, почему вариант проиграл.
6. Раскатывайте постепенно. 5% трафика, потом 50%, потом весь. Так плохой вариант заденет меньше людей.

Онлайн против оффлайна: не одно вместо другого

A/B в проде — не единственный инструмент, и запускать его на каждую правку запятой нерационально. До прода есть оффлайн-оценка: прогон нового промпта на зафиксированном датасете диалогов с автоматической или ручной проверкой. Она дешевле и быстрее, но не видит реального поведения пользователей.

Рабочая связка обычно такая: оффлайн отсекает явные регрессии, LLM-as-a-judge^* сужает круг кандидатов, а A/B в проде выносит финальный вердикт по деньгам и решаемости.

Кому это пригодится и кому нет

Пригодится:

• Командам с агентом в поддержке или продажах и заметным потоком диалогов — сотни в день и больше. Здесь набор значимой выборки занимает дни, а цена ошибки в промпте измеряется в реальной конверсии и счетах за токены.
• Тем, кто часто трогает промпты: меняет тон, добавляет инструменты, оптимизирует стоимость. Регулярные правки без замера накапливают незаметную деградацию.
• Продуктам, где ответ агента ведёт к деньгам: рекомендация тарифа, оформление заявки, апсейл.

Не пригодится или преждевременно:

• Внутренним прототипам и демо, где пользователей десяток. Выборки не хватит для значимости — оффлайн-прогона достаточно.
• Разовым скриптам и пайплайнам без живого пользователя на другом конце: там нет «поведения», которое можно сравнить, — сравнивайте на фиксированном датасете.
• Ситуациям, где нет ни одной измеримой метрики. Если вы не можете сказать, что считаете успехом диалога, A/B нечего сравнивать — начните с определения метрики.

Грабли, на которые наступают все

• Подглядывание в результаты. Смотреть на метрику каждый час и останавливать тест, как только B вырвался вперёд, — верный способ поймать ложное срабатывание. Определите размер выборки заранее.
• Оптимизация одной метрики в ущерб другим. «Отвечай кратко» поднимает скорость и режет токены, но роняет решаемость. Всегда держите контрметрику.
• Смешанные изменения. Поменяли промпт и модель одновременно — эффект не разложить.
• Игнор стоимости. Вариант B выигрывает по качеству на 2%, но стоит вдвое дороже. Это не всегда победа.

^* LLM-as-a-judge — приём, когда качество ответа одной модели оценивает другая (или та же) модель по заданным критериям. Ускоряет оценку на объёме, но сам оценщик может быть смещён — например, предпочитать длинные ответы, — поэтому его выводы стоит периодически сверять с ручной разметкой.