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

Продолжая рассказ, про whitepaper мы поговорим какие практические выводы можно сделать из предложенного подхода.

1️⃣ Больше контекста, не всегда выше качество. В review-задаче компактный diff + summary оказался лучше, чем более “богатый” flat prompt. Я бы читал это не как “контекст бесполезен”, а как “наивная плоская упаковка контекста вредна”. Это важная разница: авторы сами пишут, что retrieval-based или token-level relevance strategies вроде changed-vs-unchanged markers могут дать другой результат, и прямо позиционируют config_B как uncurated baseline, относительно которого и надо мерить retrieval-approaches.

Отсюда мой практический вывод о том, что агент-ревьювер должен быть многошаговым, а не одним гигантским промптом. Нормальный pipeline может выгялдеть так:

• diff-only candidate generation;
• targeted retrieval только под подозрительные места;
• verifier/critic, который режет fabricated comments;
• dedup + severity ranking перед публикацией в PR. Кажется, что это следующий шаг, который основан на результатах деградации качества по мере добавления контекста.

2️⃣ Не надо выбирать модель только по обобщенному скору. В этом исследовании top-4 модели почти не различимы статистически, зато у них разные результаты по части галлюцинаций и стоимости. Для бота, который пишет комменты прямо в PR, низкий FPR (false positive rate) обычно важнее, чем максимальный полнота; для ревьювера, что работает в shadow-mode можно взять более recall-heavy и дешёвый вариант, но обязательно с этапом верификации.

Если говорить про масштабирование подхода, то кажется сам подход отлично подходит для создания своих кастомных бенчей в компании.

• Data pipeline переносится в компанию почти напрямую: merged PR, diff, base/head SHA, changed files, human comments, frozen context fixtures, separate judge/agent pipeline
• У авторов уже опубликованы и dataset artifacts, и harness, где layout очень близок к тому, что и нужно внутри компании
• И в крупных компаниях это масштабируется даже лучше, чем в open source: внутри компании у вас обычно есть больше сигналов - ownership, CI артефакты, rollback history, incident links, review roles, labels вроде security/migration/data-contract. То есть сам подход authors я бы не просто переносил, а усиливал внутренними metadata. Но production-часть paper переносить буквально я бы не стал: их собственные результаты показывают, что flat full-context review не работает, а limitations section прямо оставляет дверь открытой для более умных relevance encodings и retrieval.

А вот для переноса на всю индустрию пока есть препятствия

• Датасет Python-dominant (69.1%), performance PR почти нет (8), security PR вообще один, paper baseline посчитан на 100 PR из полного корпуса 350, а не на всём датасете
• Нет человеческого baseline в этом режиме, а judge-family bias authors сами не исключают.

#AI #Engineering #Software #SystemDesign #Agents