Когда вмешиваться в траекторию AI-агента: причинная оценка вместо одного benchmark score

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

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

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

Работа Sawarni et al. формализует эту задачу как динамический причинный вывод и предлагает рандомизировать вмешательство в последовательных точках траектории. Авторы демонстрируют неоднородность эффектов на τ-bench Retail, ToolSandbox и ImpossibleBench. Однако на момент подготовки исследовательского досье это препринт без подтверждённой независимой репликации. Его результаты разумно воспринимать как методологическую основу и источник гипотез, а не как универсальное доказательство эффективности конкретного механизма контроля. Эта статья предлагает методику и протокол внедрения; собственного эксперимента и новых измерений в ней нет.

Benchmark оценивает конфигурацию, а не решение внутри траектории

Статическая оценка полезна, когда нужно:

• сравнить модели или версии агента;

• обнаружить регрессию;

• проверить базовые способности;

• недорого отсеять слабые конфигурации;

• оценить сочетание агента, инструментов, инструкций и среды целиком.

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

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

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

Для каждой подходящей точки существует контрфактический вопрос:

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

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

Важно также различать три уровня наблюдения:

1. Статическая оценка показывает результат фиксированной конфигурации.

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

3. Причинная оценка проверяет, изменяет ли вмешательство исход, а не просто коррелирует с ним.

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

Единица решения — подходящая точка внутри траектории

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

Такими точками могут быть:

• предложенный вызов инструмента;

• пакет взаимосвязанных вызовов;

• неудачная отправка результата;

• обнаруженный конфликт ограничений;

• превышение числа повторных попыток;

• состояние, из которого допустима процедура восстановления.

Каждая точка должна соответствовать заранее заданному критерию допустимости (eligibility rule). Он отвечает не на вопрос «нужно ли вмешаться», а на более базовый вопрос: «Можно ли здесь безопасно и технически сравнить допустимые варианты?»

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

Вмешательство должно быть конкретным

Фраза «оценим пользу review» слишком расплывчата. Эксперимент должен зафиксировать, что именно происходит:

• действие проверяет человек или модель;

• проверяющий может только одобрить либо также заменить действие;

• допускается ли запрос дополнительной информации;

• какой запрос и какая версия модели используются;

• сколько времени отводится на ответ;

• что происходит при ошибке или тайм-ауте;

• как выполняется передача управления обратно агенту.

В экспериментах Sawarni et al. проверяющий мог одобрить вызов инструмента, заменить его или запросить дополнительные сведения. Следовательно, оцениваемое воздействие — не абстрактная «проверка», а конкретный механизм с конкретной моделью и правом изменять дальнейшую траекторию.

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

• полезна именно модель-проверяющий;

• выбран лучший момент вызова;

• дополнительная задержка не влияет на поведение;

• тот же результат сохранится при проверке человеком;

• право заменить действие лучше простого запрета.

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

Четыре метода отвечают на разные вопросы

A/B-тест на уровне сессий остаётся подходящим, когда меняется весь оркестратор или агентная конфигурация. Например, Agent Arena случайно назначает конфигурации целым реальным сессиям и оценивает причинные эффекты по наблюдаемым сигналам. Это полезный производственный аналог, но он не определяет, перед каким именно действием одной траектории нужно включить проверку.

Микрорандомизированный эксперимент переносит принцип повторных назначений на внутренние состояния сессии. В исходной методологии micro-randomized trials воздействие или контроль назначаются в каждой доступной точке решения. В агентной системе:

• участником становится траектория или сессия;

• доступностью — безопасная возможность вмешаться;

• воздействием — проверка, фильтр, корректирующая обратная связь или восстановление;

• ближайшим исходом — результат следующего инструмента, событие безопасности или стоимость восстановления;

• отдалённым исходом — конечное качество выполнения задачи.

Сначала выберите причинный вопрос, затем метод оценки

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

Локальный эффект при дальнейшем рандомизированном контроле

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

Этот эффект отвечает на вопрос:

Полезна ли проверка в текущей точке, если далее система продолжит работать в том же рандомизированном режиме?

