💻 computer science

Rover: Context-aware Conflict Resolution with LLM

Rover est un nouveau système de résolution de conflits qui améliore les grands modèles de langage en intégrant l'analyse de programmes et un graphe de propriétés de code multicouche pour générer des invites sensibles au contexte, surpassant ainsi les outils existants dans la résolution précise de conflits complexes de fusion de code.

Auteurs originaux : Qingyu Zhang, Junzhe Li, Jiayi Lin, Changhua Luo, Chenxiong Qian

Publié 2026-05-19

📖 5 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Qingyu Zhang, Junzhe Li, Jiayi Lin, Changhua Luo, Chenxiong Qian

Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète

Imaginez que vous et un ami éditez simultanément le même livre de recettes. Vous décidez d'ajouter une pincée de sel à la soupe, tandis que votre ami décide d'ajouter une tasse de sucre. Lorsque vous tentez de fusionner vos deux versions, le livre se perd : « Ajoutons-nous du sel ? Du sucre ? Les deux ? Aucun ? » C'est un conflit de fusion.

Dans le monde du logiciel, des millions de développeurs font cela chaque jour. Habituellement, les ordinateurs tentent de résoudre ces conflits automatiquement, mais ils se trompent souvent car ils ne regardent que les lignes de texte immédiates, manquant ainsi la vue d'ensemble. Si vous modifiez un nom de variable dans un fichier, cela peut briser une fonction dans un fichier complètement différent. Les outils standards ne « voient » pas cette connexion.

Voici Rover, un nouvel outil conçu pour être le « super-éditeur » ultime face à ces conflits. Voici comment il fonctionne, en utilisant des analogies simples :

1. Le Problème : L'Éditeur « Aveugle »

Imaginez un robot tentant de corriger une faute de frappe dans un roman. Si le robot ne regarde que la phrase contenant la faute, il peut corriger l'orthographe mais briser accidentellement le sens du paragraphe entier, car il ne savait pas ce que le personnage était censé faire trois chapitres plus tôt.

Les outils actuels sont comme ce robot. Ils examinent les lignes en conflit et quelques lignes immédiatement adjacentes. Ils manquent les connexions « à longue distance », comme une fonction définie dans le Fichier A qui est utilisée dans le Fichier B.

2. La Solution : La « Super-Carte » de Rover (MtCPG)

Rover ne se contente pas de lire le texte ; il construit un Graphique de Propriétés de Code Multi-couches (MtCPG).

Pensez-y comme à une carte de métro massive et interactive de tout le projet logiciel.

Les outils standards ne regardent que la rue où l'accident s'est produit.
La Carte de Rover montre chaque station, chaque voie et chaque connexion entre différentes lignes, même si elles se trouvent dans des villes différentes (fichiers).

Cette carte suit :

Qui parle à qui : Si une fonction dans un fichier appelle une variable dans un autre, la carte trace une ligne entre elles.
La hiérarchie : Elle sait qu'une ligne de code spécifique appartient à une fonction spécifique, qui appartient à une classe spécifique.
Le « Pourquoi » : Elle comprend que si vous modifiez une définition, tout ce qui y est connecté est affecté, même si cela se trouve à 100 lignes de distance ou dans un fichier différent.

3. Le Processus : Trouver le Bon Contexte

Lorsqu'un conflit survient, Rover ne se contente pas de saisir le texte adjacent à l'erreur. Au lieu de cela, il utilise sa Carte de Métro pour tracer les connexions.

Localiser le Conflit : Il trouve l'endroit exact où les deux versions divergent.
Tracer les Lignes : Il suit les « voies » de sa carte pour trouver chaque morceau de code connecté à ce conflit. Peut-être que le conflit implique une variable définie dans un fichier différent ? Rover trouve ce fichier et récupère ce code aussi.
Regrouper les Indices : Il rassemble tous ces morceaux de code connectés en un « paquet de contexte ». C'est comme rassembler tous les témoins et toutes les preuves liés à une scène de crime, plutôt que de se contenter d'examiner la scène de crime elle-même.

