A/B-тест промпта или модели: как понять, что сработало

Почему A/B-тест часто врет

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

Самая частая ошибка простая. В варианте A был старый промпт и старая модель, а в варианте B - новый промпт и новая модель. Если результат стал лучше, вы не знаете, что именно сработало. Иногда помогает новый промпт, а модель, наоборот, тянет качество вниз. Иногда происходит обратное.

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

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

Проблема обычно сводится к четырем вещам: в одном запуске меняют промпт и модель, сравнивают разные выборки запросов, не замечают fallback и смотрят только на средний балл.

Среднее значение само по себе часто обманывает. Если 80% простых запросов стали лучше на 3%, а 20% сложных начали проваливаться в два раза чаще, общий результат может выглядеть нормально. Для бизнеса это плохой обмен. Пользователь запомнит не аккуратный рост среднего, а грубую ошибку в важном сценарии.

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

Сначала определите вопрос теста

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

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

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

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

Перед запуском полезно зафиксировать четыре вещи:

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

Формулировка должна быть простой и проверяемой. Например: "Новый промпт выигрывает, если точность растет минимум на 5%, средняя стоимость не растет больше чем на 10%, а 95% ответов приходят быстрее 2 секунд".

После этого тест перестает быть спором по ощущениям. У вас есть не просто "вариант понравился", а решение, которое можно повторить на следующем наборе данных.

Что зафиксировать до старта

Если вы меняете две вещи сразу, тест быстро превращается в спор о догадках. Для честного сравнения сначала заморозьте все, что не относится к гипотезе.

Начните с набора запросов. Он должен быть одинаковым для всех вариантов, в одном порядке и с похожей долей простых, средних и сложных кейсов. Если в одной группе больше коротких вопросов, а в другой - больше длинных диалогов с контекстом, сравнение уже съехало.

Потом зафиксируйте параметры генерации. Температура, top_p, лимит выходных токенов и стоп-последовательности меняют стиль и полноту ответа сильнее, чем кажется. Частая ошибка выглядит безобидно: команда обновляет промпт и заодно поднимает max_tokens, а потом решает, что новый вариант "умнее". На деле ему просто дали больше места для ответа.

Дальше проверьте формат ответа, провайдера, регион обработки, таймауты, ретраи и правила fallback. Если один вариант возвращает свободный текст, а другой строгий JSON, вы уже сравниваете не качество ответа, а удобство парсинга и риск ошибки на выходе. Если один маршрут ходит к одному провайдеру, а второй иногда уходит на резервный путь, тест снова смешивает несколько причин в один результат.

При работе через шлюз вроде AI Router стоит заранее закрепить не только модель, но и фактический маршрут: какой провайдер используется, где исполняется запрос и что происходит при отказе. Иначе часть трафика уйдет по другому пути, и вывод станет мутным.

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

Как разделить влияние промпта, модели и маршрута

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

Рабочий порядок обычно такой:

1. Сначала сравните только два варианта промпта на одной и той же модели и по одному маршруту.
2. Потом оставьте победивший промпт без новых правок и сравните модели в тех же условиях.
3. После этого отдельно проверьте маршрутизацию: прямой вызов, fallback, разные провайдеры или разные регионы.
4. Финальную связку прогоните на новой выборке, которую вы не использовали раньше.

Этот порядок кажется скучным, но он дает чистый вывод. Промпт меняет постановку задачи. Модель меняет стиль и точность ответа. Маршрут меняет провайдера, задержку, лимиты и иногда даже фактическую версию модели. Когда все это смешано, спорить потом можно долго, а доказать почти ничего нельзя.

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

Как провести тест

Не начинайте с пары удобных примеров. Возьмите 100-300 обычных запросов из реальной работы: обращения клиентов, внутренние задачи, длинные и короткие формулировки, простые и спорные случаи. Не отбирайте только "красивые" запросы, иначе тест покажет витрину, а не рабочую картину.

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

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

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

Оценивать ответы лучше по одной шкале для всех прогонов. Подойдет система от 1 до 5 или простое "прошел / не прошел", если критерии строгие. Главное - одна и та же шкала для всех вариантов.

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

Пример из практики

У ритейл-команды был помощник для возвратов. Он отвечал покупателям в чате: какие документы нужны, можно ли вернуть товар, куда везти заказ и что делать, если срок уже на грани. Жалоб было две: ответы выглядели неровно, а в спорных случаях помощник путал правила.

Команда не стала менять все сразу. Она взяла один и тот же набор из 200 реальных обращений, оставила одинаковые метрики и начала с самого простого.

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

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

Третий тест проверял уже не текст и не саму модель, а способ вызова. Команда сравнила прямой запрос к одной модели и маршрут с fallback: сначала быстрый вариант для простых вопросов, потом переход на более сильную модель, если ответ неуверенный или запрос сложный. Качество почти не сдвинулось, зато средняя задержка упала. Простые обращения закрывались быстрее, а сложные не терялись.

Итог получился очень приземленный. Новый промпт улучшил формат и полноту ответа. Новая модель подняла точность. Маршрут с fallback сократил задержку. Если бы команда запустила одно большое обновление, она увидела бы общий рост и не поняла бы, что именно сработало.

Какие метрики смотреть отдельно

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

Поэтому метрики лучше разносить по отдельным столбцам:

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

Полезно смотреть на эти метрики и по типам задач. Извлечение полей из документа и свободный ответ клиенту ведут себя по-разному. Одна и та же модель может аккуратно держать структуру и при этом ошибаться в фактах.

На практике часто побеждает не та версия, у которой самый высокий средний балл, а та, что проходит минимальный порог по каждой группе. Если точность выросла на 2%, но доля сломанного формата подскочила с 1% до 9%, такую версию рано выпускать.

Где чаще всего ошибаются

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

Вторая ошибка - слишком маленькая выборка. На 20 или 30 запросах легко получить красивую картину, которая рассыпается на реальном трафике. Особенно если запросы похожи друг на друга.

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

Еще одна ловушка - слепая вера в средний балл. Допустим, средняя оценка выросла с 4,1 до 4,3. Звучит неплохо. Но если при этом новая версия стала чаще ломать JSON, путать поля или давать опасные ответы на редких сценариях, среднее это скроет.

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

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

Что делать после теста

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

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

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

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

Если вы сравниваете модели и провайдеров через единый OpenRouter-совместимый шлюз, такой как AI Router, полезно хранить в одном месте фактический маршрут, задержку, ошибки и логи по каждому запросу. Это помогает не путать эффект промпта с эффектом маршрутизации и быстрее разбирать спорные случаи.

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