Impact effectif d'un assistant à la révision de code utilisant un LLM

La révision de code est une pratique standard dans le développement logiciel moderne, qui vise à améliorer la qualité du code et à faciliter l'échange de connaissances entre les développeurs. Devant la complexité que sous-tend la révision constructive d'un patch soumis, Ubisoft a investi dans le développement et l'évaluation d'un assistant à la révision de code, RevMate, afin d'aider nos développeurs à accomplir cette tâche. Cette initiative a été conduite en collaboration avec Mozilla, qui a également développé le plug-in pour ses propres besoins.

Vous trouverez plus de détails sur notre étude dans notre article : [2411.07091]

Dans quel but évaluer l'assistance à la révision en pratique ?

La révision de code logiciel est une pratique fondamentale dans l'assurance qualité des logiciels modernes, largement adoptée dans les projets industriels et open-source. Si à l'origine, la révision de code était avant tout synonyme d'inspections de code pour un patch après soumission (en suivant une structure par blocs, c'est-à-dire des lignes successives de code modifié), le domaine a progressivement adopté une approche plus dynamique. La révision de code dite moderne prend ainsi en compte des dimensions sociales, pour faciliter par exemple le transfert de connaissances entre les développeurs et renforcer la synergie d'équipe.

Malgré ces avantages, les révisions de code peuvent aussi s'accompagner de surcoûts en raison des délais entre la soumission d'un patch et sa validation dus aux allers et retours entre l'auteur et les réviseurs. En outre, fournir des révisions pertinentes et efficaces nécessite des efforts non négligeables de la part des réviseurs d'un point de vue technique, social et personnel à la fois. Les réviseurs doivent comprendre et rationaliser l'impact global des modifications en cours d'analyse, tout en communiquant ces modifications de façon efficace. Même des réviseurs qualifiés et concentrés sur un patch peuvent passer à côté de problèmes par fatigue, distraction ou pression due à d'autres échéances.

La révision constructive d'un patch soumis étant donc une tâche difficile et sujette aux erreurs, les avancées des grands modèles de langage (LLM) en matière de traitement automatique des langues (TAL) d'une façon analogue aux humains ont poussé les chercheurs à évaluer la capacité des LLM à automatiser le processus de révision de code. Toutefois, en dehors d'un environnement de laboratoire, il reste difficile de savoir si les réviseurs seront enclins à accepter des commentaires générés par les LLM dans des conditions de développement réelles.

Pour combler ce vide, nous effectuons une vaste étude de case empirique en conditions réelles afin d'évaluer l'acceptation des commentaires générés par LLM et leur impact sur le processus de révision. Cette étude de cas a été effectuée dans deux organisations, puisqu'elle a été conduite collaborativement avec Mozilla. Dans le cadre de cet article toutefois, nous nous limiterons aux observations côté Ubisoft.

Comment fonctionne notre outil d'assistance à la révision, RevMate ?

Dans le cadre de cette évaluation, nous avons conçu RevMate, un assistant à la révision utilisant un LLM qui génère des commentaires de révision et s'intègre facilement aux environnements de révision modernes. Basé sur GPT4o, RevMate utilise (i) la génération augmentée d'informations applicatives (Retrieval Augmented Generation, RAG) pour intégrer des informations pertinentes et adapter le modèle au projet en cours d'analyse ; et (ii) le jugement par LLM (LLM-as-a-Judge) pour exploiter la capacité des LLM à évaluer les contenus générés et supprimer les commentaires de révision peu pertinents. Dans la mesure où nous voulions collecter un maximum d'évaluations de révision malgré les limitations des évaluations humaines, nous avons choisi deux variantes :

• RevMate avec contexte de code supplémentaire (Code) : le modèle peut demander à un outil de récupération de code de fournir des définitions des fonctions et des lignes de code supplémentaires dans la base de code en cours d'analyse.
• RevMate avec exemples de commentaires connexes (Exemple) : pour chaque patch, le modèle sélectionne de façon dynamique un nombre limité (few-shot) d'exemples de commentaires de révision analogues à ses blocs.

