Как оценивать ИИ-агентов: тестовые наборы, оценщики и регрессионные проверки

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

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

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

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

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

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

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

При этом оценка агента может охватывать несколько аспектов запуска:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Развернуть

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

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

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

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

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

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

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

Выбор типа грейдера зависит от того, что вы хотите проверить. Вот как соотносятся три подхода:

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

Как комбинировать грейдеры?

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

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

Важно! LLM-грейдер может неверно интерпретировать доказательства или неправильно применить рубрику. Поэтому ему нужен дополнительный этап оценки — калибровка по суждениям людей.

Откалибруйте LLM-грейдер по суждениям людей.

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

Вот пятиэтапный процесс калибровки грейдера:

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

Хомутов также подчеркивает, как важно отдельно проверять стабильность LLM-грейдера:

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

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

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

Шаг 5. Сравнивайте версии и проводите регрессионные проверки

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

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

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

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

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

Шаг 6: отслеживайте качество работы ИИ-агента в продакшене

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

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

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

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

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

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

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

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

1. Чем оценка ИИ-агентов отличается от оценки LLM?

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

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

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

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

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

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

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

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

Распространённые варианты:

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

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

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

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