Тестирование ИИ-агентов по результатам: проверка состояния вместо доверия к ответам

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

Уверенный ответ — не доказательство

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

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

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

Сначала составьте договор о приемке

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

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

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

Поэтому в каждом случае оценки следует указать:

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

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

Три взгляда на одну операцию

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

• Результат: сообщение, которое увидел пользователь. Является ли оно точным и полезным, а также отражает ли оно незавершенную работу вместо того, чтобы скрыть её?
• Ход выполнения: наблюдаемая последовательность вызовов инструментов, результатов их работы, утверждений, повторных попыток и проверок. Выбрал ли агент правильное действие, действовал ли в рамках своих полномочий и реагировал ли разумно при сбое инструмента?
• Итог: фактическое состояние календаря по окончании попытки.

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

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

Проверяйте состояние среды через независимый канал

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

Сравните поля, которые фактически определяют корректность, с ожидаемым состоянием:

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

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

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

Поймите, чего на самом деле обещает сигнал успеха

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

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

Самый сложный момент: сразу после тайм-аута

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

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

1. Снова прочитайте целевое событие.

Проверьте, уже ли внесены запрошенные изменения.

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

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

Если после этого результат по-прежнему неизвестен, правильным шагом может быть остановка и объяснение пользователю неопределенности. Четкое сообщение лучше, чем выдуманный успех. Тот же принцип применяется и в обычном проектировании бэкенда; для информации о стороне сервера см. ключи идемпотентности для Node.js POST-эндпоинтов.

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

Сопоставьте оценщика с вопросом

Разные вопросы требуют разных оценщиков.

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

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

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

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

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

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

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

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

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

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

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

Оценивайте последовательность, а не лучшую демонстрацию

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

τ-bench ввёл показатель повторных попыток — pass^k, который определяет, добивается ли агент успеха при всех k попытках, а не хотя бы при одной. Опубликованные им показатели эффективности носят исторический характер и не должны рассматриваться как рейтинг современных агентов, однако из этого следует важный урок: «способность к успеху» и «надёжный успех» — это разные свойства, причём одна успешная попытка указывает лишь на первое из них.

На панели управления первым продуктом могут отображаться следующие показатели:

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

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

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

Превращайте каждую неудачу в тест на регрессию

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

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

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

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

Основные выводы

• Рассматривайте статус «Готово» как утверждение, требующее проверки, а не как доказательство.
• Составляйте контракт для каждого случая: начальное состояние, запрос, допустимые действия, необходимое конечное состояние и то, что нельзя изменять.
• Оценивайте результат, соблюдайте установленные границы и используйте отслеживание для объяснения различий.
• Проверяйте через независимый, авторизованный путь чтения и сохраняйте статус «Не проверено» как честный результат.
• Явно тестируйте ситуации с истечением времени, дубликатами и отсутствием действий; именно здесь терпят неудачу надежные агенты.
• Исключайте критические сбои из средних показателей качества и оценивайте надежность повторных попыток.

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