Книжный куб

[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