PRIME: агент не может выдать вывод без проверенного маршрута доказательств

ШАГ 0 (до проверки): из требований собрать «программу» →
      выводы по силе (слабый → сильный) + маршруты к каждому
      (маршрут = набор условий, все должны быть «да»)
      Программу фиксируют и хэшируют. После первой проверки менять её нельзя.

ШАГ 1: агент запускает проверку → внешний журнал пишет: неизвестно / да / нет
ШАГ 2 (ШЛЮЗ): агент просит выдать вывод →
      программа разрешает, только если в журнале закрыт хотя бы один маршрут
      к этому выводу или к более сильному
ШАГ 3 (НАВИГАЦИЯ): программа показывает агенту «самый сильный достижимый вывод»
      и что осталось проверить на самом дешёвом живом маршруте
ШАГ 4 (ДОВЕДЕНИЕ): агент решил остановиться раньше → программа сама
      запускает оставшиеся проверки, пока цель не достигнута или не кончился бюджет
ИТОГ: выдаётся самый сильный разрешённый вывод; если разрешённых нет — отказ

Это работает как программа с отдельным кодом, а не как один промпт. Но сами правила (шаг 0) можно составить в чате.

Задача: Вы руководите модерацией продавцов на маркетплейсе в духе Ozon или Wildberries. Агент проверяет заявки новых продавцов. Требования такие:

• Карточка готова к допуску на витрину, если есть описание магазина и выполнено одно из двух.
  • (а) ИНН подтверждён по выписке ЕГРИП/ЕГРЮЛ и есть расчётный счёт.
  • (б) Подтверждена самозанятость через «Мой налог».
• Раньше агент видел, что выписка не нашлась, и всё равно ставил «допущено». В другой раз он видел «не нашлась» и сразу отклонял, хотя путь (б) не проверил.

Промпт (шаг 0: составление программы в чате, до любых проверок конкретной заявки):

Ты составитель правил проверки. Ты видишь только регламент, не конкретные заявки.


<Регламент>
Заявка продавца может получить один из выводов (от слабого к сильному):
1. «Заявка заполнена» — есть название магазина и контактный e-mail.
2. «Продавец идентифицирован» — подтверждена личность или статус.
3. «Готов к допуску на витрину» — заполнена, идентифицирован,
   есть описание магазина, и выполнено одно из двух:
   (а) ИНН подтверждён по ЕГРИП/ЕГРЮЛ И указан расчётный счёт;
   (б) подтверждена самозанятость через «Мой налог».


<Доступные проверки>
- прочитать поле заявки (цена: 1 вызов)
- запрос в ЕГРИП/ЕГРЮЛ по ИНН (цена: 1 вызов)
- запрос статуса самозанятого (цена: 1 вызов)
- текстовое суждение модели «описание магазина осмысленное» (цена: 1 вызов, помечать как суждение)


<Задача>
1. Выпиши условия-атомы: каждое — вопрос с ответом да/нет.
   Для каждого укажи, чем проверяется (чтение поля / запрос / суждение).
2. Для каждого вывода выпиши все маршруты.
   Маршрут — набор атомов, все должны быть «да».
3. Для каждого маршрута посчитай число различных проверок.
4. Отметь маршруты, которые частично совпадают.
Не придумывай условий, которых нет в регламенте.


<Формат>
Таблица: вывод → маршрут → атомы → число проверок.

Результат: Модель выдаст список атомов с пометкой, чем каждый проверяется. Затем таблицу маршрутов по трём выводам. Для третьего вывода будут два маршрута: (а) и (б), общая часть у них «описание + идентификация». Для каждого маршрута будет посчитано число проверок. Эту таблицу вы подаёте в автоматизацию-шлюз или вставляете в инструкцию агенту. Она нужна и людям: по ней видно, что считается достаточным основанием.

Слабость LLM. Модель, которой сказали «проверь» и показали правила, не превращается в бухгалтера. Она продолжает текст в сторону «ответ найден». В эксперименте агент с полным доступом к правилам и к собственному журналу сам записал 67 проверок, где маршрут уже был провален, и всё равно выдал вывод. Информация не заменяет контроль.

Сильная сторона. Модель хорошо выбирает, что проверить дальше, если ей показать «осталось вот это». Эти подсказки подняли среднюю оценку подтверждённых выводов заметно выше, чем простой запрет. А запрет сам по себе делает почти всё безопасно, но агент сдаётся слишком рано.

Как метод связывает одно с другим. Один и тот же набор маршрутов решает две задачи. Он разрешает вывод, когда журнал это подтверждает. Он же показывает, где ещё можно найти подтверждение. Агент остаётся в роли «что проверить», а решение «что можно сказать» уходит из его рук.

Рычаги управления:

• Число маршрутов → больше альтернативных путей, меньше пропущенных подтверждений.
• Бюджет проверок → при малом бюджете агент выбирает самый дешёвый путь. Хватает ли бюджета, считается заранее: достаточно посчитать число различных проверок по всем маршрутам.
• Суждение модели как проверка → помечайте такие атомы отдельно. Это самое слабое место, шлюз их не выправит.
• Доведение вместо упрёков → когда агент останавливается рано, надёжнее запустить оставшиеся проверки автоматически, чем уговаривать его.

Это шаг 0 из статьи: составить программу проверки из регламента до просмотра записей. Статья показывает, что программу может написать и сама модель, и человек.

Ты составитель правил проверки. Ты видишь только регламент,
не конкретные записи. Не пытайся угадать значения полей.


<Регламент>
{текст_требований}


