Sauron: проверка работы агента по доказательствам, а не по его отчёту

ШАГ 0: Сгруппировать критерии по общим доказательствам → кластеры + краткая «суть задачи» (подсказка, не доказательство)
ШАГ 1: Следователь точечно запрашивает итоговый результат и журнал действий → утверждения (что утверждается, тип, адрес источника)
ШАГ 2: Проверяющий (отдельный вызов, видит только утверждение + цитату) → принято / отклонено с причиной
ШАГ 3: Следователь предлагает вердикт → Финализатор принимает, только если проверенные утверждения его поддерживают
ИТОГ: по каждому критерию — ВЫПОЛНЕН / НЕ ВЫПОЛНЕН + справка о доказательствах
Бюджет исчерпан, критерий не решён → НЕ ВЫПОЛНЕН

В оригинале это параллельные сессии на коде. В чате шаги 1–3 повторяются как отдельные запросы (см. шаблон).

Задача: Вы настроили агента (Claude Code или сценарий в n8n), чтобы он каждую пятницу собирал расходы на рекламу из Яндекс Директа и VK Рекламы в Google Таблицу. Сегодня он ответил: «Готово, отчёт обновлён». Перед тем как отправить таблицу собственнику, нужно убедиться, что это правда.

Промпт (шаг 1 — Следователь):

Ты — следователь. Ты проверяешь работу агента. Его слова не являются доказательством.


Задача агента: «Собери расходы на рекламу за неделю из Яндекс Директа и VK Рекламы, обнови таблицу "Реклама_неделя"».
Ответ агента: «Готово, отчёт обновлён».
Итоговое состояние: [выгрузка таблицы]
Журнал действий: [лог вызовов инструментов агента]



C1. Итог по Директу в таблице равен значению, которое агент получил из кабинета Директа.
C2. Итог по VK Рекламе в таблице равен значению, которое агент получил из кабинета VK.
C3. Агент обратился к обоим кабинетам ДО записи итога в таблицу.
C4. Общий бюджет недели в ячейке B2 равен 300 000 ₽.



Для каждого критерия предложи утверждения в формате:
- утверждение: что именно ты считаешь фактом
- тип: значение_в_состоянии / значение_в_журнале / совпадение_состояния_и_журнала / порядок_действий
- адрес: ячейка таблицы или номер события в журнале + точная цитата

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

Результат: Модель выдаст список утверждений по каждому критерию. У каждого будут тип, адрес и цитата: ячейка, номер события в журнале, найденное число. Если итог в таблице не совпал с числом из журнала, это будет видно уже на этом шаге. Затем вы передаёте утверждения проверяющему (шаг 2) и финализатору (шаг 3).

Слабость. Судья по умолчанию доверяет рассказу агента. Ему удобно сделать вывод по ответу: «Готово» звучит убедительно. Но самые опасные сбои невидимы в ответе. Это молчаливая неудавшаяся запись, расхождение числа в файле и числа из источника, пропущенный шаг. Модель-судья ещё и теряется в длинных логах: точность падает, когда нужный фрагмент в середине.

Сильная сторона. Модель хорошо сравнивает короткую цитату с коротким утверждением. «В источнике 250, в утверждении 200» — легко. Она хорошо планирует, куда смотреть. А вот делать одновременно поиск, вывод и самоконтроль она хуже.

Как метод использует это. Он разделяет роли. Следователь ищет, проверяющий видит только утверждение и цитату (без рассуждений следователя, поэтому не поддаётся его предвзятости), финализатор принимает вердикт только по подтверждённым фактам. «Нет доказательств» автоматически означает «не выполнено».

Рычаги управления: - Источники: итоговое состояние + журнал действий. Без журнала потеря F1 на 0.15, это самая большая потеря среди всех проверок. - Проверяющий: убери его для простых задач — потеряешь около 0.03 F1, но сэкономишь ~40% стоимости. - Группировка критериев по общим доказательствам: одна сессия вместо отдельной на каждый критерий. Качество то же, расход на 63% меньше. - Краткая «суть задачи»: на точность не влияет, но экономит ~15% ресурсов. Подсказка, не доказательство. - Бюджет запросов: ограничь число чтений. Что не успели доказать — «не выполнено».

Метод по сути — три отдельных запроса (лучше в разных чатах, чтобы проверяющий не видел рассуждений следователя).

Запрос 1 — Следователь:

Ты — следователь. Слова агента — не доказательство. Доказательство — только цитата из итогового состояния или журнала действий.


Задача агента: {задача}
Ответ агента: {ответ_агента}
Итоговое состояние (файлы, таблицы, записи): {состояние}
Журнал действий (вызовы инструментов и их результаты): {журнал}



{C1: критерий}
{C2: критерий}
{C3: критерий}



1. Сгруппируй критерии, которым нужны одни и те же доказательства. Напиши кратко, что агент должен был сделать (это подсказка, а не доказательство).
2. Для каждого критерия предложи утверждения в формате:
   - утверждение: {что считаешь фактом}
   - тип: значение_в_состоянии / значение_в_журнале / совпадение_состояния_и_журнала / порядок_действий
   - адрес: {где найдено: ячейка / файл / номер события} + точная цитата
3. Сначала ищи широко (где это лежит), потом точечно (какое значение). Не пересказывай весь журнал.
4. Вердикты пока не выноси.

Запрос 2 — Проверяющий (новый чат):

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

{утверждение}
{цитата_из_первоисточника}


