💬 NLP

Beyond "What to Retrieve": Uncertainty in Retrieval-Augmented Code Generation

Cet article introduit OpenCoder, un cadre conscient de l'incertitude qui estime et exploite l'incertitude spécifique à la source pour filtrer et classer les preuves de recherche hétérogènes, améliorant ainsi la correction de la génération de code au niveau du dépôt tout en démontrant que ses bénéfices dépendent du moteur de langage de grande taille (LLM) spécifique et des interactions entre les preuves.

Auteurs originaux : Chandan Kumar Sah, Xiaoli Lian, Li Zhang

Publié 2026-07-29

📖 6 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Chandan Kumar Sah, Xiaoli Lian, Li Zhang

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 essayez de construire un château LEGO complexe, mais qu'on vous a remis un manuel d'instructions qui ne couvre que la porte d'entrée. Vous connaissez la porte, mais le château a besoin de fenêtres, d'un toit et d'un tunnel secret souterrain. C'est la lutte quotidienne de l'Intelligence Artificielle (IA) lorsqu'elle tente d'écrire du code informatique pour des projets du monde réel. Bien que l'IA soit devenue incroyablement douée pour écrire de petits fragments de code isolés, elle se perd souvent lorsqu'on lui demande de construire quelque chose qui s'intègre dans un « quartier » logiciel massif et existant. Pour résoudre cela, les chercheurs utilisent une technique appelée Génération Augmentée par Récupération (RAG). Considérez le RAG comme le fait de donner à l'IA un moteur de recherche surpuissant : avant d'écrire la moindre ligne de code, elle recherche des projets similaires, vérifie les règles du quartier (les conventions spécifiques du projet) et trouve les bons outils (API) à utiliser.

Cependant, il y a un piège. Ce n'est pas parce que le moteur de recherche trouve beaucoup d'informations que ces informations sont utiles. Parfois, l'IA trouve un morceau de code qui semble similaire mais qui casse en réalité le projet ; d'autres fois, elle trouve un outil qui ne convient pas à la tâche spécifique. L'information est là, mais elle est bruyante, conflictuelle ou tout simplement fausse. La grande question que les chercheurs se posent est la suivante : comment apprendre à l'IA non pas seulement à trouver la bonne information, mais à savoir à quel point elle peut lui faire confiance ? Si l'IA ne peut pas faire la différence entre un indice utile et un leurre trompeur, elle construira un château qui s'effondrera dès que vous essaierez d'ouvrir la porte.

C'est ici qu'intervient une nouvelle étude de chercheurs de l'Université de Beihang. Ils introduisent un système appelé OpenCoder, qui agit comme un chef de projet sceptique et ultra-organisé pour l'IA. Au lieu de faire aveuglément confiance à chaque information trouvée par le moteur de recherche, OpenCoder attribue un « score de doute » à chaque indice. Il se demande : « Quel est notre degré d'incertitude quant à savoir si cette API est la bonne ? » ou « Quelle est la probabilité que ce code similaire entre en conflit avec notre projet ? ». En traitant l'incertitude non pas comme un bug, mais comme un signal utile, OpenCoder filtre le bruit, classe les indices en fonction de leur fiabilité apparente et sait même quand s'arrêter et corriger ses propres erreurs.

Les chercheurs ont testé ce système en demandant à l'IA d'écrire du code pour 32 tâches réelles différentes. Ils ont constaté que lorsqu'ils utilisaient un modèle d'IA puissant appelé GPT, OpenCoder augmentait considérablement le taux de réussite du code final, passant de 56,25 % (avec les méthodes de recherche standard) à 78,13 %. Cependant, les chercheurs ont découvert une nuance cruciale : cette amélioration correspondait aux performances d'un groupe de contrôle utilisant une recherche standard mais ajoutant une étape de « vérification et réparation ». Cela suggère que si le filtrage de l'incertitude par OpenCoder a aidé, le bond massif de réussite était largement porté par la capacité du système à vérifier et à corriger les erreurs, plutôt que par le seul filtrage. La recette secrète n'était pas seulement de trouver plus d'informations, mais la capacité du système à dire : « Ce morceau d'évidence spécifique semble fragile, donc ignorons-le », et « Celui-ci semble solide, donc utilisons-le », tout en ayant un filet de sécurité pour rattraper les erreurs.

