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

Как оценить качество AI-агента: почему одних ответов мало

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

• Верный ответ неверным путём. Агент назвал правильный статус заказа, не проверив, что пишет владелец заказа. Совпало случайно: по тексту случай «пройден», а в работе это утечка.
• Неверный ответ при верных шагах. Агент сделал всё по инструкции, но в учётной системе устаревшие данные. Править нужно данные (подготовка данных), а не инструкцию, и без разбора по шагам это не отличить.
• Опасное действие вне текста. Агент вежливо ответил клиенту, но создал лишний документ. Текст безупречен, система испорчена.
• Хороший результат за плохую цену. Задача решена, но с лишними запросами и обращениями к модели; на потоке это расходы и ожидание.

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

Здесь речь о качестве агента, бизнес-эффект измеряется отдельно (как измерить эффект от внедрения ИИ): агент может работать корректно и не окупаться.

Тестирование AI-агентов на трёх уровнях: шаг, траектория, итог

В англоязычных источниках такие проверки называют evals (от evaluations); по сути это тесты, которые учитывают, что агент действует шагами.

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

Иллюстрация, а не описание проекта: агент отвечает на вопрос «где мой заказ?». Шаг: вызвал инструмент статуса с номером, который назвал клиент, а не вывел из контекста. Траектория: убедился, что пишет владелец заказа, запросил статус один раз и при сбое системы не стал повторять запрос бесконечно. Итог: клиент получил статус из системы, в карточке заказа ничего не изменено. «Зелёный» итог не отменяет красной траектории.

Тест-набор из ваших реальных случаев: четыре группы

Тестируют на запросах вашего процесса: письмах, обращениях и заявках за последний стабильный период. Придуманные примеры чище настоящих, и агент проходит их легче. Персональные данные в тестовых случаях маскируют или заменяют вымышленными; кто и как это делает, оговаривают заранее, оператор данных — заказчик (ИИ и 152-ФЗ; юридических заключений мы не даём).

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

• Эталон пишет владелец процесса, тот, кто знает, как правильно. Подрядчик предлагает формат, но не решает, что верно у вас.
• Часть случаев контрольная: на ней ничего не подгоняют. Иначе на тесте результат будет лучше, чем в работе: инструкцию подогнали под экзамен.
• Ожидания устаревают. Сменился прайс — обновляют и эталоны (сопровождение агента).
• Набор растёт: каждая реальная ошибка становится новым случаем. Размер зависит от процесса; важнее покрыть все типы запросов и четыре группы, чем набрать число.

Группу «нужно отказаться» легко упустить, а она проверяет умение сказать «не знаю» (галлюцинации ИИ в бизнесе). Провокационные случаи проверяют устойчивость к обману (безопасность AI-агентов).

Метрики качества ИИ-агента: что считать

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

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

Способы оценки результата: эталон, правила, человек и LLM-проверяющий

Способов четыре. Чем проще способ, тем он дешевле и надёжнее, начинают с простого.

• Эталон. Для того, что имеет один верный ответ: категория, номер документа, сумма, статус. Сравнение с ответом владельца процесса точное и бесплатное, но для свободного текста не годится.
• Правила в коде. Вызван ли запрещённый инструмент; нет ли в ответе внешнему адресату чужого телефона или адреса; совпадает ли сумма с суммой из системы; шла ли идентификация раньше запроса данных. Такие проверки детерминированы и запускаются при каждом изменении: что можно записать правилом, лучше записать правилом.
• Проверка человеком. Для свободного текста, спорных случаев и тона. Владелец процесса читает выборку по короткой анкете. Это дорого по времени, но только человек знает, что значит «правильно» у вас; его оценки нужны и для калибровки четвёртого способа.
• LLM-проверяющий. Другая модель (в англоязычных источниках LLM-as-a-judge, по-русски также «LLM-судья») оценивает ответ агента по критериям. Он масштабируется и берёт свободный текст, но с ограничениями.

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

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

