Как тестировать AI-агента: гайд по evals

Агент отличается от обычного запроса к модели тем, что он действует: сам решает, какой инструмент вызвать, с какими аргументами, сколько шагов сделать и когда остановиться. Из-за этого привычная проверка «посмотрел ответ — вроде норм» перестаёт работать. Ответ может выглядеть безупречно, а под капотом агент трижды дёрнул платёжный API, дважды сходил не туда и случайно попал в правильный итог.

Eval (от английского evaluation — «оценка») — это автоматизированный тест для системы на базе языковой модели. По сути тот же юнит-тест, только вместо строгого сравнения строк вы измеряете качество на наборе заранее подготовленных задач. Ниже — как построить такие проверки для агента: что складывать в датасет, что именно измерять, чем оценивать и какими инструментами это делать в 2026 году.

Почему агента нельзя проверить «на глазок»

У ручной проверки три системные проблемы.

Недетерминированность. Один и тот же запрос при одной и той же температуре может дать разные траектории. Прогнали один раз, получили зелёный результат — это ничего не доказывает.

Регрессии не видны. Вы поправили формулировку в системном промпте, чтобы починить один сценарий, и молча сломали три соседних. Без набора задач это выяснится в проде.

Правильный ответ по неправильному пути. Агент мог угадать, мог вытащить факт из своих знаний вместо того, чтобы сходить в вашу базу, мог обойти проверку прав. Итоговый текст этого не покажет.

Из чего состоит eval

Любой eval, независимо от инструмента, собирается из четырёх частей.

1. Датасет. Набор кейсов: входной запрос, нужное состояние системы, ожидаемый результат (его часто называют golden answer — «эталонный ответ»). Anthropic в документации советует не гнаться за идеальными кейсами: больше задач с чуть более шумным сигналом полезнее, чем десяток вылизанных, но размеченных вручную. Кейсы должны повторять реальное распределение запросов, включая пограничные — пустой ввод, противоречивые требования, попытку обойти правила.

2. Прогон. Агент запускается на каждом кейсе — желательно с моками внешних API, чтобы тесты не списывали деньги и не зависели от чужого аптайма.

3. Грейдер (grader) — то, что выставляет оценку. Код, человек или другая модель.

4. Метрика и порог. Число, по которому вы решаете, катить изменение или нет: «доля успешных задач не ниже 85 %», «ноль вызовов инструментов записи в read-only сценариях».

Три уровня проверки: итог, траектория, компонент

Итоговый результат (end-to-end)

Система рассматривается как чёрный ящик: задача решена или нет. Это главная метрика — task completion. Она отвечает на вопрос «работает ли вообще», но не говорит, почему не работает.

Траектория

Траектория — это полная последовательность сообщений и вызовов инструментов, которую агент проделал по пути к ответу. Её сравнивают с эталонной. В LangSmith такие проверки делятся на четыре режима: строгий (тот же набор вызовов в том же порядке — нужно, когда важна последовательность, например «сначала проверить полис, потом авторизовать»), без учёта порядка, подмножество (агент не вызвал ничего лишнего) и надмножество (обязательный минимум вызван, лишнее допустимо). Отдельно траекторию можно отдать модели-судье с рубрикой — тогда оценивается ещё и эффективность пути.

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

Компонент

Когда end-to-end упал, а траектория выглядит странно, спускаемся ниже: отдельно проверяем ретривер (нашёл ли нужные документы), парсер, конкретный инструмент, суб-агента. Полезный диагностический порядок такой: сначала итог, потом путь, потом сломанный компонент.

Чем оценивать: код, человек, модель-судья

Код. Самый быстрый и надёжный способ: точное совпадение, наличие ключевой подстроки, валидность JSON по схеме, проверка «был ли вызван инструмент X с аргументом Y». Если ваш агент отдаёт структурированный вывод в JSON, большую часть проверок закрывает обычный код без всякой магии. Правило простое: всё, что можно проверить кодом, проверяйте кодом.

Человек. Самый гибкий и самый дорогой способ. Держите ручную разметку только для небольшой контрольной выборки — ею вы калибруете автоматические грейдеры.

LLM-as-a-judge («модель-судья»). Отдельная модель оценивает ответ по рубрике. Хорошо работает там, где нет одного правильного текста: тон, полнота, следование политике. Чтобы судья был вменяемым, соблюдайте три вещи: пишите детальную рубрику с конкретикой («ответ должен содержать название компании в первом предложении, иначе — incorrect»), требуйте дискретный вывод (correct/incorrect или шкала 1–5, а не абзац рассуждений), просите сначала обосновать, потом поставить оценку — рассуждение повышает качество, а хранить его необязательно.

