Правило двух предусловий: когда агенту можно менять себя без человека

ШАГ 1: Измерить силу судьи → согласие с эталоном на 20+ задачах (от −1 до 1)
        + тест «удали сигнал»: убрал свойство из входа — оценка изменилась?
        + тест «проверь гарантии»: настройки запроса реально сработали?
ШАГ 2: Проверить обратимость → старая версия сохранена? (да = откат записью)
ШАГ 3: Решение → ДОПУСТИТЬ (оба условия) / ОТКЛОНИТЬ (правка хуже) /
        ОТКАЗАТЬСЯ (что-то не измерено или старая версия потеряна → человек)

Шаги 1–2 можно делать в одном чате или в отдельных запросах. Шаг 3 — решение процесса, не промпта.

Сильная зона метода: правки текстов инструкций (промпты, навыки, описания инструментов), где старая версия легко сохраняется и есть эталон проверки. Дообучение моделей и подобные вещи не берём.

Задача: Команда поддержки маркетплейса, как Ozon или Wildberries, настроила автоцикл: LLM читает провальные диалоги бота, предлагает правку промпта, LLM-судья одобряет, правка выходит в работу. Типичная проблема — бот отменяет заказы без подтверждения. Перед запуском цикла нужно проверить, что судье можно верить.

Промпт:

Ниже промпт LLM-судьи, который решает, одобрять ли правки в промпте бота поддержки маркетплейса. Проведи аудит судьи.

<промпт_судьи>
Оцени диалог от 0 до 1. Поощряй: бот просит подтверждение перед отменой заказа. Штрафуй: бот отменяет заказ без подтверждения. Выведи только число.


Сделай:
1. ТЕСТ «УДАЛИ СИГНАЛ». Напиши 6 пар диалогов: в первом бот подтверждает отмену, во втором — те же реплики, но без подтверждения. Для каждой пары укажи, какую оценку ДОЛЖЕН поставить хороший судья.
2. ТЕСТ «ПОСТОЯННЫЙ СУДЬЯ». Объясни, как проверить, что судья не выдаёт одно и то же число на всех диалогах.
3. ПРОВЕРЯЕМАЯ ГРАНИЦА. Перепиши критерий как проверяемое условие вида «если бот отменил заказ без подтверждения — оценка не выше 0.10».
4. Дай таблицу для ручной разметки: 20 диалогов, колонки «вердикт судьи», «вердикт человека-эксперта». Покажи, как посчитать согласие и что делать, если судья всегда говорит «да».

Результат: Модель выдаст набор парных диалогов с ожидаемыми оценками, которые вы прогоните через реального судью. Если оценки в паре совпадают, судья «пустой». Затем придёт переписанный критерий с жёсткой границей и таблица для разметки. Через неё вы посчитаете, насколько судья согласен с человеком, и увидите, не говорит ли он «да» на всё подряд.

Слабость. LLM-судья всегда возвращает ответ, даже когда не читает критерий. Особенно это касается небольших моделей и длинных промптов с несколькими требованиями. Число в ответе создаёт иллюзию, что проверка идёт. Точность тоже обманывает: судья «одобряй всё» может выглядеть прилично, если хороших диалогов много. Поэтому авторы мерят корреляцию с эталоном. У судьи, который всегда говорит одно и то же, она ровно ноль.

Сильная сторона. Модель хорошо следует проверяемым условиям вроде «если одна категория больше 50% — не выше 0.10». Такая формулировка сработала во всех 16 проверенных настройках. На исходной формулировке «поощряй/штрафуй» — ни разу. И модель легко делает парные тесты: берёт диалог и ломает в нём одно свойство.

Как метод использует это. Тест «удали сигнал» превращает невидимую поломку в видимую: убрал свойство — оценка не изменилась — судья мёртв. Копия старой версии превращает откат из «ещё одной генерации, которую снова надо проверить» в простую замену текста.

Рычаги управления: - Размер эталонной выборки — больше задач дают устойчивую оценку согласия. На 20 задачах доверительный интервал у судьи с согласием 0.70 был от 0.36 до 1.00. - Порог согласия — авторы его не фиксируют. Он зависит от цены ошибочного допуска и сдвигается примерно на ±0.15 в зависимости от числа прогонов судьи на правку. Для рискованных правок ставьте выше. - Число прогонов судьи на правку — усреднение по нескольким прогонам меняет порог. Калибруйте на своих данных. - Критерий оценки — формулируйте как жёсткое условие с числом, а не как «поощряй/штрафуй».

Аудит судьи перед запуском цикла самоулучшения:

Ты проводишь аудит LLM-судьи, который одобряет изменения в {что_правим: промпте / описании инструмента / навыке} агента для задачи {задача_агента}.

<промпт_судьи>
{вставь_промпт_судьи_целиком}


<свойство_которое_судья_должен_оценивать>
{например: «агент просит подтверждение перед необратимым действием»}


Сделай по шагам:

ШАГ 1 — Тест «удали сигнал»:
Напиши {число_пар} пар диалогов. В паре первый диалог содержит свойство, во втором оно убрано, остальное идентично. Для каждой пары укажи, какую оценку должен поставить исправный судья.

