Прямой ответ
LLM-приложение нельзя тестировать assert response == expected — ответы вариативны, и это не баг, а свойство; но нестрогое поведение всё равно должно измеряться: эвалы (evals) — прогон датасета кейсов с автоматической оценкой по метрикам, дающий число «качество = 0.87» вместо ощущения «вроде работает». Минимальный рабочий набор: датасет из 30–50 реальных кейсов (вопросы/задачи + эталон или критерий — собирается из реального трафика и краевых случаев, живёт в репозитории); метрики по типу задачи: классификация/извлечение — accuracy/F1 против эталона (строго детерминированно), генерация/RAG — faithfulness (ответ опирается на контекст, не выдуман), answer relevance, корректный refusal на вопросы вне данных (RAG-сценарий); LLM-as-judge для открытых ответов (сильная модель оценивает по явной рубрике 1–5 — дешевле человеческой разметки, но калибруется на ней); регрессия: любой сдвиг — смена модели, промпта, чанкинга — прогоняет эвалы, и падение метрики блокирует релиз так же, как упавшие тесты. Без этого процесс «улучшили промпт» — рулетка: правка, починившая три кейса, незаметно ломает пять других.
Датасет кейсов: откуда брать и как жить
Датасет — главный артефакт, важнее кода прогона. Источники по ценности: реальный трафик (логи продакшн-запросов — сэмпл с анонимизацией: что люди спрашивают на самом деле, включая опечатки и странные формулировки); краевые случаи от команды (то, что «неловко» спросить; вопросы вне области — на refusal; инъекционные промпты — на безопасность); исторические баги (каждый прод-инцидент качества — новый кейс в датасет, как регрессионный тест). Структура кейса: вход (вопрос/контекст/инструменты), ожидаемое (эталонный ответ ИЛИ критерии приемлемости ИЛИ ожидаемое поведение — «отказать», «вызвать инструмент X»), метки (категория — для срезов метрик «на вопросах про возвраты точность ниже»). Правила жизни: датасет в git (JSONL), правки — через PR; разделение dev/holdout (промпт крутится на dev-наборе — риск подгонки под него; holdout-набор трогается только на релизных проверках); рост — постоянный (30 кейсов на старте, 200 через полгода — метрика становится представительной); устаревание — кейсы с устаревшими эталонами удаляются так же осознанно, как тесты.
Метрики: от строгих к мягким
Детерминированные (там, где ответ проверяем): классификация/маршрутизация/извлечение сущностей — accuracy, precision/recall/F1 по категориям; извлечение JSON — валидность схемы + точность полей; exact/substring match для коротких ответов («да/нет», суммы) — работает чаще, чем кажется (нормализация: регистр, пробелы, единицы). Структурные для RAG (фреймворки Ragas-класса): faithfulness — все утверждения ответа выводимы из контекста (ловит галлюцинации); context precision/recall — звено поиска оценивается отдельно от генерации (правильные чанки найдены? — без этого «плохой ответ» непонятно чья вина); answer relevancy — ответ по делу. Поведенческие: refusal-rate на внеобластных вопросах (должен быть ~100%), корректность выбора инструмента (агенты — ожидаемая последовательность вызовов), отсутствие инъекционного послушания. Мягкие — LLM-as-judge: рубрика явная («оцени 1–5: фактическая опора на контекст; 5 — все утверждения подтверждены»), judge-модель сильнее оцениваемой, калибровка обязательна (50 кейсов с человеческими оценками — совпадение судьи с человеком ≥80%, иначе рубрика переписывается); судья тоже тестируется, слепое доверие ему — типичная ошибка.
Прогон: CI, регрессии, стоимость
Инфраструктура прогона проста: скрипт «датасет → приложение → метрики → отчёт» (свои 100 строк или Ragas/promptfoo — по вкусу); запуск — вручную при итерациях промпта, в CI — на изменения промптов/пайплайна (не на каждый коммит: дорого и медленно — scheduled + pre-release обязателен). Регрессионная политика: порог на агрегате (общая метрика не ниже baseline − 2%) и на срезах (категория не просела больше 10% — агрегат прячет локальные провалы: «в среднем хорошо, вопросы про возвраты сломаны»); отчёт — дифф по кейсам (какие кейсы ухудшились — смотреть глазами, не только число). Стоимостной контроль: эвал-прогон 200 кейсов на платной модели — ощутимые деньги и минуты — кеш ответов на неизменных входах, judge дешевле генератора, ночной scheduled вместо каждого PR. Вариативность: температура 0 где можно, N прогонов на кейс для флуктуирующих (доля успеха 4/5 вместо одного бинарного результата), флуктуирующие кейсы помечаются и не блокируют релиз по одному прогону.
Практический сценарий: эвалы спасают релиз
Команда меняет модель RAG-бота на более дешёвую: «ответы на глаз не хуже». Прогон эвалов (120 кейсов: 80 рабочих вопросов, 20 внеобластных, 20 с таблицами): агрегированный faithfulness 0.91 → 0.89 — терпимо; срез «вопросы с таблицами» — 0.74 → 0.52: новая модель хуже держит табличный контекст; срез «refusal» — 100% → 85%: чаще фантазирует вне данных. Решение: для табличных вопросов оставить старую модель (маршрутизация по типу вопроса — классификатор уже есть), для простых — новая; повторный прогон — оба среза в норме, релиз проходит с экономией 40% стоимости. Без эвалов этот релиз ушёл бы в прод и собирал жалобы две недели до обнаружения паттерна. Обратный пример из той же практики: правка промпта «отвечай короче» подняла релевантность, но уронила полноту на многошаговых вопросах — дифф-отчёт показал шесть ухудшившихся кейсов, промпт скорректирован до релиза. В обоих случаях инструмент один: датасет + метрики + срезы.
FAQ
Сколько кейсов нужно для старта? 30–50 покрывают основные сценарии и дают сигнал (не статистическую точность, а «сломалось заметно»); качество кейсов важнее количества: десять реальных краевых случаев полезнее сотни синтетических «как дела».
Можно ли обойтись без LLM-as-judge? Для классификации/извлечения/RAG-метрик — да (детерминированные проверки); для открытых диалогов и стиля — практически нет: альтернатива — человеческая разметка, дороже и медленнее; judge — компромисс, требующий калибровки.
Как оценивать агентные сценарии (мультишаговые)? Оценивается траектория, не только финал: ожидаемые вызовы инструментов (мок-инструменты, проверка последовательности и аргументов), эффективность (число шагов до решения), финальный ответ судья; полная недетерминированность траекторий нормальна — метрика «доля успешных завершений за ≤N шагов».
Нужны ли эвалы при использовании чужого AI-продукта (API-фича без своего промпта)? Да, в урезанном виде: регрессионный датасет на интеграцию (провайдер меняет модель молча — ваши кейсы ловят деградацию; smoke-набор из 20 кейсов в ночном прогоне — страховка от «обновили модель, качество упало»).
Источники: документация Ragas, публикации Hamel Husain об evals, OpenAI evals — ссылки в шапке.