Семь метрик вместо одного балла: в блоге Hugging Face разобрали оценку ИИ-агентов

Что произошло

24 сентября 2026 года в блоге Hugging Face вышла статья «KI-Agenten evaluieren: 7 Metriken für Qualität, Kosten und Sicherheit» — практический разбор того, как измерять качество ИИ-агентов. Материал опубликован как Community Article, его автор — Kai | Core Architecture; текст продолжает немецкоязычную серию об агентных системах, первая часть которой объясняла, что такое ИИ-агент.

Главный тезис разбора: оценка отдельного ответа языковой модели и оценка агента — разные задачи. Агент выполняет несколько шагов, поэтому одного вопроса «правильный ли пришёл ответ» недостаточно; автор формулирует второй вопрос так: решил ли агент задачу надёжным, эффективным и контролируемым путём.

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

Семь метрик

Первую метрику автор называет Task Success Rate — доля задач, где достигнута заданная цель. Пример из текста: агент поддержки проходит 100 тестовых задач, 82 решает полностью, 11 корректно эскалирует и 7 разбирает неверно или неполно. Корректная эскалация может считаться успехом, а может учитываться отдельно, поэтому до начала измерений нужно договориться, что такое «успех»; определение «агент должен быть полезным» автор считает непригодным и предлагает формулировки вида «определить текущий статус заказа, назвать срок доставки, при отсутствии данных эскалировать сотруднику».

Вторая — Tool Call Accuracy: выбран ли правильный инструмент, переданы ли корректные параметры и применён ли инструмент в нужный момент. Автор отдельно предупреждает, что технический успех вызова ничего не доказывает: ответ HTTP 200 не означает, что действие было правильным, поэтому техническую успешность вызовов и смысловую точность инструментов стоит измерять раздельно. В документации Microsoft Foundry для агентов действительно разведены оценщики выбора инструмента, точности его входных данных, использования результата инструмента и общая оценка качества вызова инструмента.

Третья метрика — Grounding Error Rate, доля утверждений, недостаточно подкреплённых контекстом, результатами инструментов или надёжными источниками. Иллюстрация в статье: инструмент вернул «доставка задержана, новая дата неизвестна», а агент ответил «ваш заказ будет доставлен в пятницу». Проблема здесь не в вызове инструмента, а в истолковании его результата, и последствия тем серьёзнее, чем больше действий агент выполняет самостоятельно.

Четвёртая — Human Correction Rate, частота, с которой людям приходится исправлять работу агента: переписать ответ, переделать вызов инструмента, отменить решение, доработать документ или вручную завершить процесс. Автор подчёркивает разницу между плановым согласованием и незапланированным ремонтом: если подтверждение перевода заложено в процесс, это не рост ошибок, а если сотрудник регулярно исправляет неверно выбранных получателей — это уже дефект качества.

Пятая — Safety Violation Rate: раскрытие чувствительных данных, выполнение запрещённых действий, обход правил безопасности, некритичное принятие данных из недоверенных источников, реакция на внедрение команд в промпт, выход за пределы своей задачи. Для критичных систем средняя величина мало что говорит: агент может сработать верно в 999 случаях из 1000, но один оставшийся случай окажется неразрешённым переводом. Microsoft Foundry держит для этого отдельные оценщики рисков и безопасности, а Google Cloud — безопасность как самостоятельное измерение.

Шестая — Cost per Successful Task, отношение всех затрат на прогоны агента к числу реально решённых задач; учитываются вызовы моделей, внешние API, поиск, обращения к базам данных, исполнение кода, хранение и дополнительные модели-критики. Пример из статьи: вариант A — 100 задач, 90 успешных, 9 евро, то есть 0,10 евро на успешную задачу; вариант B — 100 задач, 95 успешных, 28,50 евро, то есть 0,30 евро, втрое дороже при небольшом выигрыше в качестве.

Седьмая — End-to-End Latency: полное время от ввода пользователя до финального ответа или действия, включая вызовы инструментов и промежуточные шаги. Автор советует смотреть не только среднее, но и перцентили, потому что среднее скрывает выбросы; его пример — p50 около 4,1 секунды при p95 около 16,8 секунды означает, что половина запросов завершается за четыре секунды, но пять процентов ждут почти семнадцать.

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

