Evals: как понять, что промпт вообще работает

Промптинг — один из первых навыков, которые инженеры осваивали в работе с языковыми моделями, и до сих пор один из самых важных для построения работающих AI-систем. Но прежде чем править промпт, нужен способ проверять, стало ли лучше. Этому способу — оценочным наборам, или evals, — и посвящён первый урок.

Два сценария работы над промптом

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

Второй сценарий: вы строите нового агента с нуля, и промпт нужно написать от начала и до конца. В обоих случаях работа начинается с одного и того же вопроса: как понять, что промпт вообще работает — и что очередная правка его улучшает, а не ломает?

Почему промпт ломается после смены модели

Когда вы переходите на другую модель, система может перестать работать по двум разным причинам.

• Модель способна, но ведёт себя иначе. Задача новой модели по силам, просто она по-другому читает те же инструкции. Такое поведение чинится правками промпта.
• Модель слабее. Новая модель не справляется с задачей, и никакой промптинг это не исправит.

Снаружи оба случая выглядят одинаково: «раньше работало, теперь нет». Отличить один от другого можно только с помощью оценочного набора — evals. Набор фиксирует, какие именно случаи перестали проходить, и даёт строгую проверку: действительно ли изменение промпта связано с улучшением результата, а не просто совпало с ним по времени.

Из чего состоит оценочный набор

Оценочный набор — это список тестовых случаев с ожидаемыми ответами, по которому вы прогоняете промпт. Для наглядности возьмём уменьшенный набор из пяти тест-кейсов; в реальных системах их намного больше. Важно не количество, а то, что набор покрывает три типа случаев.

1. Контрольный случай. Однозначная задача, с которой модель заведомо справляется. Этот случай должен проходить всегда: если провалился он — сломалось что-то базовое.
2. Пограничные случаи (edge cases). Ситуации, в которых модель уже ошибалась. Инструкция в промпте не даёт ошибке повториться, а тест-кейс следит, чтобы то же поведение не вернулось в будущем.
3. Границы возможностей. Ситуации, в которых модель должна передать вопрос человеку или прямо отказаться отвечать. Агент должен понимать, где заканчивается его зона ответственности, и набор обязан это проверять.

Пример: бот поддержки Meridian Mobile

Разберём на примере промпт бота поддержки клиентов телеком-компании Meridian Mobile. Для него собран набор из пяти тест-кейсов:

1. Контрольный случай: какой лимит трафика в базовом тарифе. Простой вопрос с однозначным ответом.
2. Расчёт пропорциональной оплаты: если клиент меняет тариф в середине месяца, каким будет его следующий счёт.
3. Точные ответы на ключевые вопросы, покрытые политикой компании.
4. Передача вопроса живому оператору, когда клиент сообщает об ошибке в счёте.
5. Проверка, что бот не утаивает информацию, к которой у него есть доступ и которую он должен передать клиенту.

Обратите внимание на пятый пункт. Обычно все переживают о том, что модель выдумает факты, но возможна и обратная проблема: модель умалчивает о данных, которые у неё есть, — например, из-за старой перестраховочной инструкции в промпте. Оценочный набор должен ловить и это.

Порядок работы: прогнать и чинить по одному

Дальше порядок действий такой. Берёте промпт и прогоняете его на первой версии оценочного набора. Смотрите, какие тест-кейсы провалились, — это и есть список проблем, с которым вы будете работать. Затем провалы разбираются по одному: изолировали случай, поправили промпт, снова прогнали весь набор, убедились, что случай прошёл и ничего другого не сломалось.

Чтобы такой цикл был быстрым, удобно собрать небольшое веб-приложение: на одной странице запускается оценка по всем пяти тест-кейсам, и там же можно подробно рассмотреть результаты каждого прогона. По замыслу примера в первом прогоне у бота Meridian Mobile проходит только контрольный случай: он подтверждает, что базовая часть работает, а остальные провалы очерчивают фронт работ.

Замечание к этому порядку: прежде чем прицельно чинить отдельные провалы, стоит навести в промпте общий порядок — структуру, роль, формат вывода; этому посвящён следующий урок. После этого провалы устраняются по одному, пока весь набор не начнёт проходить.

Мы редко пишем промпт с чистого листа — чаще отлаживаем уже существующий. Оценочный набор превращает эту отладку из угадывания в измеримый процесс: у каждой правки есть проверка, у каждого провала — воспроизводимый тест-кейс. С этой основы начинается всё остальное в курсе.