Как измерять качество AI-агента: метрики и подводные камни

Классические метрики для языковых моделей — точность ответа, релевантность, отсутствие галлюцинаций — на агентах ломаются. Агент не выдаёт один ответ: он планирует, вызывает инструменты, читает результаты, исправляется и делает это в несколько шагов. Модель, которая на одиночном вопросе показывает 92% точности, в роли агента может проваливать половину многошаговых задач — потому что ошибка на третьем шаге тянет за собой всю цепочку. Именно поэтому за последний год выделилась отдельная тема — evaluation агентов, и под неё выросли инструменты вроде LangSmith, Braintrust, Arize Phoenix и открытых бенчмарков.

Почему обычные метрики не работают

Оценка одиночного ответа языковой модели — это сравнение с эталоном: есть правильный текст, есть выданный, считаем совпадение. Агент[1] устроен иначе. Один и тот же результат он может получить пятью разными путями, а может выдать верный ответ, случайно наткнувшись на него после трёх неверных вызовов инструмента. Смотреть только на финальный ответ — значит закрывать глаза на то, сколько это стоило по токенам, времени и запросам к API.

Есть три уровня, на которых стоит измерять качество, и они не заменяют друг друга:

• Итоговый результат (outcome) — решил ли агент задачу целиком. Самое понятное, но самое грубое: говорит «да/нет», не объясняя, где именно ломается.
• Траектория (trajectory) — какие шаги агент сделал, в каком порядке, какие инструменты вызвал. Здесь видно, что он «угадал» ответ или, наоборот, шёл верно, но упёрся в баг инструмента.
• Отдельный шаг (step-level) — корректность каждого вызова: правильно ли сформирован запрос к функции, верно ли распарсен ответ.

Что конкретно измерять

Достижение цели

Главная метрика — task success rate, доля полностью выполненных задач на фиксированном наборе кейсов. Важно, что «полностью»: частично выполненную задачу лучше считать провалом, иначе метрика льстит. Для задач с чётким результатом (собрал корректный JSON, вернул нужную сумму) проверка автоматическая. Для размытых (написал письмо, составил план) приходится звать LLM-судью или человека.

Качество траектории

Здесь считают: сколько шагов ушло на задачу против оптимального числа, сколько лишних вызовов инструментов, зацикливался ли агент, вызывал ли инструмент, который в этой ситуации не нужен. Агент, решающий задачу за 12 шагов вместо 4, формально успешен, но в проде он в три раза дороже и медленнее.

Стоимость и латентность

Две метрики, которые часто забывают на этапе прототипа и получают счёт в конце месяца. Считать стоит стоимость в токенах на задачу, число вызовов внешних API, время до финального ответа (end-to-end latency) и время до первого действия. У агента с длинным контекстным окном[2] каждый лишний шаг тянет за собой всю накопленную историю — и цена растёт нелинейно.

Надёжность вызова инструментов

Отдельно измеряют tool call accuracy: правильно ли агент выбрал инструмент и корректно ли заполнил его аргументы. Это частая точка отказа — модель уверенно вызывает функцию с невалидными параметрами, инструмент возвращает ошибку, а агент либо застревает, либо игнорирует её.

Агент, который проходит 90% ваших тестов, но разваливается на второй день в проде, чаще всего проваливает не тесты, а надёжность: он нестабилен от запуска к запуску, и один прогон ничего не гарантирует.

Стабильность прогонов

Языковые модели недетерминированы. Один и тот же кейс при одинаковом входе может пройти сейчас и упасть через минуту. Поэтому success rate имеет смысл только на нескольких прогонах одного набора — например, три прогона по всему датасету, и смотреть не только среднее, но и разброс. Метрика pass@k (доля задач, решённых хотя бы раз за k попыток) показывает потенциал, а стабильность за n прогонов — реальное поведение в проде.

Инструменты и бенчмарки

Готовые публичные бенчмарки помогают сравнить подходы, но не заменяют оценку на ваших данных. Среди известных: SWE-bench — задачи по починке багов в реальных репозиториях, WebArena — навигация по веб-интерфейсам, GAIA — многошаговые вопросы, требующие инструментов и рассуждения. Ниже — сравнение по назначению; точные текущие лидерборды и цифры смотрите на страницах самих бенчмарков, они обновляются часто.

Для оценки на своих данных используют платформы трейсинга и eval: LangSmith (от команды LangChain), Braintrust, открытый Arize Phoenix. Они пишут трейс каждого прогона — все шаги, вызовы инструментов, токены — и позволяют повесить на кейсы автоматические проверки и LLM-судью. Цены на коммерческие платформы зависят от объёма трейсов и меняются; актуальные тарифы смотрите на их официальных страницах, у большинства есть бесплатный уровень для старта.

LLM-судья: удобно и опасно

Когда правильность ответа нельзя проверить кодом, задачу оценки отдают другой модели — это LLM-as-a-judge. Дёшево и масштабируемо, но со своими ловушками: судья склонен завышать оценку длинным и уверенным ответам, чувствителен к формулировке промпта-инструкции и может систематически ошибаться в одну сторону. Минимальная гигиена — раз в какое-то время сверять вердикты судьи с ручной разметкой на выборке кейсов. Если судья расходится с человеком чаще, чем на 10–15% случаев, доверять его цифрам как абсолютным нельзя.

Кому это пригодится, а кому нет

Пригодится:

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

Избыточно:

• Для разового прототипа на выходные, который вы показываете и выбрасываете, — здесь хватит ручной проверки на десяти кейсах.
• Для агента без внешних инструментов и без многошаговости — по сути это обычная генерация, и хватает классических метрик качества ответа.

С чего начать

1. Соберите датасет из 30–50 реальных кейсов с ожидаемым результатом. Маленький, но настоящий набор полезнее большого синтетического.
2. Настройте трейсинг, чтобы видеть все шаги и вызовы инструментов, а не только финальный ответ.
3. Считайте минимум три метрики: success rate, среднее число шагов, стоимость на задачу.
4. Прогоняйте датасет несколько раз и смотрите на разброс, а не только на среднее.
5. LLM-судью для размытых задач вводите только после сверки его вердиктов с ручной разметкой.

[1] Агент — языковая модель, которой дали возможность самостоятельно планировать шаги и вызывать внешние инструменты (поиск, код, API), а не просто отвечать одним сообщением.

[2] Контекстное окно — объём текста (в токенах), который модель удерживает за один вызов: и входные данные, и накопленная история диалога с вызовами инструментов.