Путь и результат: вендоры уже разделяют эти измерения

Разделение результата и пути не является изобретением одной публикации. Google Cloud в документации по оценке агентов в Vertex AI прямо предлагает два варианта: оценку финального ответа — достиг ли агент цели — и оценку траектории, то есть последовательности вызовов инструментов, которая к этому ответу привела; метрики для обоих вариантов можно получить одним запросом SDK, а время выполнения и признак сбоя вызова возвращаются по умолчанию.

Microsoft Foundry описывает ту же логику как два подхода: системная оценка end-to-end результата и процессная оценка пошагового исполнения. Среди встроенных оценщиков агентов названы завершение задачи, следование задаче, точность вызова инструментов, успешность вызовов, опора на источники и эффективность навигации, а сами оценки выдаются как бинарные «прошло / не прошло».

Есть и третья опора — сама документация Hugging Face: в руководстве по сборке хороших агентов библиотеки smolagents советуют сокращать число вызовов языковой модели, объединяя инструменты и шаги, потому что каждый лишний вызов увеличивает стоимость, задержку и риск ошибки. Это ровно те величины, которые в разборе вынесены в отдельные метрики стоимости и времени.

Автор добавляет важное различие между процессами: там, где шаги детерминированы — проверить личность, получить баланс, проверить лимит, подготовить транзакцию, — ожидаемую последовательность проверять осмысленно; там, где процесс открытый, например «исследуй пять подходящих моделей», допустимы разные пути, и оценивать нужно иначе: использованы ли необходимые инструменты, не появилось ли лишних шагов, учтены ли релевантные источники, объяснимо ли итоговое решение.

Набор тестов и трассы

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

Второй инструмент — трассы: они показывают не результат, а ход работы, включая ввод пользователя, вызовы модели, выбор инструмента, его параметры, результаты, ошибки и длительности. Офлайн-оценка на наборе тестов и онлайн-мониторинг в продакшене дополняют друг друга; переоценивать агента автор советует после изменений системного промпта, модели, описаний инструментов, API, источников данных, поиска, памяти, логики оркестрации, разрешений и правил безопасности — потому что даже неизменённый агент меняет поведение вместе с внешними системами.

Для качественных критериев, которые нельзя проверить кодом, в статье допускаются модели-судьи, но не как абсолютная истина: автор предлагает сочетать детерминированные проверки — использован ли нужный инструмент, верен ли номер клиента, уложилась ли задержка в порог, не вызван ли запрещённый инструмент — с рубриками моделей, человеческой выборкой и метриками продакшена.

Порядок внедрения и типичные ошибки

Процесс в статье разложен на шесть шагов: определить, что считается успехом; собрать 30–100 представительных тестовых случаев; измерять семь ключевых значений; сохранять трассы, чтобы ошибки оставались объяснимыми; задать пороги — например, доля решённых задач не ниже 90 процентов, ноль нарушений безопасности, менее пяти процентов правок человеком и p95 задержки меньше 15 секунд; и сравнивать версии, отвечая не на вопрос «хороша ли версия B», а на вопрос «стала ли версия B измеримо лучше версии A и какой ценой». Приведённые числа автор называет именно примерами, а не нормой, поскольку осмысленные пороги зависят от процесса и риска.

Отдельный раздел посвящён типичным ошибкам: проверять только финальный ответ — тогда ошибки выбора инструментов и траектории остаются невидимыми; опираться только на средние — средняя задержка и средняя успешность скрывают проблемные выбросы; брать слишком простые тесты — агент, знающий только идеальные условия, кажется лучше, чем он есть; игнорировать стоимость — дополнительные вызовы модели могут улучшать качество, но съедать выгоду; считать корректные эскалации ошибками, хотя агент должен уметь распознавать неуверенность; и никогда не обновлять тестовые данные, хотя продакшн-сбои должны превращаться в новые тестовые случаи.

Что из этого следует

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

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