Почему финальный балл врёт про качество агента
Агент вернул ответ за 12 секунд, задача помечена как выполненная, метрика успеха 92%. Через сутки выясняется, что половина ответов построена на неверно истолкованном запросе. Финальный балл такое не ловит.
Причина в структуре задачи. У одношаговой модели есть вход и выход, между ними ничего не спрячешь. У многоходового агента между входом и выходом лежит цепочка решений: как понять запрос, какой инструмент вызвать, с какими аргументами, как прочитать результат, что делать при пустом ответе. Ошибка в любом звене уходит дальше по цепочке.
Одна ошибка на раннем шаге портит весь диалог
Синтетический пример. Запрос: «посчитай возвраты по заказам клиента за март». На втором ходу агент решает, что речь о марте прошлого года, потому что в контексте промелькнула дата из истории переписки. Дальше всё идёт по инерции: агент вызывает инструмент с неверным диапазоном, получает пустой список, честно агрегирует ноль и отвечает «возвратов нет».
Ответ выглядит правдоподобно. Формат верный, тон верный, ни одной ошибки в рассуждении после шага 2. Оценка по финальному результату поставит здесь либо ноль за всю сессию, либо, что хуже, единицу, если судья не сверяет даты. В обоих случаях непонятно, что чинить: промпт разбора запроса, логику выбора диапазона или инструмент, который молча вернул пустой список вместо ошибки.
Такой сбой не виден на дашбордах. Процент успешных завершений остаётся высоким, задержки в норме, ошибок нет. Поведенческие сбои агентов разобраны отдельно в материале про тихие сбои AI-агентов: там же показано, почему инфраструктурные метрики не пересекаются с метриками качества.
Что должна уметь метрика оценки AI-агентов
Из примера выше вытекают четыре требования. Считать качество по каждому ходу, а не по сессии целиком. Раскладывать качество на именованные под-метрики, чтобы итог 0.6 можно было расшифровать. Указывать ход, ставший первопричиной сбоя. Отделять этот ход от шагов, которые лишь унаследовали ошибку и сами по себе корректны.
Ни одно из этих требований не закрывается одной цифрой на выходе. Agent Evaluation Metric строится вокруг них.
Что такое Agent Evaluation Metric (AEM)
Agent Evaluation Metric (AEM) раскладывает качество агента на именованные под-метрики и считает их по каждому ходу отдельно. Общего балла в этой схеме нет по построению.
Именованные под-метрики вместо одного общего балла
Имя под-метрики несёт больше информации, чем её значение. Набор вида correctness.truthfulness, correctness.completeness, tool_choice, argument_validity позволяет сопоставлять прогоны между собой: если на сорока сессиях проседает одна и та же под-метрика, это паттерн, а не случайность.
Сравните два отчёта. Первый: «качество 0.71». Второй: «truthfulness упал на шагах разбора запроса, completeness в норме, выбор инструментов не менялся». Второй отчёт сразу задаёт направление поиска.
Пошаговая оценка: почему считаем по каждому ходу
Ход в контексте агента это одно решение с наблюдаемым результатом: вызов инструмента с аргументами, сформулированное рассуждение, финальный ответ. Привязка метрик к ходам даёт адрес сбоя внутри сессии. Без неё у вас есть только факт, что сессия провалена, и весь трейс на 15 шагов как объект для ручного разбора.
Практический эффект простой: вместо чтения трейсов целиком вы смотрите на два-три хода, которые метрика отметила.
Пример: как AEM измеряет correctness и находит корневую причину
correctness удобно взять как пример, потому что это самая частая под-метрика и самая склонная к смешиванию разных типов ошибок.
truthfulness и completeness: две стороны correctness
AEM разделяет correctness на truthfulness и completeness. truthfulness отвечает на вопрос, соответствует ли сказанное агентом фактам: данным из инструментов, условиям задачи, содержимому контекста. completeness отвечает на другой вопрос: покрыты ли все части задачи, не потеряно ли требование по пути.
Агент может провалить truthfulness при полной completeness: выдумал число, но структуру отчёта собрал целиком. И наоборот: не выдумал ничего, но забыл половину условий. Один общий балл correctness смешивает эти случаи, а чинятся они по-разному. Смешение скрывает и тип сбоя: непонятно, работать над точностью фактов или над полнотой покрытия.
Метка prior_action_failed: как отделить первопричину от последствий
Вернёмся к примеру с возвратами и посмотрим, как выглядит разметка по ходам.
| Ход | Действие агента | truthfulness | completeness | Метка |
|---|---|---|---|---|
| 1 | Разбор запроса: период и объект | провал: выбран неверный год | ок | корневая причина |
| 2 | Вызов инструмента с диапазоном дат | провал: диапазон неверный | ок | prior_action_failed |
| 3 | Фильтрация результатов | данные пустые из-за диапазона | ок | prior_action_failed |
| 4 | Агрегация возвратов | ноль по пустому набору | ок | prior_action_failed |
| 5 | Финальный ответ «возвратов нет» | факт неверен | ок | prior_action_failed |
AEM ищет первый ход, где под-метрика упала без внешней причины, и помечает всё, что после, меткой prior_action_failed. Ход 3 в таблице формально тоже содержит неверные данные, но его вход уже был испорчен на шаге 2, и как отдельная единица работы он не нужен.
Без этой метки список сбоев раздувается. Вы получаете пять проблем вместо одной и тратите итерацию на шаги, которые исправятся сами, как только починишь разбор периода.
Семантическое сравнение вместо точного совпадения строк
Сравнение ответа агента с эталоном через точное совпадение строк даёт ложные сбои. Агент ответил по смыслу верно, но переставил слова, добавил пояснение или выбрал синоним, и метрика записала это как ошибку. На длинных ответах доля таких ложных срабатываний растёт быстро.
AEM использует семантическое сравнение: значения сверяются по смыслу, а не посимвольно. Для чисел и идентификаторов это может быть нормализация и допуск, для текстовых полей - сравнение через модель-судью или эмбеддинги. Подход с моделью-судьёй разобран на практическом кейсе оценки длинных отчётов агентов в LangSmith, включая ошибку калибровки судьи, которая почти замаскировала реальное улучшение агента.
Ограничение здесь тоже есть. Семантическое сравнение требует настройки: порог совпадения, выбор модели-судьи, правила нормализации. Слишком мягкий порог пропустит настоящие ошибки, слишком строгий вернёт вас к ложным срабатываниям. Это параметр под задачу, а не константа.
Таксономия сбоев и порядко-независимая оценка вызовов инструментов
Два дополнительных компонента AEM не ищут корневую причину напрямую, зато делают диагностику полнее.
Зачем нужна таксономия типов сбоев
Отдельные инциденты плохо поддаются приоритизации: их много, и они выглядят разными. Категории собирают их в группы. Если 60% сбоев попадают в одну категорию, порядок работ очевиден. Если сбои размазаны по десяти категориям, чинить всё сразу бессмысленно.
Конкретный состав категорий AEM не фиксирует. Разметку задаёт команда: у одного агента это ошибки разбора запроса и выбора инструмента, у другого - работа с контекстом и формат вывода. Важно, чтобы один и тот же тип сбоя попадал в одну и ту же категорию во всех прогонах, иначе группировка теряет смысл.
Порядко-независимая оценка цепочек вызовов инструментов
Порядок вызовов инструментов не всегда несёт смысл. Агент, которому нужно собрать данные из трёх независимых источников, может вызвать их в любой последовательности, и результат будет одинаковым. Требовать фиксированного порядка значит штрафовать за корректное поведение.
Порядко-независимая оценка сравнивает набор вызовов как множество: какие инструменты задействованы, с какими аргументами, покрыт ли обязательный минимум. Порядок учитывается только там, где он реально важен: запись после чтения, отмена после создания, обращение к зависимости после её инициализации.
Как встроить AEM в пайплайн оценки как кастомный evaluator
AEM подключается к пайплайну оценки кастомным evaluator'ом. Вы не заменяете существующий процесс, а добавляете узел, который получает трейс сессии и возвращает разметку по ходам. Общий контур оценки кодинг-агентов с метриками токенов, latency и стоимости успешного решения разобран в материале про Terminal Bench 4.0, там же видно, куда такой evaluator встаёт в наборе проверок.
Что подаётся на вход и что получается на выходе
Вход: последовательность ходов агента. Для каждого хода нужны тип действия, аргументы, результат и, если есть, рассуждение. Без результата вызова оценить truthfulness не получится.
Выход состоит из трёх слоёв данных:
- под-метрики по каждому ходу с именами;
- метки
prior_action_failedна унаследованных шагах; - список корневых причин, уже отфильтрованный от последствий.
Третий слой и есть то, ради чего вся конструкция собиралась.
От списка сбоев к списку корневых причин
Исходный материал для работы: длинный список проваленных ходов, разбросанных по сессиям. Практическая ценность AEM в том, что этот список сжимается в короткий упорядоченный список корневых причин, которые действительно стоит чинить.
Как приоритизировать фиксы по корневым причинам
Логика отсева: унаследованные шаги помечены prior_action_failed и уходят из списка. Остаются ходы-первопричины. Дальше они упорядочиваются по частоте: причина, которая встречается в 40 сессиях из 100, стоит выше той, что попалась дважды.
Чинить первопричину выгоднее, чем симптом. Правка разбора периода на шаге 2 убирает сразу четыре помеченных шага ниже по цепочке. Работа над шагом 5, где агент некрасиво сформулировал вывод, не даст ничего: вход в этот шаг уже испорчен.
Есть второй эффект, менее очевидный. Короткий список причин ускоряет итерации: команда закрывает одну причину, перезапускает прогон и видит, сколько помеченных шагов исчезло. Прогресс становится измеримым, а не оценочным.
Ограничения AEM: что метрика не даёт из коробки
Численных порогов у AEM нет. Какой уровень truthfulness считать провалом, зависит от задачи: для агента, который считает деньги, и для агента, который пишет черновик письма, пороги разные. Формулы и эталонные значения тоже задаются под контекст.
Готовых реализаций и привязки к конкретному фреймворку в описании метрики нет. Это схема организации оценки, а не библиотека, которую достаточно подключить. Таксономия сбоев не зафиксирована: категории определяет команда под своего агента. Семантическое сравнение требует настройки и калибровки, иначе будет ошибаться в обе стороны.
Отсюда честный вывод: AEM помогает понять, что чинить, но не чинит сама. Если у команды нет процесса работы с найденными причинами, метрика останется красивым отчётом.
Начать можно с малого. Заведите под-метрики по ходам на одном сценарии, где сбой воспроизводится стабильно, и посмотрите, какой ход окажется первопричиной. Регулярно он оказывается не тем, на который показывала финальная метрика: сломанный шаг лежит выше по цепочке и выглядит безобидно.