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

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

Что значит оценивать ИИ-агента?

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

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

А если вы измените его системный промпт для решения этой проблемы, как вы узнаете, что не создали новую?

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

Тем не менее, оценка агента может затрагивать несколько аспектов его работы:

Качество финального результата
Информацию, которую использовал агент
Инструменты, к которым он обращался
Следование правилам, определяющим его поведение

Распространенные метрики оценки ИИ-агентов

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

Вот список основных метрик оценки ИИ-агентов:

Успешность выполнения задачи (Task success) измеряет, достиг ли агент желаемого результата; обычно измеряется в процентах запусков, дающих валидные результаты.
Корректность действий (Action correctness) измеряет, правильно ли агент использовал инструменты, выбирал валидные аргументы и соблюдал права доступа.
Качество ответов (Answer quality) оценивает, является ли финальный результат точным, полным и полезным. Оно может включать фактическую точность, соблюдение инструкций и то, подкрепляет ли агент свои решения доступной информацией.
Надежность (Reliability) измеряет стабильность при повторных запусках, изменяющихся входных данных и в граничных случаях.
Стоимость и задержка (Cost and latency) измеряют ресурсы, необходимые для достижения успешного результата, включая время выполнения, потребление токенов и вызовы инструментов.

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

Шаг 1: Определите, как выглядит успешный запуск агента

Сначала четко опишите, что именно должен делать агент — таковы требования к продукту. Звучит очевидно, но на практике это может оказаться на удивление сложной задачей. Для этого явления даже есть название: разрыв в спецификациях (specification gap).

Вот как к этому подойти, по словам Андрея Хомутова, нашего старшего специалиста по работе с данными:

«Начните с двух вопросов: „Что можно считать выполнением работы?“ и „Что сделает внешне успешный запуск неприемлемым?“».

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

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

«Я ожидаю, что проверка траектории станет стандартной частью наборов для оценки агентов, а не чем-то, к чему мы прибегаем только тогда, когда результат выглядит подозрительно», — добавляет он.

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

Шаг 2. Создайте тестовый набор на основе реальных задач и сбоев

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

Хамель Хусейн (Hamel Husain), ML-инженер в Parlance Lab, и Шрея Шанкар (Shreya Shankar), исследовательница ML-систем и прикладных ИИ-оценок, рекомендуют начать с анализа ошибок — метода, заимствованного из машинного обучения и науки о данных. Процесс начинается с качественного анализа траекторий выполнения агента — записей, содержащих вводные данные пользователя, вызовы инструментов, извлеченную информацию и вывод агента.

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

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

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

Использование бенчмарков при оценке ИИ-агентов

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

Но бенчмарки не безупречны. Аудиты SWE-bench, обзоры бенчмарков от Epoch AI и правильные ответы, изначально отклоненные в TheoPhysEval, иллюстрируют, как несовершенные задачи или ожидаемые ответы могут исказить результаты оценки.

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

Шаг 3. Запустите агента в повторяемой тестовой среде

Воспроизводимая тестовая среда — это контролируемая установка, в которой можно запустить AI agent для одних и тех же тестовых сценариев в одинаковых исходных условиях и сравнить результаты. Она включает в себя папку с тестовыми сценариями, Python-скрипт, запускающий агента, или набор проверок для оценки результатов.

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

Чтобы настроить воспроизводимую тестовую среду, выполните следующие действия:

