Коротко: разбор сбоя ИИ-агентов должен найти не последнюю неправильную фразу, а первое критическое отклонение, после которого цепочка уже не могла получить допустимый бизнес-результат. Назначение виновного агента остаётся гипотезой, пока точечная замена его шага, данных или состояния не исправила результат в контролируемом replay.
Материал предназначен для владельцев AI-процессов, CTO/CIO, product, operations, QA и ИБ-команд. Он охватывает task-oriented цепочки с проверяемым исходом. Открытые творческие задачи, юридическое распределение ответственности и расчёт ущерба для конкретной компании в scope не входят.
Содержание
- Что показала новая работа DoCtOR
- Почему последний агент не обязательно виноват
- Атрибуция, причина и доказательство — разные вещи
- Что говорят DoCtOR, AgentRx и DoVer
- Метод ИСТОК для разбора сбоя
- Какой trace нужно сохранять
- Как провести контрфактуальный replay
- Что исправлять после подтверждения причины
- Какие метрики использовать
- Ограничения анализа
- Частые вопросы
- Как AIrassvet помогает построить контур разбора
- Вывод
Что показала новая работа DoCtOR
28 августа 2026 года исследователи Renmin University of China и Ant Group опубликовали работу Finding Where the Buck Stops, отмеченную как принятую в основную программу EMNLP 2026. Авторы предложили DoCtOR: система сначала ищет первый неверный шаг и выполнившего его агента, затем генерирует исправленный контрфактуальный шаг и добавляет reflection только в память этого агента.
Эксперимент использовал Magentic-One с замороженными GPT-4o-mini агентами, Qwen3-1.7B для атрибуции и Llama-3.1-8B-Instruct как reflector. На случайных выборках по 100 задач из HotPotQA, ChartQAPro и Mind2Web, в пяти прогонах, авторы сообщают улучшения относительно исходной доли успеха на 22%, 26% и 27% соответственно. Это результаты выбранной лабораторной конфигурации, а не прогноз для бизнес-процесса.
Самая важная для практики оговорка находится в таблице атрибуции. На своих доменах ProFA определял ошибочного агента с точностью 0,79–0,85, но на двух внешних наборах — только 0,53 и 0,55. Точность первого ошибочного шага на внешних наборах составила 0,38 и 0,20. Следовательно, автоматический RCA полезен как ранжирование гипотез, но недостаточен для автоматического наказания роли, изменения общей памяти или выпуска патча.
| Наблюдение | Практический смысл | Чего оно не доказывает |
|---|---|---|
| Целевая reflection улучшила benchmark success | не всем агентам нужно записывать один постмортем | что метод перенесётся в CRM, 1С или закупки |
| Атрибуция сильнее на held-in данных | знакомые типы сбоев диагностировать легче | что внешний домен сохранит точность |
| Шаги после ошибки дали сопоставимое качество reflection | можно сокращать диагностический контекст | что ранний контекст никогда не нужен |
| Работа принята EMNLP 2026 | есть конференционная экспертиза | что проведена независимая production-репликация |
Почему последний агент не обязательно виноват
В цепочке «поиск → анализ → решение → действие» последний агент видит уже изменённое состояние. Аналитик мог корректно посчитать вывод по неполным данным, а исполнитель — корректно выполнить неверно сформулированное решение. Их сообщения выглядят ошибочными только потому, что первый агент выбрал не тот период, неверно прочитал tool output или потерял ограничение пользователя.
Поэтому полезно различать четыре уровня:
| Уровень | Вопрос | Пример |
|---|---|---|
| Симптом | что увидел пользователь | неверный итоговый статус заказа |
| Эффект | что изменилось в системе | создан возврат не того типа |
| Первое критическое отклонение | где допустимая траектория стала недостижима | классификатор перепутал причину обращения |
| Условие системы | почему отклонение прошло дальше | оркестратор не потребовал подтверждение |
Корректное downstream-действие не превращается в ошибку только потому, что оно использовало плохой upstream-ввод. Но и первый необычный шаг не обязательно является причиной: система могла компенсировать его позднее. Критической считается точка, после которой без вмешательства допустимый исход уже не достигается.
Атрибуция, причина и доказательство — разные вещи
Атрибуция отвечает: «какой шаг наиболее вероятно запустил каскад?» Причинный тест спрашивает: «если изменить только этот фактор, изменится ли исход?» Между ними есть важный разрыв.
Microsoft Research в работе DoVer показала, что log-only гипотеза может быть неверной, а один сбой иногда ремонтируется несколькими различными вмешательствами. В их экспериментах точечные интервенции переводили 18–28% неуспешных trials в успешные и подтверждали либо опровергали 30–60% гипотез о причинах. На другом наборе и agent framework восстановлено 49% неуспешных trials; это также benchmark evidence, не production SLA.
Из этого следует консервативное правило:
Trace локализует гипотезу. Replay проверяет причинность. Бизнес-эффект определяет приоритет ремонта.
Если после замены предполагаемого ошибочного шага результат не меняется, расследование продолжается. Если разные вмешательства дают успех, проблема может находиться не в «виновном агенте», а в отсутствии системной избыточности, проверяющего ограничения или механизма восстановления.
Что говорят DoCtOR, AgentRx и DoVer
Эти работы не нужно сводить к одному победителю: они измеряют разные части диагностики.
| Подход | Основной объект | Набор/масштаб | Сильная сторона | Ограничение |
|---|---|---|---|---|
| DoCtOR | первый неверный шаг и агент | 3×100 test tasks; 1 757 failure logs для training corpus | selective reflection и counterfactual correction | held-out step accuracy 0,20–0,38 |
| AgentRx | первый unrecoverable step и категория | 115 размеченных failed trajectories | проверяемые constraints и evidence log | небольшая benchmark-выборка |
| DoVer | гипотеза + активное вмешательство | GAIA, AssistantBench, GSMPlus | проверяет, ремонтирует ли вмешательство исход | успех вмешательства не делает атрибуцию единственной |
| NIST AI RMF | риск и жизненный цикл системы | voluntary framework | мониторинг, incident response, recovery, change management | не задаёт конкретный алгоритм attribution |
В описании AgentRx Microsoft сообщает о 115 вручную размеченных сбойных траекториях из API-workflows, incident management и Magentic-One. Метод синтезирует guarded constraints из tool schemas и policy, проверяет их по шагам и оставляет evidence-backed violation log. Такой слой полезен там, где «ошибка» определяется не красивым ответом, а нарушением явного правила.
Метод ИСТОК для разбора сбоя
Предлагаем метод ИСТОК. Это редакционный синтез failure attribution, incident response и counterfactual testing; он не является стандартом EMNLP, Microsoft или NIST.
И — Исход
Сначала зафиксируйте ожидаемый бизнес-исход, фактический эффект и границу допуска. «Агент ответил плохо» слишком расплывчато. Подходящие формулировки: заказ не должен менять статус без approval; сумма должна совпасть с документом; невыполнимая операция должна завершиться отказом.
С — След
Соберите единый trace: версии модели и harness, сообщения между агентами, tool calls и outputs, состояния памяти, approvals, retries, timestamps и наблюдаемый эффект. Лог только финального чата не позволяет отделить ошибку чтения от ошибки исполнения.
Т — Точка первого критического отклонения
Идите от начала траектории и отмечайте первый шаг, нарушивший проверяемое ограничение или внесший факт, которого не было в доступном состоянии. Не называйте его причиной автоматически. Запишите альтернативные гипотезы и уверенность.
О — Опыт с вмешательством
Повторите frozen case, изменив один фактор: подмените шаг корректным, верните прежнюю память, исправьте tool output, добавьте approval или смените routing. Остальные версии и данные должны остаться неизменными. Сравните не текст, а бизнес-исход и запрещённые эффекты.
К — Коррекция и контроль
Меняйте только подтверждённого владельца: prompt роли, tool schema, memory entry, policy, orchestrator или evaluator. Затем повторите исходный case, соседние нормальные cases и adversarial cases. Сохраните решение, остаточный риск и rollback.
Минимальная карточка инцидента:
| Поле | Что записать |
|---|---|
| Case и версия | вход, модель, harness, tools, policy, memory snapshot |
| Ожидаемый исход | критерий успеха и запрещённый эффект |
| Фактический эффект | изменение данных, сообщение, действие, ущерб |
| Первая подозреваемая точка | agent ID, step ID, нарушение, evidence |
| Альтернативные гипотезы | routing, stale state, tool error, ambiguity, judge |
| Интервенция | один изменённый фактор и контрольная версия |
| Replay-результат | outcome, side effects, latency, cost если измерены |
| Решение | owner, patch, regression set, rollback, дата пересмотра |
Какой trace нужно сохранять
Полезный trace связывает намерение, исполнение и эффект. Для каждого шага достаточно хранить не весь чувствительный payload, а идентификаторы и доказательства, необходимые для воспроизведения в соответствии с политикой данных.
- Correlation ID: одна сквозная связь task → agents → tools → effect.
- Assembly manifest: model ID, prompt hash, tool/schema version, policy, router и evaluator.
- State lineage: какие документы, memory records и tool outputs видел агент в момент решения.
- Action record: запрос инструмента, выданные права, approval, ответ и фактическое изменение.
- Decision record: выбранный путь, отклонённые варианты, confidence только если он калиброван.
- Outcome record: бизнес-результат, human override, жалоба, rollback и время восстановления.
Лог chain-of-thought не является обязательным и часто недоступен. Для расследования важнее наблюдаемые входы, действия, состояния и эффекты. Статья про обвязку ИИ-агента отдельно объясняет, почему runtime harness должен быть частью замороженной сборки.
Как провести контрфактуальный replay
Replay должен быть похож на маленький эксперимент, а не на свободное повторение prompt.
- Заморозьте исходную сборку. Зафиксируйте manifests, входы, доступные данные и состояние внешней системы.
- Опишите одну гипотезу. Например: «ошибка классификации на шаге 7 вызвала неверный возврат».
- Выберите одну интервенцию. Подмените только шаг 7 проверенным значением; не обновляйте одновременно модель и prompt.
- Повторите прогон. Сохраните полный trace, outcome и запрещённые эффекты.
- Добавьте отрицательный контроль. Измените фактор, который не должен исправить сбой, либо replay соседнего нормального case.
- Сделайте вывод.
подтверждено,опровергнуто,несколько достаточных причинилинедостаточно evidence.
Для необратимых действий replay проводят в sandbox, shadow mode или на синтетическом состоянии. NIST AI RMF Playbook рекомендует тестировать incident response, recovery и fail-safe behavior, документировать условия теста и сравнивать результаты с risk tolerance (Measure).
Что исправлять после подтверждения причины
| Подтверждённый владелец | Точный ремонт | Обязательная регрессия |
|---|---|---|
| Роль/agent prompt | уточнить правило и допустимые действия | соседние задачи этой роли |
| Tool/schema | исправить contract, validation или permissions | malformed, timeout и partial output cases |
| Memory/state | удалить или scope-ограничить запись | no-memory и stale-version controls |
| Orchestrator/router | изменить delegation, stop или escalation | альтернативные маршруты и dead ends |
| Evaluator/policy | исправить критерий допуска | false accept и false reject cases |
| Human workflow | добавить approval или ручной fallback | время ответа и доступность ответственного |
Не записывайте общий текст «всегда перепроверяй» во все роли. Работа DoCtOR показывает риск загрязнения памяти исправно работающих агентов неверными выводами. Но selective repair безопасен только после evidence: held-out точность автоматической атрибуции в той же работе далека от 100%.
Если инцидент связан со скрытым каналом или подменой trace, одной self-reflection недостаточно. В статье про скрытый сговор ИИ-агентов показано, почему бизнес-эффект и control-plane evidence нужно отделять от текста агентов.
Какие метрики использовать
Не ограничивайтесь долей правильно названных агентов. Для рабочей системы нужны минимум пять показателей.
| Метрика | Что измеряет | Опасная подмена |
|---|---|---|
| Step localization accuracy | совпадение с размеченной критической точкой | не доказывает causal repair |
| Hypothesis validation rate | доля гипотез, проверенных интервенцией | зависит от качества набора гипотез |
| Recovery rate | доля failed cases, ставших допустимыми | может скрыть новый запрещённый эффект |
| Regression escape rate | новые сбои после ремонта | требует соседних и adversarial cases |
| Time to evidence-backed decision | скорость от сигнала до решения | не равно времени до первого объяснения |
Стоимость и latency полезны только вместе с результатом. Более дешёвая диагностика, которая назначает неверного владельца и загрязняет память, может увеличить полный incident cost. Универсальные пороги для этих метрик неизвестны: их задают по критичности процесса и risk tolerance.
Ограничения анализа
DoCtOR — опубликованная 28 августа версия v1, хотя на arXiv указано принятие в EMNLP 2026 main. Основная оценка использует по 100 задач на dataset, небольшие команды, преимущественно английские task-oriented benchmarks и конкретные модели. Размечающий конвейер включал GPT-4o и проверку трёх исследователей; это не безошибочный oracle.
Показатели DoCtOR, AgentRx и DoVer нельзя напрямую сравнивать как рейтинг: они используют разные datasets, labels, interventions и метрики. Результаты не доказывают частоту инцидентов в компаниях, точность на русскоязычных процессах, безопасность, экономию, ROI или универсальное преимущество multi-agent architecture.
NIST AI RMF добровольный и не заменяет отраслевые, договорные и российские требования. Search volume, difficulty, rankings, traffic, CTR, backlinks и AI citations для темы остаются Unknown.
Частые вопросы
Что считать первой критической ошибкой ИИ-агента?
Это самый ранний наблюдаемый шаг, после которого система без вмешательства уже не достигает допустимого результата. Он должен быть связан с конкретным нарушением, состоянием и последующим эффектом.
Можно ли автоматически определить виновного агента?
Можно ранжировать гипотезы, но нельзя считать атрибуцию доказанной. В свежей работе held-out точность шага составила 0,20–0,38, поэтому нужен replay или другое независимое evidence.
Зачем replay, если ошибка видна в логе?
Лог показывает последовательность, но не причинность. Replay меняет один фактор и проверяет, меняется ли бизнес-исход при сохранении остальных условий.
Нужно ли хранить все сообщения и chain-of-thought?
Нет. Нужны версии, доступное состояние, tool calls, approvals и эффекты, достаточные для воспроизведения. Хранение payload и персональных данных ограничивается политикой и правовым основанием.
Кому записывать reflection после сбоя?
Только роли или компоненту, чья причина подтверждена. Для остальных лучше сохранить поведение неизменным и прогнать regression cases, чем распространять непроверенный урок.
Что делать, если несколько интервенций исправляют сбой?
Зафиксировать несколько достаточных путей восстановления и выбрать контроль по риску, стоимости и обратимости. Это признак системной уязвимости, а не обязательно одного виновника.
Как AIrassvet помогает построить контур разбора
AIrassvet может связать диагностику с реальной агентной сборкой:
- провести аудит одного процесса и описать ожидаемые исходы, запретные эффекты и точки approval;
- связать логи моделей, инструментов, RAG, 1С/ERP или браузерной автоматизации единым correlation ID;
- собрать frozen regression set, sandbox replay и правила эскалации человеку;
- внедрить selective repair для prompts, memory, tools и orchestration с rollback.
Безопасный первый шаг — выбрать один процесс, зафиксировать baseline, источники данных, ограничения и критерий приёмки. Обсудить задачу.
Вывод
Хороший разбор сбоя ИИ-агентов не ищет удобного виновника. Он фиксирует недостигнутый исход, восстанавливает полный след, локализует первую критическую точку, проверяет гипотезу одним вмешательством и меняет только подтверждённого владельца.
Свежая работа DoCtOR показывает ценность selective reflection, но её же held-out результаты напоминают о границе автоматизации. Поэтому практический порядок такой: trace → attribution hypothesis → counterfactual replay → outcome check → selective repair → regression. До replay причина остаётся гипотезой.