Оценка ИИ-агентов: как проверять многошаговую работу и находить ошибки

Почему правильного ответа недостаточно для оценки ИИ-агента

В обычном сценарии работы с LLM объект оценки сравнительно прост: пользователь отправляет запрос, модель возвращает ответ, после чего можно проверить его точность, полноту, релевантность или соответствие инструкции.

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

ИИ-агент может последовательно принимать решения, обращаться к API, искать информацию в базе знаний, изменять записи, учитывать предыдущие шаги и выбирать, продолжать работу или остановиться.

Из-за этого финальный текст показывает только часть картины.

Output, Outcome и Trajectory — три разных объекта оценки

Представим, что ИИ-агент сообщает:

Это output — сообщение пользователю.

Но реальный эффект нужно проверять отдельно. Если order.status действительно изменился на cancelled, это уже outcome — фактическое изменение данных по итогам работы.

Когда агенты взаимодействуют с API, CRM, базой данных или другими сервисами, оценивать нужно не только текст ответа, но и последствия совершённых действий.

Есть и третий уровень — траектория выполнения (trajectory): последовательность решений и операций, через которую ИИ-агент дошёл до цели.

Хороший сценарий может выглядеть так:

find_order
→ check_status
→ cancel_order
→ verify_result
→ stop

Другой запуск может закончиться тем же статусом, но пройти иначе:

find_order
→ wrong_action
→ error
→ retry
→ cancel_order
→ duplicate_action
→ success

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

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

Что именно нужно оценивать у ИИ-агента

Для диагностики полезнее не искать одну универсальную метрику, а рассматривать несколько уровней работы системы.

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

Такую декомпозицию можно использовать как рабочую модель, но не как единый отраслевой стандарт. Разные AI-платформы используют сходные уровни анализа, однако состав evaluators и конкретные метрики различаются.

Часть evaluation относится не к качеству ответа, а к соблюдению заданной политики. Если политика AI-системы разрешает определённую функцию только после подтверждения человека или ограничивает полномочия агента, нарушение такого правила нужно фиксировать отдельно.

Outcome-first, но не outcome-only

Если конечный эффект можно объективно подтвердить, начинать стоит с него.

ИИ-агент должен создать запись — проверяем её наличие. Должен изменить заказ — смотрим статус. Должен сформировать файл — убеждаемся, что документ действительно появился и соответствует требованиям.

Но успешный outcome ещё не заканчивает анализ.

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

Минимум, с которого можно начать

Для первой версии системы оценки достаточно контролировать четыре аспекта:

• достигнута ли фактическая цель;
• верно ли агент работает с доступными функциями и API;
• допустима ли его траектория;
• повторяется ли успех в нескольких запусках.

Восстановление, остановку, вмешательство человека, стоимость и время можно добавлять по мере роста сложности и риска.

Почему одного общего score недостаточно

Представим dashboard:

Agent Quality: 82 / 100

Такое число удобно как общий индикатор, но плохо объясняет причину отклонения. Неясно, ошиблась ли модель при принятии решения, были ли неверными параметры, не сработал ли API или агент остановился не в тот момент.

Поэтому общий score можно использовать для мониторинга или как release gate, но показатели разных уровней лучше сохранять отдельно.

Как трассировка помогает увидеть, что произошло внутри выполнения

Чтобы анализировать многошаговый процесс, его нужно сделать наблюдаемым. Для этого используется трассировка (tracing).

USER TASK
↓
AGENT STEP
↓
TOOL CALL
↓
TOOL RESULT
↓
STATE / OBSERVATION
↓
NEXT ACTION
↓
RETRY / RECOVERY
↓
STOP
↓
OUTCOME

В зависимости от платформы trace может фиксировать запросы к модели, обращения к API, параметры, ответы сервисов, временные метки, длительность операций и handoff-события. Так можно видеть, что происходило на каждом шаге.

Trace при этом не равен скрытому chain-of-thought. Для оценки достаточно наблюдаемых решений и событий AI-системы.

