«Когда я попробовал, выглядело хорошо» — так большинство регрессий промптов попадает в продакшен. Тестирование и оценка промптов заменяют это доказательствами: фиксированным набором входов, определением правильного вывода и проверкой, которая запускается при каждом изменении промпта.
Эти два термина пересекаются. Оценка — это измерение того, насколько хорош промпт или его вывод. Тестирование — это автоматический запуск таких измерений и сбой, когда порог не достигнут.
Две вещи, которые можно оценивать
Сам промпт. Ясен ли он, полон, согласован и безопасен в том виде, как написан? Это статический анализ. Он не требует вызова модели, поэтому мгновенен, бесплатен и каждый раз даёт один и тот же результат.
Вывод модели. Верен ли ответ для этого промпта и этого ввода? Для этого нужны вызовы модели и способ судить о результате.
Они ловят разные проблемы, и хороший процесс использует обе. Статические проверки запускаются при каждом нажатии клавиши и каждом коммите. Оценка вывода запускается, когда изменение может повлиять на поведение.
Слой 1: статические проверки промпта
Статическая проверка читает текст промпта и ищет известные дефекты:
- Не указана цель или нет формата вывода.
- Расплывчатые слова и размеры без чисел.
- Инструкции, которые противоречат друг другу или повторяются.
- Переменные шаблона без разделителей.
- Формулировки инъекций, учётные данные или персональные данные.
- Число токенов выше бюджета.
Именно это делает оценка промптов PromptFlowEngine. Оценка — это 100 минус фиксированный штраф за каждую находку (30 за критическую, 10 за предупреждение, 3 за информационную), с потолком 50, если есть хоть одна критическая, и с той же арифметикой для каждого из восьми измерений. Поскольку формула опубликована, любое изменение оценки всегда прослеживается до конкретной находки.
Статическая оценка не говорит, верен ли ответ модели. Она говорит, даёт ли промпт модели честный шанс.
Слой 2: тестовый набор
Тестовый набор — это список входов с ожиданиями. Начинайте с малого.
| Вид случая | Зачем |
|---|---|
| Типичные входы | Подтверждает, что основной путь работает |
| Граничные случаи | Пустой, очень длинный, не тот язык, искажённый |
| Состязательные входы | Попытки переопределить инструкции |
| Прошлые сбои | Каждая найденная ошибка становится постоянным тестом |
Двадцать хорошо подобранных случаев лучше двухсот почти одинаковых. По возможности берите их из реального трафика, удалив персональные данные.
Слой 3: решаем, проходит ли вывод
Используйте самый дешёвый метод, способный судить об этом свойстве.
Проверки кодом. Детерминированные и бесплатные. Используйте их везде, где возможно.
- Разбирается как JSON и соответствует схеме.
- Содержит или не содержит заданную строку.
- Длина в допустимых пределах.
- Метка равна ожидаемой.
- Числовой ответ в пределах допуска.
Сравнение с эталоном. Сравнение с заведомо хорошим ответом по точному совпадению или мере сходства. Подходит для извлечения и классификации, слабо для свободного письма.
Оценка моделью. Вторая модель судит о выводе по критериям. Используйте её для качеств, которые код проверить не может: верность источнику, тон, полнота.
You are grading an answer against a source document.
Does the answer contain any claim not supported by the source?
Reply with a JSON object: {"unsupported_claims": [string], "pass": boolean}.
<source>{{source}}</source>
<answer>{{answer}}</answer>
Оценивающие модели сами являются промптами, со своими режимами сбоев. Ограничивайте каждый критерий одним вопросом, требуйте доказательства до вердикта и проверяйте оценщика на выборке человеческих суждений, прежде чем ему доверять.
Проверка человеком. Эталонный стандарт и самый дорогой. Используйте её для калибровки автоматических методов и просмотра выборки продакшен-вывода.
Метрики, которые стоит отслеживать
| Метрика | О чём говорит |
|---|---|
| Доля прохождения | Доля тестовых случаев, отвечающих ожиданиям |
| Валидность формата | Доля выводов, которые разбираются |
| Верность | Доля ответов, подкреплённых предоставленным контекстом |
| Точность отказов | Отказывает там, где надо, отвечает там, где надо |
| Согласованность | Совпадение результатов повторных запусков одного ввода |
| Токены и задержка | Цена получаемого качества |
Сообщайте долю прохождения вместе с числом случаев. «90 %» на 10 случаях — это один сбой.
Недетерминизм
Один и тот же промпт и ввод могут давать разные выводы. Учитывайте это:
- Ставьте низкую температуру для задач, где нужна согласованность.
- Запускайте каждый случай несколько раз и сообщайте долю прохождения, а не единичный результат.
- Проверяйте свойства («упоминает срок возврата»), а не точный текст.
- Фиксируйте версию модели и перезапускайте набор при её смене.
Регрессионное тестирование в CI
Тесты защищают вас, только если запускаются автоматически.
При каждом коммите: статические проверки. Они быстры и не требуют ключа API. Контрольная точка тестирования промптов роняет pull request, когда файл промпта опускается ниже минимальной оценки, превышает лимит токенов или содержит критическую находку вроде утёкшего ключа.
- run: promptflow check "prompts/**/*.md" --min-score 70 --max-tokens 1500
При изменении промпта или модели: тестовый набор вывода с порогом доли прохождения.
По расписанию: полный набор против действующей модели, чтобы поймать изменения на стороне провайдера.
PromptFlowEngine покрывает первое из перечисленного. Он не запускает промпты на модели; для оценки вывода нужны ваш собственный исполнитель тестов и доступ к модели.
Сравнение двух версий
Выбирая между черновиками, сравнивайте их на одних и тех же входах и смотрите, что изменилось, а не только итоги: какие случаи перешли из прохождения в провал, как изменились токены и появились ли новые проблемы. Режим сравнения в рабочем пространстве показывает различия двух промптов по качеству, токенам и стоимости и перечисляет находки, которые каждая версия устраняет или вносит.
Минимальный процесс для начала
- Запустите статическую проверку и исправьте предупреждения.
- Напишите 20 тестовых случаев с ожиданиями.
- Добавьте проверки кодом для формата и обязательного содержимого.
- Запишите базовую долю прохождения.
- Привяжите pull request к статической проверке.
- Перезапускайте тестовый набор при каждом изменении промпта или модели.
О том, как использовать эти результаты для улучшения промпта, см. оптимизацию промптов. О том, как держать версии и результаты в порядке, см. управление промптами.