Nous avons intégré RevMate dans l'environnement de révision des participants pour qu'ils puissent y recourir en effectuant leurs tâches quotidiennes de révision de code. À travers l'étude de cas, les réviseurs peuvent évaluer chaque commentaire généré, qui est présenté sous forme de suggestion par le biais d'une boîte d'évaluation comme celle en figure 1 : « add to comment » pour accepter ou « ignore » pour refuser. En cas de refus, nous avons également demandé aux réviseurs de justifier leur choix, sur la base des options indiquées en figure 2. Avant d'évaluer le commentaire, les réviseurs peuvent aussi en modifier le contenu. Cela fait, la boîte d'évaluation disparaît. Un refus ne laisse pas de trace ; une acceptation laisse un commentaire public. Chaque commentaire généré ne peut être évalué qu'une fois.

Figure 1 : Interface utilisateur de RevMate pour les boîtes d'évaluation des commentaires générés

Figure 2 : Interface utilisateur de RevMate pour le choix des raisons d'ignorer les commentaires générés

Sur une durée de 6 semaines, notre étude de cas chez Ubisoft a impliqué 31 réviseurs, 422 révisions de patchs, et abouti à l'évaluation de 1 200 commentaires générés. Au cours de cette étude, nous avons surveillé les interactions des réviseurs avec un assistant à la révision utilisant un LLM, évalué l'impact des commentaires générés sur le processus de révision et, pour finir, effectué une enquête auprès des réviseurs participants afin d'obtenir leur avis. 22 des 31 participants s'y sont prêtés.

À quelle fréquence les réviseurs utilisent-ils les commentaires générés par RevMate ?

Au cours de cette étude, chez Ubisoft, les commentaires de révision générés obtiennent un pourcentage d'appréciation prometteur (28,3 %). Le pourcentage d'appréciation reflète trois données : les commentaires marqués comme acceptés (7,2 %), utiles aux développeurs (12,8 %) et utiles aux réviseurs (7,7 %).

Les commentaires utiles aux développeurs révèlent que 12,8 % des commentaires générés pourraient aider les développeurs avant qu'ils ne soumettent leurs modifications. Ces commentaires générés apparaissent donc trop tard dans le processus de développement. Un participant a signalé dans le cadre de l'enquête : « L'assistant détecte des failles tout à fait possibles dans le code, mais la plupart des suggestions relèvent plus du domaine du développement que de la révision ». 4 participants ont laissé des commentaires analogues. Donner aux développeurs un aperçu de ces suggestions avant l'étape de révision par les pairs pourrait donc améliorer sensiblement les pipelines de développement ; de ce fait, les commentaires « utiles aux développeurs » pourraient améliorer la qualité du code que reçoivent les réviseurs.

Les utilisateurs accordent de l'importance aux commentaires « utiles aux réviseurs en tant que conseil » pour guider la révision. Bien que certains commentaires ne soient pas exploitables en l'état ou passent sous silence des problèmes spécifiques, ils peuvent néanmoins poser des questions intéressantes. Un participant a noté : « Il y a plus d'intérêt à mettre en exergue des problèmes potentiels avec une explication concise et à laisser le réviseur rédiger le commentaire », un avis partagé par 10 autres participants. Nous suggérons par conséquent que ces conseils de révision soient présentés séparément des commentaires publiables, dans la mesure où leur finalité diffère.

Comment la catégorie de commentaire est-elle corrélée aux pourcentages d'acceptation de RevMate ?

Notre étude unique montre que les commentaires générés les plus courants font partie des catégories Fonctionnel et Réusinage avec 84,8 % et 14,5 % respectivement pour Ubisoft. Nous nous sommes aperçus que la distribution des catégories était comparable à celle des commentaires rédigés par des humains, pour lesquels nous avions obtenu 81,4 % en Fonctionnel et 15,8 % en Réusinage sur un échantillon de 1 211 commentaires humains.

