Как измерять качество ИИ-агента

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

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

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

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

Фраза «агент должен хорошо отвечать пользователям» почти бесполезна для оценки. Что значит хорошо? Дать правильный ответ? Решить вопрос без сотрудника? Сделать это за две минуты? Не совершить ошибочного действия?

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

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

Не путать качество ответа и качество выполнения задачи

Для чат-бота ответ часто и является конечным результатом. У агента всё сложнее.

Например, сотрудник пишет: "Найди неоплаченные счета клиента, проверь срок задолженности и подготовь письмо менеджеру."

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

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

Основная метрика — доля успешно выполненных задач

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

Например, подготовили 200 тестовых сценариев. В 174 случаях агент достиг нужного результата без критических ошибок. Условный показатель успешности — 87%. Но сама цифра мало что значит без правил оценки. Нужно заранее определить, какие отклонения допустимы.

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

Ошибки имеют разную цену

Одинаковая доля успешных задач может скрывать совершенно разное качество.

Представим двух агентов с показателем 95%. Первый в оставшихся 5% случаев не может найти информацию и передаёт вопрос человеку. Второй иногда уверенно сообщает неверные данные или выполняет неправильное действие в системе. Формально результат одинаковый. Для бизнеса — нет.

Ошибки имеет смысл разделять как минимум по критичности:

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

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

Проверять фактическую корректность отдельно

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

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

Особенно это важно для агентов, которые работают поверх RAG, корпоративной базы знаний, CRM, ERP или других внутренних систем.

Оценивать использование инструментов

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

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

Отдельно измерять самостоятельность

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

• 60% запросов решены без участия сотрудника;
• 25% корректно переданы человеку;
• 10% потребовали уточнения;
• 5% закончились ошибкой.

Такое распределение информативнее одной цифры «агент справляется в 85% случаев». При этом передача человеку сама по себе не обязательно является неудачей. Если агент понимает границы своих возможностей и вовремя эскалирует сложный случай, это может быть правильным поведением. Плохой сценарий — когда он должен передать задачу сотруднику, но вместо этого продолжает действовать самостоятельно.

Скорость тоже важна, но не сама по себе

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

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

Считать стоимость успешной задачи

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

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

Нужен набор тестовых сценариев

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

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

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

Тесты должны меняться вместе с агентом

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

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

Онлайн-метрики дополняют тесты

Хорошие результаты на тестовом наборе ещё не гарантируют такой же результат после запуска. В реальной эксплуатации стоит отслеживать:

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

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

Бизнес-метрики отвечают на главный вопрос

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

В итоге оценка должна отвечать не только на вопрос «насколько хорошо работает ИИ?», но и на вопрос «стал ли благодаря ему лучше сам процесс?»

Не искать одну идеальную цифру

Для ИИ-агента практически никогда не существует универсального показателя вроде «качество — 93%». Гораздо полезнее небольшая система метрик. Например:

Что проверяем	Возможная метрика
Выполнение задачи	Task Success Rate
Корректность данных	Доля фактически верных результатов
Безопасность	Частота критических ошибок
Самостоятельность	Доля задач без участия человека
Эскалация	Доля корректно переданных человеку случаев
Производительность	Время выполнения задачи
Экономика	Стоимость успешной задачи
Польза для бизнеса	Изменение показателей процесса

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

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