«219 реальных pull request вместо демо-набора»: GitHub выпустила ReviewBench — открытый бенчмарк для ИИ-ревьюеров кода

Зачем понадобился бенчмарк

Агентное ревью кода, по оценке GitHub, становится частью обычного процесса разработки: такие системы просматривают pull request, ищут проблемы и помогают решить, что заслуживает внимания до выпуска кода.

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

Из чего собран набор

Чтобы понять реальное распределение задач ревью, GitHub проанализировала 103,9 млн pull request на своей платформе. Итоговый корпус — 219 pull request из 187 публичных репозиториев с открытой лицензией на 19 языках; распределение по языкам и размеру репозиториев повторяет распределение GitHub в целом.

Одно отклонение сделано сознательно: размер pull request смещён к «обозримой середине и хвосту», чтобы уменьшить долю крошечных однофайловых правок и сохранить содержательные многофайловые изменения, где качество ревью важнее всего.

Разметка из нескольких источников

Эталон строится так, чтобы не зависеть от одного ревьюера — ни человека, ни модели: находки собирают из нескольких источников одновременно — человеческих ревьюеров, передовых LLM и статического анализа. Каждую находку размечают по критичности (critical, medium, low) и категории: корректность, безопасность, надёжность, поддерживаемость, тестирование.

Перед выпуском senior-инженеры, не участвовавшие в построении набора, заново разметили каждую эталонную находку с нуля; их вердикты «истинно положительная / ложно положительная» совпали с разметкой ReviewBench в 96,6 % случаев. Датасет, судья (judge) и сопоставитель версионируются на каждую оценку, а методология валидации, измерения согласия и известные угрозы валидности публикуются открыто.

Шесть метрик вместо двух

Большинство бенчмарков считают precision и recall относительно фиксированного эталонного набора. ReviewBench считает шесть метрик в двух семействах.

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

Различие важно именно потому, что фиксированный эталон со временем становится неполным. В качестве основной метрики для сравнения систем GitHub использует grounded recall, а augmented-метрики — как дополнительную диагностику. Результаты можно нарезать по критичности и категории, а параметр β в Fβ позволяет сместить вес в сторону полноты или в сторону меньшего шума — под разные предпочтения команд.

Как это применяют в Copilot

GitHub использовала ReviewBench для последовательных итераций Copilot code review (CCR), чтобы измерять прогресс, ловить регрессии и расставлять приоритеты изменений. Главная заявленная ценность — ранний офлайн-сигнал: по словам компании, офлайн-изменения до A/B-тестов устойчиво указывали то же направление, что затем показывали продакшн-эксперименты.

Один из примеров — ансамблевый режим ревью, объединяющий несколько независимых прогонов модели в одно ревью: ReviewBench предсказала рост precision, recall и объёма комментариев при меньшей стоимости ревью. Онлайн-тест пошёл в ту же сторону: addressed rate (онлайн-аналог precision) вырос на 8,0 %, recall — на 13,6 %, объём комментариев — на 61 %, а стоимость ревью упала на 8,0 % относительно контроля.

Отдельно бенчмарк уловил структуру: рост объёма комментариев сам по себе не говорит о качестве, поэтому оценка по критичности предсказала рост критичных замечаний на 227 % против 262 % в онлайне — вместе с тем же сдвигом к более умеренным замечаниям и меньшим числом придирок.

Как попробовать

Исследовательская предварительная версия ReviewBench доступна на сайте бенчмарка. Чтобы прогнать свою систему, нужно войти через GitHub, зарегистрировать агента (container image, конфигурация и собственный ключ модели — судью предоставляет GitHub), отладиться на тестовом наборе из 25 pull request, а затем выполнить финальный прогон по всем 219 pull request в три раунда с тем же судьёй, что и у остальных участников.

Результаты публикуются в общем лидерборде только после проверки мейнтейнером и только если превышают текущий результат агента или это первая заявка. Полный датасет, методология, промпт судьи, конфигурация модели-судьи и self-serve runner открыты, поэтому оценку можно воспроизвести самостоятельно.