Настройка A/B-тестирования AI-промптов под ключ

Почему A/B тестирование промптов даёт ложные выводы

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

Вторая причина — малый объём выборки. На двух-трёх десятках примеров разница в доле удачных ответов тонет в этом шуме: чтобы уверенно различить прирост в несколько процентных пунктов, нужны сотни независимых запросов, а не десятки. Чем меньше выборка, тем выше шанс, что лидер определится броском монеты и повторить его результат на новых данных не получится.

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

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

Итог предсказуем: в работу уходит случайный вариант, а реальное улучшение откатывают как «не сработавшее». Разбираем, как поставить A/B тестирование промптов так, чтобы ложные выводы не проходили повторную проверку.

Что даёт управляемый контур оценки качества ответов

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

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

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

Воспроизводимость — главный эффект: через месяц можно повторить тот же прогон на той же выборке и понять, что именно изменило результат — новая версия инструкции, обновление модели или состав запросов. Это превращает настройку промптов из ручной подгонки в инженерный процесс, где у каждого изменения есть проверяемый след.

Режимы A/B тестирования промптов: прогон, сплит, теневой запуск

Выбор режима зависит от двух вещей: есть ли архив реальных обращений для сравнения и можно ли показывать новый ответ части пользователей. Отсюда офлайн-прогон по сохранённым диалогам и онлайн-сплит, где две версии промпта делят трафик. Теневой запуск стоит между ними — новый вариант считается параллельно с текущим, но ответы не показываются, поэтому сравнение идёт без риска для пользователей.

Режимы не заменяют, а дополняют друг друга: теневой запуск отсеивает заведомо слабые версии, офлайн-прогон считает метрики на истории, онлайн-сплит подтверждает их на живых обращениях, а раскатка доводит победителя до всей аудитории долями — от 5% до 100%.

Выбор режима определяет и объём подготовки: для прогона собираем и размечаем корпус диалогов, для сплита настраиваем разбиение групп и сбор метрик. Если архива обращений ещё нет, начинаем с теневого запуска — он накапливает данные, не влияя на опыт пользователей.

От аудита до передачи: этапы инженерной работы

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

1. Аудит прогона. Разбираем, как формируются промпты, откуда берутся входные данные, что уже логируется и в каком виде хранятся ответы. На выходе — карта процесса и список мест, где варианты расходятся неуправляемо.
2. Критерии сравнения. До запуска фиксируем основную метрику и правило остановки: доля ответов, прошедших проверку по разметке, доля отказов и повторов, устойчивость формулировки на перефразированных входах. Остальные показатели идут контрольными.
3. Схема проверки. Определяем, как варианты делят входной поток: одна и та же выборка для A и B, случайный порядок, изоляция — за прогон меняется строго одна часть промпта. Тогда результат относят к изменению, а не к разнице во входных данных.
4. Настройка запуска. Логируем версию промпта вместе с ответом и параметрами вызова, чтобы любой результат воспроизводился и объяснялся, а не оставался единичной удачей.
5. Отложенная выборка. Держим отдельный набор примеров, не участвовавший в подборе формулировок, и проверяем победителя только на нём. Это отсекает варианты, выигравшие за счёт подгонки под знакомые случаи.
6. Передача команде. Отдаём регламент прогона, шаблон отчёта, описание метрик и правило отката на предыдущую версию — следующий вариант вы проверяете сами.

Артефакты: наборы тестов, правила оценки, регламент прогонов

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

Что остаётся у вас на руках:

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

Кейс: сократили долю неудачных ответов и время проверки

Исходно это была первая линия поддержки: несколько десятков тысяч диалогов в месяц по заказам и возвратам. Промпт правили по интуиции прямо в боевом конфиге, откат держали в переписке. Доля неудачных ответов держалась около 18% — ассистент уверенно называл неверные сроки доставки и предлагал условия возврата, которых не было.

Проверка занимала два дня на вариант: сорок диалогов прогоняли вручную, оценивал один человек, спорные случаи повторно не размечали. Сравнивать правку было не с чем — с памятью, а не с числами.

Что изменили

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

Что стало

Доля неудачных ответов упала с 18% до 6%, эскалации на оператора — с 27% до 14%. Время проверки варианта сократилось с двух дней до 45 минут: прогон идёт ночью, утром готов отчёт с разбивкой по рубрикам и списком диалогов, где варианты разошлись.

Поддержка ассистента стала регламентом: каждую неделю в набор добавляют диалоги, где он ошибся в бою, и прогоняют по ним предыдущий вариант. Регресс виден до выкатки, а не после жалоб.

Чем отличается офлайн-оценка от онлайн-сплита в вашем контуре

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

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

На практике это не альтернатива, а последовательность. Офлайн отсеивает явные регрессии и дешёвые правки, онлайн подтверждает эффект на живых данных, после чего версию раскатывают на весь трафик.

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

Технические сомнения: воспроизводимость, разметка, дрейф данных

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

Как понять, что разница между вариантами — не шум?

Один прогон на варианте ничего не доказывает: при ненулевой температуре модель отвечает по-разному. Считаем дисперсию по повторным прогонам на одном наборе, сравниваем варианты парно на идентичных примерах и смотрим доверительный интервал. Перекрываются — фиксируем ничью, а не «победителя».

Что делать с дрейфом данных?

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

Как размечать и не утонуть в расхождениях?

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

Что прислать для старта и как мы вернёмся с оценкой

Чтобы старт работ не растянулся на переписку, хватает одного письма с вводными — остальное уточним в разговоре. Чем конкретнее исходные данные, тем точнее оценка объёма: видно, сколько промптов в контуре, по каким метрикам сравнивать варианты и есть ли на что опираться при выборе победителя. Ниже — минимум, которого достаточно для обсуждения задачи.

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

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