Регрессионный прогон: проверка перед любым изменением

Регрессия — это когда после правки перестаёт работать то, что работало. У агента её вызывает почти любое изменение:

• правка инструкции: чинили один случай, сломали два других;
• смена модели или её версии, в том числе обновление у поставщика под тем же названием (некоторые поставщики так делают, проверяйте политику версий);
• изменение описания инструмента или API системы: обновили 1С или CRM, поменялось поле;
• обновление базы знаний или параметров поиска по ней; новый инструмент или тип запросов.

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

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

Как проверить ИИ-агента перед запуском: условный протокол приёмки

Условный пример, не описание проекта: агент отвечает о статусе заказа и готовит черновик возврата. Пороги записывают в техзадание по вашим цифрам.

1. До работы. Владелец процесса и подрядчик собирают набор по четырём группам, записывают ожидания, делят его на рабочую и контрольную части. Набор, метрики и пороги входят в техзадание. Настройка идёт по рабочей части, контрольная не открывается.
2. Приёмочный прогон. Замороженная версия (инструкция, модель, инструменты и база не меняются) проходит контрольную часть на тестовой копии систем, а не на боевых данных; каждый случай гоняют несколько раз.
3. Отчёт: таблица по группам и метрикам и разбор каждого проваленного случая по журналу шагов и причине (данные, инструкция, инструмент, модель).
4. Решение владельца: запускаем; запускаем с суженной зоной (агент берёт два типа запросов из пяти, остальное идёт человеку); не запускаем. «Не запускаем» — нормальный исход, как и отказ по итогам аудита.
5. Боевой режим с подтверждением. На старте человек подтверждает каждое решение агента; подтверждения снимают по отдельным операциям, когда данные показывают, что агент справляется.

После запуска: мониторинг и обратная связь

Тест-набор — это то, что вы предусмотрели. Клиенты формулируют иначе, поэтому проверка продолжается в работе.

• Журнал шагов: что агент запросил, что получил, что ответил. Без него нельзя разобрать жалобу и пополнить набор. Какие персональные данные хранить, решает заказчик как оператор.
• Выборочное чтение: сотрудник читает случайные диалоги по той же анкете, что на приёмке, и диалоги с жалобами.
• Сигналы: доля передач человеку, ошибки инструментов, рост числа шагов, отметки «не помогло».
• Каждая найденная ошибка идёт в набор: владелец указывает верный ответ, случай добавляют, после правки запускают регрессию.

Что собирать и что вывести на панель, разбирает статья как мониторить AI-агента.

Приёмка фиксирует, что агент умеет на момент запуска; мониторинг и регрессия показывают, что это сохраняется.

Как мы строим проверку в проектах

Метрику пилота записываем в договор до начала работ, критерии приёмки и выборку для проверки фиксируем в техзадании. Экспресс-аудит (50 000 ₽, 5-7 рабочих дней, засчитывается в проект) показывает, есть ли что мерить: собирается ли показатель и есть ли тот, кто напишет эталон. Если измерить результат нельзя, это тоже результат аудита. Нулевых ошибок мы не обещаем, мы закладываем способ видеть ошибки и сравнивать версии. Об услуге — разработка AI-агентов.

Чек-лист: что проверить перед запуском

• Для каждого типа запросов словами записано, что считается успехом.
• Набор собран из реальных обращений, включает четыре группы и контрольную часть; эталоны писал владелец процесса.
• Каждый случай прогоняется несколько раз; проверены шаг, траектория, итог и состояние системы.
• Для опасных действий есть правило остановки, запись и необратимые шаги идут через человека.
• Оценки LLM-проверяющего сверены с оценками людей, и он не единственный судья.
• Записано, после каких изменений прогон обязателен; после запуска есть журнал шагов и выборочное чтение.
• Назначен тот, кто решает «запускаем, сужаем или не запускаем», и решает по отчёту.