<Выводы>
Перечисли выводы от слабого к сильному: {список_выводов}
Если вывод нельзя подтвердить — результат «отказ».


<Доступные проверки>
{список_проверок_с_ценой}
(для каждой укажи: чтение поля / запрос в систему / суждение модели)


<Задача>
1. Выпиши атомы: условия с ответом да/нет. Для каждого укажи способ проверки.
2. Для каждого вывода выпиши ВСЕ маршруты. Маршрут = набор атомов, все «да».
   Допускается условие вида «НЕ X».
   Более сильный вывод включает маршруты более слабых.
3. Посчитай для каждого маршрута число различных проверок.
4. Отметь атомы, которые проверяются только суждением модели.
Не добавляй условий сверх регламента.


<Формат>
Вывод → Маршрут 1: [атомы] (N проверок) → Маршрут 2: [атомы] (N проверок)
В конце: общее число различных проверок по всем маршрутам.

Что подставить: {текст_требований} — ваш регламент или критерии приёма. {список_выводов} — 2–4 уровня («заполнено → идентифицировано → готово»). {список_проверок_с_ценой} — реестры, поля, API или вызовы модели, которые у вас есть.

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

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

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

LLM спросит про уровни выводов, про то, какие альтернативные пути допустимы, и про доступные проверки. Без этого нельзя построить маршруты: именно варианты «или (а), или (б)» и дают метод. Она возьмёт структуру из шаблона и соберёт программу под вашу задачу.

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

⚠️ Гарантия касается только допуска, не правды: если правила составлены неверно или проверка вернула ошибку, шлюз пропустит неверный вывод как «подтверждённый». Ошибки остаются в самих правилах и в данных.

⚠️ Суждения модели — слабое звено: когда проверка — это мнение LLM («описание осмысленное»), ложные выводы остаются. Вторая согласующая оценка снижала их долю, но добавляла вызовы модели и немного снижала полезность.

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

⚠️ Малые модели и синтетика: проверяли на открытых моделях среднего размера и на задачах, собранных из публичных реестров по шаблонам. Слабая модель из эксперимента почти не делала выводов вообще, и шлюзу нечего было отсекать. Как это поведёт себя на современных флагманских моделях и на вашей грязной реальной выгрузке, неизвестно.

⚠️ Нужен код или автоматизация: сам runtime — программа. Читателю без кода придётся собирать его в no-code сценарии или просить разработчика.

Авторы сделали собственный бенчмарк SUFFICE: 938 задач из публичных реестров. Это база уязвимостей, регистр клинических испытаний, отзывы лекарств и финансовые отчёты. В каждой задаче есть три вывода разной силы и заранее известные правила. Часть доказательств намеренно блокировали или прятали, чтобы проверить, когда агент примет недоказанное. Оценивал не LLM-судья, а исполняемый код.

Главный эксперимент: на 480 отложенных задачах последовательно добавляли агенту информацию. Сначала обычный ReAct (агент, который чередует рассуждение и вызов инструментов). Потом инструкция «проверяй», потом описание правил, потом сами маршруты, потом журнал. Каждый шаг не уменьшал ложные выводы, а увеличивал их. Обычный агент ошибался в 13% случаев, полностью информированный — в 26,7%. Добавили шлюз — ноль. Это держалось на четырёх моделях.

Второй вопрос: не заставляет ли шлюз агента сдаваться слишком рано? Да. Без подсказок средний балл подтверждённых выводов был 30,1. Подсказки подняли его до 45,5, а автоматическое доведение до конца — до 59,2, то есть до максимума на этих задачах. При этом на неопределённых местах данных выигрыш от выбора «где проверять» зависел от бюджета и модели.

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

🔧 Техника: промптовая имитация шлюза → слабее, но лучше, чем ничего

Такой вариант в статье не проверялся. Её данные говорят, что он ненадёжен. Используйте как дополнительную страховку в чате или в инструкции агента, а не как гарантию.

Copy

Работай по программе проверки ниже. Веди журнал: для каждого условия —
НЕИЗВЕСТНО / ДА / НЕТ и какой проверкой это установлено.
Вывод можно писать только если в журнале все условия одного его маршрута = ДА
(или маршрута более сильного вывода).
Если на маршруте появилось НЕТ — он закрыт. Не заменяй его догадкой.
Перед выводом перечисли, какие маршруты ещё живы, и проверь недостающее
на самом дешёвом. Не останавливайся, пока не закрыт маршрут
к самому сильному достижимому выводу или не кончился бюджет в {N} проверок.
Если ни один маршрут не закрыт — ответ «отказ».
Программа: {вставить_таблицу_маршрутов}

🔧 Техника: двухстадийная схема без кода → привратник вместо шлюза

Первый чат или агент собирает проверки и пишет журнал. Второй чат получает только таблицу маршрутов и журнал, без рассуждений первого. Его задача: «Определи, какой самый сильный вывод разрешён этим журналом. Если ни один — отказ». Это ближе к идее внешнего шлюза: второй не знает, чего «хочется» первому. Не проверялось авторами.

• PRIME: Towards Verifiable Evidence-Grounded Reasoning in LLM Agents — Hamed Khosravi, Xiaoming Huo, H. Milton Stewart School of Industrial and Systems Engineering, Georgia Institute of Technology.
• Бенчмарк SUFFICE (938 задач; корпус, оценщик, runtime и логи опубликованы авторами, ссылки в разделе 8 статьи).
• Близкие подходы, с которыми сравнивали: AgentSpec, ResearchLoop, Proof-or-Stop, GLEAN, HESP. Все они были переписаны авторами и не являются точными запусками оригиналов.