Как переложить нагрузку по code review с разработчиков на LLM
В Авито создаётся около 1000 pull request в неделю, а в пиковые часы нагрузка доходит до 300 PR в час. Чтобы ускорить доставку кода и снизить переключение разработчиков на рутинные проверки, ревью запускают прямо в Stash: разработчик оставляет комментарий ai_review, событие попадает в Data Bus, Go-сервис забирает diff, метаданные и структуру репозитория, а затем передаёт задачу в Python ML Pipeline service.
Для ревью выбрали Qwen3-Coder-30B-Instruct-FP8: по бенчмарку MERA-RuCodeReviewer она заняла второе место после Gemini 2.5 Flash, но подходит для self-hosting. Это важно из-за безопасности кода и экономики: небольшие PR требуют около 2000 токенов, крупные — до 10 000, поэтому API-модель при такой нагрузке становится дорогой, а код не должен уходить во внешние системы.
ML-пайплайн работает в несколько этапов. Сначала diff аннотируют, потому что обычный git diff не даёт абсолютных номеров строк и полного контекста файла; затем RuleChecker генерирует потенциальные проблемы по классам безопасности, дефектов разработки, перфоманса и поддержки кода; ReviewFilter отсеивает false positives и нерелевантные замечания; CommentAggregator строит эмбеддинги через BAAI/bge-m3 и объединяет похожие комментарии при cosine similarity выше 0.85. Малые PR обрабатываются за 10–20 секунд, большие — примерно за 60 секунд; лимит параллельных ревью установлен на уровне 650, precision комментариев достиг 85%, общий outdated rate — 32%, а в Infra и DevOps — до 60%.
Коротко
- Авито обрабатывает около 1000 PR в неделю, а в пиковые часы нагрузка на code review достигает 300 PR в час.
- LLM-ревью запускается из Stash комментарием ai_review, после чего Go-сервис оркестрирует процесс через Data Bus и ML-сервис.
- Для self-hosting выбрали Qwen3-Coder-30B-Instruct-FP8: код остаётся во внутреннем контуре, а API-расходы не растут на токеноёмких PR.
- Пайплайн разделён на RuleChecker, ReviewFilter и CommentAggregator, чтобы сначала повысить полноту, затем точность и убрать дубли.
- Текущие метрики: precision 85%, outdated rate 32% по всем репозиториям и до 60% в Infra и DevOps.
FAQ
Зачем Авито автоматизировала code review с помощью LLM, если разработчики всё равно должны контролировать результат?
Цель — снять рутинную нагрузку, ускорить прохождение PR и унифицировать качество комментариев. При этом процесс не отдают модели полностью: люди сохраняют контроль над ревью.
Почему для автоматического code review оказалось недостаточно обычного git diff без дополнительной подготовки?
Обычный git diff не содержит абсолютных номеров строк и полного состояния файла. Поэтому перед генерацией замечаний diff аннотируют и передают модели расширенный контекст.
Как система снижает риск лишних или галлюцинированных комментариев от LLM при ревью кода?
Генерация и валидация разделены: RuleChecker ищет максимум потенциальных проблем, а ReviewFilter отбрасывает нерелевантные замечания. Затем CommentAggregator удаляет семантические дубли.
Читайте также
Hybrid RAG для бизнеса: умный поиск по документам без облака и утечки данных- Как научить LLM исправлять код без лишних изменений
- Автоматизация процессов на open source: n8n и Ollama
- Как тимлид заменил десятки вкладок на файловую систему и Claude Code
- От хаоса к системе: как выстроить процесс Discovery (часть 1)
- LLM-review как отдельный асинхронный сервис: Автоматическое code review лучше выносить в отдельный ML-сервис, а не выполнять внутри основного приложения. Оркестратор должен быстро принимать событие, фиксировать состояние задачи и передавать долгую генерацию в фон, чтобы не блокировать пользовательский интерфейс и RPC-соединения.
[AI-инструменты для разработки]
Зарегистрированные пользователи видят только два тезиса.
Зарегистрироваться
Авито описала внутреннюю систему, которая снимает часть нагрузки по code review с разработчиков: ревью запускается комментарием ai_review в Stash, а замечания генерирует self-hosted LLM-пайплайн. Практическая ценность кейса — в раздельной архитектуре генерации, фильтрации и дедупликации комментариев.