[1/2] SWE-PRBench: Benchmarking AI Code Review Quality Against Pull Request Feedback (Рубрика Whitepaper)

Когда разбирался с тем, как оценивать качество агентов внутри SDLC наткнулся на интересную и свежую работу от Deepak Kumar, независимого исследователя. В этом исследовании простая : SWE-Bench-подобные бенчмарки меряют, может ли модель написать правильный патч, а не может ли она оценить чужой PR как reviewer. И в предложенном подходе автор делает именно второе: берёт реальные merged PR и реальные комментарии людей в ревью как ground truth, не синтезирует комментарии и не сводит задачу к similarity текста. Плюс авторы фиксируют три режима контекста (по нарастающей), чтобы проверить эффект от его расширения

• config_A (diff + summary)
• config_B (добавлен file context)
• config_C (ещё и test/context layers) Этот подход позволяет измерить насколько разные модели хороши в поиске issues в сравнении с находками людей.

Если глубже погружаться в методологию, то она такова 1) Сначала они отбирают репозитории по RQS (Repository Quality Score): review culture, свежесть PR, качество тестов/CI, объём PR activity и contamination proxy. Репозитории ниже 60/100 отбрасываются. Самый сильный сигнал - именно культура ревью: доля содержательных комментариев от людей в недавних merged PR. 2) Потом PR проходят 10-шаговую фильтрацию: только смердженные PR, минимум два содержательных человеческих комментария, есть изменения помимо тестов, не только изменения документации, не просто автоматический бамп зависимостей, не только AI ревью, diff можно распарсить, базовый commit доступен, репозиторий еще публичный, и проходит RVS-порог (что упоминался в первом пункте). Из примерно 3,000 raw PR остаётся 700 кандидатов, после RVS обрезается до 350 PR из 65 репозиториев. Ground truth берётся из реальных комментариев к ревью через GitHub API; комментарии не генерируются и не правятся вручную. Авторы отдельно фильтруют AI/bot комментарии и исключают PR, где AI-комментариев больше 30%. 3) Важная часть методологии построена вокруг таксономии сложности

• Type1 - проблема видна прямо в diff
• Type2 - нужно понимать окружающий код в том же файле и который не менялся
• Type3 - нужно размышление относительно кросс-файловых зависимостей Этот ход превращает “качество code review” из одной мутной метрики в три разных когнитивных режима

4. Оценивание тоже сделано интересно. Агент должен вернуть 4–6 issues в JSON с severity, а judge-модель классифицирует каждый comment как CONFIRMED, PLAUSIBLE или FABRICATED. Причем PLAUSIBLE - это хороший подход, так как авторы признают, что ревью людьми не исчерпывающее, поэтому валидный новый комментарий не считается автоматом галлюцинацией. Дальше идёт маппинг, чтобы модель не получила двойные очки за разбиение одной идеи на пять комментариев, а итоговый score смешивает полноту, точность, semantic alignment, actionability и efficiency, штрафуя галлюцинации и избыточность.

В итоге, были получены интересные результаты:

1. На их 100-PR stratified sample ни одна модель не ловит больше 31% human-flagged issues; средний detection rate по всем 8 моделям на config_A примерно 26%. Топ-4 модели показывают примерно одинаковый агрегированный score.
2. По профилю моделей видим, что нет лучшего ревьювера и у нас обычный precision/recall trade-off. В цифрах DeepSeek V3 даёт лучший raw detection на config_A (DR=0.312), а GPT-4o даёт лучший hallucination profile (FPR=0.193). У Llama 3.3 70B худший FPR — 0.417.
3. Все 8 моделей деградируют при переходе от config_A к config_C. Причём config_A и config_C отличаются всего на 500 токенов (2,000 vs 2,500) - кажется, что проблема в том, как контекст подаётся, а не только в объёме.
4. Все ухудшается на переходе от config_A к config_B: у Sonnet score по Type2 падает с 0.22 до 0.10 при переходе A→B; у DeepSeek — с 0.20 до 0.10. То есть модели ломаются не там, где нужен весь репозиторий, а уже на шаге добавления окружающего контекста из измененного файла.

В продолжении обсудим что все это значит на практике.

#AI #Engineering #Software #SystemDesign #Agents