Michael JohnsonИИ-ревьюер может оставить десятки комментариев и все равно пропустить дефект, который важен для выпуска. 5 октября 2026 года GitHub представила ReviewBench — исследовательское превью бенчмарка, которое сравнивает агентов по найденным проблемам, пропускам и точности замечаний.
Для разработчиков здесь важен сдвиг от подсчета комментариев к проверке их содержания. Бенчмарк сопоставляет вывод агента с эталонным набором проблем для pull request и отдельно учитывает тяжесть и категорию находок.
Что именно оценивает ReviewBench
В набор вошли 219 публичных pull request из 187 репозиториев с открытой лицензией и кодом на 19 языках. GitHub сообщает, что при формировании корпуса анализировала распределение более чем 103,9 млн PR. Размеры репозиториев и языков подбирались с оглядкой на общую выборку GitHub, а размер изменений намеренно сместили к более содержательным PR, пригодным для ревью.
Для каждого PR бенчмарк хранит эталонные замечания с метками серьезности и категории — например, корректность, безопасность, надежность, сопровождаемость и тестирование. ReviewBench считает точность: какая доля комментариев агента соответствует действительным проблемам, и полноту: какую долю известных проблем агент обнаружил. Показатель Fβ позволяет изменить относительный вес этих двух критериев: больший вес полноты подходит для поиска большего числа проблем, а больший вес точности — для сокращения шумных замечаний.
Как читать цифры GitHub
В публикации указано 96,6% согласия между разметкой ReviewBench и независимой перепроверкой старшими инженерами. Это показатель согласованности экспертных оценок эталонных находок, а не точность какого-либо ИИ-агента.
Отдельно GitHub описала внутренний A/B-тест ансамбля моделей для Copilot code review. По данным компании, относительно контрольной группы доля комментариев, за которыми последовали соответствующие изменения кода, выросла на 8,0%, полнота — на 13,6%, объем комментариев — на 61%, а стоимость ревью снизилась на 8,0%. Это результаты одного эксперимента GitHub; они не являются оценкой всех агентов или обещанием такого же эффекта в других командах.
Разделение метрик особенно полезно, когда команда выбирает настройки ревью. Большой объем замечаний может сопровождаться ростом полезных находок, но сам по себе не показывает, сколько из них подтвердились. ReviewBench также делит результаты по тяжести и категориям, чтобы команда могла отдельно смотреть, например, на критические дефекты или вопросы безопасности.
Как попробовать бенчмарк
Согласно описанию GitHub, исследовательское превью позволяет изучить полный набор данных, сравнить опубликованные результаты и запустить собственный агент. Для предварительного прогона предусмотрены 25 PR; полный запуск охватывает 219 PR в трех раундах. Участник предоставляет образ контейнера, конфигурацию и собственный ключ модели, а оценивание выполняется с общим судьей. Результаты остаются частными до проверки и одобрения отправки.
Практический смысл такого прогона — получить сопоставимую исходную точку, а затем проверить систему на собственных правилах ревью и характерных для репозитория изменениях. Условия конкретной команды — языки, архитектура, пороги серьезности и допустимый уровень шума — могут отличаться от состава общего корпуса.
GitHub утверждает, что изменения офлайн-оценок ReviewBench в ее экспериментах совпадали по направлению с результатами в эксплуатации. Опубликованные измерения относятся к собственным тестам компании. Поэтому наиболее надежное применение бенчмарка сейчас — сравнение агентов на общей выборке и диагностика их сильных сторон, а решение о внедрении стоит основывать также на проверке в рабочем процессе конкретной команды.