Главное про судью: его самого нужно проверить. Разметьте 30–50 кейсов руками и посмотрите, насколько судья с вами совпадает. Если совпадение слабое — чините рубрику, а не масштабируйте.

Метрики, которые реально нужны агенту

• Task completion — доля решённых задач. Оценивается судьёй или кодом по конечному состоянию системы.
• Tool correctness — вызваны ли нужные инструменты. Детерминированная метрика, судья не нужен.
• Argument correctness — переданы ли правильные параметры. Здесь прячется масса тихих ошибок: не тот id, не тот формат даты, не та валюта.
• Step efficiency — обошёлся ли агент без лишних шагов, повторов и циклов. Напрямую конвертируется в деньги; как считать расход, разбирали в заметке про токены и лимиты.
• Plan adherence — следовал ли агент заданным правилам и ограничениям.
• Безопасность — отдельный набор кейсов: промпт-инъекции в документах и письмах, попытки вытащить системный промпт, выход за границы прав. Эти кейсы должны быть в регрессе постоянно, а не «проверили один раз перед релизом».
• Стоимость и латентность — фиксируйте вместе с качеством, иначе рискуете выкатить версию, которая на 2 % точнее и втрое дороже.

Отдельно тестируйте многошаговые диалоги: не путает ли агент пользователей, не тянет ли устаревший факт. Механику разбирали в заметке про память у AI-агентов.

Один прогон ничего не доказывает: pass^k

Это, пожалуй, главный практический вывод последних лет. В бенчмарке τ-bench (тау-бенч), который проверяет агентов на диалоге с пользователем и следовании правилам домена, авторы ввели метрику pass^k — доля задач, решённых успешно во всех k прогонах подряд. Результат отрезвляющий: даже сильные на момент публикации модели с function calling решали меньше половины задач с одной попытки, а pass^8 в розничном домене падал ниже 25 %.

Что с этим делать: гоняйте каждый кейс несколько раз (3–5 достаточно для старта) и смотрите не только среднее, но и худший случай. Стабильность — отдельное свойство системы, и её не видно на единичном запуске.

Инструменты в 2026 году

Ландшафт заметно перетряхнуло, и это стоит учитывать при выборе.

Promptfoo — открытый инструмент для evals и ред-тиминга, работает из конфига в YAML и легко встраивается в CI. В марте 2026 года команда объявила о переходе в OpenAI, пообещав продолжить развивать открытую часть и поддержку разных провайдеров.

OpenAI Evals — платформа объявлена устаревшей: уведомление разработчикам ушло 3 июня 2026 года, с 31 октября существующие evals переводятся в режим только для чтения, а 30 ноября 2026 года дашборд и API отключаются. В качестве замены OpenAI рекомендует как раз Promptfoo и публикует гайд по миграции. Если вы всё ещё держите тесты там — переезд лучше не откладывать.

LangSmith — готовые trajectory-эвалюаторы и оценка на уровне отдельного прогона, трассы и целого треда диалога.

DeepEval — открытый фреймворк с pytest-подобным синтаксисом и большим набором готовых агентных метрик (tool correctness, task completion и другие).

Langfuse — открытая трассировка плюс evals поверх реальных продовых трасс; удобен, когда нужен self-hosted.

Консоль Claude — встроенный инструмент оценки промптов: тест-кейсы, прогон вариантов бок о бок, оценка по шкале. Хорошая точка входа, если всё держится на промпте.

С чего начать за неделю

1. Соберите 20–30 кейсов из реальных логов: половина — типовые запросы, половина — то, на чём агент уже падал. Идеально, если каждый кейс приходит из настоящего обращения пользователя.
2. Опишите для каждого критерий успеха одной строкой: что должно оказаться в ответе, какой инструмент обязан быть вызван, чего быть не должно.
3. Закройте кодом всё, что закрывается кодом, а на остальное поставьте судью с короткой рубрикой.
4. Прогоните каждый кейс 3 раза и зафиксируйте базовую линию: процент успеха, среднее число шагов, стоимость прогона.
5. Повесьте прогон на CI — на каждый пул-реквест, который трогает промпты, инструменты или модель. Порог: не ниже базовой линии.
6. Заведите правило: каждый инцидент в проде превращается в новый кейс в датасете. Так набор растёт сам и всегда описывает реальные боли.

Частые ошибки

Тестировать только счастливый путь. Ценность датасета в пограничных случаях: пустой ответ инструмента, таймаут, противоречивый запрос, попытка манипуляции.

Судить только по финальному тексту. Без траектории вы не отличите «решил правильно» от «случайно вышло правильно».

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

Забыть про права доступа. Eval — не замена ограничению прав; о том, что должно быть закрыто на уровне инфраструктуры, — в заметке про безопасность AI-агентов.

Вывод

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