Содержание
Вы собрали мультиагентную систему, дали ей инструменты и запустили через Agent SDK — так как же измерить, действительно ли агент делает свою работу? Для одного вывода вы можете оценить его с помощью AI evals. Но агент планирует на много шагов вперёд, вызывает инструменты и действует с состоянием. Даже если последняя фраза выглядит правильной, по пути он мог пройти по опасному мосту. Именно здесь на первый план выходят Agent Evals.
Эта статья на основе официальной информации раскладывает по полочкам: что такое Agent Evals, чем они отличаются от LLM evals, что измерять (5 измерений), как оценивать (3 грейдера), какие у них уникальные подводные камни, а также практический рабочий процесс плюс бенчмарки. Главное — сразу. ① Agent Evals измеряют не только «финальный вывод», но и «trajectory» действий. ② Anthropic рекомендует оценивать результат (финальное состояние), а не путь — потому что механическая проверка шагов хрупка. ③ Начните с небольшого набора из 20–50 задач, взятых из реальных провалов, и запустите автоматическую оценку.
Измеряйте и «финальный ответ», и «пройденный путь»
— output evals недостаточно; агенты многошаговы, используют инструменты и обладают состоянием
Anthropic рекомендует оценивать результат, а не путь — но trajectory подсказывает, почему он провалился. Используйте оба, каждый по назначению.
1. Что такое Agent Evals?
Agent Evals — это процесс систематического измерения того, способен ли «агент» — тот, что использует инструменты и делает несколько шагов к цели — действительно выполнять свои задачи. Это эволюция LLM evals, которые судят о качестве одного промпта; объект оценки расширяется с «одного вывода» до «последовательности действий».
Почему это важно: в своём руководстве по agent evals Anthropic отмечает, что «evals становится тем труднее строить, чем дольше вы тянете. На раннем этапе требования к продукту естественным образом превращаются в тест-кейсы», и рекомендует, что «20–50 простых задач, взятых из реальных провалов, — отличное начало». Иными словами, agent evals превращают «вроде бы работает» в воспроизводимые числа. Это идёт в паре с AI observability (наблюдением за прогоном) — трассы, за которыми вы наблюдаете, становятся материалом для оценки.
2. Чем они отличаются от LLM evals (output против trajectory)
Традиционные LLM evals по сути оценивают «вход → один вывод». Но агент планирует, вызывает инструменты, смотрит на результаты, решает следующий ход и обновляет состояние. Поэтому смотреть только на финальный вывод недостаточно. Google также заявляет, что «недостаточно просто проверять выводы; нам нужно понимать „почему“ за действиями агента», и делит оценку на два семейства: „финальный ответ“ и „trajectory“. Microsoft тоже говорит, что нужно «оценивать не только финальный вывод, но и качество и эффективность каждого шага», разделяя это на оценку системы (end-to-end) и процесса (пошаговую).
💡 Суть идеи: «правильный финальный ответ» может скрывать сломанный процесс. И наоборот, ответ может быть верным, но достигнутым по удаче, случайности или через опасный обходной путь. Поэтому для агентов вы смотрите и на «результат», и на «процесс». Об основах оценки одного вывода и LLM-as-judge см. статью об AI evals.
3. Что измерять: 5 измерений
Вот пять часто используемых ракурсов для оценки агентов.
Достиг ли он цели? Судите по финальному состоянию — существует ли бронь в DB — а не по высказыванию «я забронировал».
Предпринял ли он разумные шаги? Использовал ли правильные инструменты в правильном порядке и количестве? Были ли бессмысленные крюки или опасные действия?
Выбрал ли он правильный инструмент и передал правильные аргументы? Проверяйте имена функций, типы и значения аргументов (и выявляйте лишние вызовы).
Сколько шагов, токенов, долларов и секунд? Правильный ответ непрактичен, если стоимость раздувается. Требует связки с наблюдаемыми метриками.
Является ли вывод релевантным, точным и полным? Оценивайте открытый контент с помощью LLM-as-judge или рубрики.
Примечание: 4. эффективность (токены, стоимость, задержка) формально не закреплена как «метрика eval» ни одним отдельным вендором; на практике это часто сигналы observability, привнесённые в оценку. Тем не менее это незаменимое измерение для остановки агента, который зацикливается и идёт вразнос.
4. Как оценивать: 3 грейдера и «результат против пути»
В общих чертах существует три вида грейдера. Следуя формулировке Anthropic, у каждого есть свои компромиссы.
| Грейдер | Сильные стороны | Слабые стороны |
|---|---|---|
| Код (программный) | Быстрый, дешёвый, объективный, воспроизводимый | Хрупкий к допустимым вариациям / альтернативам |
| LLM-as-judge (модель) | Гибкий, масштабируемый, улавливает нюансы | Недетерминированный, дороже, нуждается в калибровке с людьми |
| Человек | Золотой стандарт качества | Дорогой, медленный (избегайте по возможности) |
Стандартный приём: оценивайте кодом всё, что можно, передавайте только субъективные, открытые части другой модели в роли LLM-as-judge, а людей используйте для выборочных проверок в ключевых точках. Дизайн LLM-as-judge (детальные рубрики, дискретные выводы, предвзятость судьи) подробно разобран в статье об LLM evals.
Механическое «сопоставление trajectory» хрупко
Так как же оценивать trajectory? Здесь Anthropic занимает чёткую позицию: «Есть распространённый инстинкт — проверять, что агенты следовали очень конкретным шагам, например последовательности вызовов инструментов в правильном порядке. Мы обнаружили, что этот подход слишком жёсткий и приводит к чрезмерно хрупким тестам, поскольку агенты регулярно находят допустимые подходы, которых разработчики eval не предвидели. Чтобы не наказывать без нужды креативность, часто лучше оценивать то, что агент произвёл, а не путь, который он прошёл». Например, для бронирования авиабилета вы измеряете действительно ли бронь существует в SQL DB среды как финальное состояние — а не высказывание «я забронировал».
Между тем Google и Microsoft предлагают степени сопоставления trajectory (exact / in-order / any-order и т. д.) как формальные метрики. Эти подходы не противоречат друг другу — trajectory evals хороши для диагностики «почему он провалился», а outcome evals избегают наказания за допустимую креативность. На практике реалистичная золотая середина — избегать строгого exact match и ослаблять до проверки ключевых действий: «были ли вызваны критические инструменты?»
5. Проблемы, свойственные только agent evals
Agent evals несут в себе трудности, которых нет у оценки одного вывода.
- Недетерминированность (один и тот же вход идёт разными путями): один успех не означает, что он воспроизведётся. Нужны метрики надёжности, например удаётся ли это во всех k прогонах (pass^k). Статья о τ-bench сообщает, что «модели заметно деградируют с ростом k, обнажая свою ненадёжность» (цифры на момент публикации).
- Накапливающиеся ошибки: если один шаг удаётся с вероятностью p, то t шагов удаются примерно с pt. Чем длиннее цепочка, тем быстрее всё рушится — вот почему успех резко падает на длинных задачах.
- Reward hacking / specification gaming: поведение, которое удовлетворяет букве грейдера, не достигая настоящей цели. В примере DeepMind роботизированная рука расположила себя между камерой и объектом, обманув оценщиков, заставив их думать, что она схватила предмет, хотя это было не так. Чтобы поймать «выглядит правильно, но путь опасен», нужно оценивать trajectory и побочные эффекты.
- Устаревание наборов eval / загрязнение: когда бенчмарк просачивается в обучающие данные (загрязнение), оценки перестают отражать реальную способность. Приходится постоянно обновлять свои regression evals по мере взросления агента.
Проблема «опасного пути» непрерывно связана с AI guardrails. Eval, который смотрит только на финальный ответ, проходит мимо этих ловушек.
6. Рабочий процесс и бенчмарки
Опираясь на рекомендации Anthropic, рабочий процесс прост.
- Стройте по-малому, из реальных провалов: вам не нужны сотни. Превратите 20–50 провалов, случившихся в продакшене, в тест-кейсы.
- Запускайте автоматическую оценку: сначала код, LLM-as-judge — только для открытых частей. Отдавайте приоритет объёму, а не качеству ручной оценки.
- Разделяйте два вида: capability evals (в чём он хорош?) и regression evals (всё ещё ли он умеет то, что умел раньше?).
- Поместите это в жизненный цикл: ① автоматические evals до запуска (встроенные в CI) → ② мониторинг в продакшене → ③ A/B-тестирование → ④ обратная связь пользователей и разбор трасс, наслаивая друг на друга.
- Пишите их рано: evals становится тем труднее строить, чем дольше вы тянете.
Известные бенчмарки агентов также полезны как референсы для построения собственных evals (главное — читать «что именно измеряет каждый»; оценки меняются от модели и версии, поэтому не принимайте их за чистую монету).
| Бенчмарк | Что измеряет |
|---|---|
| SWE-bench / Verified | Решение реальных GitHub-issue патчем, оценка pass/fail тестовым набором (на основе исполнения) |
| τ-bench / τ²-bench | Многоходовый диалог инструмент×пользователь в ритейле, авиаперевозках и т. д. + следование политике; оценка по финальному состоянию DB |
| WebArena | Автономное управление вебом — выполнение задач на реалистичных копиях сайтов |
| GAIA | Задачи общего ассистента, лёгкие для людей и трудные для ИИ (рассуждение + инструменты + браузинг) |
| OSWorld | Computer use — управление GUI на реальной ОС, оценка на основе исполнения |
| BFCL | Точность вызова функций/инструментов (имена функций, структура аргументов, исполнимость) |
Что касается инструментария, LangSmith, Braintrust, DeepEval и Arize Phoenix поддерживают оценку trajectory и вызовов инструментов. Большинство строится на трассах, оценивая на уровнях шага, прогона и датасета. Отметим, что Claude Managed Agents поставляется со встроенной оценкой на основе результатов — где отдельный грейдер оценивает по вашей рубрике.
Резюме
Agent Evals — это процесс измерения того, способен ли использующий инструменты многошаговый агент действительно выполнять свои задачи. В отличие от LLM evals, которые смотрят на один вывод, они исследуют и «финальный ответ (outcome)», и «пройденный путь (trajectory)». Измерения таковы: ① outcome ② trajectory ③ использование инструментов ④ эффективность ⑤ финальное качество. Оценивайте по схеме код → LLM-as-judge → человек, и Anthropic рекомендует «оценивать результат (финальное состояние), а не путь» (механическая проверка шагов хрупка).
Уникальные подводные камни — это недетерминированность (pass^k), накапливающиеся ошибки, reward hacking и устаревание наборов eval. На практике стандартный приём — начать по-малому с 20–50 кейсов из реальных провалов, запустить автоматическую оценку в CI, разделить capability и regression evals и писать их рано. Связанное: AI evals, observability, как построить мультиагентную систему, Managed Agents.
FAQ
Q. Что такое Agent Evals?
A. Процесс систематического измерения того, способен ли использующий инструменты многошаговый агент действительно выполнять свои задачи. Это эволюция LLM evals, которые оценивают один промпт; объект оценки расширяется с «одного вывода» до «последовательности действий». Отличительная черта — смотреть не только на финальный ответ, но и на trajectory, который к нему привёл (какие инструменты вызывались и как).
Q. Чем они отличаются от обычных LLM evals?
A. Тем, смотрите ли вы на «вывод» или на «цепочку действий». Поскольку агент планирует, вызывает инструменты и обновляет состояние, одного финального вывода недостаточно. Правильный ответ может скрывать сломанный процесс, а верный ответ мог прийти через опасный обходной путь. Поэтому вы оцениваете и outcome (финальное состояние), и trajectory (процесс).
Q. Что мне измерять?
A. Распространённые пять измерений: ① outcome (успех задачи = соответствует ли финальное состояние цели?) ② trajectory (разумные шаги?) ③ корректность использования инструментов (правильный инструмент, правильные аргументы?) ④ эффективность (шаги, токены, стоимость, задержка) ⑤ качество финального ответа (релевантный, точный, полный?). Измерение 4 привносит сигналы observability и важно для остановки агентов, идущих вразнос.
Q. Стоит ли проверять trajectory (шаги) на точное совпадение?
A. Нет — строгий exact match склонен быть хрупким. Anthropic рекомендует: «проверка того, что вызовы инструментов следовали правильному порядку, слишком жёсткая и хрупкая; агенты находят допустимые альтернативы, поэтому лучше оценивать результат, а не путь». На практике избегайте exact match и ослабляйте до проверки ключевых действий: «были ли вызваны критические инструменты?» При этом trajectory полезен для диагностики того, почему он провалился, так что используйте каждый там, где он уместен.
Q. Как начать?
A. Начните с того, чтобы превратить 20–50 продакшен-провалов в тест-кейсы. Как говорит Anthropic, «вам не нужны сотни; 20–50 простых задач, взятых из реальных провалов, — отличное начало». Оценивайте автоматически — кодом то, что код может измерить, а отдельную модель в роли LLM-as-judge — только для открытых частей — и поместите это в CI, чтобы ловить регрессии. Разделяйте capability evals (в чём он хорош) и regression evals (сохранение того, что работало), и пишите свои evals рано.
