Как оценивать работу AI-агентов в проде

2026-05-28 · 7 мин

Когда мы в Raft выводим агента в продакшен, первый вопрос от заказчика почти всегда один и тот же: «А ему можно доверять?» И это правильный вопрос — но обычно он задан неправильно. Доверие к агенту — это не «он ни разу не ошибётся», а «он даёт повторяемый ожидаемый результат на множестве взаимодействий». Мы недавно разобрали эту тему подробно, и я хочу пересказать ключевые идеи: за последний год в моей команде через это прошёл почти каждый проект, где есть LLM в цикле принятия решений.

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

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

Один проверочный кейс — это не просто «вопрос и эталонный ответ». В агентных системах он распадается на несколько частей:

Задача и критерий успеха — что именно должно произойти и как мы поймём, что всё хорошо.
Прогон — фактический выход системы на этом входе.
Грейдер (evaluator) — логика, которая выносит вердикт pass/fail.
Транскрипт действий — вызовы инструментов и шаги рассуждения, а не только финальный ответ.
Итоговое состояние — что в итоге изменилось в системе.

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

Путь и результат — это разные вещи

Тут кроется тонкость, которую часто пропускают. Оценивать нужно по двум осям:

Корректность результата — пришёл ли агент к правильному выводу.
Разумность пути — сколько ресурсов и времени он потратил, не нарушил ли политики, не полез ли куда не следует.

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

Почему «95% прохождений» — пустая цифра

Для бинарных решений (одобрить / отклонить) одной общей доли успеха катастрофически мало. Нужны нормальные метрики классификации:

Precision — из всех заявок, которые агент одобрил, сколько реально соответствовали политике.
Recall — из всех заявок, которые следовало одобрить, сколько он реально одобрил.
F1 — гармоническое среднее, балансирующее эти два числа.

«95% прохождений» ничего не значат, пока вы не знаете, где сидят ошибки: в ложных одобрениях или в ложных отказах. У этих двух типов совершенно разная цена для бизнеса.

Ложно одобрить возврат на крупную сумму и ложно отказать лояльному клиенту — это разные катастрофы, и усреднять их в одну зелёную цифру нельзя. Для непрерывных шкал (тон, ясность, полнота ответа) confusion matrix не подходит — там смотрят на распределение оценок и на согласованность оценщиков между собой.

Кто ставит оценки

В статье хорошо разложены типы грейдеров, и на проектах мы комбинируем их ровно так же:

Люди — дорого, но качественно; незаменимы при сборке первого датасета и периодической калибровке.
Детерминированные алгоритмы — быстро и точно там, где есть чёткое правило: regex, статический анализ, проверка чисел, факт вызова нужного инструмента.
LLM-as-judge — компромисс по скорости и цене, но со своими искажениями: любят многословные ответы, чувствительны к формулировке промпта.
Агенты-оценщики — когда логика сложная и надо судить и результат, и путь.

На одном кейсе из статьи это видно наглядно. Возврат товара: на 12-й день — одобрить (детерминированный грейдер проверяет факт вызова инструмента, LLM оценивает тон). На 75-й день — отклонить с объяснением (детерминированный проверяет, что возврат денег не прошёл, LLM — что отказ дан сочувственно). На 65-й день с размытой жалобой без доказательств — правильное действие не «да» и не «нет», а запросить документы или эскалировать на человека.

Где команды спотыкаются

Раздел про типичные ошибки я бы распечатал и повесил у каждой команды:

Закон Гудхарта — оптимизируем метрику вместо реальной пользы. Оценки растут, а жалоб становится больше.
Замороженные evals — датасет отражает устаревшие предположения, а поведение в проде давно уехало.
Иллюзия зелёного дашборда — команда перестаёт читать сырые транскрипты, и новые классы отказов копятся незамеченными.
Одно агрегатное число — «92% успеха» прячет провалы, сконцентрированные в самом дорогом сегменте.

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

Моя практическая ремарка

Идеал из статьи — eval-driven development: пишем проверки до продукта. На практике так выходит редко, и это нормально — главное правило простое: чем раньше, тем лучше. Как только у вас есть хотя бы десяток честных кейсов с однозначным критерием, рефакторинг агента перестаёт быть прыжком в темноту, а становится обычной инженерной задачей с зелёными и красными тестами. Именно в этот момент, по моему опыту, заказчик и начинает по-настоящему доверять системе — не потому что ему пообещали, а потому что показали повторяемый результат.

Полный разбор — в нашей статье на Хабре: Как оценивать работу агентов.