Бенчмарк агента код-ревью: как оценивать ревьюера и запускать c-CRAB на своём коде

Как понять, что агент для ревью кода действительно хорош? На протяжении почти всей недолгой истории этой области ответ звучал так: «чем ближе его комментарии к комментариям человека-ревьюера, тем лучше». Это звучит разумно, пока не попробуешь на практике: два разных ревьюера могут указать на одну и ту же проблему совершенно разными словами. Code Review Agent Benchmark — статья на arXiv:2603.23448, датасет называется c-CRAB — это первая серьёзная попытка оценивать ревью по тому, что получается в результате его учёта, а не по формулировкам. Авторы превратили 234 человеческих ревью-комментария в исполняемые тесты, прогнали через них четыре широко используемых ревьюера — PR-Agent, Devin, Claude Code и Codex — и обнаружили, что все четыре вместе проходят 41,5% таких тестов, или, как сказано в самой статье, «лишь около 40%». Эта страница — практическое руководство: как правильно прочитать этот результат и не исказить его, как запустить c-CRAB самостоятельно и что делать, если вашей кодовой базы в бенчмарке вообще нет.

Число из заголовка — наименее полезная вещь на этой странице. Полезное — это метод и режимы отказа: почему каждая прежняя схема оценки измеряла не то; сколько стоит вместо этого оценивать рецензию с помощью исполняемых тестов; и почему «рецензентские агенты ловят только 40% багов» — это неверное прочтение фактического результата сразу в трёх аспектах. Всё здесь — это прочтение сообществом опубликованного бенчмарка и опыта практиков, запускавших его, а не рекомендации вендоров от создателей соответствующих инструментов.

Почему очевидные метрики не работают

До c-CRAB оценки агентов проверки кода делились на небольшое число семейств, и собственная сравнительная таблица статьи (Table 1) показывает эту родословную. Старейшая из них — пересечение текста: BLEU, ROUGE, chrF и им подобные, используемые в таких бенчмарках, как CodeReviewer и ContextCRBench. Идея в том, что комментарий агента хорош, когда его n-граммы совпадают с человеческими. Эта идея рушится на том единственном случае, который повсеместно встречается в проверке кода: один и тот же дефект описан разными словами.

