Версионирование и тестирование промптов

Промпт — это код, влияющий на поведение продукта; меняя его «на глаз», легко устроить тихую регрессию.

Eval-набор — набор тестовых входов с ожидаемыми (или оцениваемыми) выходами, на котором измеряют качество промпта при каждом изменении.

Почему «работает на моём примере» недостаточно

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

Eval-набор

Соберите 20–100 репрезентативных входов с эталонами или критериями оценки. Покройте обычные случаи и краевые. Прогоняйте на нём каждую новую версию промпта и сравнивайте метрику.

[
  {"input": "Кнопка оплаты не работает", "expected": "баг"},
  {"input": "Хочу тёмную тему", "expected": "фича"},
  {"input": "Как сменить пароль?", "expected": "вопрос"},
  {"input": "", "expected": "другое"}
]

Как мерить качество

Для текста без единственно верного ответа применяют LLM-as-a-judge: другая модель оценивает ответ по заданным критериям (точность, полнота, тон). Это масштабируемо, хотя и требует калибровки.

Версионирование

Храните промпты в системе контроля версий (или в хранилище промптов) с понятными версиями. Тогда вы можете: сравнить v3 и v4 на eval-наборе, откатиться при регрессе, привязать версию к релизу и понять, какое изменение что улучшило. Документируйте, зачем менялся промпт.

Регрессионная проверка

При каждом изменении прогоняйте eval-набор и сравнивайте с предыдущей версией. Падение метрики хотя бы на части кейсов — повод не катить изменение. Это превращает «магию промптов» в инженерную дисциплину.

Итог

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