AdaPRA: агент-супервайзер поднял результат ИИ в дата-сайентистских задачах на 24,5 процентиля

Агенты, которым поручают полный цикл дата-сайенс-задачи — от загрузки данных до отправки предсказаний на Kaggle, — регулярно теряют баллы не из-за незнания алгоритмов, а из-за процессных промахов: останавливаются на первой работающей модели вместо того, чтобы попробовать что-то сильнее, путают обучающую и проверочную выборки, допускают утечку данных в кросс-валидации. Хуже того, многие такие ошибки не оставляют следа в логе выполнения — пайплайн формально отрабатывает и выдаёт файл с ответами, а то, что ответы бессмысленны, становится видно только при ручной проверке. Авторы из Carnegie Mellon University показывают характерный пример: агент должен распознавать голосовые команды по 12 классам, но из-за неверного пути к файлам все 158 538 тестовых аудиозаписей загружаются как тишина — и модель классифицирует их все как «неизвестная команда», при этом лог выглядит так, будто всё прошло штатно.

Как работает проверяющий агент

Решение называется AdaPRA (Process Reward Agent с адаптивными рубриками). Это не статичный чек-лист и не обычный LLM-судья, который просто читает текстовый отчёт о работе агента. AdaPRA — сам по себе агент с доступом к терминалу: он открывает рабочую папку основного агента, запускает собственный код, чтобы пересчитать метрики (например, заново посчитать качество кросс-валидации по отложенным предсказаниям), и только после этого выносит вердикт по каждому пункту рубрики. Это нужно, потому что отчёты самого агента о своей работе нельзя принимать на веру — агент может искренне ошибаться насчёт того, что он на самом деле сделал.

Проверка идёт не постоянно, а через фиксированные интервалы — каждые несколько шагов агента, плюс финальная проверка перед сдачей результата. Чтобы не перегружать агента лишней информацией, в отчёт попадают только те пункты рубрики, которые действительно важны для текущей задачи и, по оценке проверяющего, скорее всего не выполнены — с вероятностью нарушения выше 40% и значимостью не ниже половины от максимума.

Откуда берутся правила и почему они переносятся между задачами

Авторы не писали рубрики руками — это было бы нереально для сотен типов задач. Вместо этого они прогнали базового агента много раз на 38 задачах уровня «легко» (набор DSPredict-Easy, в основном табличные соревнования Kaggle Playground Series) и сравнили лучшие попытки с худшими по итоговому месту в лидерборде. LLM-судья (Claude Sonnet 4.

6) извлёк из 906 наблюдений — удачных приёмов и провалов — 342 «хороших» паттерна и 564 проблемы, а затем сгруппировал их в 17 конкретных правил плюс 2 общих правила про использование прошлых попыток — итого 19 базовых рубрик. Важная деталь: почти все выявленные проблемы видны только в самом коде и логах работы (344 из 564), а удачные решения — в артефактах рабочей папки (235 из 342). То есть если смотреть только на диалог с агентом или только на файлы — большую часть сигналов потеряешь.

Эти 19 рубрик без каких-либо изменений перенесли на DSPredict-Hard — набор из 54 куда более сложных задач (зрение, текст, аудио, молекулярные данные), и они сработали. При этом AdaPRA умеет и дописывать правила на лету: например, на задаче House Prices проверяющий сам добавил правило под названием «недостаточная дисперсия предсказаний» — проверку того, не стягивает ли модель все прогнозы цен к среднему значению, вместо того чтобы давать разброс.

Результаты и ограничения

При пяти попытках на задачу AdaPRA с базовой моделью Qwen3-Coder-Next (80 млрд параметров) поднял средний процентиль на лидерборде Kaggle на 24,5 пункта на лёгких задачах и на 14,8 пункта на сложных — это сопоставимо или лучше результатов GPT-5.1 с усиленным режимом рассуждений. Система также обошла DataPRM — конкурирующую модель-проверяющую на 4 млрд параметров, которая оценивает шаги агента по шкале 0–1 без использования гибких рубрик. Отдельный эксперимент показал, что рубрики, собранные на одной модели, работают и при переносе на другую — DeepSeek-V3.2.

Для инженерных команд, которые строят автономных агентов для анализа данных, вывод практичный: проверка «по логу диалога» ловит далеко не все ошибки — нужен супервайзер с правом сам исполнять код и смотреть в файлы рабочей папки. Второй вывод — сохранять контекст между попытками (а не стартовать каждый раз с чистого листа) само по себе даёт заметный прирост, ещё до добавления любого внешнего контроля качества.