Когда вы внедряете нейросеть в рабочий процесс – будь то бот поддержки интернет-магазина, генератор описаний для маркетплейса или скрипт для анализа договоров, – рано или поздно возникает вопрос: какой из двух промптов работает лучше. Опираться на интуицию или метод «на глаз» в работе с LLM нельзя. То, что отлично выглядит на одном примере, может выдать галлюцинацию или сломать формат на десяти других. Чтобы выбрать лучший промпт и доказать это цифрами, нужен A/B-тест.
| Что разберем | Что это даст |
| Как собрать датасет для проверки | Перестанете делать выводы по двум-трем случайным запросам |
| Как оцифровать качество ответа | Сможете сравнивать промпты математически, а не на уровне «нравится/не нравится» |
| Автоматизация: LLM-as-a-judge | Ускорите тесты в десятки раз без ручной вычитки каждого ответа |
| Проблема «переобучения» промпта | Не допустите ситуации, когда тест пройден, а в реальности бот ошибается |
Базовый алгоритм A/B-теста промптов
Чтобы сравнить промпт А и промпт Б, вам нужно прогнать их через один и тот же набор данных и измерить результат по заранее заданным правилам.
1. Зафиксируйте параметры модели
Перед началом теста убедитесь, что обе версии промпта тестируются на одной и той же модели (например, только YandexGPT 3 Pro или только gpt-4o-mini). Строго установите параметр Temperature = 0 (или минимально возможное значение). Это снизит креативность нейросети и сделает ее ответы максимально предсказуемыми. Если тестировать на высокой температуре, разница в ответах может быть вызвана случайностью, а не изменением промпта.
2. Соберите тестовый датасет (Golden Dataset)
Нельзя тестировать промпт на пяти примерах, которые вы только что придумали. Вам нужен набор реальных вводных данных.
- Объем: минимум 30-50 примеров для узкой задачи, от 100 для сложной логики.
- Происхождение: берите реальные данные. Если делаете бота поддержки – выгрузите реальные тикеты из хелпдеска. Если суммаризатор отзывов – спарсите отзывы с Wildberries или Авито.
- Разнообразие: включите в датасет «краевые случаи» (очень короткие запросы, запросы с опечатками, запросы не по теме), чтобы проверить, как промпт справляется с мусором.
3. Определите критерии оценки (Метрики)
Вы должны четко понимать, что делает ответ «хорошим». Метрики бывают двух типов:
- Бинарные (0 или 1): Ответил ли бот на вопрос? Сохранил ли формат JSON? Использовал ли запрещенное слово?
- Шкальные (от 1 до 5): Насколько вежливым был тон? Насколько полно раскрыта тема?
Для A/B-теста бинарные метрики всегда предпочтительнее, так как их проще автоматизировать и в них меньше субъективности.
4. Проведите прогон и подсчитайте Win Rate
Запустите оба промпта на всем датасете. Подсчитайте процент успешных выполнений (Win Rate) для каждого. Победителем объявляется промпт с наибольшим Win Rate. Если промпт А лучше справляется с форматом, но промпт Б точнее по смыслу, вам придется вводить систему весов для метрик в зависимости от бизнес-задачи.
Как оценивать результаты: три сценария
Самая сложная часть A/B-тестирования – оценка сотен ответов. Делать это можно тремя способами в зависимости от задачи.
Сценарий 1: Программная проверка (Exact Match)
Когда подходит: задачи на извлечение данных, форматирование, классификацию.
Как делать: пишется простой скрипт на Python, который проверяет ответ без участия человека или нейросети.
Примеры проверок:
- Промпт должен вернуть только валидный JSON. Скрипт пытается сделать json.loads(). Если ошибка – тест провален.
- Промпт должен определить категорию обращения (возврат, доставка, брак). В датасете уже есть правильные ответы. Скрипт просто сверяет строку ответа со строкой в датасете.
- Ограничение по длине: скрипт считает количество символов.
Сценарий 2: Ручная разметка (Human Evaluation)
Когда подходит: генерация креативных текстов, сложные тональности бренд-войса, начальные этапы разработки промпта.
Как делать: ответы обоих промптов выгружаются в таблицу «вслепую» (разметчик не должен знать, где промпт А, а где Б). Эксперт ставит оценки по заданным критериям.
Ограничение: это медленно и дорого. Подходит для датасетов не более 50-100 строк.
Сценарий 3: Нейросеть-судья (LLM-as-a-judge)
Когда подходит: массовое тестирование смысловых ответов, саммаризации, работы с контекстом (RAG).
Как делать: вы берете более мощную и дорогую модель, чтобы она оценивала ответы дешевой и быстрой модели. Например, тестируете промпты для GPT-3.5 или GigaChat Lite, а судьей назначаете Claude 3.5 Sonnet или GPT-4.
Как настроить: судье нужен свой собственный жесткий промпт. В нем вы передаете исходный текст, правильный ответ (если есть), ответ промпта А и ответ промпта Б.
Шаблон промпта для судьи:
«Ты – беспристрастный оценщик. Твоя задача – сравнить два ответа на один и тот же запрос пользователя.
Запрос пользователя: [текст запроса]
Ответ А: [текст ответа А]
Ответ Б: [текст ответа Б]
Критерии оценки:
- Точность: содержит ли ответ фактические ошибки?
- Тон: ответ должен быть вежливым, но без излишнего заискивания.
- Краткость: ответ не должен содержать воды.
Оцени оба ответа и выбери победителя. Верни ответ строго в формате JSON: {«winner»: «A» | «B» | «Tie», «reason»: «краткое объяснение»}.»
Частые ошибки и точки провала
Изменение нескольких переменных одновременно
Если вы в промпте Б переписали системную инструкцию, добавили два новых примера (few-shot) и изменили формат вывода, вы не узнаете, что именно улучшило (или ухудшило) результат.
Как избежать: меняйте только один смысловой блок за итерацию. Добавили примеры – протестировали. Изменили тон – протестировали.
Оценка на обучающей выборке (Overfitting промпта)
Выделив 20 сложных примеров, вы начинаете подгонять промпт так, чтобы он идеально решал именно их. Промпт начинает обрастать костылями вроде «Если пользователь спрашивает про доставку в Саратов, отвечай так…». При запуске в продакшен промпт ломается на новых запросах.
Как избежать: разделите датасет. Используйте 50 примеров для отладки и изменения промпта. Оставьте еще 50 «секретных» примеров (Holdout set) исключительно для финального A/B-теста. Если на отладочной базе промпт работает на 95%, а на секретной на 60% – вы переобучили промпт.
Использование синтетических данных
Просить саму нейросеть сгенерировать 100 примеров запросов пользователей для тестирования – плохая идея. LLM генерирует слишком чистые, логичные и грамматически правильные запросы. Реальные люди пишут без знаков препинания, обрывками фраз и с опечатками.
Как избежать: собирайте только реальные логи из ваших систем.
Ограничения: когда A/B-тест может обмануть
Недетерминированность даже при Temperature 0
Многие коммерческие API (особенно OpenAI) могут выдавать слегка разные ответы даже при нулевой температуре из-за особенностей вычислений на GPU. Если разница в Win Rate между промптами составляет 1-2%, считайте, что это статистическая погрешность (Tie), а не победа одного из вариантов.
Конфликт длины и внимания (Lost in the middle)
Вы добавили в промпт Б объемный блок с правилами компании. Промпт стал в два раза длиннее. Тест показывает, что нейросеть начала игнорировать инструкцию по формату, которая написана в самом начале. Дело не в том, что формулировка промпта Б хуже. Дело в том, что из-за раздутого контекстного окна модель «забыла» начало инструкции.
Решение: если тестируете длинный промпт, всегда дублируйте критически важное ограничение (например, «ВЕРНИ ТОЛЬКО JSON») в самом конце промпта.
В чем технически проводить тесты
Вам не обязательно писать инфраструктуру с нуля. Используйте подходящий инструмент:
- Google Таблицы / Excel: подходит для старта. В одной колонке запросы, в двух других – формулы с вызовом API (через расширения вроде GPT for Sheets) для промпта А и Б. Оценка производится визуально или формулами (если нужно найти конкретное слово в ответе).
- Promptfoo: бесплатный open-source инструмент, ставший стандартом индустрии. Запускается в консоли, берет промпты из файлов, прогоняет через датасет (CSV или JSON) и выдает удобную таблицу с метриками и подсветкой победителя. Умеет сравнивать модели разных провайдеров параллельно.
- LangSmith / Phoenix: тяжелые платформы для мониторинга LLM-приложений. Имеют встроенные модули для A/B-тестирования, хранения датасетов и настройки пайплайнов LLM-as-a-judge. Стоит внедрять, если у вас сложный RAG или агенты.
Коротко о главном
- Всегда фиксируйте температуру на нуле перед началом тестов.
- Тестируйте промпты только на реальных пользовательских данных.
- Для выбора победителя используйте четкие бинарные метрики или точное совпадение форматов.
- Чтобы не читать сотни ответов вручную, напишите промпт для «модели-судьи» и поручите проверку ей.
- Оставляйте часть датасета скрытой от разработчика промпта, чтобы проверять финальный результат на чистых данных.