Toutefois, l'histoire n'est pas un simple « l'IA gagne pour toujours ». Les chercheurs ont pris soin de noter que ce succès dépend fortement de quel cerveau d'IA effectue la réflexion. Lorsqu'ils ont remplacé GPT par un autre modèle appelé Gemini, les résultats étaient beaucoup moins clairs. Les améliorations n'étaient pas statistiquement significatives, suggérant que le « radar d'incertitude » d'OpenCoder fonctionne différemment selon la personnalité de l'IA. De plus, le système a atteint un mur lorsque le projet manquait trop d'informations. Dans ces cas de preuves incomplètes, un système standard doté de vérification et de réparation a en fait surpassé OpenCoder. Cela indique que lorsque le moteur de recherche ne peut pas trouver les outils nécessaires pour commencer, le mécanisme de filtrage d'OpenCoder peut parfois supprimer les rares fragments d'évidence disponibles, plutôt que d'améliorer la décision finale.

L'étude a également découvert quelque chose de surprenant sur la façon dont différents types d'informations fonctionnent ensemble. Vous pourriez penser que posséder du « code similaire », du « contexte de projet » et des « connaissances sur l'API » est toujours préférable à n'en avoir qu'un seul. Mais les chercheurs ont découvert qu'il n'existe pas de règle universelle. Parfois, ajouter du « code similaire » a en fait confondu l'IA, à moins qu'il ne soit couplé au bon « contexte de projet ». C'est comme avoir une carte, une boussole et un GPS : si vous n'avez que le GPS, vous pourriez vous perdre ; si vous avez la carte et la boussole mais pas de GPS, vous pourriez vous en sortir ; mais si vous avez les trois et qu'ils se contredisent, vous pourriez tourner en rond. La valeur de chaque indice dépend entièrement des autres indices présents.

Pour faire fonctionner cela, OpenCoder suit une danse en cinq étapes. Premièrement, il construit une bibliothèque de toutes les règles et outils du projet. Deuxièmement, il décompose la requête de l'utilisateur en petites étapes. Troisièmement, il part à la chasse aux indices, mais cette fois, il les évalue en fonction de leur niveau d'« incertitude ». Quatrièmement, il génère le code, mais garde un œil attentif sur le « score d'incertitude » pour éviter d'utiliser des indices fragiles. Enfin, et c'est peut-être le plus important, il agit comme son propre inspecteur de contrôle qualité. Il fait passer le code par une série de tests. Si le code échoue, il ne baisse pas les bras ; il identifie l'erreur et tente de réparer le code en se basant sur ce retour de validation.

En fin de compte, l'article suggère que l'avenir du codage par l'IA ne consiste pas seulement à rendre l'IA plus intelligente ou à lui donner plus de données. Il s'agit d'apprendre à l'IA à être humble et critique. En traitant l'incertitude comme un outil pour guider les décisions — en filtrant les mauvaises données, en vérifiant le résultat et en corrigeant les erreurs à la volée — des systèmes comme OpenCoder peuvent construire des logiciels plus fiables. Mais comme les chercheurs l'avertissent, ce n'est pas une baguette magique qui fonctionne dans toutes les situations. Cela fonctionne mieux lorsque l'IA dispose d'assez de bonnes informations pour travailler et lorsque le modèle d'IA spécifique est réglé pour comprendre correctement les « scores de doute ». Pour l'instant, OpenCoder est une étape puissante, prouvant que parfois, savoir ce que l'on ne sait pas est la partie la plus importante de la résolution d'un puzzle.

Résumé technique : Au-delà de « ce qu'il faut récupérer » : l'incertitude dans la génération de code assistée par récupération

