ИИ-агенты перепроверили 2000+ статей ICML 2026 и нашли ошибки, пропущенные рецензентами

Рецензирование на топовых ML-конференциях во многом держится на доверии. Ревьюер получает несколько статей, у него есть пара недель, и запускать чужой код ради проверки одной таблицы он обычно не будет. Летом 2026 года это решили проверить в лоб и привлекли ИИ-агентов.

Что произошло

Hugging Face вместе с alphaXiv, сервисом для обсуждения научных публикаций, провели хакатон ICML 2026 Open Reproductions. Задача: взять принятые на конференцию работы (их было больше двух тысяч) и попытаться воспроизвести заявленные результаты. Участники делали это с помощью ИИ-агентов. В статьях нашлись ошибки, которые рецензенты не заметили.

ICML — одна из главных конференций по машинному обучению, и принятая статья часто воспринимается как знак качества. Но рецензент видит PDF, а приложенный код нередко остаётся незапущенным: на это не хватает ни времени, ни стимулов.

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

Как это работает на практике

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

Допустим, в статье заявлен прирост в 3 процентных пункта на бенчмарке. Агент запускает код с указанными настройками и получает прирост в полпункта. Дальше возможны варианты: гиперпараметр в тексте не совпадает с кодом, тестовые данные попали в обучение, или базовая модель для сравнения была настроена хуже, чем собственная. Человек без запуска кода такого не увидит. Агент не устаёт и может гонять сотни проверок параллельно.

Это типичные причины расхождений, а не список находок хакатона: конкретные типы ошибок в исходных данных не раскрыты.

Что с этим делать разработчикам и продактам

Не принимайте таблицу из статьи за гарантию. Если вы строите продукт на «state of the art» из свежей работы, её цифры остаются гипотезой. Заложите время на собственное воспроизведение и сначала проверьте, не пытался ли это сделать кто-то до вас.

Применяйте тот же приём внутри компании. Агент, который берёт ваш внутренний отчёт об эксперименте или оценку модели и пробует повторить её с нуля по описанию, — дешёвый способ найти разрыв между написанным и реально запущенным. Для команд, которые публикуют бенчмарки и сравнения, это почти готовый QA-этап.

Смотрите на рынок. Для основателей хакатон подсвечивает нишу: инструменты проверки воспроизводимости, чекеры методологии, аудит исследований для инвесторов и корпоративных R&D-отделов.

Ограничения

Агент, который не смог воспроизвести результат, ещё не доказал ошибку авторов. Причиной может быть нехватка вычислительных ресурсов, закрытые данные, неполное описание метода или ошибка самого агента. Поэтому находки нужно подтверждать человеком. Реалистично выглядит связка, где агент собирает кандидатов на ошибку, а эксперт выносит вердикт.

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

Рецензенты никуда не делись, но у них появился напарник, который действительно запускает код. Воспроизводимость перестаёт быть роскошью и становится автоматизируемой процедурой, чем-то вроде CI для науки. Командам, которые зависят от свежих исследований, стоит привыкать к этому раньше, чем авторы статей.