Automatisation de la revue de code : comment les réseaux de neurones déchargent les développeurs des tâches répétitives

Pourquoi l'automatisation est nécessaire

Chez Avito, mille pull requests sont créées chaque semaine — jusqu'à 300 simultanément aux heures de pointe. Cela impose une charge énorme aux développeurs, détournés de leur travail principal pour faire de la revue de code. Résultat : les PR peuvent rester des jours en file d'attente, le time-to-market des nouvelles fonctionnalités augmente, et l'équipe s'épuise au point de laisser passer des bugs critiques.

L'équipe d'ingénieurs LLM a formulé trois objectifs pour cette automatisation :

• Accélérer le développement — supprimer les files d'attente de revue • Réduire l'influence du facteur humain — les changements de contexte constants font perdre leur concentration aux développeurs • Unifier le processus — des reviewers différents formulent des remarques différentes, ce qui introduit souvent de la subjectivité

Architecture du système

Le système comprend trois composants reliés dans un workflow précis :

1. Stash — l'interface où le développeur laisse le commentaire ai_review dans la PR 2. Service Go — reçoit l'événement depuis le Data Bus, parse la commande, récupère le diff et les métadonnées du dépôt, place la revue en base avec le statut STATE_REQUESTED et envoie un RPC au service ML 3. Service Python ML Pipeline — traite le contexte et renvoie les commentaires générés

Le service ML répond immédiatement par un 200 OK pour ne pas bloquer le service Go — la génération peut en effet prendre du temps.

Le pipeline ML : trois étapes

RuleChecker (génération). Le modèle identifie tous les problèmes potentiels, en s'appuyant sur une taxonomie des erreurs issue des vraies PR de l'équipe. Il est optimisé pour un rappel (Recall) élevé, même au prix de faux positifs. En sortie : un JSON avec les numéros de ligne et les recommandations.

ReviewFilter (validation). Cette seconde passe améliore la précision (Precision). Le modèle fonctionne selon le pattern Conclusion First — il reçoit le même contexte, plus un commentaire spécifique, et répond si cette remarque est pertinente ou non. Il élimine 90% des hallucinations et des faux positifs.

CommentAggregator (déduplication). Le système construit des embeddings des commentaires via BAAI/bge-m3, puis calcule la similarité cosinus. Si la similarité dépasse 0,85, les commentaires sont regroupés. De chaque groupe ne subsiste qu'un seul commentaire, le plus pertinent. En sortie : une liste finale de remarques uniques.

Choix du modèle et performances

Sur le benchmark MERA-RuCodeReviewer (689 exemples en Java, Python, Scala, Go), Gemini 2.5 Flash arrive en tête, mais l'équipe a choisi Qwen3-Coder-30B-Instruct-FP8 (deuxième place) — un modèle open source, hébergeable sur sa propre infrastructure. C'est un point critique : le code ne transite pas par des API externes, et l'auto-hébergement revient moins cher à grande échelle (les PR nécessitent de 2000 à 10 000 tokens).

Performances : • Petites PR (jusqu'à 3 fichiers) : 10 à 20 secondes • Grosses PR (10+ fichiers) : ~60 secondes • Maximum 650 revues en parallèle

Les métriques de qualité sont collectées via les likes des développeurs : • Précision : 85% des commentaires sont classés comme pertinents • Taux d'obsolescence : 32% (commentaires que le développeur a résolus par une correction). Pour l'Infra et le DevOps, ce taux atteint 60%.

Principaux enseignements

L'idée centrale : séparer Recall et Precision fonctionne mieux qu'une requête unique. Même avec un contexte long, le modèle s'y perd — un système à plusieurs étapes est donc nécessaire. La validation qui élimine les hallucinations est cruciale : c'est elle qui fonde la confiance des utilisateurs.

Le modèle doit voir le code complet des fichiers et la structure du dépôt — un simple diff ne suffit pas pour une analyse de qualité. L'IA prend en charge les tâches répétitives, mais les humains doivent garder le contrôle du processus.