Tracing, logging, observability и evaluation — не одно и то же

Например:

Tool A
→ Tool B
→ Tool A

Trace показывает последовательность. Но он не отвечает сам по себе, был ли повтор Tool A необходим.

Для этого нужен evaluator, assertion или другое правило контроля.

Как по trace найти место, где агент ошибся

Главная ценность оценки ИИ-агента — возможность определить, на каком этапе возникло отклонение.

Сначала проверить outcome

Первый вопрос — достигнута ли поставленная цель.

Если агент сообщает «клиент обновлён», но запись в CRM или базе осталась прежней, уже ясно, на каком уровне искать причину.

Затем проверить выбор инструмента и параметры

Каждое действие агента можно разбирать отдельно: какой API или сервис выбран, какие значения переданы, завершилась ли операция и как ИИ-агент использовал ответ.

подходящая функция выбрана
↓
параметры проходят schema validation
↓
значения соответствуют запросу
↓
операция завершена
↓
ответ использован в следующем решении

Например:

cancel_order(order_id="1027")

JSON валиден и соответствует схеме.

Но если пользователь просил отменить заказ 1072, действие всё равно неверно.

То есть техническая валидность параметров не гарантирует их смысловую точность.

Затем проверить trajectory и контекст

Даже если отдельная операция выполнена успешно, следующий шаг может основываться на устаревших или неверно интерпретированных данных.

Нужно проверить обязательные действия, порядок шагов, запрещённые операции и использование предыдущих наблюдений.

Здесь особенно важно учитывать качество данных. Неполные, устаревшие или противоречивые входные данные могут привести к плохому решению даже тогда, когда сама модель и интеграция работают штатно.

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

Проверить восстановление при отказе

Timeout, недоступный API или пустой ответ сервиса возможны и в хорошо спроектированной системе.

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

FAILURE
↓
AGENT RECOGNIZED IT?
↓
RETRY?
↓
CHANGED ARGUMENTS?
↓
ALTERNATIVE PATH?
↓
FALLBACK?
↓
ESCALATION?

Повторная попытка допустима, если есть основания ожидать успеха. Если же ИИ-агент снова отправляет идентичный запрос, не меняя стратегию, ресурсы и время расходуются без прогресса.

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

Проверить завершение задачи

ИИ-агент может остановиться слишком рано, сообщить об успехе без подтверждения, зациклиться или продолжить действия, когда цель уже достигнута.

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

Как устроен сам цикл принятия решений, подробнее разобрано в материале «Как работает AI-агент: Agent Loop от цели до результата».

Почему одной эталонной траектории часто недостаточно

Интуитивный подход — задать один правильный путь и сравнивать с ним каждый запуск.

verify_identity
→ request_approval
→ process_refund

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

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

Разные пути могут быть одинаково хорошими, если ИИ-агент соблюдает правила и достигает требуемого эффекта.

Как построить eval-набор до запуска агента

Оценка должна охватывать не один демонстрационный пример, а разные сценарии использования.

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

В eval set полезно включать разные запросы пользователей, неполные данные, отказы API, ограничения политики, сценарии с обязательным подтверждением и случаи, где важно проверить остановку или восстановление.

Качество самого набора также имеет значение: если примеры не отражают реальные рабочие процессы, высокая оценка на тестировании мало говорит о поведении AI-системы в production.

Каким evaluator проверять разные требования

Если условие можно проверить кодом, такой подход обычно проще и воспроизводимее.

Модель-оценщик полезна там, где нет одного точного эталона и требуется анализ текста или траектории.

LLM-as-Judge полезен, но не является ground truth

LLM-as-Judge позволяет масштабировать оценку сложных ответов AI и многошаговых сценариев.

Но решения второй модели зависят от критериев, prompt и контекста. Поэтому такую оценку полезно предварительно сравнить с экспертной разметкой на части набора данных.

Так команда разработки может понять, в каких задачах автоматический grader достаточно надёжен, а где всё ещё нужен человек.