4. La Résolution : L'IA Intelligente

Une fois que Rover a ce riche « paquet de contexte », il le remet à un Modèle de Langage de Grande Taille (LLM) — une IA très intelligente qui sait écrire du code.

Sans Rover : L'IA reçoit un tout petit extrait de code et doit deviner le reste. Elle devine souvent mal car elle manque de contexte.
Avec Rover : L'IA reçoit le conflit plus la « Carte de Métro » complète du code associé. Elle peut voir l'image entière. Elle comprend : « Ah, cette variable est utilisée ici, et cette fonction attend ce type de données. »

L'IA écrit ensuite la solution parfaite qui satisfait les deux versions du code, préservant l'intention des deux développeurs.

5. Les Résultats : Pourquoi Cela Compte

Les chercheurs ont testé Rover contre :

L'IA standard : Juste l'IA regardant le texte voisin.
Les anciens outils d'apprentissage automatique : Des outils entraînés sur des modèles spécifiques.
D'autres outils « d'aide » : Des outils qui tentent de trouver du code associé mais manquent souvent les connexions profondes.

Le Résultat :
Rover était nettement meilleur pour résoudre les conflits.

Il a produit des solutions qui ressemblaient davantage à ce que des développeurs humains auraient écrit.
Il a géré des situations complexes où le code d'un fichier dépendait du code d'un autre fichier, ce que les autres outils n'ont pas réussi à résoudre.
Il a fonctionné à travers différents langages de programmation (C, Java, Python) sans avoir besoin d'être réentraîné pour chacun d'eux.

Résumé

Pensez à Rover comme à un détective qui ne se contente pas d'examiner la scène de crime (le conflit) mais qui interroge aussi chaque témoin et vérifie chaque alibi (les dépendances du code) avant de résoudre l'affaire. En donnant à l'IA une carte complète des relations du logiciel, Rover garantit que le code fusionné final est correct, sûr et fonctionne réellement.

Résumé technique : Rover, résolution de conflits consciente du contexte avec les LLM

1. Énoncé du problème

La fusion de code dans les projets logiciels à grande échelle constitue un goulot d'étranglement majeur, nécessitant souvent une intervention manuelle extensive pour résoudre les conflits de fusion. Les solutions existantes présentent des limitations critiques :

Fusion textuelle et structurelle : Les outils traditionnels (par exemple, Git, les outils de fusion structurelle) manquent souvent de la capacité à inférer l'intention du développeur ou à gérer les dépendances sémantiques complexes, ce qui entraîne des fusions incorrectes ou des conflits non résolus nécessitant une correction manuelle.
Approches par apprentissage automatique : Les modèles d'apprentissage automatique antérieurs (par exemple, MergeGen) sont souvent limités à des langages spécifiques ou à des motifs de conflits particuliers et nécessitent un pré-entraînement spécifique à la tâche.
Approches basées sur les LLM : Bien que les grands modèles de langage (LLM) soient prometteurs, ils peinent avec les conflits impliquant des dépendances de code complexes qui s'étendent au-delà du voisinage immédiat du conflit. Les méthodes existantes reposent généralement sur des blocs de code adjacents comme contexte, ce qui est souvent insuffisant pour capturer les véritables dépendances sémantiques (par exemple, les définitions de variables, les interactions inter-fichiers).
Approches basées sur des agents : Bien que les agents puissent explorer les dépôts pour trouver un contexte, ils souffrent de non-déterminisme, d'une surcharge computationnelle élevée et de difficultés à attribuer les échecs à un contexte manquant plutôt qu'à des erreurs de raisonnement.

