TL;DR
Confidence Reasoning Graphs (CRG) — способ узнать, можно ли доверять результату агента. Утверждение «агент справился» разбивается на мелкие проверяемые утверждения. Для каждого из них из лога агента выбираются доказательства. Затем каждое утверждение оценивается отдельным запросом, а итоговая уверенность получается перемножением этих оценок.
Главная боль в том, что на вопрос «насколько ты уверен, что агент справился?» модель отвечает «90%+» почти всегда, даже когда успех на деле около 50%. Агент часто не ошибается, а просто не добирается до проверки: тесты не запустились, зависимость не встала, а в отчёте написано «готово». Общая оценка этого не замечает. Подробный промпт «разложи на части и оцени» в одном запросе тоже не помогает: авторы проверили, и калибровка почти не улучшилась.
Суть метода в трёх шагах. Сначала строится список «что должно быть правдой, чтобы задача считалась решённой». К каждому пункту из лога прикрепляются шаги-доказательства с пометкой «подтверждает», «подрывает» или «не проверено». Потом каждый пункт получает вероятность в отдельном запросе, а их произведение даёт итоговую уверенность. Каждая оценка опирается на конкретные шаги лога, поэтому её можно проверить глазами.
Схема метода
ШАГ 1: Декомпозиция → дерево утверждений
«Агент справился» → [необходимые и вместе достаточные подутверждения]
+ уточнение под конкретную задачу (то же утверждение, но конкретно)
(глубина до 5 уровней)
ШАГ 2: Доказательства → к каждому «листу» привязаны шаги лога
метка: Подтверждено / Подорвано / Не проверено
(один запрос: на входе задача + лог + дерево)
ШАГ 3: Оценка каждого листа → вероятность 0–1
(ОТДЕЛЬНЫЙ запрос на каждый лист; на входе лист + его доказательства + лог до последнего цитируемого шага)
ШАГ 4: Агрегация → итог = произведение вероятностей листьев
(простой подсчёт, можно вручную)
Шаги 1–2 можно выполнить в одном чате. Шаг 3 нужен в отдельных чатах или вызовах.
Пример применения
Задача: Вы руководите небольшим интернет-магазином. Разработчик попросил Claude Code перенести приём платежей на новую версию API ЮKassa. Агент отчитался: «Готово, всё работает». Деплой в пятницу вечером, и нужно решить: принимать как есть или проверять руками.
Промпт (шаг 1–2, один чат):
Ты — аудитор работы AI-агента. Ниже задача и полный лог работы агента.
<Задача>
Перенести приём платежей с ЮKassa API v2 на актуальную версию.
Сохранить обработку вебхуков, возвраты и чек по 54-ФЗ.
<Лог>
{вставь лог / историю шагов агента с номерами}
Утверждение G0: «Агент успешно выполнил задачу».
Шаг 1. Разложи G0 на дерево утверждений.
Используй два приёма:
- РАЗДЕЛЕНИЕ: раздели утверждение на части, каждая из которых необходима, а все вместе достаточны. Части не должны зависеть друг от друга.
- УТОЧНЕНИЕ: перепиши общее утверждение так, чтобы оно проверялось именно в этой задаче (смысл тот же).
Максимальная глубина — 5 уровней. Остановись, когда утверждение можно проверить по конкретным шагам лога.
Шаг 2. К каждому конечному утверждению привяжи доказательства из лога:
- номера шагов
- что именно произошло на этих шагах
- метка: Подтверждено / Подорвано / Не проверено
(«Не проверено» — если агент не пытался проверить или попытка оборвалась.)
Выведи: дерево утверждений, затем таблицу «утверждение → доказательства → метка».
Промпт (шаг 3, отдельный новый чат для каждого листа):
Утверждение: «{конечное_утверждение}»
Доказательства из лога агента:
{доказательства_с_метками}
Лог агента до последнего упомянутого шага:
{лог_до_нужного_шага}
Оцени вероятность, что утверждение истинно, числом от 0 до 1.
Опирайся только на лог. Если проверки не было — вероятность не должна быть высокой.
Ответ: число и 2 предложения обоснования.
Затем перемножьте числа.
Результат: После шагов 1–2 вы получите дерево из 4–8 конечных утверждений (например, «вебхуки принимаются и подпись проверяется», «возвраты проходят», «чек формируется»). У каждого будут шаги-доказательства и метка. Скорее всего, у части пунктов окажется «Не проверено»: агент не смог запустить тесты вебхуков. После шага 3 вы получите набор вероятностей, а после перемножения — итоговую оценку. Видно, какой именно пункт тянет её вниз, так что руками проверять нужно только его.
Почему это работает
Слабость. Если спросить «агент справился?», модель смотрит на общее впечатление от лога: много действий, финальный отчёт уверенный, значит, вероятно, да. Единственный оборвавшийся запуск тестов теряется в длинной истории. Поэтому уверенность завышена почти всегда. Описание декомпозиции в одном промпте («подумай по частям») не помогает: модель всё равно приходит к общему впечатлению.
Сильная сторона. Модель хорошо проверяет узкое конкретное утверждение по конкретным шагам лога: «функция вызвана с нужными параметрами?», «тест запускался и прошёл?». Она также неплохо находит в логе место, где агент остановился, не дойдя до подтверждения.
Как метод это использует. Он превращает одну размытую оценку в серию узких, каждая из которых опирается на цитируемые шаги. Пометка «Не проверено» отделяет «не подтверждено» от «подорвано». Произведение делает так, что одно слабое звено снижает итог, и общее впечатление его не прикроет. Авторы показали, что выигрыш даёт именно оценка каждого листа отдельно плюс агрегация, а не само построение графа.
Рычаги управления: - Глубина дерева (в статье максимум 5): для простых задач ограничьте 2–3 уровнями, это дешевле. - Метки доказательств: можно добавить свои, например «Подтверждено только на тестовых данных». - Отдельные запросы на лист — рычаг, который нельзя убирать. Без него эффект пропадает. - Агрегация: перемножение — это допущение независимости. Она занижает итог при множестве листьев (см. ограничения). - Лог до последнего цитируемого шага экономит токены, но если шаг не процитирован, оценщик его не увидит.
Шаблон промпта
Метод состоит из трёх промптов. Структуру (дерево, метки, отдельные оценки, произведение) сохраняйте.
<Роль>
Ты — аудитор работы AI-агента. Твоя задача — оценить вероятность,
что агент выполнил задачу, опираясь только на лог.
<Задача>{описание_задачи}
<Лог>{лог_агента_с_номерами_шагов}
<Утверждение_G0>Агент успешно выполнил задачу.
<Логика>
1. РАЗДЕЛЕНИЕ(G): раздели G на подутверждения G1..Gm так, чтобы
G истинно ⇔ истинны все Gj (необходимы и достаточны),
и Gj не зависят друг от друга.
2. УТОЧНЕНИЕ(G): перепиши G как G' для конкретной задачи (G ≡ G').
3. Применяй 1 и 2 рекурсивно к листьям, глубина ≤ {макс_глубина}.
Остановись, когда лист проверяется по конкретным шагам лога.
4. Для каждого листа: найди доказательства,
укажи номера шагов, опиши событие,
метка: Подтверждено | Подорвано | Не проверено.
<Вывод>
Дерево утверждений + таблица: лист | шаги | событие | метка.
Вероятности пока не ставь.
Затем для каждого листа — отдельный новый чат:
Утверждение: «{лист}»
Доказательства: {доказательства_с_метками}
Лог до шага {последний_шаг}: {лог}
Оцени вероятность истинности утверждения (0–1).
Опирайся только на лог. Метка «Не проверено» не может давать высокую вероятность.
Ответ: число + 2 предложения обоснования.
Итог: уверенность = p1 × p2 × … × pn.
Подставляйте: {описание_задачи} — что просили агента сделать, {лог_агента} — историю шагов с номерами, {макс_глубина} — 3–5.
🚀 Быстрый старт — вставь в чат:
Вот шаблон метода Confidence Reasoning Graphs. Адаптируй под мою задачу: [твоя задача и что делал агент].
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит, что именно просили агента сделать, какие критерии «готово» у вас есть и как выглядит лог. Это нужно, чтобы дерево утверждений было заточено под вашу задачу, а не было общим. Затем она составит промпты шагов 1–2 и 3 под ваш случай.
Ограничения
⚠️ Один промпт не заменяет метод: если «влить» всё в один запрос («разложи на части и оцени уверенность»), калибровка почти не улучшается. Эффект даёт оценка каждого листа в отдельном запросе.
⚠️ Нужен лог агента: метод смотрит на траекторию (шаги, вызовы инструментов, результаты). Без лога его не применить. Оценить по одному финальному отчёту нельзя.
⚠️ Произведение — упрощение: оно предполагает независимость пунктов и при многих листьях занижает итог. Абсолютное число лучше читать как ранг и сигнал, а не как точную вероятность.
⚠️ Разделение ролей не сравнено: вероятность выставляет сама модель. Если пункт не попал в дерево или доказательство не процитировано, оценщик его не увидит.
⚠️ Ранжирование не улучшилось: различать удачные и неудачные запуски CRG стал не заметно лучше простых вербальных оценок (AUROC близок). Выигрыш — в калибровке и решениях под риском.
⚠️ Стоимость и ручной труд: в статье это автоматизировано (4–7 центов за траекторию). В чате вручную — много копирования. Для каждой правки в продакшн это избыточно.
⚠️ Проверено на кодовых и «инструментальных» задачах: где есть формальный верификатор успеха. Для творческих задач, где «успех» субъективен, дерево утверждений трудно сделать честным.
Как исследовали
Авторы взяли три сложных бенчмарка агентов: исправление багов в реальных репозиториях (SWE-Bench Verified), корпоративные многошаговые сценарии с инструментами (EnterpriseOps-Gym) и задачи на использование навыков (SkillsBench). Три модели-агента прогнали через OpenHands, всего больше 2000 траекторий. Каждая траектория получила честную метку «успех/провал» от проверяющей программы бенчмарка. Затем разные «оценщики» должны были заранее сказать, насколько они уверены в успехе, и это сравнивали с реальностью.
Сравнивали CRG с тремя вариантами с обычным промптом: прямой вопрос об уверенности, тот же вопрос с описанием декомпозиции в промпте и десять голосований с рассуждением. Четвёртым был «суррогат»: вероятности токенов другой модели. Мерили, насколько уверенность совпадает с фактической долей успехов (ECE и Brier), умеет ли она отличать удачи от провалов (AUROC) и сколько стоит ошибка, если принимать решения по ней (BAS).
Результаты. Прямые вербальные оценки были сильно завышены: более 90% уверенности у большинства траекторий при успехе около 40–50%. У CRG ошибка калибровки примерно 0,09–0,13 против 0,18–0,49 у прямой вербализации. Её итоговая решающая польза положительна на всех бенчмарках. Ещё CRG работал на траекториях Codex и Claude Code, не только OpenHands.
Самое показательное — «суррогат». Он показал низкую ошибку калибровки, но почти случайное различение удач и провалов. Он просто выдавал среднюю успешность для всех. Вывод для практики: хорошая калибровка в среднем не значит, что оценка полезна для конкретного случая. Ещё один важный результат: промпт «разложи на части» без раздельных запросов почти не помогает. Метод работает за счёт структуры процесса, а не красивой формулировки.
Адаптации и экстраполяции
Это не из статьи, а мои идеи по её мотивам.
🔧 Техника: добавить требование отчёта «Подтверждено / Не проверено» в инструкцию агенту → видеть пробелы сразу.
Центральная находка статьи: типичный сбой агента — остановиться, не подтвердив результат. Это можно закрепить в файле инструкций (CLAUDE.md, AGENTS.md):
В финальном отчёте раздели результат на утверждения:
- Подтверждено: что именно ты проверил и как (команда, вывод).
- Не проверено: что не удалось проверить и почему.
Не пиши «готово», если в разделе «Не проверено» есть критичные пункты.
Это не заменяет аудит CRG, но делает слабые места видимыми без отдельного прогона.
🔧 Техника: брать слабое звено вместо произведения → проще читать.
Если произведение вам кажется слишком пессимистичным, возьмите минимальную вероятность по листьям и покажите, какой пункт её определяет. Авторы сравнивали правила агрегации (приложение A.9), но этот вариант не рекомендуют в тексте, поэтому используйте как грубый ориентир.
Ресурсы
- Работа: Confidence Reasoning Graphs: Structured Confidence Estimation for LLM Agents (pre-print)
- Авторы: Brendan King (University of California, Santa Cruz); Farima Fatahi Bayat, Jean-Flavien Bussotti, Pouya Pezeshkpour, Estevam Hruschka (Megagon Labs)
- Код: https://github.com/megagonlabs/crg_ce
- Идейная основа: assurance cases (аргументация безопасности в инженерии), Goal Structuring Notation (Kelly & Weaver, 2004)
- Бенчмарки: SWE-Bench Verified, EnterpriseOps-Gym, SkillsBench; агентные фреймворки OpenHands, Codex, Claude Code
- Точные промпты метода приведены в приложении A.12 статьи. В переданном фрагменте их нет, поэтому шаблон выше собран по описанию метода.