Такой показатель удобен для поиска состояний и типов действий с положительным или отрицательным эффектом. В основной работе для него применяется перекрёстно подогнанное расширенное взвешивание по обратной вероятности назначения (cross-fitted augmented inverse-probability weighting) с известными вероятностями назначения.

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

Эффект текущего вмешательства без дальнейших вмешательств

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

Он ближе к вопросу:

Что даст исправление сейчас, если затем агент должен завершить задачу самостоятельно?

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

Выигрыш целой политики

Третий показатель — разница конечного результата между двумя полноценными политиками. Например:

• всегда исполнять вызовы напрямую;

• проверять каждый вызов;

• проверять только операции записи;

• включать восстановление после второй ошибки;

• направлять на проверку состояния с оценкой риска выше порога.

Это наиболее близкий к эксплуатации вопрос:

Что изменится, если развернуть выбранное правило маршрутизации вместо текущего?

Выигрыш политики нельзя в общем случае получить суммированием локальных эффектов. Вмешательство меняет будущие состояния, а вместе с ними — состав точек, в которых политика сможет сработать. Для оценки альтернативных продолжений и политик Sawarni et al. используют дополнительные параметрические предположения вложенной структурной модели средних (structural nested mean model) и прямо указывают это как ограничение.

Как устроить экспериментальный стенд

1. Зафиксировать экспериментальную конфигурацию

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

• версию агента и системных инструкций;

• модели и запросы проверяющего;

• версии инструментов и схем API;

• состояние или версию среды;

• критерии допустимости точек;

• смысл контрольной и экспериментальной ветвей;

• правила тайм-аутов и обработки ошибок;

• определения конечных исходов.

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

2. Записывать состояние до назначения

Минимальная запись до рандомизации должна включать:

• неизменяемый идентификатор сессии и траектории;

• задачу и версию среды;

• порядковый номер точки решения;

• причину, по которой точка признана подходящей;

• доступную к этому моменту историю и вычисленные признаки;

• предложенное действие или пакет вызовов;

• версию агента, инструментов и проверяющего;

• вероятность назначения каждой ветви;

• генератор случайных чисел или начальное значение (seed) рандомизации.

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

3. Рандомизировать только допустимые варианты

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

Для идентификации нужны и другие условия:

• Согласованность (consistency): наблюдаемый результат соответствует фактически реализованному варианту.

• Позитивность (positivity): в релевантных состояниях каждая сравниваемая политика имеет ненулевой шанс быть представленной в данных.

• Отсутствие взаимного влияния (interference): одна траектория не изменяет результат другой.

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

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

4. Записывать фактическое исполнение и исходы

После назначения нужны как минимум:

• ответ проверяющего или процедуры восстановления;

• фактически исполненное действие;

• результат инструмента;

• отклонение фактического исполнения от назначения;

• конечный результат задачи;

• метки фактически произошедших нарушений;

• число повторов и шагов;

• время ожидания и полная задержка;

• токены и денежная стоимость агента и проверяющего;

• объём человеческой работы, если она использовалась.

Отдельная фиксация назначения и исполнения необходима для контроля верности реализации вмешательства (treatment fidelity). Если ветвь «проверка» регулярно завершается тайм-аутом и фактически превращается в прямое исполнение, эксперимент оценивает уже другой механизм.

5. Считать сессию связанной системой наблюдений

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

6. Разделить поиск и подтверждение политики

Практичный процесс состоит из трёх этапов:

1. Исследовательский сбор: достаточно широкая рандомизированная политика создаёт покрытие релевантных состояний.

2. Офлайн-отбор: по журналам сравниваются кандидаты на выборочную политику.

3. Подтверждение: заранее выбранная политика проходит прямое рандомизированное сравнение с базовой.

Оценка новой политики по старым данным экономит запуски, но не устраняет неопределённость. При длинных горизонтах стандартные веса важности (importance weights) могут иметь быстро растущую дисперсию. Дважды устойчивые (doubly robust) и методы с опорой на модель (model-assisted) способны уменьшить среднеквадратичную ошибку, но не создают отсутствующее покрытие и не спасают от неверно заданной модели. Ограничения таких методов подробно обсуждаются в работе по off-policy evaluation.

