TL;DR
Модель не умеет сама определить, какое правило можно проверить простым кодом, а какое требует суждения. На очевидных случаях разные модели отвечают почти одинаково. Стоит дать им отдельные условия из регуляторного текста, и ответы разъезжаются. COVER (corroborate-then-verify, «подтверди, потом проверь») — способ обойти эту слабость. Несколько независимых моделей лишь выдвигают кандидатов на проверку кодом. Правило пропускают дальше, только если реально написанная проверка прошла тест на вмешательство.
Болезнь устроена так. Одни модели склонны объявлять «это проверяется кодом» слишком часто, другие слишком редко. «Самой осторожной» модели не существует: та, что осторожна на тексте закона, становится самой беспечной на правилах агента. Хуже всего то, что на правилах агента ошибаются все вместе, в опасную сторону. Поля вроде customer_consent_logged звучат механически, и модели записывают их в «проверяемое кодом». Но что именно значит «согласие получено», код не решит. Такое условие не уйдёт на проверку судье, и нарушение пройдёт молча.
Суть метода в трёх шагах. Сначала несколько разных моделей слепо классифицируют каждое условие правила. Дальше берутся только единогласные «проверяемо кодом». Для них пишется конкретная проверка, и её испытывают вмешательством: читает ли она поля, которые агент не может изменить сам, реагирует ли на их изменение, не ломается ли при механическом переформулировании записи. Что не прошло, уходит судье или человеку.
Схема метода
ШАГ 1: Каждая модель из панели (3–4 разных) слепо размечает условие:
«проверяется кодом» / «нужно суждение» → таблица ответов
ШАГ 2: Оставить только единогласное «кодом» → кандидаты (это ещё не вердикт)
ШАГ 3: Для кандидата написать проверку и устроить ей вмешательство:
(а) читает поля, которые агент не может записать
(б) меняет вывод, если поменять эти поля
(в) держится при детерминированной переформулировке записи
ШАГ 4: Прошла все три → отдать скрипту. Не прошла → судье/человеку
Шаги 1–2 выполняются в нескольких отдельных чатах. Шаг 3 — отдельный запрос на каждого кандидата.
Пример применения
Задача: Маркетплейс запускает агента, который проверяет рекламные посты блогеров перед публикацией. Правила пришли извне: закон о рекламе и требования площадки. Юрист разбил их на отдельные условия. Нужно решить, что отдать регулярке или скрипту, а где обязательно нужен судья (LLM или человек).
Промпт (шаг 1, запускается в 3–4 разных моделях — Claude, ChatGPT, Gemini, DeepSeek):
Ты классифицируешь условие правила. Отвечай строго одним из двух слов, без оговорок.
DECIDABLE = фиксированная процедура над явно указанными фактами возвращает
точный ответ без толкования, оценки степени или ценностного суждения.
Иначе — JUDGMENT.
Условия:
1. В тексте поста есть идентификатор erid.
2. Пост не вводит аудиторию в заблуждение о свойствах товара.
3. Метка «реклама» стоит в первых двух строках поста.
4. Условия рассрочки изложены достаточно понятно.
5. Пост опубликован не позже трёх рабочих дней после согласования.
6. В карточке записано поле partner_consent_logged = true (согласие партнёра получено).
Формат ответа: номер — DECIDABLE/JUDGMENT.
Результат: Каждая модель выдаст таблицу из шести строк. Очевидные пункты (1, 3, 5, а также 2 и 4 с обратным знаком) скорее всего совпадут у всех. Расхождения ждите на пунктах вроде 6: название поля звучит механически, но нужно ещё понять, кто и как это поле заполняет. В кандидаты идут только единогласные DECIDABLE. Дальше по каждому кандидату запускается шаг 2 (см. шаблон ниже): модель пишет проверку и называет поля, которые она читает. Если агент может их изменить сам, пункт возвращается судье.
Почему это работает
Слабость. Модель решает, «механическое» условие или нет, по звучанию формулировки, а не по тому, кто и откуда берёт данные. Название поля customer_consent_logged выглядит как флажок, и модель записывает его в проверяемое кодом. При этом одна и та же модель меняет свой собственный ответ после безобидного переформулирования условия. Это не осторожность перед трудным вопросом, а нестабильный ответ. Смещения в разные стороны у разных моделей складываются в хаос.
Сильная сторона. Модель умеет написать конкретную проверку и сказать, из каких полей она читает. Модели из разных лабораторий ошибаются в разные стороны, поэтому единогласие вычёркивает перегибы каждой. На регуляторном тексте единогласный набор почти не содержит ложных «проверяемо кодом».
Как метод это использует. Ответ модели трактуется как предположение, а не как вердикт. Решает проверка, которую реально написали и испытали: она читает то, что агент не может подделать, и реагирует, когда это меняют. Главная находка статьи: сверка с «эталонным судьёй» ничего не доказывает. Судья из той же популяции моделей одобряет те же слепые зоны, поэтому согласие с ним растёт, а доля реально проверяемого кодом не двигается.
Рычаги: - Размер панели. Больше моделей даёт больше расхождений и более строгий набор кандидатов. Платите охватом. - Строгость рубрики. Подробная инструкция с процедурой и примерами даёт согласие, но не правильность. Не усиливайте рубрику ради «стабильности». - Условие допуска. Единогласие можно заменить на «все, кроме одной» ради охвата. Точность упадёт. - Правило по умолчанию. Сомнение уходит судье. Это дороже, но безопасно: ошибка в эту сторону стоит лишь лишнего вызова.
Шаблон промпта
Шаг 1 — классификатор (рубрика из статьи, запускать в нескольких разных моделях):
Ты классифицируешь условия правила. Отвечай без оговорок и объяснений.
DECIDABLE = фиксированная процедура над явно указанными фактами возвращает
точный ответ, без толкования, оценки степени и ценностного суждения.
Всё остальное = JUDGMENT.
Условия:
{список_условий}
Формат: номер — DECIDABLE или JUDGMENT.
Шаг 2 — испытание кандидата (только для единогласных DECIDABLE, по одному условию):
Условие: {условие}
Данные, которые видит проверка: {список_полей_и_кто_их_заполняет}
1. Напиши точную проверку (формулу, регулярное выражение или псевдокод).
2. Перечисли поля, которые она читает.
3. Для каждого поля ответь: может ли агент, который проверяется, изменить
его сам? Если да — проверка не годится.
4. Придумай изменение входных данных, после которого вывод проверки обязан
измениться. Покажи, меняется ли он.
5. Перепиши запись детерминированно (другой порядок полей, другой формат
даты, те же факты). Даст ли проверка тот же результат?
Вердикт: ПРОХОДИТ (все три теста) или ВОЗВРАЩАЕТСЯ СУДЬЕ (с указанием, какой тест не пройден).
Что подставлять: {список_условий} — отдельные условия правил, разбитые по одному; {условие} — единогласный кандидат из шага 1; {список_полей_и_кто_их_заполняет} — реальные поля вашего агента или CRM и кто их пишет (человек, система или сам агент).
🚀 Быстрый старт — вставь в чат:
Вот шаблон двухшаговой проверки «что можно отдать скрипту, а что — судье».
Адаптируй под мою задачу: {твоя_задача}. Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит, из каких правил состоит задача, какие поля видит проверка и кто их заполняет. Это нужно потому, что весь шаг 2 держится на вопросе «может ли агент подделать вход». Без этих сведений тест не провести.
Ограничения
⚠️ Единогласие работает только при разных ошибках: на правилах реального агента модели ошибаются вместе, и точность единогласного набора падает заметно ниже, чем на тексте законов. Высокая точность — следствие того, что смещения расходятся, а не свойство единогласия.
⚠️ Платите охватом: единогласный набор отдаёт судье большую часть того, что на самом деле можно проверить кодом. Безопасность покупается ростом стоимости.
⚠️ Подробная инструкция не лечит: рубрика с процедурой и примерами снижает разногласия, но согласие не приближает к правде. Она «отступает» в сторону судьи, и её эффект зависит от выбранных примеров, как лотерея.
⚠️ «Правда» — приближённая: эталонные метки на реальных корпусах проставлены LLM. Человеческая разметка сделана лишь на небольшой выборке (53 правила FINRA), хотя картина там та же.
⚠️ Модели не новейшие: панель — Claude Sonnet и Opus, GPT-4o, Llama-3.1-70B. Добавленная позже модель с рассуждением только усилила разброс, но сегодняшние версии могут вести себя иначе.
⚠️ Полная схема требует кода: в статье гейт описан для автоматического прогона. Выше показана ручная версия, которую автор не проверял в таком виде. Текст исследования также обрывается на разделе про корроборацию, часть деталей проверки (§8.2 и далее) здесь не видна.
⚠️ Агент не атакует верификатор: модель угроз предполагает, что агент может ошибаться, но не пытается обмануть проверку. Злонамеренный автор правил за рамками исследования.
Как исследовали
Автор собрал 832 отдельных условия из шести источников. Крайние точки шкалы — IFEval (чисто проверяемые кодом инструкции) и MT-Bench (чистые суждения). Между ними — «серая зона»: тексты EU AI Act и FINRA, правила реального кредитного агента и синтетический контрольный набор. Четыре модели трёх лабораторий размечали каждое условие под четырьмя вариантами рубрики и двумя видами «встряски» (переформулировки). Итого около 22 000 вызовов.
На краях шкалы модели почти не расходятся (согласие 0.92–0.99). На регуляторном тексте согласие падает до 0.20–0.50, и спорной оказывается середина, а не хвост: 65% условий EU AI Act, 52% FINRA. Затем автор проверил самую очевидную отговорку: «может, это просто двусмысленная формулировка, а не слабость моделей». Он заранее зафиксировал порог (падение спорности больше чем на 5 п.п. подтвердит возражение) и перепроверил с подробной рубрикой. Порог перешагнули: спорность упала на 31 п.п. на EU AI Act. Но согласие, которое «купила» инструкция, верно лишь в 58% случаев, против 89% у согласия, возникшего само. Константа «всегда проверяемо» набрала бы около 75%. Разные восемь примеров в рубрике открыли другую треть условий: подробность инструкции оказалась лотереей.
Больше всего удивил итог про «судью». Сверка с эталонным судьёй поднимала показатель с 30% до 77%, а доля реально проверяемого кодом не менялась. Судья из той же популяции моделей подтверждает общие слепые зоны. Практический вывод: доказательством служит исполненная проверка, а не чьё-то мнение, пусть и модели.
Адаптации и экстраполяции
🔧 Техника: добавить правило «не верь названию поля» → снижает перекос в сторону «проверяемо кодом»
Это достроено мной по результатам статьи, сама статья этого правила не проверяла. В инструкцию агента-проверяющего или в CLAUDE.md можно добавить:
Прежде чем отнести условие к «проверяемому скриптом», назови поле, которое читает проверка, и укажи, кто его записывает. Если поле может записать проверяемый агент или оно описывает «согласие», «адекватность», «понятность» — классифицируй как JUDGMENT.
Экстраполяция: человеческая «панель» вместо кода. Шаг 1 можно выполнять без скриптов. Сначала запустите классификатор в трёх чатах разных лабораторий. Потом пропустите единогласные «кодом» через шаг 2 и покажите результат юристу или владельцу процесса. Статья опирается на исполненную проверку, а не на мнение. Поэтому сомнительные пункты, где проверку не удалось написать однозначно, отдавайте человеку, а не четвёртой модели.
Ресурсы
- Anthony Rhodes, Not Self-Decidable: LLMs Cannot Draw the Boundary of What an Agent Verifier Can Check, Confidential Core AI. Принято на воркшоп NeurIPS 2026 «Who Verifies the Agents?».
- Корпуса: IFEval, MT-Bench, EU AI Act, FINRA, RegData (подсчёт обязательных требований в US CFR).
- Связанная работа: Zhou & Shbita, Evaluating Ill-Defined Tasks in LLMs; Kaplow о правилах и стандартах.