TL;DR
RewardEngine — схема, где агент до сдачи работы составляет себе набор проверок. Часть проверок — жёсткие тесты «да/нет», часть — шкальные рубрики качества. Каждая проверка пересчитывает результат по исходным данным и возвращает «квитанцию»: «ожидал 78%, получил 92% — провал». Потом проверки испытывают на заведомо плохих и пограничных примерах, замораживают, и только после этого агент правит работу по ним.
Главная боль в том, что у открытых задач (отчёт по таблицам, разбор тикетов) нет готового правильного ответа. Модель-судья смотрит на «общее впечатление», и красивый отчёт с неверной цифрой проходит. Сам агент тоже не понимает, что именно чинить: ему говорят «стало лучше/хуже», а не «вот эта цифра не сходится с исходными строками». Дополнительный риск: проверка, которую написала сама модель, может быть кривой. Она читает не ту колонку или пропускает почти-правильный вариант.
Суть метода в трёх ходах. Строим проверки по задаче и первым черновикам. Атакуем их контрпримерами и чиним так, чтобы не сломать то, что уже работало. Используем замороженный набор: критик берёт до трёх проваленных проверок и даёт правки, а новая версия заменяет исходную только если она строго лучше и не провалила ничего из того, что исходная проходила.
Схема метода
ЭТАП 1. СТРОИМ НАГРАДУ (критерии + проверки)
1a. Жюри (3 роли) пишет обязательства из задачи, до просмотра результатов
→ затем сверяет с первыми черновиками
1b. Редьюсер сливает в критерии: тест (pass/fail) или рубрика (fail/partial/full)
1c. Строитель привязывает к каждому критерию проверку,
которая пересчитывает по источнику → вердикт + квитанция
ЭТАП 1.5. САМОАТАКА (контроль качества проверок)
Строим примеры трёх видов: контрольный (должен пройти),
ошибочный (нарушает критерий), пограничный (почти-промах)
→ эталонную метку ставит отдельный «слепой» судья
→ чиним проверку, только если: ничего из ранее верного не сломано,
исправлена хотя бы одна ошибка, нет «неразрешённых» случаев
→ ЗАМОРАЖИВАЕМ набор
ЭТАП 2. РАБОТАЕМ ПО НАГРАДЕ (набор заморожен)
Кандидат A: только задача | Кандидат B: правки по проваленным проверкам
(критик берёт ≤3 проверки) | Кандидат C: с дополнительной гипотезой
→ Жюри ранжирует по результатам и квитанциям
→ B или C заменяют A, только если строго лучше И не провалили то, что A проходил
ЭТАП 3. ОБНОВЛЯЕМ (только между раундами)
Что нашли при использовании → в следующий набор проверок
В оригинале это система из множества вызовов модели. В чате или у агента её можно прогнать несколькими запросами или одним длинным промптом: так читатель получает ту же структуру без кода.
Пример применения
Задача: Вы селлер на Wildberries. Агент (Claude Code или Cursor) получает выгрузку продаж за неделю и должен собрать отчёт для собственника: выручка, процент выкупа, топ-5 артикулов. Типовой провал: отчёт красивый, процент выкупа в нём 92%, а по строкам выгрузки получается 78%. Файл создан, форматирование на месте, судья-модель кивает.
Промпт:
Ты работаешь в режиме «сначала критерии, потом работа». Ты не сдаёшь отчёт,
пока он не прошёл замороженный набор проверок.
Файл: wb_sales_week_42.csv (выгрузка продаж Wildberries, 18 400 строк).
Нужно: недельный отчёт для собственника в report.xlsx — выручка в рублях,
процент выкупа, топ-5 артикулов по выручке, 3 вывода.
Период: 14–20 октября. Выкуп = выкупленные / заказанные штуки.
Три роли независимо пишут обязательства ДО просмотра результата:
- Jury_1 (бухгалтер): точность чисел и периода
- Jury_2 (собственник): что нужно для решения, чего не должно быть
- Jury_3 (скептик): где модель обычно ошибается в таких отчётах
Затем редьюсер сливает их в критерии. Каждый критерий:
- тип: TESTCASE (pass/fail) или RUBRIC (fail/partial/full с описанием якорей)
- источник: откуда обязательство
- проверка: как пересчитать из исходных строк CSV (не «выглядит верно»)
- формат вердикта: {критерий, вердикт, квитанция «ожидал X, получил Y»}
Если данных для проверки нет — вердикт «нет данных» (не fail).
Если проверка сама сломалась — «проверка не выполнена».
Для каждой проверки придумай примеры трёх видов:
- control: корректный результат (проверка должна пройти)
- error: результат с нарушением (например, подправленная ячейка,
меняющая процент выкупа)
- boundary: почти-промах (например, 77,6% вместо 78%, или период 13–20 октября)
Эталонную метку каждому примеру ставь отдельно, не глядя на то, как устроена проверка.
Если проверка ошиблась — исправь. Исправление принимается, только если:
(а) все ранее верные случаи остались верными, (б) исправлен хотя бы один
ошибочный случай, (в) не появилось случаев «нет решения».
После этого НАБОР ЗАМОРОЖЕН. Правила не менять до конца раунда.
1. Сделай отчёт только по задаче → кандидат A.
2. Прогони A по замороженному набору, выведи таблицу «критерий | вердикт | квитанция».
3. Critic: выбери не более 3 самых значимых проваленных проверок,
сформулируй правки со ссылкой на квитанции. Если неясно — задай вопрос или воздержись.
4. Исправь отчёт → кандидат B. Перепроверь.
5. Выбор: B заменяет A, только если он строго лучше И не провалил ни одной проверки,
которую проходил A. Иначе оставь A.
Результат: Модель сначала выдаст список критериев от трёх «жюри» (например, формулу выкупа, период, сверку суммы выручки с исходными строками). Затем покажет примеры-атаки на свои же проверки и поправки к ним. Дальше будет таблица проверок по первому варианту отчёта с квитанциями вроде «ожидал / получил». В конце: правки по трём главным провалам, повторная проверка, решение «B заменил A» или «остался A» и список того, что проверить не удалось. Ключевой артефакт здесь таблица с квитанциями: по ней видно, где отчёт врёт.
Почему это работает
Слабость. Когда модель оценивает результат «в целом», она судит по внешнему виду: порядку, оформлению, уверенному тону. Цифра 92% рядом с красивой таблицей выглядит убедительно. Если критерии придумывать на ходу, они подстраиваются под уже готовый ответ. Если проверку не испытывать, она может проверять не то.
Сильная сторона. Модель хорошо пересчитывает конкретное по источнику («возьми строки, посчитай долю») и хорошо придумывает контрпримеры. Ей легче найти способ сломать проверку, чем написать идеальную с первого раза.
Как метод это использует. Критерии фиксируются до просмотра результата. Проверка обязана пересчитывать по исходникам и выдавать квитанцию, поэтому критику понятно, что чинить. Проверку атакуют контрпримерами, а правка принимается только без регрессии: что было верно, остаётся верным. Набор замораживают, чтобы улучшение не оказалось «сдвигом цели» (поменяли линейку и решили, что стало лучше).
Рычаги управления промптом: - Число проверок у критика (≤3 в оригинале) → увеличьте для крупных задач, уменьшите для экономии токенов. Меньше — правки точнее. - Состав жюри → дайте ролям конкретные профили под вашу область (бухгалтер, юрист, клиент). Критерии станут разнообразнее. - Три вида контрпримеров (control / error / boundary) → boundary ловит «почти правильно». Не убирайте его, это самая частая реальная ошибка. - Статус «нет данных» → не превращает отсутствие доказательства в провал. Отличает «нарушено» от «не смог проверить». - Условие замены («строго лучше и ничего не сломал») → ослабьте, если хотите больше экспериментов; ужесточите, если важна стабильность.
Шаблон промпта
Ты работаешь в режиме «сначала критерии, потом работа». Не сдавай результат,
пока он не прошёл замороженный набор проверок.
{задача}
Входные данные: {файлы_или_текст}
Ограничения и определения: {период, формулы, формат, что считать успехом}
Три роли независимо пишут обязательства ДО просмотра результата:
- Jury_1 ({роль_1}): {на_что_смотрит}
- Jury_2 ({роль_2}): {на_что_смотрит}
- Jury_3 (скептик): где модели обычно ошибаются в такой задаче
Редьюсер сливает в критерии. Для каждого:
- тип: TESTCASE (pass/fail) или RUBRIC (fail/partial/full + описание каждого уровня)
- источник обязательства
- проверка: как пересчитать из исходных данных
- вердикт: {критерий, вердикт, квитанция «ожидал X, получил Y»}
Нет данных → «нет данных». Проверка сломалась → «проверка не выполнена».
Оба статуса не равны fail.
Нерешённые обязательства оставь видимыми.
Для каждой проверки построй примеры: control (должен пройти),
error (нарушает критерий), boundary (почти-промах).
Эталонные метки ставь отдельно, не опираясь на устройство проверки.
Если проверка ошиблась — исправь.
Принимай исправление, только если:
(1) все ранее верные случаи остались верными,
(2) исправлен минимум один ошибочный,
(3) нет случаев «нет решения».
После этого НАБОР ЗАМОРОЖЕН.
1. Кандидат A: выполни задачу, пока не опираясь на набор.
2. Прогони A по набору → таблица «критерий | вердикт | квитанция».
3. Critic: до {число_проверок} самых значимых провалов; правки со ссылкой
на квитанции. Если неясно — вопрос или воздержание.
4. Кандидат B: исправь и перепроверь.
5. B заменяет A, только если строго лучше И не провалил то, что проходил A.
Если при проверке найдены новые дефекты набора — запиши их для СЛЕДУЮЩЕГО раунда.
Текущий набор не меняй.
Что подставлять: {задача} — конкретное дело; {роль_1}, {роль_2} — два профиля людей, которые будут принимать работу; {число_проверок} — обычно 3.
🚀 Быстрый старт — вставьте в чат:
Вот шаблон RewardEngine. Адаптируй под мою задачу: [твоя задача].
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит, какие входные данные и определения у вас есть, кто принимает работу и какие ошибки для вас самые дорогие. Это нужно, чтобы роли жюри и проверки были привязаны к реальным критериям приёмки. Из шаблона она возьмёт структуру этапов и подгонит под вашу задачу.
Ограничения
⚠️ Скромный эффект: на одном бенчмарке прирост среднего балла статистически неотличим от нуля (интервал включает ноль). На другом он заметен, но небольшой. Рассчитывать на «чудо» не стоит.
⚠️ Цена: система делает намного больше вызовов модели, чем один прогон. Авторы сознательно не сравнивали общую стоимость и равный бюджет. Возможно, часть выигрыша куплена токенами.
⚠️ Не ловит забытые требования: если ни одна роль жюри не придумала нужное обязательство, проверка его не увидит. Авторы это признают.
⚠️ Эталонные метки — тоже суждения модели: их точность не измеряли. Ошибочная метка закрепляется так же крепко, как верная, потому что правка не должна её «ломать».
⚠️ Заморозка не спасает от обмана метрики: фиксированная проверка тоже может быть «перехитрена» агентом. Стабильность цели не равна правильности цели.
⚠️ Стабильность vs качество: простая «всегда принимай правку критика» даёт больше полностью успешных серий из трёх запусков, чем выбор по набору. Выбор повышает средний балл, но немного жертвует стабильностью.
⚠️ Не проверено: обучение с подкреплением на таких наградах и «мета-цикл» улучшения самого способа строить проверки авторы не оценивали.
Как исследовали
Идея была простой: открытая задача не имеет правильного ответа, значит, агент должен сам выучить критерии, как студент перед незнакомым экзаменом. Проверили на двух бенчмарках: WorkBuddy Bench Office (50 офисных задач со смешанными файлами) и Claw-Eval (104 версии задач из 68 сценариев с исполняемой средой). Скрытые ответы и оценки грейдера системе не показывали.
Сравнивали итоговый результат («выбрано по награде») с чистым Baseline, с «всегда брать ревизию», с равномерным случайным выбором и с Oracle, который всегда берёт лучшего по настоящему грейдеру. На Claw-Eval средний балл вырос на ~2 пункта (интервал не включает ноль), доля серий «три успеха из трёх» выросла с 78,4% до 83,7%, число провалов упало на 37,5%. На WorkBuddy серии «три из трёх» выросли с 45% до 54%, но по среднему баллу интервал включал ноль.
Отдельно проверили: насколько порядок кандидатов по замороженной награде совпадает с порядком грейдера. Совпадение — около 82% и 80% пар. Выбор по награде отыгрывает 26–39% разрыва между случайным выбором и идеальным.
Неожиданность: простая «всегда принимай ревизию» даёт лучшую стабильность. Практический вывод такой: проверки с квитанциями реально помогают агенту чинить результат, но выбор между вариантами остаётся компромиссом. Авторы честно оговаривают, что наборы могли «видеть» оцениваемых кандидатов, то есть обобщение на новые варианты не измерено.
Адаптации и экстраполяции
🔧 Техника: убрать этап выбора A/B → оставить только «чек-лист и правка»
Для рутинных задач, где вы и так делаете одну версию, возьмите Stage1 + Stage1_5 + шаг «Critic ≤3 → правка» и удалите кандидатов A/B/C. Получается облегчённая версия: дешевле, но защиты от «правка сделала хуже» меньше. Верните условие замены, если задача критична.
Экстраполяция: правило в CLAUDE.md / AGENTS.md
Перед сдачей любого отчёта, таблицы или документа: (1) составь список проверяемых обязательств по задаче, отдельно жёсткие (да/нет) и качественные (по шкале); (2) для каждого пересчитай значение из исходных данных и запиши «ожидал X, получил Y»; (3) не меняй критерии после просмотра результата; (4) исправь не более трёх главных провалов; (5) если правка ломает то, что уже проходило, откати её; (6) в конце перечисли, что проверить не удалось.
Это перенос принципов статьи (критерии до результата, квитанции, заморозка, запрет регрессии) в постоянную инструкцию агенту. В самой статье такой вариант отдельно не проверяли.
Ресурсы
- Работа: RewardEngine: Reward-Centric Self-Evolution for Open-Ended Tool Agents. В предоставленном фрагменте указана аффилиация Ji Qi (Department of Statistics and Data Science, CUHK); полный список авторов не приведён.
- Бенчмарки: WorkBuddy Bench Office (Tencent Youtu Lab et al., 2026); Claw-Eval (Ye et al., 2026).
- Близкие работы из текста: EvoRubrics (Ding et al., 2026) — rubric co-evolution; Self-Refine, Reflexion, CRITIC, TextGrad; Stechly et al., 2025 о том, что часть эффекта «критики» объясняется простым повторным запросом.