Оценка и итерация промптов

Распространённая ошибка новичков в prompt engineering: написать промпт, проверить на одном-двух примерах, увидеть хороший результат — и считать задачу решённой. Это ловушка.

Один успешный пример ничего не доказывает. LLM — вероятностные модели: один и тот же промпт при разных входных данных даёт разные результаты. Пример, на котором вы тестировали, мог попасть точно в "сильную зону" модели. На production-трафике, где входные данные разнообразны, промпт может деградировать до неприемлемого качества.

Проблема "работает на одном примере" проявляется несколькими способами:

Систематическая оценка решает все эти проблемы. Она превращает субъективное ощущение "промпт хорош" в измеримое, воспроизводимое утверждение с конкретными числами.

Выбор метрики зависит от типа задачи. Универсальных метрик не существует.

Когда модель должна отнести текст к одной из категорий (сентимент-анализ, тематическая классификация, детекция намерений):

Пример: для задачи модерации контента важен recall (не пропустить токсичный контент), даже ценой precision (некоторые ложные срабатывания допустимы).

Когда модель генерирует свободный текст — резюме, переводы, рерайтинг:

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

Схема LLM-as-judge:

Преимущества: понимает нюансы, оценивает следование инструкциям, работает без эталонных ответов (reference-free evaluation). Недостатки: дороже, медленнее, может иметь bias в сторону многословных ответов или ответов "похожих на GPT-4".

Для минимизации bias применяют: оценку с нескольких позиций, pairwise сравнение вместо абсолютных оценок, calibration промпты.

Хороший eval set — половина успеха в оценке промптов.

Размер: минимально значимый размер для базовой оценки — 100 примеров. Для статистически надёжных выводов об улучшении на 2-3% нужно 500-1000 примеров. Для enterprise-систем — тысячи.

Разнообразие: eval set должен покрывать всё распределение реальных входных данных. Типичные пользовательские запросы — безусловно, но также:

Edge cases — особое внимание. Это сценарии, которые редко встречаются, но критически важны: запросы на запрещённый контент (нужно отклонять), очень длинные входные данные, пустые входные данные, противоречивые инструкции.

Баланс: избегайте засилья одного класса или типа задач — eval set должен отражать реальное распределение, а не только "лёгкие" случаи.

Золотой стандарт: эталонные ответы должны быть размечены экспертами, а не автоматически. Для сложных задач — несколько независимых аннотаторов с расчётом inter-annotator agreement (Cohen's kappa).

Regression testing для промптов — это автоматическая проверка, что новая версия промпта не хуже предыдущей по уже решённым задачам.

Проблема без regression testing: вы улучшаете промпт для одного типа запросов и непреднамеренно ухудшаете поведение для других. Без тестов это обнаруживается только в production.

Практическая организация:

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

Хорошая практика: фиксировать не только метрики, но и конкретные примеры, где поведение изменилось. Это помогает понять характер регрессии.

A/B тест для промптов — это контролируемый эксперимент, где часть трафика обрабатывается промптом A (контрольная группа), остальная — промптом B (экспериментальная).

Принципы корректного A/B теста:

Для оценки результатов используйте t-test или bootstrap confidence intervals. Разница считается статистически значимой при p < 0.05.

Сложность A/B тестирования промптов: нелегко получить достаточно трафика для редких задач, и пользовательское поведение может само по себе влиять на результаты (novelty effect).

При масштабировании до нескольких промптов в production необходимы инструменты версионирования.

Минимальный подход: хранить промпты в git как обычный код. Каждый промпт — отдельный файл. Изменения — через pull requests с code review. Это бесплатно и работает для небольших команд.

PromptLayer: платформа для логирования каждого вызова LLM, сравнения версий промптов, отслеживания стоимости. Интегрируется с OpenAI SDK через обёртку. Позволяет видеть, как менялось поведение промпта во времени.

LangSmith (от LangChain): более мощная платформа — трассировка LLM-вызовов, создание datasets для оценки, запуск evaluations, сравнение версий промптов. Особенно удобна при использовании LangChain в стеке.

Что должна давать система управления промптами:

Эффективная итерация — это не случайные изменения, а структурированный процесс:

Типичные улучшения в порядке убывания эффективности: уточнение task description, добавление few-shot примеров для сложных кейсов, добавление негативных примеров, CoT для сложных рассуждений, изменение формата вывода.

Data leakage — ситуация, когда информация из eval set "утекает" в процесс разработки промпта, делая оценку нереалистично оптимистичной.

Как это происходит: разработчик видит конкретные примеры из eval set, знает их правильные ответы и (осознанно или нет) пишет промпт, оптимальный именно для этих примеров. В production, где данные другие, производительность падает.

Защита от leakage: строгое разделение train/eval/test. Eval set используется для итерации промпта. Test set — финальная оценка, используется один раз. Разработчик не должен видеть примеры из test set до финальной оценки.

Overfitting на eval set — более тонкая проблема. Даже без прямого просмотра примеров, если итераций много, а eval set маленький, промпт может "переобучиться" на eval set через множественные сравнения.

Пример: если eval set из 50 примеров, и вы провели 100 итераций, сравнивая варианты — статистически вероятно случайное нахождение "хорошего" промпта для именно этих 50 примеров без реального улучшения.

Защита от overfitting: достаточно большой eval set (500+), использование holdout test set для финального измерения, осторожность с числом итераций относительно размера eval set.

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