TL;DR
AdaPRA — это связка из двух агентов. Первый пишет код и делает ML-проект. Второй, ревизор (process reward agent, PRA), каждые несколько шагов заглядывает в папку проекта и проверяет работу по списку критериев (рубрик). Проверяет не на слово: он сам пишет и запускает код, пересчитывает метрики и смотрит файлы. Провалившиеся и важные для текущего этапа критерии ревизор вставляет рабочему агенту прямо в поток сообщений. Попутно папка проекта сохраняется между попытками, а список критериев пополняется под конкретную задачу.
Главная боль: ошибки молчаливые. Агент отчитывается «всё готово», файл с результатом валидный, в логе ни одной ошибки. На деле неверный путь к файлам превратил все 158 тысяч аудиозаписей в тишину, и модель на каждую отвечает «неизвестно». Другие частые проблемы: агент останавливается на первом рабочем решении и не пробует модели посильнее, а валидация «протекает». Судья, который читает только историю действий, этого не видит: там агент пишет о своих намерениях, а не о реальном состоянии файлов. Поэтому ревизору нужен доступ к самим файлам и возможность запускать проверки.
Метод в четыре хода. Критерии добывают из логов прошлых запусков, сравнивая лучшие попытки с худшими. Ревизор проверяет работу кодом. Агенту показывают только провалившиеся важные пункты. Критерии дописывают под задачу по ходу работы. Итог: средний процентиль на Kaggle вырос с 44,5 до 69,0 на простых задачах и с 21,3 до 36,1 на сложных, причём часть прироста даёт сам сохраняемый между попытками проект.
Схема метода
ПОДГОТОВКА (один раз, офлайн)
Логи + папки прошлых запусков → ЛУЧШИЕ и ХУДШИЕ попытки одной задачи
ШАГ A: LLM вытаскивает «что сработало / что подвело» + цитаты-доказательства
ШАГ B: LLM сводит всё в набор рубрик без пересечений (MECE) → ~19 рубрик
РАБОТА (на каждой попытке)
Рабочий агент пишет код ──каждые c шагов и перед финишем──▶
РЕВИЗОР (отдельный агент, папка агента — только чтение):
1. Читает историю и файлы выборочно (не всё в контекст)
2. По каждой рубрике: пишет и запускает свою проверку
3. Ставит: p (выполнено?), i (важно сейчас?), обоснование, что делать
4. Фильтр: показать только i ≥ 0,5 И p < 0,6
5. Короткий отчёт ─▶ прямо в поток сообщений агента
6. Добавляет / обновляет / снимает рубрики под эту задачу
Между попытками: папка проекта и сводки прошлых попыток сохраняются
Шаги выполняются в отдельных запусках: рабочий агент и ревизор — разные агенты.
Пример применения
Задача: Вы аналитик у продавца на Wildberries. Claude Code строит модель прогноза спроса на 2 недели по SKU. Агент отчитался: «MAPE 9%, модель готова, прогноз выгружен в forecast.csv». Слишком красиво. Хочется поручить второй сессии проверить работу не по отчёту, а по файлам.
Промпт (для второго агента-ревизора с доступом на чтение к папке проекта и терминалом):
Ты ревизор работы другого агента. Папка проекта /project доступна тебе
только на чтение. Свои проверки пиши и запускай в /audit.
Не верь отчётам агента: любое его утверждение проверяй по файлам.
Агент строил прогноз продаж на 14 дней вперёд по SKU Wildberries.
Данные: /project/data/sales.csv (дата, sku, цена, остатки, продажи).
Результат: /project/forecast.csv.
R1 Целостность выгрузки: в forecast.csv все SKU, все 14 дней, нет NaN,
разброс прогнозов не равен нулю.
R2 Честная валидация: в валидации обучающие даты строго раньше проверочных,
нет утечки будущего (скользящие средние, остатки «на завтра»).
R3 Сравнение моделей: первая рабочая модель сравнена минимум с одним
более сильным семейством (например, градиентный бустинг против
простого базового прогноза).
R4 Признаки: сезонность, акции, цена, остатки действительно дошли
до финальной модели.
R5 Происхождение результата: forecast.csv получен именно тем
пайплайном, который описан в отчёте.
R6 Эффективность: нет повторов одной и той же упавшей команды;
если улучшений нет несколько экспериментов подряд, сменён подход.
Для каждой рубрики:
1. Выбери, что проверить: файлы или историю действий.
2. Если проверка требует вычислений (пересчитать метрику по
out-of-fold предсказаниям, сравнить разброс прогноза и факта),
напиши и запусти код в /audit.
3. Выставь:
p — вероятность, что рубрика выполнена (0–1)
i — важность рубрики на текущем этапе работы (0–1)
обоснование — 1–2 предложения с ссылкой на файл или число
действие — конкретный следующий шаг для агента
- В отчёт попадают ТОЛЬКО рубрики с i ≥ 0,5 и p < 0,6.
- Порядок: по убыванию важности.
- Без похвал и пересказа того, что в порядке.
- Если провалов нет, напиши: «Критичных замечаний нет».
- Если нашёл ошибку, которой нет в рубриках, добавь новую рубрику
в конец отчёта (название, критерий, как проверять) — только если
успел запустить для неё проверку.
Результат: Ревизор выдаст короткий отчёт только по провалившимся важным рубрикам. Для каждой будут обоснование со ссылкой на файл или число и конкретное действие для агента. Если всё в порядке, придёт одна строка. В конце он может предложить новую рубрику, которая появилась из его проверок. Вы скопируете отчёт в сессию рабочего агента и получите исправленную версию.
Почему это работает
Слабость. LLM-судья, читающий только историю действий, верит словам агента. Агент пишет «проверил валидацию», и судья принимает это за факт. Но самые вредные ошибки (утечка, неверный путь, остановка на простой модели) в логе не видны. Если выдать судье весь отчёт по всем критериям, он тонет в «всё хорошо», и рабочий агент действует так же, как без отчёта.
Сильная сторона. Модель хорошо пишет короткий код для проверки конкретного факта: пересчитать метрику, сравнить разброс, посмотреть, не одинаковы ли все предсказания. Также она хорошо сравнивает две попытки и выделяет, чем удачная отличается от неудачной.
Как метод это использует. Он заменяет вопрос «похоже ли, что агент сделал правильно» на вопрос «подтверждается ли это файлами». Критерии берутся из реальных ошибок, а не из головы. Фильтр оставляет только то, что важно сейчас и скорее всего провалено, и такой отчёт агент действительно выполняет.
Рычаги управления: - Частота ревизий (c). Чаще — раньше ловишь ошибки, но дороже. Проверка перед финишем нужна всегда. - Пороги важности и вероятности (0,5 и 0,6). Строже — меньше шума, но можно пропустить ошибку. Мягче — больше замечаний. - Список рубрик. Добавляй свои, исходя из ваших типовых ошибок. Это главный рычаг. - Куда идёт отчёт. Авторы пробовали записывать отчёт в файл — агент иногда его не открывал. Вставка прямо в диалог сработала лучше. - Запрет ревизору менять файлы. Нужен, чтобы проверка не подправляла работу молча.
Шаблон промпта
Ты ревизор работы агента по задаче: {задача}.
Папка проекта {путь} доступна только на чтение. Свои проверки пиши
и запускай в {папка_ревизора}. Не верь отчётам агента: проверяй
по файлам и результатам запуска.
{список рубрик: ID, название, критерий проверки.
Группы: валидация, выбор и сравнение моделей, подготовка данных,
целостность итогового файла, эффективность работы}
Для каждой рубрики:
1. Реши, что проверять: файлы проекта или историю действий агента.
2. Если нужны вычисления — напиши и запусти код проверки.
3. Выставь p (выполнено, 0–1), i (важность на этом этапе, 0–1),
обоснование со ссылкой на файл или число, следующее действие для агента.
- Показывай только рубрики с i ≥ {порог_важности} и p < {порог_выполнения}.
- Порядок: по убыванию важности.
- Коротко и по делу, без пересказа того, что в порядке.
- Если нашёл новую ошибку, которой нет в списке, предложи новую рубрику,
но только после того, как запустил для неё проверку.
Подставьте:
- {задача} — что делает агент;
- {путь} — папка проекта;
- {список рубрик} — 5–20 критериев, которые вы видели нарушенными;
- пороги — по умолчанию 0,5 и 0,6.
🚀 Быстрый старт — вставь в чат:
Вот шаблон ревизора агента (AdaPRA). Адаптируй под мою задачу: [твоя задача].
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит, какую работу делает агент, где лежат его файлы, какие ошибки у него уже бывали и как выглядит «хороший результат». Это нужно, чтобы превратить ваши боли в проверяемые рубрики и подобрать для них проверки кодом.
Ограничения
⚠️ Нужна инженерия: В статье это полноценная система: харнесс на OpenHands, ревизор с терминалом, хранилище рубрик, вставка отчётов в поток сообщений. Полностью повторить её можно только кодом. В чате получается упрощённая версия: вы сами вручную переносите отчёт между сессиями.
⚠️ Без запуска кода хуже: Когда ревизор только читал файлы, результат падал с 69,0 до 63,0 на простых задачах и с 36,1 до 31,8 на сложных. На сложных задачах разница не прошла проверку на значимость.
⚠️ Нужен сильный ревизор: Ревизором была Claude Sonnet 4.6, а рабочим агентом — более слабая открытая модель. Слабый ревизор может сам ошибаться в проверках.
⚠️ Рубрики сделаны под data science: Список из 19 рубрик относится к ML-задачам на Kaggle (валидация, утечки, выбор моделей). Для других работ нужны другие критерии. Принцип переносится, готовый список нет.
⚠️ Шум в метриках: Медали на Kaggle — шумная метрика, и по ней картина противоречива. По медалям вариант без запуска кода на сложных задачах выглядит лучше, а по процентилю хуже. Эффект на «пробиваемость» ограничен: на сложных задачах медалей получают единицы.
⚠️ Сравнение с GPT-5.1 неполное: Одна попытка AdaPRA примерно равна одной попытке GPT-5.1, но внешние результаты взяты из другой статьи и другого запуска.
⚠️ Универсальный судья вредит: DataPRM (пошаговый судья без рубрик) на сложных задачах оказался хуже, чем вообще без супервизии. Шаг «правильный» ещё не значит, что весь процесс разумный.
Как исследовали
Исследователи взяли два набора Kaggle-соревнований из DSGym: 38 простых табличных задач (Easy) и 54 сложные с изображениями, текстом, аудио и молекулами (Hard). Рабочим агентом был Qwen3-Coder-Next на 80 миллиардов параметров, ревизором — Claude Sonnet 4.6. Каждой задаче давали по 5 последовательных попыток. Оценки Kaggle ни агент, ни ревизор не видели, их использовали только для измерения.
Рубрики сначала добыли из прошлых запусков на лёгких задачах. LLM-судья нашёл в попытках 906 поведений: 564 проблемы и 342 хороших. Оставили проблемы нижней четверти и хорошее из верхней четверти, потом свели к 17 рубрикам и добавили 2 на переносимость между попытками. Эти 19 рубрик отдали без изменений на сложные задачи. Они сработали: правила, найденные на простом, помогли и на трудном.
Сравнивали шесть вариантов: стандартный DSGym, только сохраняемый проект, DataPRM, полный AdaPRA, без адаптации рубрик и без запуска кода ревизором. Одна лишь сохраняемая между попытками папка уже подняла процентиль с 44,5 до 60,8 на Easy. Ревизор добавил ещё 8,2 пункта. На Hard всё наоборот: сохранение дало 4,2, ревизор 10,6. Сложные задачи требуют контроля сильнее, чем просто памяти.
Из неожиданного. В раннем варианте ревизор отчитывался по всем рубрикам, но большинство проходило почти всегда, и агент действовал одинаково с отчётом и без. Фильтр «только важные провалы» решил проблему. Отчёт в файле агент иногда игнорировал, вставка в диалог работала лучше. Адаптация рубрик под задачу добавила 1,7 пункта на Easy и 4,3 на Hard, а ревизор почти только добавлял рубрики, снимал их практически никогда. Больше всего новых рубрик появлялось в первых двух попытках, и ими стали проверки вроде «разброс предсказаний слишком мал по сравнению с реальными значениями».
Оригинал из исследования
Полные промпты ревизора и добычи рубрик лежат в приложениях (E.2, E.3), в предоставленном тексте их нет. Вот формат оценки и примеры рубрик из основного текста:
S(x, W, τ:t, ρj) = (pj, ij, ej, âj)
pj — probability of satisfaction ∈ [0,1]
ij — importance ∈ [0,1]
ej — rationale
âj — suggested next action
Показывать агенту: ij ≥ 0.5 и pj < 0.6
Пример рубрики: "compare the first valid baseline against at least one stronger model family."
Artifact-grounded: "the submission has the correct columns and row count"
Trajectory-grounded: "kept retrying the same failing command"
Добавленная ревизором: "prediction underdispersion" — проверяет, что out-of-fold предсказания не намного менее разбросаны, чем целевая переменная.
Контекст: Это формат, в котором ревизор оценивает каждую рубрику, и порог, по которому отбираются пункты для показа агенту.
Адаптации и экстраполяции
💡 Адаптация для обычного кодового агента (CLAUDE.md): Статья показывает, что отчёт лучше вставлять в диалог, чем оставлять файлом. Но два принципа можно закрепить в инструкциях и до полной системы с ревизором:
## Перед тем как сказать «готово»
1. Не пересказывай, что сделал. Для каждого пункта чек-листа ниже
запусти проверку и покажи результат (число, вывод команды).
2. Если первое рабочее решение получено, сравни его минимум с одним
более сильным вариантом, прежде чем останавливаться.
3. Проверь итоговый файл: размер, колонки, нет ли одинаковых значений
во всех строках.
4. Веди NOTES.md: что пробовали, что не сработало, что осталось.
В начале следующей сессии прочти его.
Это самостоятельная адаптация, статья этот текст не проверяла. Пункт 4 соответствует идее сохраняемой памяти между попытками.
🔧 Техника: добывать рубрики из своих логов → критерии под ваши ошибки. Если у вас накопились удачные и неудачные сессии с агентом, дайте LLM по очереди обе группы:
Вот 5 лучших и 5 худших запусков агента по одной задаче: {логи}.
Для каждого найди поведения, которые объясняют разницу результатов,
с цитатой-доказательством. Потом сведи в 10–15 непересекающихся
проверяемых критериев и пометь: можно ли проверить по файлам
или только по истории действий.
Это воспроизводит двухэтапную добычу рубрик из статьи, но в виде промпта. В статье она работала на 906 поведениях из 190 попыток, а в чате у вас будет выборка гораздо меньше.
Ресурсы
- AdaPRA: Process Reward Agents with Adaptive Rubrics for Data Science — Atharva Naik, Vivek Chari, Pol Llado, Daniel Fried, Carolyn Rosé, Benjamin Van Durme, Sam Thomson, Justin Svegliato. Carnegie Mellon University, Microsoft. Авторы сообщают, что делятся кодом для воспроизведения.
- Связанные работы: DSGym (Nie et al., 2026), DataPRM (Qiu et al., 2026), RubricEM (Li et al., 2026), OpenHands (Wang et al., 2025), Zhang et al. (2026b) — контрастное обнаружение рубрик.