Énoncé du problème

La génération de code au niveau du dépôt nécessite que les modèles de langage de grande taille (LLM) synthétisent des implémentations qui respectent les dépendances inter-fichiers, les conventions de projet et les API privées. Bien que la génération augmentée par récupération (RAG) réponde à la limitation de la connaissance paramétrique en fournissant des preuves externes au dépôt, les approches existantes se concentrent principalement sur l'optimisation de ce qu'il faut récupérer (par exemple, du code similaire, le contexte du dépôt, la connaissance des API). Elles négligent largement l'incertitude inhérente à ces preuves.

Les preuves récupérées sont souvent hétérogènes et peu fiables : les exemples de code similaires peuvent être sémantiquement liés mais fonctionnellement incompatibles ; le contexte du dépôt peut contenir des dépendances redondantes ou conflictuelles ; et la connaissance des API peut être incomplète ou mal délimitée. Les méthodes actuelles optimisent la pertinence de la récupération sans modéliser explicitement comment l'incertitude de ces sources affecte la génération, la vérification et la réparation en aval. Par conséquent, la combinaison d'informations supplémentaires peut introduire du bruit et propager les erreurs de récupération, conduisant à un code exécutable qui contient encore des défauts substantiels d'utilisation d'API ou des défauts fonctionnels.

Méthodologie : OpenCoder

Les auteurs introduisent OpenCoder, un cadre conscient de l'incertitude conçu pour traiter l'incertitude comme un signal de contrôle actionnable plutôt que comme un score de confiance a posteriori. Le cadre opère à travers cinq phases :

Profilage de l'incertitude et des connaissances du dépôt : Construit un index contenant trois sources de preuves : les API spécifiques au projet ( $A$ ), le code contextuel du dépôt ( $X$ ), et les exemples de code sémantiquement similaires ( $S$ ).
Décomposition de l'incertitude de la requête : Décompose la requête de l'utilisateur en étapes d'implémentation et prédit les preuves requises pour chaque étape.
Récupération multi-sources sensible à l'incertitude : Récupère des candidats à partir de $A$ $A$ , $X$ $X$ , et $S$ $S$ . Crucialement, OpenCoder assigne un score d'incertitude spécifique à la source $u_m(e|q) \in [0,1]$ $u_{m} (e ∣ q) \in [0, 1]$ à chaque élément récupéré, où des valeurs plus élevées indiquent une confiance moindre dans la pertinence, l'exhaustivité ou la compatibilité.
- La preuve est scorée via une combinaison de similitude cosinus ( $r_m$ ), de poids d'intention de la source prédit ( $w_m$ ), et d'incertitude : $\gamma_m(e|s) = r_m \cdot w_m \cdot \max\{0, 1 - \alpha u_m(e)\}$ .
- Les preuves à faible confiance sont filtrées, et les éléments restants sont dédoublonnés et classés sous un budget de contexte partagé.
Génération de code guidée par l'incertitude : Le LLM génère du code candidat conditionné par la requête, l'ensemble de preuves filtrées, et la trace d'incertitude par source.
Vérification et atténuation de l'incertitude : Les candidats générés subissent des contrôles statiques et des tests exécutables. Le premier candidat passant est sélectionné. Si aucun candidat brut ne passe, le système identifie le candidat « mode » (provenant du groupe de cohérence de soi le plus large) et effectue jusqu'à deux tours de réparation guidée par la validation.

Le cadre utilise également l'Affinement d'API sensible à la cible pour supprimer les API auto-récupérées, redondantes ou incompatibles avec l'intention avant la génération.

Contributions clés