Le défi central réside dans le fait que les LLM manquent de conscience du contexte concernant les dépendances de code qui s'étendent sur plusieurs fichiers ou niveaux d'abstraction, et que les outils d'analyse de dépendances existants sont soit non agnostiques au langage, soit incapables de capturer les dépendances à travers plusieurs versions du code.

2. Méthodologie : Le système Rover

Rover est un nouveau système automatisé de résolution de conflits qui intègre l'analyse de programme avec les grands modèles de langage (LLM). Sa conception est guidée par l'idée qu'une résolution efficace nécessite une notion de contexte principielle et analysable, dérivée de l'analyse des dépendances, plutôt qu'une exploration heuristique ou de simples fenêtres de code adjacentes.

2.1 Graphe de propriétés de code multicouche (MtCPG)

Pour pallier le manque d'analyse de dépendances complète, Rover introduit le MtCPG, un nouveau schéma de représentation construit sur le cadre du graphe de propriétés de code (CPG) (en utilisant spécifiquement Joern).

Architecture : Le MtCPG étend le CPG standard en introduisant une structure hiérarchique avec des nœuds de haut niveau (par exemple, TypeDef, MethodDef, GlobalVarDef, ImportDef) et des nœuds de bas niveau (par exemple, MemberDef, MethodStmt, MethodVarDef).
Types d'arêtes :
- Arêtes inter-couches : Relient les définitions de haut niveau à leurs composants internes de bas niveau, permettant un raisonnement fin.
- Arêtes inter-fichiers : Modélisent explicitement les dépendances entre les nœuds de différents fichiers sources via des nœuds ImportDef, permettant une analyse de dépendances inter-fichiers sans aplatir les fichiers sources.
Avantages : Contrairement aux CPG standards, le MtCPG capture les dépendances inter-fichiers et les abstractions au niveau des définitions, ce qui est crucial pour comprendre les conflits s'étendant sur plusieurs fichiers ou impliquant des définitions de types situées ailleurs.

2.2 Génération de contexte par alignement graphe-texte

Rover aligne la représentation textuelle des modifications de code (issues des résultats de fusion Git) avec la structure MtCPG pour générer des contextes sémantiquement significatifs.

Alignement graphe-texte : Un mécanisme de "coloration" mappe les blocs de modifications de code (diffs) vers des nœuds spécifiques du MtCPG en utilisant un arbre de segments basé sur les numéros de ligne.
Regroupement de contexte : Rover emploie un algorithme de Recherche en largeur multi-source (MS-BFS) sur le MtCPG en partant des nœuds de conflit. Il explore les dépendances jusqu'à une profondeur $k$ configurable pour regrouper les blocs de code apparentés en "contextes".
Intégration inter-versions : Les contextes sont générés indépendamment pour les deux versions à fusionner, puis fusionnés en utilisant une approche d'union de ensembles disjoints pour garantir que toutes les dépendances pertinentes des deux versions sont capturées.

2.3 Génération de la résolution

La résolution finale est générée par un LLM (par exemple, Qwen3-30B-A3B) guidé par un prompt structuré contenant :

Définition de la tâche : Des instructions claires sur le rôle et l'objectif.
Chaîne de pensée (CoT) : Un processus de raisonnement en trois étapes exigeant que le LLM analyse la cause racine, infère la logique prévue pour les deux versions et détermine la meilleure stratégie de fusion.
Format d'entrée/sortie : Utilise le format "diff" pour un traitement optimisé.
Entrée contextuelle : Le code conflictuel combiné au contexte sémantiquement pertinent récupéré depuis le MtCPG.

3. Contributions clés

L'article revendique les contributions suivantes :

MtCPG : Un schéma de représentation novateur qui capture des dépendances complètes pour tous les composants de code, y compris les relations inter-fichiers et inter-couches, surmontant les limitations des CPG standards.
Méthodologie de classification de contexte : Une approche principielle pour classifier les blocs de code basée sur la connectivité MtCPG, générant des contextes plus adaptés à l'évaluation des dépendances du code que de simples fenêtres de code adjacentes.
Système Rover : Une implémentation d'un outil de résolution de conflits basé sur les LLM intégrant le MtCPG. Il est évalué sur l'ensemble de données ConGra et montre des performances supérieures aux LLM autonomes et aux outils de référence.