Если агент ещё проектируется, eval-набор и критерии полезно определить заранее. См. «Как создать ИИ-агента».

Один успешный запуск ещё не означает надёжность

Здесь важно различать capability и reliability.

Capability отвечает на вопрос: способен ли ИИ-агент решить такую задачу?

Reliability отвечает на другой вопрос: насколько стабильно AI-система работает при повторных попытках?

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

Два запуска одного ИИ-агента могут привести к разным решениям и траекториям. Один удачный запуск подтверждает capability, но не доказывает reliability.

pass@k показывает, был ли хотя бы один успешный запуск среди k попыток.

pass^k показывает, успешны ли все k попыток.

Для production-систем это важное различие: возможность иногда получить правильный ответ не равна стабильной работе.

Что меняется после выхода агента в production

Даже хороший offline eval set не способен заранее воспроизвести весь длинный хвост реальных запросов и рабочих процессов.

В production появляются новые сочетания данных, нестабильность API, необычные действия пользователей, аномально долгие или дорогие запуски.

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

Поэтому offline evaluation и production monitoring дополняют друг друга.

PRODUCTION TRACE
↓
FAILURE SIGNAL
↓
FAILURE CLUSTER
↓
REPRODUCIBLE TEST CASE
↓
OFFLINE REGRESSION
↓
FIX
↓
VERIFY
↓
RELEASE
↓
PRODUCTION

Трассы, аналитика и обратная связь помогают находить новые случаи, а затем добавлять их в набор регрессионных тестов.

Регрессионную проверку стоит повторять при изменении модели, prompt, настроек API, логики workflow или других компонентов AI-системы.

Так команда может контролировать, не ухудшила ли новая версия уже работавшие сценарии.

Как интерпретировать участие человека, стоимость и latency

Не каждую метрику стоит напрямую считать качеством ИИ-агента.

Не всякое вмешательство человека — ошибка

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

Другая ситуация — оператор подключается потому, что AI-система не смогла самостоятельно продолжить работу.

Поэтому intervention rate нужно анализировать вместе с причиной эскалации.

Подробнее о Human-in-the-Loop, approvals и границах автономности — в материале «Автономность ИИ-агента: сколько свободы давать AI-агенту».

Низкая стоимость не означает лучшего агента

Первый ИИ-агент может стоить условно $0.05 за попытку и решать только половину задач. Второй стоит $0.08, но работает значительно стабильнее.

Поэтому иногда полезнее считать cost per successful task, а не только цену одного запуска.

Latency зависит от пользовательского сценария

Для поддержки клиентов в реальном времени задержка непосредственно влияет на пользовательский опыт. Для фоновой обработки документов те же несколько секунд могут не иметь большого значения.

Полезно различать общее время до ответа, время работы модели, задержку API и дополнительное время, которое уходит на retries.

Минимальная система оценки ИИ-агента на практике

Для первой версии не обязательно сразу внедрять сложную платформу оценки.

1. Определить ожидаемый outcome. Какой эффект должна подтвердить система или база данных?
2. Зафиксировать правила. Какие операции разрешены, запрещены или требуют approval?
3. Записывать trace. Решения модели, API-запросы, параметры, ответы и переходы между шагами.
4. Разделить критерии. Outcome, trajectory, recovery и завершение не должны сливаться в один score.
5. Проверять кодом формальные условия. Схемы, ID, статусы, budgets и обязательные операции.
6. Использовать модель-оценщик или человека для неоднозначных задач.
7. Повторять тесты. Один успешный запуск не доказывает стабильность.
8. Возвращать production-кейсы в regression suite. Новые реальные задачи становятся частью тестового набора.

Такая методика позволяет не просто оценить ИИ-агента, а понять, как он работает, почему принимает конкретные решения и насколько его поведение остаётся стабильным при изменении запросов и условий.

Вывод

Смысл оценки ИИ-агентов не в том, чтобы присвоить модели ещё один общий балл. Задача — сделать работу AI-системы проверяемой.

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