SWR-Bench: генерация комментариев при код-ревью с помощью LLM на реальных Pull Request'ах

Статья с бенчмарком от исследователей из Пекинского университета и Северо-Западного политехнического университета (Zhengran Zeng, Ruikai Shi с коллегами), впервые опубликованная в сентябре 2025 года и представленная на FSE 2026. Предыдущие бенчмарки автоматизированного код-ревью оценивали модели на отдельных методах или фрагментах диффов без контекста проекта и выставляли оценку по метрике BLEU. SWR-Bench оценивает ревью целого pull request'а с учётом контекста репозитория, куда он вливается, а критерием служит то, нашла ли модель проблемы, реально поднятые ревьюерами-людьми.

Формирование бенчмарка

PR взяты из 12 Python-проектов из SWE-bench. После отсева PR без комментариев ревьюеров, с более чем 10 коммитами или с ребейзами осталось 21 350 штук. Gemini-2.5-Pro проанализировала историю ревью каждого PR и извлекла "change-actions" (локализованная проблема плюс предлагаемое изменение), классифицированные по 11 типам. Они делятся на эволюционные изменения (документация, форматирование, структура) и функциональные (интерфейс, логика, ресурсы, проверки, внешняя поддержка, крупные дефекты). PR сохранялся только при согласии трёх независимых прогонов. Алгоритм SZZ исключил PR, где последующий коммит исправлял пропущенную ревьюерами ошибку, благодаря чему PR без change-actions можно считать чистыми. Пять разметчиков затем проверили метки парами (каппа Коэна 0.66, разногласия решались обсуждением) и удалили PR, где все изменения сводились к форматированию или документации.

Итоговый набор содержит 500 PR с change-actions (в среднем 1.90 на PR) и 500 чистых PR, подобранных по размеру, чтобы модель не могла различить их по количеству строк. На чистом PR любой комментарий считается ложным срабатыванием. Фильтрация подняла долю функциональных изменений с менее чем 15% в сырых данных до 31.8%.

Оценка использует LLM для сопоставления, а не для выставления баллов: она извлекает отдельные предложения из ревью и отмечает, какие эталонные change-actions каждое из них закрывает. Согласованность попаданий между людьми и LLM-судьями составила от каппы 0.71 до 0.87. При выборе человеком лучшего из двух ревью этот метод совпадал с мнением людей на 0.53 - 0.62, что сопоставимо с согласием людей между собой (0.56 - 0.63); LLM с оценкой качества по шкале 1 - 10 совпадала на 0.31 - 0.45, а BLEU показал результаты хуже случайного угадывания. Роль судьи выполняет Gemini-2.5-Flash, что обходится примерно в $1.57 за полный прогон.

Результаты

Ни один подход не показывает высоких результатов. Лучшая комбинация в основной таблице, PR-Review (одиночный промпт с выверенной структурой) на Gemini-2.5-Pro, достигает precision 16.65%, recall 23.18%, F1 19.38%. Средний F1 по инструментам: PR-Review - 18.73%, агентный baseline с исследованием репозитория - 12.61%, простой промпт - 12.49%, два дискутирующих агента CR-Agent - 9.22%, а Hybrid-Review, вставляющий вывод статического анализа в промпт, - 4.87% при 6.18 ложных срабатываниях на PR в среднем. Более старые дообученные ревьюеры уровня отдельных hunk'ов набирают 6.13% и 7.22%, при этом у них самый высокий BLEU, что авторы приводят как доказательство неприменимости текстового сходства для этой задачи.

Среди моделей с подходом PR-Review максимальный F1 у GPT-5 - 20.85% (recall 35.93%). Обучение рассуждениям помогает: Qwen-2.5-R1-14B достигает 15.95% против 9.01% у Qwen-2.5-14B. Ранжирование не совпадает с SWE-bench или LiveCodeBench, что авторы трактуют как свидетельство того, что ревью требует иных навыков, чем генерация кода.

Функциональные проблемы находятся надёжнее эволюционных: изменения логики достигают 26.20% F1, тогда как лучший эволюционный тип, организация кода, набирает 16.45%. Recall резко падает при росте числа проблем в PR: с 38.35% при одной проблеме до 8.88% при пяти и более, в то время как precision остаётся в пределах от 29.63% до 44.12%. Ручной разбор 100 из 1101 ложных срабатываний лучшей конфигурации выявил нехватку контекста (48%), восприятие любой крупной модификации как рискованной (17%), расплывчатые непрактичные советы (16%), незнание соглашений проекта (13%) и неверную трактовку намеренных отступлений от лучших практик (3%).

Ревью зашумлены, поэтому их объединяют

Разные модели сошлись всего на 36 найденных change-actions, а одна и та же модель в пяти прогонах совпала лишь в 27 случаях. Эта нестабильность привела к идее Multi-Review: запустить ревьюера n раз и объединить отчёты ещё одним вызовом LLM - либо от той же модели (Self-Agg), либо от нескольких разных (Multi-Agg). Gemini-2.5-Flash с Self-Agg при n = 10 достигает 21.91% F1 (относительный прирост 43.67%) и увеличивает recall на 118.83% - до 30.44%. При n = 5 Flash набирает 20.48% и обходит одиночный проход Gemini-2.5-Pro (19.38%) при стоимости $0.00368 против $0.00586 на PR. Pro с Self-Agg при n = 5 достигает 23.84%. Прирост выходит на плато после n = 5, тогда как затраты продолжают расти линейно. Qwen-Chat-7B и 32B улучшают показатели на 26.13% и 19.25% относительно базовых. Результаты Multi-Agg приведены только на графике, в копии в vault'е их нет.

Что бенчмарк не проверяет

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

Связанные страницы

• cross-model-code-review - как это соотносится со статьями, где варьируется, кто кого ревьюит
• code-review-throughput-limits - человеческий предел пропускной способности, делающий автоматическое ревью привлекательным
• google-code-review-looking-for и code-review-knowledge-transfer - эволюционная сторона ревью, не связанная с дефектами, которая даётся моделям тяжелее всего
• roborev - ревьюер на commit-hook'ах с фазой фильтрации ложных срабатываний, практическое воплощение этой задачи
• llm-output-variance - межпрогонная нестабильность, которую эксплуатирует Multi-Review