En outre, les commentaires de réusinage bénéficient d'un taux d'acceptation supérieur aux commentaires fonctionnels (respectivement, 18,6 % contre 5,2 % chez Ubisoft).  Toutefois, en cas de non-acceptation, les commentaires de réusinage sont aussi plus souvent marqués comme « incorrects » (25 % contre 15,6 %). Les commentaires fonctionnels étant plus difficiles à générer précisément sur la base d'un patch, l'assistant a tendance à prendre moins de risques pour cette catégorie et génère donc des commentaires plus évidents ou anecdotiques, que les réviseurs publient rarement. En effectuant une inspection manuelle d'un échantillon de 244 commentaires générés, nous déterminons leur exploitabilité (c'est-à-dire si les auteurs ont compris la modification nécessaire à partir du commentaire). Nous avons ainsi observé que parmi les 244 commentaires de l'échantillon, où 79 % des commentaires « acceptés » et 62 % des « refusés » étaient exploitables, 36 % des commentaires « utiles » étaient en réalité exploitables. C'est la preuve que le modèle prend effectivement moins de risques dans les affirmations de ces commentaires.

Quel impact l'adoption de RevMate a-t-elle sur le processus de révision du patch ?

Les commentaires générés et acceptés ont un impact sur le code semblable aux commentaires rédigés par des humains. Chez Ubisoft, les commentaires générés et acceptés ont entraîné autant de révisions par lignes (62,3 % et 64,3 %) et par blocs (73,9 % et 73,2 %) que les commentaires humains.

Synthèse

La révision de code joue aujourd'hui un rôle essentiel dans le développement logiciel collaboratif. C'est un moyen d'améliorer la qualité des systèmes évolutifs tout en améliorant les capacités sociales et techniques des développeurs. Des études récentes ont intégré des tâches de génération de commentaires dans le processus de révision, en exploitant des approches par LLM. Toutefois, elles n'ont pas évalué l'impact de ces approches sur le processus de révision.

Dans le cadre d'une étude de cas de grande ampleur, nous constatons un pourcentage d'appréciation de 28,3 % chez Ubisoft. Les commentaires de réusinage, même s'ils ne sont que le deuxième type de commentaires générés le plus populaire (14,5 %) derrière les commentaires fonctionnels (84,8 %), enregistrent des taux d'acceptation sensiblement plus élevés (18,6 % contre 5,2 %). Pour ce qui est des commentaires acceptés, nous constatons que leur impact sur les processus de révision des patchs est équivalent aux commentaires rédigés par des humains, puisque 74 % contre 73 % des commentaires ont au moins un suivi au niveau des blocs. Sur la base de ces résultats prometteurs pour l'avenir de l'adoption des commentaires de révision générés par LLM, nous avons intégré notre solution à nos productions pour aider nos développeurs dans leur tâche de révision. L'intégration a été conçue pour servir à l'auto-révision (réviser son propre code) comme à la révision par des pairs.

Notre hypothèse est que la différence entre l'acceptation et l'appréciation des commentaires de révision générés est due à une définition incorrecte de la tâche pour le LLM. En effet, le LLM utilisé est conçu pour plusieurs tâches : générer des commentaires publiables, des conseils pour les développeurs et pour les réviseurs, trois axes utiles pour le processus de révision. Les travaux futurs devraient chercher à améliorer l'acceptation globale des commentaires, tout en envisageant une distinction dans les types de commentaires : publiables, à l'intention des développeurs, conseils de révision. En outre, nous pourrions affiner les catégories de commentaires de révision, en envisageant la génération de chaque catégorie en tant que tâche distincte, et axer la génération sur des catégories spécifiques selon les préférences des réviseurs. La génération de commentaires fonctionnels devrait être améliorée car elle entraîne des pourcentages d'acceptation moindres, alors que c'est le type de commentaires que les humains rédigent le plus.