Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Модель научили не только отклонять ошибочный код, но и предъявлять входные данные, на которых он ломается. Работа HKUST и Amazon показывает, что Arbiter повысил точность решения «принять или отклонить» с 71,41% до 87,41%, хотя препринт не рецензирован и числа получили сами авторы. Такой проверяющий агент может отбирать варианты и подсказывать исправления, не расходуя лимит обращений к официальной системе.
Как диагноз превращают в проверяемый контрпример
Обычная модель-оценщик может назвать программу неверной и правдоподобно объяснить ошибку. Но объяснение само по себе ничего не доказывает: модель способна неверно понять условие или придумать сбой, которого в коде нет.
Arbiter получает условие задачи и исходный код, но не видит скрытые тесты, эталонное решение и ответ официальной системы. Агент работает в обычной песочнице: запускает команды, пишет собственные тесты, компилирует программу и исследует её поведение. Основой служит Qwen3.6-35B-A3B со смесью экспертов.
В конце агент возвращает вердикт, описание предполагаемой ошибки и генератор входных данных на Python. Для ошибки с отрицательными числами такой генератор может напечатать набор, на котором программа ошибочно оставляет начальное значение ноль вместо настоящего максимума.
Затем независимая инфраструктура проверяет, допустим ли вход по условию, запускает кандидат и сравнивает результат с эталоном. Если программа ломается, контрпример становится воспроизводимым свидетельством ошибки. Если агент ничего не нашёл, это ещё не доказывает корректность: один тест может опровергнуть программу, но конечное число тестов не подтверждает её для всех входов.
Эта асимметрия определила обучение. За простое угадывание отрицательного вердикта агент получал мало пользы; основная награда зависела от легального входа, который действительно ломает кандидат. Без такого условия модель быстро училась отклонять большинство программ и почти переставала пользоваться песочницей.
Обучение улучшило и вердикты, и поиск ошибок
До обучения агент находил успешный контрпример для 40,61% неправильных программ, после — для 62,67%. Здесь успех означает не убедительный текст, а вход, который прошёл проверку ограничений и воспроизвёл ошибку при исполнении.
Главный набор USACO-JUDGE включает 900 программ для 39 задач соревнований USACO. В него вошли принятые и отклонённые решения на C++17 от опытных участников и нескольких LLM. Это позволяет измерять не только способность находить дефекты, но и умение не отклонять правильный код.
Проверку дополнили задачами из LiveCodeBench и OJBench для отбора готовых вариантов. Arbiter ранжировал наборы программ по собственным вердиктам: если агент несколько раз признавал кандидат правильным, тот получал приоритет. Во всех показанных условиях такой отбор обошёл опубликованные базовые методы, хотя вычислительные затраты между подходами не выравнивали.
Границы результатов задаёт сам эксперимент: работа посвящена соревновательному программированию с формальным условием, исполняемым кодом и автоматической проверкой ответа. Диагнозы оценивали через контрпримеры, а не напрямую, поэтому верный тест подтверждает наличие дефекта, но не обязательно подтверждает каждую формулировку в объяснении.
Когда работа меняет планы по архитектуре продукта
Подход полезен там, где система генерирует несколько реализаций или последовательно исправляет одну. Вместо ещё одного запроса к той же модели можно выделить отдельного проверяющего агента: он получает спецификацию и код, исследует кандидат в изолированной среде, а затем возвращает вердикт вместе с воспроизводимым случаем отказа.
В разборе IOI 2026 Arbiter направлял доработку решений GPT-OSS-120B при лимите в 50 официальных отправок на задачу. Ожидаемый итог достиг 385,46 балла и превысил золотой порог 361,12; вариант, который получал только ответ онлайн-судьи, остался ниже порога. Эксперимент показывает ценность промежуточной проверки, когда внешний запуск дорог или число попыток ограничено.
Для продуктовой команды вывод уже не сводится к выбору более сильной модели генерации. Если ошибки можно воспроизводить автоматически, в архитектуре стоит разделить автора и проверяющего, а обратную связь передавать в виде исполняемого примера, а не только текста. Это особенно уместно для преобразователей данных, правил расчёта и других модулей с формальной спецификацией.
Перенос потребует собственного аналога валидатора и эталонной проверки: песочница должна определить, допустим ли созданный сценарий и каким должен быть правильный результат. Для кода без исполняемой спецификации Arbiter не заменяет тесты, проверку типов и ревью. Работа скорее показывает шаблон контура проверки, чем готовый универсальный судья для любой кодовой базы.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
