Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Научный черновик научились проверять не общим вердиктом, а цепочкой проверок текста, доказательств, кода и экспериментов. В нерецензированном препринте, где все числа получили сами авторы, PaperDoctor добился согласия исследователей с доказательной опорой у 70,6% замечаний. Для команд, которые автоматизируют подготовку исследований, это готовая схема контроля качества между генерацией статьи и её отправкой.
Три слоя распределяют проверку по стоимости
PaperDoctor — агентная система: она сама разбирает задачу на этапы, выбирает инструменты и собирает результаты в единый отчёт. На вход поступают рукопись, код и данные. Система превращает текст статьи в структуру по разделам, сохраняет страницы как изображения, индексирует файлы проекта и отдельно разбирает библиографию.
На уровне L1 проходят дешёвые проверки, для которых не требуется запускать код. Языковая модель ищет опечатки и неясные формулировки, визуально-языковая модель проверяет рисунки, таблицы и вёрстку, а поиск сверяет библиографические записи с существующими публикациями. Параллельно PaperDoctor извлекает из текста проверяемые утверждения о теории, реализации, экспериментах и предшествующих работах.
Уровень L2 направляет каждое утверждение к подходящему проверяющему модулю. Описание оптимизатора или архитектуры сверяется с конфигурацией и исходным кодом. Теоретический модуль повторяет вывод по шагам, ищет пропущенные допущения и следит за обозначениями. Проверка литературы отделяет существование ссылки от более сложного вопроса: действительно ли найденные работы подтверждают заявленную новизну.
Экспериментальный модуль сначала оценивает сам план исследования. Он проверяет, подтверждает ли опыт основной тезис, хватает ли сравнений и разборов отдельных компонентов, а затем составляет команды для повторного запуска. PaperDoctor отдаёт приоритет опытам, от которых зависят главные выводы, и предпочитает оценку готовой модели более дорогому обучению.
На уровне L3 система показывает автору план с ожидаемыми затратами GPU, объёмом данных и требованиями к хранилищу. Код запускается только после ручного подтверждения. Это отделяет анализ рукописи от действий, которые расходуют ресурсы и меняют рабочее окружение.
Замечание содержит причину, адрес и способ исправления
Единица результата в PaperDoctor — не оценка статьи, а диагностическая карточка. В ней указано, что не так, где лежит доказательство и как исправить проблему. Адресом может быть предложение, формула, рисунок, строка кода или найденная публикация.
Такой формат позволяет проверить саму критику. Если статья говорит об AdamW, а конфигурация задаёт Adam, карточка указывает на конкретную строку и предлагает выяснить, какой оптимизатор использовали в опыте. Автору не приходится заново просматривать весь проект, чтобы понять основание замечания.
Система различает ошибки и предупреждения. Явное противоречие можно отметить как ошибку, а неоднозначную конфигурацию — как повод для ручной проверки. Для экспериментов карточка также хранит команду запуска, целевой результат и журнал выполнения. Если опубликованное значение не удалось повторить, отчёт связывает расхождение с фактическим запуском, а не только с чтением статьи.
Первую проверку провели на 30 незавершённых работах младших исследователей: участники оценивали замечания по собственным рукописям. Вторую — на 40 статьях из машинного обучения, естественных и социальных наук; в набор входили тексты людей и ИИ с сопровождающим кодом и данными. PaperDoctor давал более проверяемые замечания, чем люди и другие агентные рецензенты, однако работа оценивает помощь автору до отправки, а не способность предсказывать решение конференции.
Командам нужен отдельный контур проверки, а не ещё один запрос к LLM
Работа меняет планы команд, которые строят автономную подготовку исследований или технических отчётов. Между генерацией результата и публикацией стоит добавить отдельный контур: извлечь утверждения, определить нужный тип доказательства, проверить дешёвые части параллельно и запускать дорогие проверки по приоритету.
Главная архитектурная идея — не просить одну модель «отрецензировать всё». Рукопись, изображения, библиография и код требуют разных представлений и инструментов. Утверждение должно храниться вместе с адресом доказательства и предлагаемой правкой, иначе общий отзыв трудно проверить и превратить в задачу для автора или разработчика.
Полное воспроизведение стоит оставлять за ручным подтверждением: оно запускает чужой код и расходует вычислительные ресурсы. Самые сильные проверки PaperDoctor также зависят от доступного и запускаемого проекта. При этом система не подменяет решение о ценности исследовательского вопроса — она берёт на себя проверяемые несоответствия, а выбор направления оставляет человеку.
Поэтому PaperDoctor полезнее рассматривать как образец контура обеспечения качества, а не как автономного рецензента. Для продукта ключевыми компонентами станут реестр утверждений, маршрутизация по типу доказательства, привязанные к исходникам замечания и управляемый исполнитель экспериментов.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