Сохраните репрезентативные входные данные. Сохраняйте реальные события или тестовые сценарии в той же структуре, которую ваше приложение получает в продакшене. В нашем сценарии вы сохраните запрос на техническое обслуживание, содержащий ID машины, требуемую запасную часть и дату обслуживания, в виде JSON-файла вместе со снимком данных об инвентаре и утвержденных деталях.
Выполните рабочий процесс. Пропустите каждый входной параметр через агента, включая этапы извлечения данных, вызовы инструментов и генерацию ответа.
Запишите результат и трассировку. Зафиксируйте окончательный вывод и соответствующие промежуточные действия (например, поиск по инвентарю), чтобы увидеть не только то, потерпел ли агент неудачу, но и где именно.
Повторяйте сценарии в зависимости от серьезности сбоев, частоты и сложности устранения проблемы. Приложения на базе LLM недетерминированы (они могут выдавать разные результаты при идентичных входных данных, поэтому успешный запуск не гарантирует успех следующего. Сообщайте долю успешных попыток и исследуйте сбои.

Что касается последнего, Хомутов советует измерять pass@1 (как часто агент преуспевает с одной попытки) и pass@k (вероятность успеха хотя бы один раз за указанное количество попыток). При сообщении pass@k укажите количество попыток, так как получение одного правильного ответа среди нескольких не означает, что агент знает, какой из них выбрать.

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

Шаг 4. Выберите правильный оценщик для каждой проверки

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

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

Правильный тип оценщика зависит от того, что именно вы пытаетесь проверить. Вот как соотносятся эти три подхода:

Оценщик

Лучше всего подходит для

Пример

Основное ограничение

На основе кода

Точные, проверяемые условия

Была ли рекомендованная запасная часть в списке разрешенных совместимых деталей?

Не может надежно оценивать каждое субъективное решение

LLM в качестве судьи

Оценки, зависящие от контекста

Объяснил ли агент, почему он не может порекомендовать замену?

Его суждения могут быть ошибочными или противоречивыми

Человек

Отраслевая экспертиза и неопределенные случаи

Считает ли менеджер по обслуживанию рекомендацию агента подходящей?

Дорого применять в больших масштабах

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

Как комбинировать оценщики?

Вы задаетесь вопросом: «Можно ли проверить результат по известному правилу или ожидаемому значению, или это требует человеческого суждения?»

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

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

Откалибруйте оценщик LLM по суждениям человека.

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

Вот пять этапов процесса калибровки оценщика:

Соберите примеры входных данных агента, результатов и соответствующих трассировок.
Поручите эксперту в предметной области независимо оценить, соответствует ли каждый пример критерию оценки.
Запустите оценщик LLM на этих примерах.
Сравните суждения человека и модели.
Исследуйте разногласия и уточните критерии оценщика перед тестированием на новых примерах.

Хомутов также подчеркивает важность отдельного тестирования согласованности оценщика LLM:

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

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

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

Шаг 5. Сравните версии и запустите проверки на регрессию

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

Здесь на помощь приходит регрессионное тестирование.

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

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

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

Шаг 6: Мониторинг производительности AI agent в продакшене

Оценка агента не заканчивается после развертывания вашего приложения. Как объясняют Хусейн и Шанкар, те же оценщики, которые вы используете во время разработки, также могут работать с реальными производственными данными, чтобы измерять производительность вашего агента с течением времени.

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

Этот процесс носит итеративный характер и включает в себя четыре взаимодополняющих действия:

Запустите откалиброванные оценки LLM на производственных трассировках. Выберите образцы реальных взаимодействий агента и примените оценщики, которые вы уже проверили на соответствие человеческим суждениям.
Отслеживайте показатели сбоев с течением времени. Используйте категории сбоев, установленные во время анализа ошибок, для количественной оценки повторяющихся проблем.
Продолжайте анализировать трассировки вручную. Автоматизированные оценщики обнаруживают только те проблемы, для поиска которых они созданы. Выборочно проверяйте реальные взаимодействия агентов вручную, чтобы выявить новые ошибки или необычные запросы пользователей.
Используйте A/B-тестирование для оценки бизнес-результатов (только когда это уместно). Сравнивайте различные промпты, модели или рабочие процессы с использованием таких метрик, как успешность выполнения задач, удовлетворенность пользователей и время до разрешения проблемы. Этот процесс помогает определить, улучшает ли изменение реальный опыт взаимодействия с продуктом, помимо прохождения отдельных тестов.

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

Распространенные заблуждения при оценке AI-агентов

Оценки — это просто модульные тесты. Это не так; модульные тесты представляют собой небольшие автоматизированные проверки, которые являются лишь частью оценки. Оценки также включают качественный анализ ошибок, экспертные оценки людей, мониторинг в продакшене и эксперименты для измерения качества приложения.
Платформа оценки может сделать все за вас. Готовые инструменты могут автоматизировать некоторые проверки, но они не могут определить, какие типы сбоев (виды ошибок или нежелательное поведение агента) важны для вашего продукта.
Вы можете позволить LLM оценивать все. Это серьезное заблуждение. Проводимый людьми анализ ошибок и калибровка оценщиков остаются критически важными, поскольку LLM не хватает бизнес-контекста, необходимого для обнаружения каждой проблемы.
A/B-тестирование или просто использование агента заменяет оценки. Неверно. A/B-тесты могут показать, какая версия работает лучше по выбранным метрикам, но сами по себе они не могут объяснить первопричины проблем.

Часто задаваемые вопросы об оценке AI-агентов

1. В чем разница между оценкой AI-агента и оценкой LLM?

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

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

2. Ключевые метрики для оценки AI-агентов

Метрики оценки AI-агентов делятся на две основные категории:

Метрики технической производительности: процент успешных задач, правильность действий, качество ответов, надежность (pass@1 и pass@k), задержка (latency), использование токенов и стоимость успешного выполнения задачи.
Метрики бизнеса и пользовательского опыта: удовлетворенность клиентов (CSAT), процент решения проблем, процент эскалации, коэффициент конверсии, время выполнения задачи и другие результаты, специфичные для роли агента.

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

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

3. Каковы лучшие инструменты для оценки AI-агентов?

Распространенные варианты включают:

Тестирующие фреймворки: утверждения на Python и полезны для запуска повторяемых тестовых сценариев и проверки точных условий, например, выбрал ли агент правильный инструмент или вернул ли корректный идентификатор детали.
Фреймворки оценки AI-агентов: DeepEval и инструментарий Google agent-eval toolkit поддерживают более сложные оценки, включая трассировки выполнения, оценщики на базе LLM и автоматическое регрессионное тестирование.
Платформы оценки и наблюдаемости: LangSmith, Arize Phoenix и MLflow помогают командам исследовать поведение агентов, управлять наборами данных для оценки, сравнивать версии агентов и отслеживать производительность в продакшене.

4. Как автоматизировать оценку AI-агентов?

Вы можете автоматизировать оценку AI-агентов, создавая повторяемые тесты, применяя автоматизированные оценщики и интегрируя эти проверки в рабочие процессы разработки и продакшена:

Создайте набор данных для оценки: соберите репрезентативные пользовательские задачи, ожидаемые результаты, известные сбои и трассировки выполнения агента. Включите краевые случаи, такие как неудачные вызовы инструментов, недостающая информация и несанкционированные действия.
Автоматизируйте выполнение тестов и оценку: используйте такие фреймворки, как или , для запуска тестовых сценариев и применения проверок на основе кода или оценщиков на базе LLM. Проверяйте оценки LLM на соответствие человеческим суждениям, прежде чем полагаться на их баллы.
Интегрируйте оценки в CI/CD: автоматически запускайте регрессионные тесты, когда разработчики обновляют промпты, модели, инструменты или рабочий процесс агента. Сравнивайте результаты с базовым уровнем и устанавливайте пороговые значения качества, которые предотвращают релизы в случае сбоя критически важных проверок.
Применяйте откалиброванные оценщики к выборочным трассировкам из продакшена, отслеживайте частоту сбоев и другие метрики производительности, а также расследуйте новые ошибки посредством ручной проверки.