A/B-тестирование промптов в AI CareerBot без сюрпризов по API

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

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

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

Что именно тестировали

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

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

Схема получилась такой:

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

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

Вирусный запуск быстро показал цену каждого эксперимента

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

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

Мы добавили три уровня защиты.

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

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

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

Модерация ответа, а не только входа

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

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

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

Это особенно важно в A/B-тестах. Новый системный промпт может улучшить один тип ответов и внезапно испортить другой. Без выходной модерации такой вариант успеет попасть к пользователям в сыром виде.

Почему A/B-тесты промптов требуют продуктовой обвязки

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

Для AI CareerBot инфраструктура A/B-тестирования стала отдельным слоем вокруг LLM-вызовов. В нём есть назначение варианта, сбор метрик полезности, бюджетирование, лимиты, кэш типичных вопросов, модерация выхода и fallback при некорректных ответах.

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