Наиболее показательный пример — это case study из статьи. В pull request в python-telegram-bot (PR #3514) и человек-ревьюер, и Codex указали на одну и ту же ошибку устойчивости при вложенной индексации. Ревью Codex фактически было верным: агент, который на него отреагировал, создал исправление, прошедшее исполняемый тест. Однако текстовые метрики оценили его как BLEU-4 0.00, ROUGE-L 7.02, chrF 20.74, а сходство эмбеддингов — как 54.59. Ноль пересечения n-грамм — и при этом ревью было правильным. Та же проблема, другие слова: строковые метрики не смогли её увидеть. Сходство эмбеддингов — частичный шаг вперёд: 54.59 при подтверждённом прохождении теста всё ещё далеко от пригодного порога — и оно наследует ту же проблему в более мягкой форме.

Подход LLM-as-judge, при котором модель сравнивает рецензию агента с человеческой и голосует, устраняет лексическую проблему, но привносит три новые, которые в статье названы прямо: предвзятость, нестабильность и чувствительность к дизайну промпта. Запустите одно и то же сравнение дважды — и судья может выдать вам разные вердикты; перефразируйте судейский промпт — и ранжирование меняется. Когда вы выбираете между двумя рецензентами, которые отстоят на три балла друг от друга на одном и том же бенчмарке, судья с таким разбросом не может подкрепить решение — а оценка, которую нельзя воспроизвести, не является оценкой.

Что даёт исполняемый оракул — и чего это стоит

Идея, лежащая в основе c-CRAB, одновременно проста и радикальна: вместо вопроса «звучит ли ревью как написанное человеком?» спросите: «если следовать ревью, исправится ли код?». Каждый сохранённый комментарий человека к ревью преобразуется в исполняемый тест, фиксирующий основную проблему. Комментарий к ревью считается правильным, если его применение даёт поведенчески корректное исправление, которое проходит тест, а каждый экземпляр поставляется с запускаемым Docker-окружением, так что «тест проходит» — это факт, а не суждение.

В статье определяются два вида тестов. Поведенческие тесты «импортируют и выполняют тестируемый код во время выполнения», вызывая функции «с конкретными входными данными» и проверяя «результаты или подтверждая исключения». Структурные тесты «просматривают текст исходного кода, сопоставляют шаблоны и проверяют API-поверхности, чтобы определить, были ли внесены желаемые изменения в код». Итоговое разделение: 42 поведенческих (17,9%) и 192 структурных (82,1%) — и такой перекос заслуживает честного замечания: большая часть этого оракула — это сопоставление с образцом по тексту исходного кода, а не выполнение кода. Золотой стандарт — поведенческий тест; большинство набора данных — его прагматичная версия.

Создание оракула — это четырёхэтапная воронка, и каждый этап что-то отбрасывает:

• Исходный набор данных — 671 PR, 1 313 комментариев к ревью.

• Фильтрация ревью — 410 PR, 595 комментариев. LLM-классификатор, откалиброванный по золотому набору из 100 вручную аннотированных комментариев, оставляет только объективно проверяемые проблемы и отбрасывает разговорные или субъективные замечания.

• Создание исполняемого окружения — 410 PR, 595 комментариев. Один Docker-образ на каждый PR, с разрешением зависимостей, передаваемым кодирующему агенту при сбое автоматизации.

• Преобразование комментариев на естественном языке в тесты — 339 пул-реквестов, 481 комментарий. Сгенерировано с помощью GPT-5.2 в цикле уточнения по результатам выполнения (до трех попыток); тест сохраняется только в том случае, если он не проходит на версии «до» и проходит на версии «после».

• Валидация с помощью агента кодирования — 184 PR, 234 комментария (итог). Claude Code на бэкенде Sonnet-4.6 пытается исправить код, имея только комментарий человека-ревьюера; случаи, когда ему не удаётся добиться прохождения теста, отбрасываются.

Около 27% исходных pull request-ов выживают. Сформулируем это прямо, потому что это честная цена тестового оракула: если комментарий недостаточно конкретен, чтобы превратиться в падающий тест, или окружение не собирается, или компетентный агент по написанию кода не может исправить код на основе одного лишь комментария, экземпляр отбрасывается. Именно поэтому бенчмарк небольшой. 184 экземпляра PR и 234 проверенных комментария — это датасет, который можно прочитать, а не корпус, в котором можно утонуть. А для оракула, которому приходится запускать реальные Docker-окружения, небольшой размер — это преимущество.

Для масштаба: средний инстанс затрагивает 418,1 изменённых строк, тесты в среднем насчитывают 31,8 строк, а на один инстанс приходится 1,27 теста. Два аннотатора соглашались в 84% случаев — на 50 выборочных инстансах — относительно того, точно ли сгенерированный тест передавал замечание человека-ревьюера.

Одна библиографическая шероховатость, с которой вы столкнётесь, если сами пойдёте читать статью: в таблице с данными (Таблица 4) указано 67 репозиториев, тогда как в разделе «Угрозы валидности» сказано: «184 экземпляра pull request с 234 проверяемыми оракулами в 56 репозиториях». В статье обе цифры приводятся в разных местах и никак не согласуются. Не выбирайте одну из них и не усредняйте — цитируйте каждую там, где она встречается. Подобные расхождения — это как раз та деталь, по которой читатели решают, стоит ли бенчмарк их времени.

Для должной проверки независимости: в статье раскрывается, что один из авторов аффилирован с SonarSource, и указывается, что результаты не следует интерпретировать как «оценку качества продуктов SonarSource». Это их заявление об отказе от ответственности, процитированное, а не перефразированное.

Как читать партитуру в c-CRAB, не искажая её

Ключевая метрика — доля пройденных тестов: для каждого экземпляра берётся доля тестов этого PR, которые проходят, и усредняется по 184 экземплярам. Вот полная таблица результатов из статьи, по одной строке на рецензента. Строка человека — это маркер шкалы, а не конкурент: люди написали оракул, поэтому они получают 100% по построению:

• Claude Code — 1 336 комментариев, 7,3 на PR, в целом 32,1% (поведенческие 38,1%, структурные 30,7%).

• Devin — 1 344 комментария, 7,3 на PR, в целом 24,8% (поведенческие 31,0%, структурные 23,4%).

• PR-Agent — 524 комментария, 2.8 на PR, в целом 23.1% (поведенческие 38.1%, структурные 19.8%).

• Codex — 324 комментария, 1,8 на PR, в целом 20,1% (поведенческие 38,1%, структурные 16,1%).

• Человек — 234 комментария, 1.3 на PR, 100% по построению.

Три поправки, потому что фраза «всего около 40%» из абстракта — это самое перевираемое число в этой части разговора об ИИ-кодерах прямо сейчас. Во-первых, показатель 41,5% — 97 из 234 тестов, пройденных хотя бы одним инструментом, — это объединение по всем четырём рецензентам: тест засчитывается один раз, если его прошёл любой агент. Ни один отдельный агент не набрал 41,5%; лучший индивидуальный результат — 32,1% у Claude Code. Во-вторых, строка «человек» — это оракул, а не участник; повторять её как «люди побеждают ботов» — категориальная ошибка. В-третьих, и это самое важное: c-CRAB не даёт баллов за валидную проблему, которую человек-рецензент не поднимал. Оракул — это намерение человека-ревьюера. Агент, который находит реальный баг, о котором никто не упомянул, получает за него ноль. Так что утверждение «ИИ-агенты ревью находят только 40% багов» неверно трижды — это объединение, это не доля обнаружения багов, и это измеряет согласие с людьми-ревьюерами, а не полную корректность.

Объем комментариев — это ловушка.

Самый интересный показатель в результатах — не победитель. Claude Code и Devin оставили более 1300 комментариев каждый — около 7,3 на PR — и достигли 32,1% и 24,8%. Codex оставил 324 комментария, примерно 1,8 на PR, и достиг 20,1%. Базовый уровень человека — 1,3 комментария на PR. Объём — это не покрытие: примерно в пять раз больше комментариев даёт едва ли вдвое больший процент прохождения. Если вы выбираете ревьюера, настоящая цена всех этих дополнительных комментариев — усталость человека от проверки: каждый комментарий агента — это решение, которое человеку приходится разбирать.

Вывод о полезности говорит об обратном, и именно он не даёт превратить всё это в дешёвую историю «боты шумят». Авторы вручную изучили 92 комментария в 6 PR и признали полезными 84% (77/92) — PR-Agent 94%, Codex 88%, Devin 85%, Claude Code 78%. Так что большинство комментариев, не прошедших тест, — это не шум; они о том, чего человек-ревьюер не упомянул. Выборка небольшая — 92 комментария, 6 PR, — и упоминать её стоит в одном ряду с процентами.

То, о чем на самом деле говорят обе стороны, объясняет форму результатов. Люди-рецензенты тяготели к сопровождаемости, дизайну и документации; инструменты — к надежности, тестированию и обработке ошибок. Статья трактует это как аргумент в пользу сотрудничества человека и агента, а не замены — и это также лучшее из имеющихся объяснений того, почему оценки выглядят низкими. Рецензент, который силен в граничных случаях, но молчит о дизайне, систематически упускает категории, которые отмечают люди, а оракул полностью построен на человеческих отметках.

Практики, прошедшие через это, приходят к одному и тому же выводу. Подробный разбор Дэниела Вона, в котором эта работа названа CR-bench, приводит к тому же заключению и превращает его в рабочий процесс: пусть агент выполняет проверку надёжности и корректности, а за людьми остаются дизайн, соглашения и архитектура — те категории, в которых агенты показывают худшие результаты, — и направляйте агента инструкциями для ревью, в которых названы слабые категории. Его самое полезное предостережение для тех, кто читает лидерборд: «полезность — это не то же самое, что доля прохождения тестов», поскольку тестовый набор требует совпадения с задуманным человеком исправлением, и корректное альтернативное исправление тест не проходит. Путь от 20% к содержательно более высокому результату, по его мнению, — это не обновление модели, а работа с конфигурацией.

Запуск c-CRAB самостоятельно

Всё вышеуказанное — это чтение чужих результатов. Репликационный пакет делает бенчмарк запускаемым — он находится по адресу c-CRAB-Benchmark/dataset на GitHub — и в README честно описано, что для этого требуется.

Требования: code>uv sync/code>; Docker; и либо code>OPENAI_API_KEY/code> или code>ANTHROPIC_API_KEY/code> (Claude Code также читает учётные данные из code>~/.claude/.credentials.json/code>, по умолчанию монтируемый в контейнеры). Структура состоит из пяти каталогов: code>pipeline//code> (логика конвейера и промпты), code>execution//code> (сборщики Docker-образов и вспомогательные средства выполнения), code>results_preprocessed//code> (выпущенное подмножество бенчмарка), code>results_pipeline_funnel//code> (файлы JSONL этапов 0–4 и сводка по воронке), и code>raw_results_compressed//code> (исходные результаты экспериментов). Пять шагов по порядку:

1. Соберите окружения Docker — code>uv run python -m execution.build_swe_care --split test --instance results_preprocessed/instance-ids.txt --max-workers 4/code>. Готовые образы также публикуются в организации c-CRAB-Benchmark на GitHub Packages, если вы предпочитаете пропустить сборку.

2. Сгенерируйте тесты — code>./run_testgen_full.sh --instances-file results_preprocessed/instance-ids.txt --workers 4 --output-dir results_testgen/code>.

3. Соберите базовые ревью — code>uv run python run_batch_baselines.py --split test --instances-file results_preprocessed/instance-ids.txt --tools pr-agent devin claude-code codex --output-dir baselines_output --workers 4/code>. Настройте соответствующие учётные данные внешнего инструмента перед этим шагом.

4. Запустите разрешение агента — code>uv run python run_batch_agent_resolution.py --stage3-file results_pipeline_funnel/stage3_testgen_verified.jsonl --testgen-dir results_testgen --output-dir results_agent_resolution --workers 4/code>.

5. Выполните оценку — повторите один раз для каждого инструмента: code>uv run python run_batch_tool_eval.py --tool pr-agent --stage3-file results_pipeline_funnel/stage3_testgen_verified.jsonl --testgen-dir results_testgen --tool-results-dir baselines_output --output-dir results_eval_pr-agent --workers 4/code>.

В README не упоминаются две вещи. Добавление пятого рецензента означает редактирование code>run_batch_baselines.py/code> — именно там находятся подсказки базовых обзоров для каждого инструмента, и никакого плагинного интерфейса нет; README не документирует более удобной точки расширения. Кроме того, в репозитории нет явного файла лицензии, так что не считайте, что код распространяется под MIT или Apache — статья доступна под CC BY 4.0, а условия использования самого кода не указаны.

Стоимость — ещё один неафишируемый пункт. В статье не приводится ни токенов, ни долларовых показателей для запуска пайплайна, так что относитесь к любой цифре стоимости, которую вы увидите в интернете, как к непроверенной. Что подразумевает структура, достаточно ясно: один Docker-образ на каждый PR в 184 инстансах, плюс проход разрешения с помощью кодинг-агента и оценочный проход для каждого инструмента. Это не масштаб «одного вечера на ноутбуке» — закладывайте бюджет на настоящие вычисления.

Когда вы не можете позволить себе исполняемые оракулы

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

Судья, работающий на той же модели, что и рецензент, соглашается сам с собой: он читает рецензию, находит её правдоподобной и сообщает об успехе, ничего не меняя. Судья от другого поставщика уменьшает это самосогласие — он не превращает судью в тест, но кладёт конец бездумному одобрению. Мы можем показать вам конкретный, проверяемый пример именно этого защитного механизма, потому что наш собственный испытательный стенд открыт: Orca-Code-Review на GitHub распространяется по лицензии MIT, и в его роутинг-рецепте правило изложено словами самого репозитория: судья «НЕ ДОЛЖЕН НАЗЫВАТЬ МОДЕЛЬ РЕЦЕНЗЕНТА ПО УМОЛЧАНИЮ», потому что «на собственной модели рецензента он соглашается сам с собой, поэтому проверка становится инертной, хотя по-прежнему сообщает об успехе». Действие никогда не называет модель; рецепт решает. В предустановленной конфигурации рецензент по умолчанию — deepseek/deepseek-v4-flash-0731, и правило, соответствующее code>x-cr-lens: judge/code> заголовку, отправляет проверку судьи на z-ai/glm-5.3 — от другого поставщика. Это конструктивная параллель к аргументу c-CRAB, а не результат: мы не участвуем в бенчмарке, и у нашего рецензента нет оценки c-CRAB. Но это практическое смягчение, доступное любому, кто не может построить исполняемые оракулы, и оно дёшево, когда судья и рецензент могут находиться у разных провайдеров под одним ключом — для этого и нужен роутер. На OrcaRouter рецензент и его судья — это две строки в роутинг-DSL, и вы платите по цене провайдера без наценки.

Когда вашего кода нет в бенчмарке.

184 PR в 56 или 67 публичных репозиториях — это не ваша кодовая база, и никогда ею не была. Переносимая часть — это метод, и вы можете применить его к своей собственной истории в гораздо меньшем масштабе. Возьмите объединённые PR, к которым были комментарии ревьюеров. Для выборки таких комментариев напишите тест, который падает до того, как ревью было учтено, и проходит после — свойство «сначала падает, потом проходит» и есть вся суть. Запустите вашего кандидата-ревьюера на diff до ревью. Затем проверьте, приводит ли учёт его комментариев к прохождению теста. В итоге вы получаете число, вычисленное на коде, который вы действительно выпускаете, а это ценнее, чем место в лидерборде. Плата за это — ровно то препятствие, о которое споткнулась статья: вам нужны воспроизводимые окружения для каждого PR, потому что тест, который проходит только на вашем ноутбуке, не является оракулом.

Вам не нужны 234 теста. Дюжина хорошо подобранных тестов на PR, по которым ваша команда действительно спорила, расскажет вам о вашем ревьюере больше, чем результат бенчмарка. А параллельный анализ практиков этого семейства бенчмарков прямо говорит о пороге: точность LLM-классификатора в определении того, является ли комментарий валидной и проверяемой проблемой, составляет от 66% до 85%. Поэтому относитесь к машинной фильтрации как к предварительному списку и сохраняйте шаг ручного арбитража, прежде чем что-либо станет тестом. В той же статье отмечается, что ReviewBench от LangChain, независимо построенный на той же идее «от комментария к тесту», в лучшем случае восстанавливает около 30% исходных проблем — это та же величина, что и 20–32% у c-CRAB, и напоминание о том, что различия между инструментами в лидерборде на единицы процентов часто меньше шума в вашей собственной настройке.

Если вы вообще решаете, какой инструмент для ревью купить, это отдельный вопрос — наше руководство покупателя по code-review-агентам охватывает сравнение ботов и агентов, ценообразование за рабочее место против оплаты за токены и сценарии, в которых выигрывает самостоятельный хостинг, — а когда инструмент уже выбран, текущие расходы на запуск проверочной обвязки при каждом пуше разобраны в нашем объяснении автоматизированного code review. Эта страница посвящена только измерениям, а сопутствующий материал проводит по анатомии бенчмарка: воронке конструирования, статистике датасета и полной таблице результатов.

Часто задаваемые вопросы

Является ли 41,5% лучшим результатом агента? Нет. 41,5% — это объединение по всем четырём инструментам: тест засчитывается один раз, если хотя бы один из них его прошёл. Лучший отдельный результат — 32,1% у Claude Code.

Измеряет ли c-CRAB, сколько ошибок обнаруживает рецензент? Нет. Он измеряет, насколько хорошо рецензия соответствует тому, что выявил человек-рецензент, преобразованное в исполняемые тесты. Реальный дефект, о котором человек не упомянул, получает ноль баллов, каким бы достоверным он ни был.

«Победили» ли люди-рецензенты ботов? Строка «100% человек» — это и есть сам оракул: тесты писали люди, так что это калибровочная метка, а не конкурент.

c-CRAB и CR-bench — это одно и то же? Да. Набор данных называется c-CRAB; некоторые сторонние обзоры называют его CR-bench, но здесь только один бенчмарк.

Во сколько обходится его запуск? В статье не приводятся цифры затрат. Один Docker-образ на каждый PR в 184 инстансах плюс проход разрешения агента подразумевают серьёзные вычислительные мощности — это не уровень «погонять полдня на ноутбуке».

Суть

Вклад c-CRAB — не лидерборд: это демонстрация того, что рецензию можно оценивать, исполняя её советы, и что прежние схемы на основе текстового сходства и LLM-судьи измеряли не то. Если нужно вынести отсюда одну мысль, пусть это будет поправка из трёх частей: 41.5% — это объединение, человеческая строка — оракул, а бенчмарк не начисляет баллов за дефекты, о которых люди не упоминали. А если вам нужно число, на которое можно опираться, метод переносится: тесты, которые сначала падают, а затем проходят, на ваших собственных смёрженных пулл-реквестах, этап человеческого арбитража и, если вы не можете построить исполняемые оракулы, хотя бы судья, чья модель независима от модели рецензента.

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