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

Функция Claude Outcomes от Anthropic объединяет в одну систему цикл, который многие команды настраивают самостоятельно: агент-рабочий составляет ответ, второй компонент оценивает его по критериям, и в случае ошибки агенту предоставляется ещё одна попытка. Сама идея настолько проста, что её можно опробовать без использования готового решения, поэтому упрощённая версия была создана в контролируемой среде с выводом агента, оценщиком по критериям и ровно одной попыткой повтора.

Вопрос

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

Здесь решающую роль играют окончательные действия, поскольку многие сбои реальных операторов не связаны с качеством текста. Ответ может выглядеть хорошо, JSON можно распарсить, но выбранное действие всё равно может оказаться неверным. Это приводит к ошибкам в процессе обслуживания. Например, оператор возвращает значение DENY, хотя правильным было NO_ACTION: даже осторожно сформулированные обоснования не могут это исправить.

Настройки

Для тестирования использовались тридцать синтетических случаев обслуживания и одна модель — gpt-5.4-mini. Такой пример нельзя считать эталоном. Важно то, как проявлялись сбои: какие из них были устранены системой, какие она пропустила и где проявляются последствия этих ошибок.

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

APPROVE
DENY
ASK_CLARIFYING_QUESTION
ESCALATE
NO_ACTION

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

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

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

Baseline:
case -> agent -> final action

Gated:
case -> agent -> rubric judge
if failed -> retry once
retry answer -> final action

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

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

Рецензент, у которого нет ключа ответов

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

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

Настоящий этап проверки ставит другой вопрос: при решении DENY агент неправильно считает, что поддержка является ответственной за принятие решения, в то время как дело находится в другом процессе обработки?

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

Что произошло

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

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

Что было исправлено

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

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

Ещё один случай ремонта касался устройства, предназначенного для замены. Клиент попросил службу поддержки отправить его заново, но утром уже была создана заявка RMA, ожидавшая сканирования на складе. Базовый алгоритм выбрал значение DENY, в то время как ожидаемым действием было NO_ACTION. Отклонение запроса неверно отражало ситуацию, поскольку клиент соответствовал всем требованиям. Процесс замены уже был запущен, и службе поддержки не следовало открывать дублирующую заявку RMA. Повторная обработка запроса привела к выбору значения NO_ACTION.

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

Что он не мог исправить

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

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

Это меняет подход к оценке шаблона для промышленного использования. Механизм контроля может заметить, что действие нарушает правило, но обнаружение проблемы не означает её устранения. Предположим, модель не может отличить вариант «отклонить запрос» от варианта «не вмешиваться, поскольку решение принимает другой рабочий процесс». В таком случае даже отмеченный как проблематичный ответ может остаться без изменений. То, что что-то кажется безопасным, не делает действие правильным, а код DENY кажется консервативным, но всё равно ошибочным, если у агента нет полномочий в данном случае.

В чём можно доверять

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

Большая осторожность требуется, когда результат субъективен:

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

Изменения в продакшене, которые стоит внести

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

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

Вывод

Механизмы контроля дают результат, когда понятие «завершение» можно сформулировать в виде контракта. В данном случае контракт был простым: выбрать одно окончательное действие, которое не нарушает установленные ограничения. При таком условии механизм контроля сократил количество неверных окончательных действий с 6 из 30 до 2 из 30.

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

Дополнительная литература

Документация API Anthropic по определению результатов и статья в руководстве, посвящённая агентам, которые проверяют свою работу, охватывают функции управления, имитируемые в этом эксперименте.