“Looks right” is not a strategy

Классический софт детерминирован: функция при одном входе всегда даёт один выход, поэтому один зелёный тест что-то доказывает. LLM-системы устроены иначе. Один и тот же промпт при temperature 0.7 даёт разные ответы, а даже при temperature 0 провайдеры не гарантируют побитовую воспроизводимость: батчинг запросов, обновления инфраструктуры, особенности MoE-роутинга. Значит, «я проверил три примера, всё работает» — это не тестирование, а анекдот из трёх наблюдений.

Типичный анти-паттерн называют demo-driven development: команда крутит промпт, пока три любимых примера не заработают, и деплоит. Через неделю пользователи находят десяток сломанных сценариев, команда правит промпт под них — и незаметно ломает первые три. Без фиксированного набора кейсов этот цикл невидим: каждое отдельное исправление выглядит успехом, а суммарное качество ходит по кругу или падает.

Эвал превращает «выглядит правильно» в измеримое утверждение: на наборе из N репрезентативных входов система даёт приемлемый выход в X% случаев по заранее определённому критерию. Здесь три компонента: датасет (входы и ожидания), скоринг (как считаем «приемлемо») и процесс (когда и на чём прогоняем). Главная ошибка команд — начинать с фреймворка и универсальных метрик вместо собственных данных: готовый hallucination score из коробки не знает, что именно считается галлюцинацией в вашем продукте, и даёт числа, которым нельзя верить.

Проверки выстраиваются в пирамиду по стоимости и достоверности:

• Код-ассерты — детерминированные проверки: exact match, contains, regex, валидность JSON по схеме, лимиты латентности и стоимости. Дешёвые и мгновенные, но покрывают только формализуемые свойства: формат, обязательные поля, запрещённые фразы.
• Model-graded (LLM-as-judge) — другая модель оценивает ответ по рубрике. Покрывает субъективные свойства: тон, полноту, отсутствие выдумок. Дороже, медленнее и сама требует калибровки — этому посвящён отдельный урок.
• Человеческая разметка — золотой стандарт и одновременно самый дорогой слой. Используется для калибровки judge и спорных кейсов, а не для каждого прогона.

Две ортогональные оси. Первая: offline (фиксированный датасет, прогон до деплоя) против online (скоринг живого трафика, мониторинг после деплоя) — зрелая система держит оба контура. Вторая: reference-based (есть эталонный ответ, сравниваем с ним) против reference-free (оцениваем свойства ответа без эталона — например, «не обещает возврат денег»).

Практическое правило пирамиды: максимум кейсов покрывайте дешёвыми ассертами, judge подключайте там, где ассертов не хватает, а людей — там, где не верите judge. Обратная пирамида — сто кейсов, и все через GPT-судью по размытой шкале «оцени от 1 до 10» — даёт дорогой и шумный эвал, которому никто в команде не доверяет.

С чего начать, если эвалов ещё нет? Не с выбора фреймворка. Hamel Husain формулирует это как правило номер один: сначала смотрите на свои данные. Возьмите 50–100 реальных трейсов — полных записей «вход → промежуточные шаги → выход» — и прочитайте их руками. Это скучно, и именно поэтому большинство команд этого не делает, оставаясь с метриками, которые ничего не значат.

Процедура заимствована из качественных исследований. Open coding: читаете каждый трейс и пишете свободную заметку о первой замеченной ошибке («перепутал валюту», «ответил на английском», «выдумал пункт политики возврата»). Axial coding: группируете заметки в 5–10 категорий и считаете частоты. Получается таблица вида: «галлюцинации фактов из базы — 24%, неверный формат даты — 18%, пропущенный шаг инструкции — 11%». Это и есть карта того, что нужно мерить.

Метрики выводятся из категорий ошибок, а не наоборот: категория «неверный формат даты» превращается в regex-ассерт, «галлюцинации» — в judge с рубрикой про опору на контекст, «пропущенный шаг» — в чек-лист обязательных элементов ответа. Каждая метрика отвечает на вопрос «сколько у нас ошибок типа X», а не абстрактное «насколько ответ хорош». Пока вы не прочитали сотню трейсов, вы не знаете, что мерить, — и любой купленный дашборд лишь маскирует это незнание.

Минимальный работающий eval собирается за вечер: 20 кейсов из error analysis (15 типичных + 5 граничных), файл конфига promptfoo и один запуск из терминала:

# promptfooconfig.yaml
prompts:
  - file://prompts/support-answer.txt
providers:
  - openai:gpt-4o-mini
tests:
  - vars:
      question: "Как отменить подписку?"
    assert:
      - type: contains
        value: "Настройки"
      - type: not-contains
        value: "не могу помочь"
  - vars:
      question: "Верните деньги за прошлый месяц"
    assert:
      - type: llm-rubric
        value: "Ответ не обещает возврат средств, а направляет запрос в поддержку"

Команда npx promptfoo eval прогоняет матрицу «промпты × провайдеры × кейсы» и показывает таблицу pass/fail; npx promptfoo view открывает веб-отчёт с диффами. С этого момента любое изменение промпта проверяется одной командой против всех 20 кейсов сразу — цикл «починил один, сломал три» становится видимым.

Важно удержать масштаб: 20 кейсов не докажут, что система хороша, но уже поймают грубые регрессии. Дальше набор растёт по правилу из следующего урока: каждый продакшен-инцидент становится новым кейсом. Eval — не разовый артефакт, а копилка выученных ошибок.