[1/3] BitsAI-CR: Automated Code Review via LLM in Practice (Рубрика #AI)
Интересная научная статья от ByteDance, создателя TikTok на тему автоматизированного code review с использованием GenAI. Интересно, что чуть раньше я уже разбирал как Google подходит к этому вопросу при разборе "Resolving Code Review Comments with Machine Learning" в трех частях: 1, 2 и 3. Но у ребят из ByteDance немного другой подход - они сделали систему, в которой LLM пишет на MR (merge requests) комментарии в code review, а у ребят из Google сам комментарий писал инженер, а LLM делало code suggest, который предлагал фикс, что соответствует этому комментарию. Но давайте посмотрим какие проблемы авторы из ByteDance пытались решить, создавая BitsAI-CR:
- Избавиться от трудоемкого узкого места в виде традиционного code review
- Устранить ошибки и непоследовательности в комментариях при code review
Вообще, тема использования LLM для code review плодотворна, но там есть проблемки, которые авторы учли и попробовали устранить (кстати, в списке ссылок больше 50 других научных статей, десяток из которых про code review)
1. Низкая точность и надёжность: многие LLM-решения генерируют неточные или нерелевантные комментарии, тратя время разработчиков.
2. Недостаточная практичность: текущие системы часто не дают полезной обратной связи, которую реально используют разработчики.
3. Отсутствие механизма постоянного улучшения: большинство решений не учатся на обратной связи пользователей и не эволюционируют со временем.
Для решения этих проблем авторы придумали архитектуру из двух частей, что сочетает высокоточный pipeline генерации комментариев к review и механизм data flywheel. Такой подход не только выявляет потенциальные проблемы в коде с высокой точностью, но и запускает цикл постоянного улучшения на основе реальной обратной связи от разработчиков. Интересно, что для генерации комментариев используется таксономия правил code review, где есть категории security vulnerability, code defect, maintainability and readability, performance issue.
Давайте заглянем в то, как устроен каждый из двух компонентов модели
Review Comment Generation Pipeline
Pipeline работает в четыре последовательных этапа:
1. Context Preparation: на этом этапе входные изменения кода структурируются для дальнейшего анализа. Изменения разбиваются на сегменты по header hunks, добавляются полные определения функций - это даёт LLM достаточно контекста для качественного анализа.
2. RuleChecker: это дообученная LLM, обученная на широкой таксономии из 219 правил review. RuleChecker выявляет потенциальные проблемы в каждом сегменте кода, классифицируя ошибки по типам: уязвимости, проблемы производительности, нарушения стандартов кодирования и др. На выходе - первоначальные комментарии к review.
3. ReviewFilter: этот слой верификации - ключевой механизм контроля качества, который фильтрует ложные срабатывания и галлюцинации RuleChecker. ReviewFilter - тоже дообученная LLM, использующая три паттерна рассуждений: Direct Conclusion, Reasoning-First, Conclusion-First. После тестов наиболее эффективным оказался Conclusion-First - он лучше всего балансирует точность и производительность.
4. Comment Aggregation: на этом этапе схожие комментарии группируются с помощью cosine similarity, чтобы не перегружать разработчиков дублирующей обратной связью. В каждой группе сохраняется один представитель.
Вторую часть модели, а также подход к обучению и результаты внедрения мы рассмотрим в следующем посте.
#Software #AI #Engineering #Process #DevEx
Интересная научная статья от ByteDance, создателя TikTok на тему автоматизированного code review с использованием GenAI. Интересно, что чуть раньше я уже разбирал как Google подходит к этому вопросу при разборе "Resolving Code Review Comments with Machine Learning" в трех частях: 1, 2 и 3. Но у ребят из ByteDance немного другой подход - они сделали систему, в которой LLM пишет на MR (merge requests) комментарии в code review, а у ребят из Google сам комментарий писал инженер, а LLM делало code suggest, который предлагал фикс, что соответствует этому комментарию. Но давайте посмотрим какие проблемы авторы из ByteDance пытались решить, создавая BitsAI-CR:
- Избавиться от трудоемкого узкого места в виде традиционного code review
- Устранить ошибки и непоследовательности в комментариях при code review
Вообще, тема использования LLM для code review плодотворна, но там есть проблемки, которые авторы учли и попробовали устранить (кстати, в списке ссылок больше 50 других научных статей, десяток из которых про code review)
1. Низкая точность и надёжность: многие LLM-решения генерируют неточные или нерелевантные комментарии, тратя время разработчиков.
2. Недостаточная практичность: текущие системы часто не дают полезной обратной связи, которую реально используют разработчики.
3. Отсутствие механизма постоянного улучшения: большинство решений не учатся на обратной связи пользователей и не эволюционируют со временем.
Для решения этих проблем авторы придумали архитектуру из двух частей, что сочетает высокоточный pipeline генерации комментариев к review и механизм data flywheel. Такой подход не только выявляет потенциальные проблемы в коде с высокой точностью, но и запускает цикл постоянного улучшения на основе реальной обратной связи от разработчиков. Интересно, что для генерации комментариев используется таксономия правил code review, где есть категории security vulnerability, code defect, maintainability and readability, performance issue.
Давайте заглянем в то, как устроен каждый из двух компонентов модели
Review Comment Generation Pipeline
Pipeline работает в четыре последовательных этапа:
1. Context Preparation: на этом этапе входные изменения кода структурируются для дальнейшего анализа. Изменения разбиваются на сегменты по header hunks, добавляются полные определения функций - это даёт LLM достаточно контекста для качественного анализа.
2. RuleChecker: это дообученная LLM, обученная на широкой таксономии из 219 правил review. RuleChecker выявляет потенциальные проблемы в каждом сегменте кода, классифицируя ошибки по типам: уязвимости, проблемы производительности, нарушения стандартов кодирования и др. На выходе - первоначальные комментарии к review.
3. ReviewFilter: этот слой верификации - ключевой механизм контроля качества, который фильтрует ложные срабатывания и галлюцинации RuleChecker. ReviewFilter - тоже дообученная LLM, использующая три паттерна рассуждений: Direct Conclusion, Reasoning-First, Conclusion-First. После тестов наиболее эффективным оказался Conclusion-First - он лучше всего балансирует точность и производительность.
4. Comment Aggregation: на этом этапе схожие комментарии группируются с помощью cosine similarity, чтобы не перегружать разработчиков дублирующей обратной связью. В каждой группе сохраняется один представитель.
Вторую часть модели, а также подход к обучению и результаты внедрения мы рассмотрим в следующем посте.
#Software #AI #Engineering #Process #DevEx