ШАГ 2 — Тест «постоянный судья»:
Опиши, как понять по результатам, что судья выдаёт одно число на всех входах. Какой разброс оценок считать тревожным?

ШАГ 3 — Проверяемая граница:
Перепиши критерий судьи так, чтобы он был проверяемым условием: «если {условие_по_числу_или_факту}, оценка не выше {порог}».

ШАГ 4 — Согласие с эталоном:
Дай таблицу для ручной разметки {число_диалогов} диалогов: вердикт судьи / вердикт эксперта. Скажи, как посчитать согласие (долю совпадений и коэффициент корреляции) и как заметить, что судья одобряет всё подряд.

ШАГ 5 — Решение:
По итогам выбери одно: ДОПУСТИТЬ автоматику / ОТКЛОНИТЬ / ОТКАЗАТЬСЯ (нужен человек). Укажи, чего не хватает для допуска.

Что подставлять: {что_правим} и {задача_агента} — ваш контекст. {число_пар} — от 6 до 10. {число_диалогов} — не меньше 20, лучше больше. В {условие_по_числу_или_факту} пишите то, что можно проверить глазами.

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

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

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

LLM спросит, какое свойство должен оценивать судья, как выглядят хорошие и плохие диалоги и есть ли у вас эталонная разметка. Эти данные нужны, чтобы собрать парные тесты и таблицу согласия под вашу задачу, а не абстрактные.

⚠️ Одна платформа, один бенчмарк: правило выведено на одной платформе и проверено на сценарном бенчмарке (авиа и ретейл), не в боевой эксплуатации. Результаты нужно перепроверять на своих задачах.

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

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

⚠️ Нужен эталон: согласие мерят против надёжной проверки (программа или эксперт). Без неё σ не посчитать.

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

⚠️ Частично проверено: на практике проверяли только правки промптов. Для инструментов, навыков и обновления весов выводы следуют из определений, но не из экспериментов.

Команда Uniphore построила платформу, где агенты правят сами себя по боевым следам. Сначала они проверили собственный фильтр разнообразия обучающих данных, который основан на LLM-судье. Прогнали 172 настройки по 10 запусков: 3 модели-судьи, 4 варианта промпта, 4 уровня дисбаланса. В развёрнутой настройке судья вернул 0.250 во всех 40 запусках и полностью игнорировал дисбаланс. Он вёл себя ровно так, как если бы про дисбаланс вообще не писали. Полный коллапс встретился в 9 из 37 конфигураций, все на самой маленькой модели. Две модели побольше на тех же входах дисбаланс видели.

Потом перешли к контролируемым опытам на τ²-bench (авиа-поддержка, 50 задач: 30 на обучение, 20 на проверку). Там одни и те же прогоны можно оценивать разными проверяющими. LLM-судья показал согласие с программной проверкой 0.70. Это намного выше нуля, но не идеал. Ошибки кластеровались: все 4 ложных допуска пришлись на одну задачу. Судья «одобряй всё» получил ровно 0 и при этом пропустил все 42 провальных прогона.

В третьем опыте проверяли откат. Сохранённая копия вернула поведение к уровню естественного шума. Три регенерированных отката остались заметно хуже исходного (падение на 0.16). Правки, пока были в работе, изменили исход у 17% задач. Задачи улетели и вверх (18), и вниз (20), так что в среднем эффект нулевой, а охват большой. Вывод для практики: средний балл «до/после» скрывает охват правки.

🔧 Техника: версионирование в файле инструкций → откат без генерации

Перед любой автоправкой инструкций добавьте агенту правило. Например, в CLAUDE.md:

Перед изменением файлов инструкций (CLAUDE.md, промпты, навыки):
1. Скопируй текущую версию в /archive/{имя_файла}_{дата}.
2. Запиши в CHANGELOG, что меняешь и по какой причине.
3. Откат делай только копированием файла из /archive. Не переписывай «как было» по памяти.
4. Если не уверен, что копия сохранена, остановись и спроси человека.

Это прямо следует из находки: регенерированный откат не возвращает поведение, копия возвращает.

🔧 Техника: контрольные судьи → видно «пустую» оценку

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

Экстраполяция: правило «отказаться» в инструкции агенту. Добавьте в системный промпт агента-улучшателя явный третий исход:

Copy

По каждой правке выбери одно: ДОПУСТИТЬ / ОТКЛОНИТЬ / ОТКАЗАТЬСЯ.
ОТКАЗАТЬСЯ — если не измерено согласие судьи с экспертом, или нет сохранённой старой версии, или правка затрагивает необратимые действия.
При отказе напиши, чего именно не хватает, и передай человеку.

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

• Работа: Recoverability and Verifier Strength: Two Measured Preconditions for Unattended Agent Self-Improvement
• Авторы: De Wang, Peng Qi (Uniphore)
• Площадка: NeurIPS 2026, Workshop AgenticOS
• Бенчмарк: τ²-bench (Barres et al., 2026); исходный τ-bench (Yao et al., 2025)
• Связанные работы: Zheng et al., 2023 (LLM-as-a-Judge); Shinn et al., 2023 (Reflexion); Madaan et al., 2023 (Self-Refine); Khattab et al., 2024 (DSPy)