Formulation : L'article formule la génération de code au niveau du dépôt comme une prise de décision sous incertitude sur des preuves hétérogènes, allant au-delà du simple classement de pertinence.
Cadre (Framework) : OpenCoder est un système unifié qui estime l'incertitude spécifique à la source et l'opérationnalise à travers le filtrage des preuves, l'intégration multi-sources, la génération, la vérification et la réparation.
Analyse factorielle : À travers une analyse factorielle complète de la connaissance des API, du contexte du dépôt et des exemples de code similaires, les auteurs démontrent que l'utilité de la récupération est dépendante de l'interaction. Il n'existe pas de classement additif universel des sources ; la valeur d'une source spécifique dépend de l'évidence qui l'accompagne et du backend LLM.
Évaluation contrôlée : Les auteurs mènent une évaluation rigoureuse et appariée sur les backends GPT et Gemini pour des tâches de niveau dépôt exécutables, isolant l'impact du traitement sensible à l'incertitude de la vérification et de la réparation en aval.

Résultats expérimentaux

L'évaluation utilise un ensemble étendu de 32 tâches RepoExec-inline appariées et un test de résistance sur 10 tâches ExecRepoBench à contexte partiel.

Performance GPT : Sur l'ensemble de 32 tâches RepoExec-inline, OpenCoder a amélioré la correction de la sortie sélectionnée de 56,25 % (RAG de base) à 78,13 % (un gain de 21,88 points de pourcentage, $p$ nominal $= .039$ ). Cependant, il a égalé le contrôle RAG + Verify/Repair (qui utilise les mêmes preuves mais sans filtrage sensible à l'incertitude), suggérant que le gain par rapport au RAG de base est largement piloté par le budget de vérification/réparation plutôt que par le filtrage de l'incertitude seul.
Performance Gemini : Pour Gemini, les différences entre OpenCoder, le RAG de base et le contrôle n'étaient pas statistiquement supportées. Le contrôle (RAG + Verify/Repair) a été le plus performant sur la plupart des métriques.
Effets d'interaction : L'analyse factorielle (RQ1) a révélé qu'aucune source de preuve unique n'avait d'effet marginal statistiquement significatif sur la performance. Au lieu de cela, des interactions croisées significatives ont été observées (par exemple, le contexte du dépôt et les exemples de code similaires ont montré une interaction positive pour GPT).
Récupération d'API : L'affinement sensible à la cible a considérablement amélioré la récupération de l'ensemble d'API, faisant passer le macro F1 de 43,4 % à 64,8 % pour GPT et à 59,1 % pour Gemini.
Conditions limites : Sur le test de résistance de contexte limité ExecRepoBench, le contrôle RAG + Verify/Repair a nettement surpassé OpenCoder. Cela indique que lorsque les preuves du dépôt sont incomplètes, le mécanisme d'incertitude peut supprimer des alternatives utiles plutôt que d'améliorer la décision finale.

Signification et affirmations

L'article affirme que l'incertitude est plus utile non pas comme une estimation de confiance isolée, mais comme un signal de contrôle opérationnel couplé à la fusion des preuves, à la validation exécutable et à la réparation.

Dépendance au backend : Les bénéfices d'OpenCoder dépendent du backend. Bien qu'il ait considérablement amélioré la sélection de sortie de GPT par rapport au RAG simple, il n'a pas montré d'avantages statistiquement significatifs par rapport à un contrôle de vérification et de réparation, ni de bénéfices clairs pour Gemini.
Complétude des preuves : L'efficacité du cadre repose sur la complétude des preuves du dépôt. Dans les scénarios où les preuves sont incomplètes, le mécanisme d'incertitude peut involontairement filtrer des informations nécessaires.
Contrôle actionnable : La principale contribution est le passage de l'optimisation de ce qu'il faut récupérer à la modélisation de combien de fiabilité possède la preuve récupérée, en utilisant ce signal pour guider le filtrage et la génération.

Les auteurs concluent que bien qu'OpenCoder démontre le potentiel de l'intégration sensible à l'incertitude, ses avantages sont tributaires du backend LLM spécifique et de la qualité/complétude des preuves du dépôt récupérées. Ils soulignent que le code généré nécessite toujours une revue par un développateur et des tests spécifiques au projet.