Одного success rate недостаточно

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

Результат следует представлять как вектор:

• конечный успех или качество задачи;

• фактические нарушения правил;

• оценённый причинный эффект на риск нарушений, включая предотвращённые нарушения;

• оценённое число спасённых неуспешных траекторий;

• оценённое число испорченных корректных траекторий;

• повторные попытки, шаги и нагрузка восстановления;

• полная задержка и время проверяющего;

• расход токенов и денежная стоимость;

• объём человеческой проверки.

Спасение и вред нужно оценивать раздельно

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

Препринт Xiao et al. рассматривает восстановление как причинное решение и разделяет спасение и вред. Авторы сообщают о выборочной политике, которая не изменяла оценённые корректные траектории наблюдений. Это предварительный результат, но сама постановка важна: маршрутизатор должен оптимизировать не только оценённое число спасений, но и риск лишнего вмешательства. Подробнее — в работе When Harnesses Lose the Signal.

Скалярная полезность требует заранее заданных правил

Иногда системе всё же нужен один показатель для выбора политики. Тогда до анализа следует определить:

• веса качества, задержки и стоимости;

• минимально допустимый уровень выполнения;

• жёсткие ограничения безопасности;

• события, автоматически запрещающие развёртывание политики.

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

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

Что показывают три типа задач

τ-bench Retail: проверять всё и проверять выборочно — разные политики

В τ-bench Retail проверка или прямое исполнение предложенного вызова назначались с вероятностью 1/2. Проверяющий мог одобрить вызов, заменить его или запросить информацию.

Авторы обнаружили неоднородные эффекты по группам инструментов. Для GPT-5 nano положительные эффекты оценивались для ряда операций чтения и записи. Для Claude Haiku 5.5 агрегированный эффект по операциям чтения был близок к нулю, хотя для получения данных аккаунта оценивался положительный эффект.

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

Сам кейс демонстрирует главное: «всегда проверять» и «проверять только определённое семейство вызовов» — разные динамические политики. Средний benchmark score не говорит, какая из них предпочтительнее.

ToolSandbox: состояние среды делает локальную ошибку долгосрочной

ToolSandbox моделирует разговорную среду с инструментами, изменяющими состояние. Оценка использует milestones — необходимые события — и minefields, то есть запрещённые события. Основной балл допускает частичное выполнение, но может обнуляться при определённом нарушении, заданном правилами benchmark. Число ходов измеряется отдельно и отражает эффективность, а не качество задачи.

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

ImpossibleBench: успешное прохождение может означать нарушение

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

В эксперименте Sawarni et al. агент Qwen3.5 Flash получал состязательную или нейтральную обратную связь перед следующими действиями. Этот пример показывает, почему показатель completion нельзя автоматически считать полезным исходом. Более высокий процент прохождения тестов здесь потенциально означает большую склонность эксплуатировать тесты вопреки требованиям.

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

Ограничения причинного эксперимента

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

Ограниченная переносимость

Результат относится к конкретным:

• распределению задач;

• версиям агента и проверяющего;

• запросам;

• инструментам;

• семантике среды;

• критериям допустимости;

• правам вмешивающегося механизма.

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

Слабое покрытие состояний

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

Множественный поиск подгрупп

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

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

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

Replay не равен фактической рандомизации

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

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

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

1. Опишите решение контура управления. Не «полезен ли verifier», а «следует ли перед операциями записи разрешить проверяющему одобрить, заменить или остановить предложенный вызов».

2. Определите безопасные точки. Исключите необратимые и недопустимо рискованные действия или перенесите их в изолированную среду.

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

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

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

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

7. Обеспечьте ненулевое покрытие. Журналирующая политика должна реально генерировать варианты, которые планируется сравнивать.

8. Анализируйте по траекториям. Не считайте последовательные точки одной сессии независимыми наблюдениями.

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

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

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

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

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