Как оценивать ИИ-агента? Задачи, траектории, надёжность и стоимость

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

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

Термины для оценки агентов

В руководстве Anthropic, посвящённом разъяснению принципов оценки агентов, приводится полезный набор терминов:

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

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

Начните с чёткого описания задачи

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

Для агента поддержки формулировка «решить обращение» слишком расплывчата. Более точное описание задачи указывает данные клиента, применимую политику, разрешённые способы решения, требования к коммуникации и изменения, которые должны отразиться в системе учёта. После этого задачу можно оценить объективно.

Четыре уровня оценки агента

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

1. Качество результата

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

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

2. Качество траектории

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

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

3. Безопасность и соблюдение политик

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

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

4. Операционная эффективность

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

Используйте несколько типов оценщиков

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

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

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

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

Для оценки надёжности нужны повторные испытания

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

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

Два показателя надёжности отвечают на разные вопросы:

• Pass@k: вероятность того, что успешно завершится хотя бы одна из k попыток. Этот показатель полезен, когда допускается несколько попыток.
• Pass^k: вероятность того, что успешно завершатся все k попыток. Этот показатель отражает стабильность, когда успешным должен быть каждый запуск.

У системы может быть привлекательный показатель pass@k, но она всё равно может быть непригодна для автоматической работы из-за ненадёжности отдельных запусков.

Составьте репрезентативный набор задач

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

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

Оценивайте среду, а не только модель

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

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

Распространённые ошибки при оценке

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

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

От офлайн-оценки к мониторингу в рабочей среде

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

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

Практическая система оценки агента

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

Полезная система оценки может включать:

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

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

Что важно помнить об оценке ИИ-агента

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

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