Этап 9 — Оценка качества промптов
Если нет измерения качества, prompt engineering превращается в субъективные споры.
Темы этапа
- Детерминированность ответов
- Повторяемость
- Метрики качества
- Prompt versioning
Детерминированность
Нужна не абсолютная одинаковость, а контролируемый разброс.
Ты должен знать, какие задачи требуют стабильности, а какие допускают вариативность.
Повторяемость
Тест должен быть воспроизводим:
- фиксированный набор кейсов,
- фиксированные критерии,
- сравнение версий prompt-а, а не «ощущений».
Метрики
Минимальный набор:
- accuracy/task success,
- format validity,
- policy compliance,
- latency/cost.
Для разных продуктов веса метрик разные.
Prompt versioning
Каждое изменение prompt-а должно иметь:
- версию,
- описание гипотезы,
- результаты до/после,
- решение rollout/rollback.
Как строится evaluation loop
Оценка начинается до переписывания prompt-а. Сначала собирают репрезентативные кейсы: простые, edge cases, известные сбои и ценные пользовательские сценарии. Затем для каждого кейса определяют, что считается правильным ответом. Только после этого prompt меняют и сравнивают версии. Если сначала редактировать, а потом придумывать критерии успеха, evaluation обычно оправдывает изменение, а не проверяет его.
Полезный benchmark небольшой, но стабильный. Он должен быть достаточно широким, чтобы ловить регрессии, но не таким тяжёлым, чтобы его никто не запускал. Human review может быть частью цикла, но критерии всё равно должны быть записаны. Для структурированных ответов автоматизируют format checks. Для фактических ответов проверяют grounding. Для support или учебного контента проверяют полезность относительно цели ученика.
| Элемент оценки | На какой вопрос отвечает | Пример сигнала |
|---|---|---|
| Regression cases | Не сломалось ли старое поведение? | Те же pass/fail критерии |
| Edge cases | Удерживает ли prompt границы? | Безопасный отказ или fallback |
| Format tests | Можно ли использовать ответ машинно? | Успешный parser/schema |
| Cost и latency | Доступно ли качество по цене? | Бюджет токенов и времени |
Вывод этапа
Хороший prompt — это не «красивый», а измеримо лучший на контрольной выборке.
Объяснение для новичка
Оценка prompt-а нужна потому, что один удачный ответ ничего не доказывает. Модель может хорошо ответить на demo-case и провалиться на соседнем реальном запросе. Поэтому prompt нужно проверять на наборе кейсов: обычные случаи, сложные случаи, известные ошибки, пустые данные, конфликтующие инструкции и важные пользовательские сценарии.
Evaluation dataset — это набор входов и ожидаемых критериев. Не всегда нужно иметь идеальный «единственный правильный ответ». Иногда достаточно критериев: JSON валиден, есть все обязательные поля, нет выдуманных источников, ответ полезен новичку, соблюдён лимит длины. Для каждого критерия нужно понимать, кто проверяет: автоматический тест, человек-reviewer или отдельная модель-judge.
Итерация должна проверять гипотезу. Плохой подход: «я переписал prompt, стало красивее». Хороший подход: «я добавил examples, ожидаю рост format validity с 82% до 95% без ухудшения factuality». Тогда можно сравнить baseline и новую версию. Если новая версия лучше только на одном кейсе, но ломает регрессионный набор, её нельзя считать улучшением.
Мини-сценарии из практики
- Улучшение промпта «на глаз» ломает другие кейсы: нет регрессионного набора тестов.
- Метрики растут, а пользовательская ценность нет: измеряются суррогатные показатели, а не бизнес-качество.
- Версия промпта изменилась, но команда не понимает, что именно дало эффект: отсутствует дисциплина versioning.
Быстрые правила принятия решений
- Любое изменение промпта проверяй на фиксированном наборе контрольных кейсов.
- Метрики качества связывай с продуктовой целью, а не с удобством измерения.
- Каждую версию промпта сопровождай changelog и ожидаемым эффектом.
Вопросы для самопроверки
- Почему без регрессионного набора нельзя объективно улучшать промпты?
- Какие метрики действительно отражают качество для твоего сценария?
- Что должно фиксироваться в prompt versioning кроме текста промпта?