Ответь: ПРИНЯТО или ОТКЛОНЕНО.
ПРИНЯТО — только если цитата прямо подтверждает утверждение, включая числа и порядок.
ОТКЛОНЕНО — если цитата не подтверждает, противоречит или её нет. Укажи причину одним предложением.

Запрос 3 — Финализатор (в чате следователя):

Вот результаты проверки утверждений: {принято / отклонено с причинами}.
Отклонённые — исправь или найди другое доказательство.

Затем для каждого критерия вынеси вердикт:
- ВЫПОЛНЕН — только если проверенные (принятые) утверждения прямо это подтверждают.
- НЕ ВЫПОЛНЕН — во всех остальных случаях, включая «не нашёл доказательств».
К каждому вердикту приложи справку: список принятых утверждений, на которые он опирается.

Подставляйте: {задача} — исходное поручение агенту; {состояние} и {журнал} — выгрузки (файл, лог из Claude Code / n8n); критерии — конкретные проверяемые условия («значение X равно Y», «шаг A был до шага B»).

🚀 Быстрый старт — вставь в чат:

Вот шаблон проверки работы агента по доказательствам (метод Sauron). Адаптируй под мою задачу: [что должен был сделать агент]. 
Задавай вопросы, чтобы заполнить поля.

[вставить шаблон выше]

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

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

⚠️ Нужны данные, которых может не быть: метод работает, если у вас есть итоговое состояние и журнал действий. Если агент не пишет лог или вы его не видите, остаётся судья по ответу. Такой судья показал худшее качество, пропускал большинство сбоев и часто тревожил на пустом месте.

⚠️ Дорого на длинных проверках: когда нужно доказать отсутствие ошибок во всём журнале, а не найти один факт, Sauron стоил в 2–3 раза больше простых судей. Экономия от точечных запросов сильно падает.

⚠️ Строгость по умолчанию: критерий, который не успели доказать за бюджет, считается невыполненным. Это защищает от самообмана агента, но может давать ложные «не выполнено» на сложных задачах.

⚠️ Проверка только на собственных данных авторов: два набора — внутренний корпус личных ассистентов и вставленные искусственные сбои. Реальные сбои проверены на публичном TRAIL, там метод тоже лучше, но абсолютные цифры скромные. Часть текста статьи (подробный анализ остаточных ошибок) в исходных данных обрезана.

Команда Scale AI собрала PA100 — 100 длинных эпизодов работы личного ассистента («проверь мои подписки», «составь утренний брифинг»), в среднем по 53 события и 20 вызовов инструментов. Люди разметили 2 586 критериев, примерно 30% из них не выполнены. Sauron сравнили с четырьмя готовыми проверяющими на восьми моделях.

На каждой из восьми моделей Sauron оказался лучшим по F1 и дешевле сильнейшего конкурента (Gandalf): 0.96 против 0.92 при расходах на 23% меньше. Судья, который читал только ответ агента, не поднимался выше 0.65–0.70. Отрыв особенно заметен на критериях про процесс («агент сначала вызвал А, потом написал Б»), там результат лежит только в журнале.

Второй тест, PAFault, интереснее: в 637 парах «сломанная версия — чистая версия» вставляли 13 видов сбоев, включая имитацию читерства (фальшивые заявления об успехе, подгонка под проверку). Sauron поймал 97% сбоев и ошибочно «обвинил» только 2% чистых. Конкуренты с доступом к журналу набирали ~0.67–0.71 по разности «поймал минус ложная тревога» против 0.95. Особенно провалились они на случаях, когда журнал и итоговое состояние противоречат друг другу (запись молча не прошла): у них минус, то есть чистые случаи они обвиняли чаще, чем сломанные. Вывод для практики: дать модели доступ — не значит заставить использовать его правильно. Нужна структура «найди, докажи, проверь».

Затем удаляли по одному механизму. Без журнала — потеря 0.15 F1. Без проверки утверждений — потеря 0.03, но на 40% дешевле. Без группировки критериев — на 63% дороже. Вместо точечных запросов дали весь журнал в контекст — +0.01 качества за тройную цену. На реальных сбоях (TRAIL: 148 трасс, 841 ошибка) Sauron тоже лидировал по всем метрикам.

💡 Адаптация для файла инструкций агента (CLAUDE.md / AGENTS.md): принцип «справки о доказательствах» можно навязать самому агенту.

Copy

## Правило завершения задачи
Перед сообщением «готово» для каждого пункта задачи приложи справку:
- что сделано
- где доказательство: путь к файлу + строка, команда + её вывод, номер шага
Не пиши «готово», если для пункта нет доказательства. Вместо этого напиши «не подтверждено» и объясни, чего не хватает.
Не опирайся на собственные прошлые сообщения как на доказательство. Перечитай файл или повтори проверку.

Это не метод статьи, а перенос его принципа. Статья его на самоотчёте агента не проверяла. Но она показывает, почему агенту нельзя верить на слово.

🔧 Техника: убрать проверяющего → дешевле, чуть менее точно. Для простых задач (3–5 точных числовых критериев) пропустите запрос 2. Для интерпретаций («отчёт объясняет перерасход разовыми покупками») оставьте: потеря качества как раз там.

• Evidence-First Agentic Verification — Reza Sanayei, Razvan-Gabriel Dumitru, Sunjie Hou, MohammadHossein Rezaei, Haris Riaz, Robert Vacareanu, Minglai Yang, Ying Liu, Mihai Surdeanu, Daniel Yue Zhang (Scale AI; University of Arizona)
• Код: github.com/rsanayei/sauron
• Упомянутые в статье: Gandalf, Agent-as-a-Judge, Archipelago, Autorubric, TRAIL