Тестування механізму перевірки, який повторно розглядає неправильну кінцеву дію агента.

Функція 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 проблем базової версії. Більшість виправлень стосувалися випадків, коли базова версія занадто швидко відхиляла пропозиції. Політика не передбачала негайної затвердження, але також не вимагала відмови. Кращим рішенням було попросити уточнень або почекати на інший процес обробки.

Надійшов запит на зміну електронної пошти облікового запису. Він надійшов з нового пристрою, процедура MFA ще не була завершена, а особа, яка подала запит, знала код поштового індексу для оплати. Згідно з правилами, підтримка могла розпочатися лише після завершення процедури MFA або проведення іншої схваленої перевірки прав власності. Базова стратегія передбачала відповідь 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 щодо визначення результатів та стаття у їхньому посібнику про агентів, які перевіряють власну роботу, охоплюють функції керування, які відображають цей експеримент.