ИИ-рецензент на EMNLP написал отзывы втрое длиннее человеческих

Вы отдаёте модели продуктовую гипотезу и получаете двадцать замечаний: добавить сравнение, расширить выборку, проверить ещё три сценария. Выглядит как тщательная работа. Но какие из этих требований способны изменить решение о запуске? В обзоре EMNLP исследовательница AIRI Мария Марьина описывает похожую проблему с автоматическими рецензиями на научные статьи. Этот сюжет полезен всем, кто использует ИИ для проверки чужой работы.

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

Что проверяли организаторы

В описанном эксперименте участвовали три варианта ИИ-рецензентов: система AAAI на GPT-5.4 и ReviewerToo с моделями GPT-OSS-120B и GLM-4.7 Flash. Авторы добровольно получали сгенерированные отзывы и оценивали их качество. Комитет, принимавший решения о публикации, этих отзывов не видел. Значит, эксперимент изучал полезность обратной связи, а не возможность автоматически отбирать научные работы.

По приведённым в обзоре оценкам, модели хорошо передавали содержание исследований и отмечали сильные стороны. С критическими замечаниями было хуже. Особенно многословной оказалась система на GPT-5.4; у двух других вариантов разрыв с человеческими отзывами был меньше.

Отдельно Марьина пересказывает претензии авторов, отказавшихся участвовать: ИИ цепляется к деталям и требует дополнительных экспериментов, недооценивая новизну идеи. Здесь важно различать источники выводов. Это комментарии отказавшихся участников, а не измеренный результат сравнения всех рецензий. Сам обзор также не даёт оснований считать каждое требование модели ошибочным.

Почему список замечаний может мешать

Представим команду, которая проверяет, помогает ли новый поиск сотрудникам быстрее находить инструкции. Модель предлагает увеличить выборку, сравнить несколько способов ранжирования, добавить другие языки и измерить результаты через полгода. Каждая рекомендация звучит разумно. Но для ближайшего решения у них разный вес.

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

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

Однако длинный отзыв сам по себе ничего не доказывает. Он может содержать полезные находки. И недовольство автора тоже не означает, что рецензент неправ: неприятное замечание иногда указывает на реальную слабость. Нужна проверка каждого существенного возражения по материалам работы.

Как использовать это в команде

Из описанного опыта можно вывести рабочий приём: просить модель связывать каждое замечание с конкретным решением. Какой вывод она оспаривает? На какой фрагмент документа опирается? Какая минимальная проверка позволит разобраться? Что изменится, если замечание подтвердится?

После этого человеку проще выделить ошибки, блокирующие решение, и улучшения, которые можно отложить. Например, требование добавить ещё один эксперимент должно сопровождаться объяснением, какую неопределённость он снимает. Без этого команда рискует тратить время на убедительно сформулированные пожелания.

Для оценки самого ИИ-рецензента полезно смотреть, сколько его замечаний подтвердилось и сколько существенных ошибок он пропустил. Это редакционный вывод для практики; приведённый обзор не сообщает таких метрик. Он показывает более узкую вещь: участники ценили пересказ и описание достоинств выше, чем качество критики.

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