4. Résultats expérimentaux

Les auteurs ont évalué Rover en utilisant l'ensemble de données ConGra (excluant le C++ en raison de la maturité des outils) et un sous-ensemble de l'ensemble de données WizardMerge (basé sur le C). Les métriques incluaient la distance d'édition (ED), la similarité Winnowing (WS) et la similarité cosinus (CS).

MtCPG vs CPG : Le MtCPG a augmenté le nombre de nœuds du graphe d'environ 3,4 % et d'arêtes d'environ 25 % par rapport au CPG standard, capturant des informations de dépendance nettement plus riches.
Performance par rapport aux références :
- LLM autonome : Rover a surpassé un LLM autonome (Qwen3-30B-A3B) de 13,29 % (WS), 10,46 % (ED) et 9,79 % (CS).
- Référence par apprentissage automatique : Comparé à MergeGen, Rover a obtenu des améliorations de 17,72 % (WS), 15,90 % (ED) et 9,10 % (CS).
- LLM assisté par outil : Rover a dépassé la combinaison LLM avec WizardMerge de 3,82 % (WS), 1,85 % (ED) et 4,07 % (CS).
Sensibilité au contexte : L'étude a révélé que l'augmentation de la taille du contexte (soit les lignes adjacentes, soit la profondeur du graphe $k$ ) n'améliore pas linéairement les performances. Une valeur optimale de $k$ (par exemple, $k=4$ ) existe ; au-delà, des dépendances lointaines non pertinentes dégradent les performances en distrayant le modèle.
Couverture : Rover a atteint un taux de couverture des conflits de 98,83 % sur l'ensemble de données de WizardMerge, nettement supérieur aux 90,67 % de WizardMerge, principalement parce que Rover opère sur le code source sans nécessiter de compilation complète du projet.
Dépendance au modèle : L'efficacité de Rover variait selon le LLM. Elle a amélioré les performances sur les grands modèles (gpt-oss-20b) mais a dégradé les performances sur les petits modèles (Llama-3.1-8B), suggérant un "goulot d'étranglement du raisonnement" où les petits modèles peinent à interpréter des contextes longs et complexes.

5. Importance et revendications

L'article présente Rover comme une étape significative vers une résolution de conflits entièrement automatisée et consciente du contexte.

Contexte déterministe : Contrairement aux systèmes basés sur des agents, Rover fournit une base déterministe et analysable pour la sélection de contexte, évitant le non-déterminisme de l'exploration pilotée par les LLM.
Combler le fossé : Il comble avec succès le fossé entre l'analyse de programme (qui comprend les dépendances mais manque de capacité générative) et les LLM (qui peuvent générer du code mais manquent d'une conscience contextuelle profonde).
Praticité : En opérant au niveau du code source et sans nécessiter de compilation complète du projet, Rover est plus robuste et applicable aux scénarios de fusion réels que les outils reposant sur une analyse basée sur le compilateur (comme WizardMerge).
Limites modestes : Les auteurs reconnaissent que le MtCPG présente actuellement des limitations avec certaines fonctionnalités spécifiques à un langage (par exemple, l'assembleur en ligne en C, la gestion complexe des exceptions) et que les métriques basées sur les chaînes de caractères ne garantissent pas entièrement la correction fonctionnelle, bien qu'une validation par échantillonnage manuel ait montré une forte corrélation positive entre les scores de métriques et l'acceptation des résolutions.

Les auteurs concluent que des informations contextuelles appropriées, dérivées d'une analyse de dépendances principielle, sont essentielles pour améliorer la résolution de conflits basée sur les LLM, et que Rover démontre efficacement ce potentiel.