💻 computer science

TICoder: A Repository-Level Code Generation Framework with Test-Driven Planning and Implementation-Aware Reuse

Ce document présente TICoder, un nouveau cadre de génération de code au niveau du dépôt qui améliore les performances des grands modèles de langage en intégrant un mécanisme de planification itérative piloté par les tests pour le guidage comportemental et une stratégie de réutilisation sensible à l'implémentation avec une similitude à double vue et une sélection à double étape afin de tirer parti efficacement du code existant du dépôt, atteignant une amélioration moyenne de 11,52 % par rapport aux méthodes de pointe.

Auteurs originaux : Siyu Nan, Yaling Luo, Jian Wang, Neng Zhang, Bing Li

Publié 2026-06-09

📖 5 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Siyu Nan, Yaling Luo, Jian Wang, Neng Zhang, Bing Li

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 êtes un chef étoilé (l'IA) essayant de cuisiner un plat complexe basé sur la commande vague d'un client : « Faites-moi quelque chose avec des pâtes. » Vous avez accès à une immense bibliothèque de livres de recettes (le dépôt de code), mais vous ne pouvez lire que quelques pages à la fois.

La plupart des chefs IA actuels essaient de résoudre cela en cherchant une recette qui semble ressembler à « pâtes » et en la copiant. Mais cela échoue souvent car le client peut vouloir un type de pâtes spécifique, ou la recette peut manquer d'une étape cruciale comme « faire bouillir l'eau d'abord ».

TICoder est une nouvelle façon plus intelligente d'aider le chef IA à cuisiner. Il agit comme un sous-chef hautement organisé qui ne se contente pas de trouver des recettes, mais aide l'IA à planifier le repas et à apprendre exactement comment utiliser correctement les ingrédients. Voici comment cela fonctionne, divisé en trois parties simples :

1. La planification par « test de validation » (Le test de goût)

Le Problème : Lorsque l'IA essaie de planifier les étapes de la cuisson du plat uniquement à partir des mots vagues du client, elle oublie souvent les détails. Elle peut oublier de vérifier si les pâtes sont sans gluten ou si la sauce doit mijoter pendant une heure.

La Solution TICoder : Avant que l'IA ne commence à cuisiner, TICoder demande un « test de goût » (cas de test). Ce sont des instructions spécifiques : « La sauce doit être épicée » ou « Les pâtes doivent être al dente ».

Comment ça marche : L'IA ébauche un plan. Ensuite, une IA « Juge » examine le plan et les tests de goût. Si le plan ne correspond pas aux tests (ex : « Vous avez oublié l'épice ! »), le Juge le renvoie pour révision.
Le Résultat : L'IA boucle à travers ce cycle « ébauche, juge, corrige » jusqu'à ce que le plan corresponde parfaitement au résultat attendu. Cela garantit que l'IA sait exactement ce qu'elle doit construire avant de commencer à construire.

2. La réutilisation « consciente de l'implémentation » (Trouver le bon outil)

Le Problème : Une fois que l'IA a un plan, elle doit trouver des outils existants (fonctions) dans la bibliothèque pour l'aider.

L'ancienne méthode : L'IA cherche un outil qui ressemble à ce dont elle a besoin. Elle peut trouver un « fabricant de sauce » qui fonctionne, mais elle utilise le mauvais type de chaleur ou ajoute du sel quand elle ne le devrait pas. Elle saisit l'outil mais ne sait pas comment l'utiliser correctement.
La Solution TICoder : TICoder examine l'outil de deux manières :
1. Fonction : Fait-il le bon travail ? (ex : « Oui, il fait de la sauce. »)
2. Implémentation : Fonctionne-t-il de la bonne manière ? (ex : « Oui, il mijote pendant 20 minutes, tout comme nous en avons besoin. »)
Le Résultat : Il trouve l'outil exact qui correspond à la fois à la description du travail et à la manière spécifique dont il doit être réalisé.

3. La sélection du « modèle d'utilisation » (Apprendre des exemples)

Le Problème : Même si l'IA trouve l'outil parfait, elle pourrait ne pas savoir comment le brancher. Imaginez trouver une machine à expresso complexe mais ne pas savoir quel bouton presser pour obtenir un latte plutôt qu'un cappuccino.

La Solution TICoder : TICoder ne donne pas seulement l'outil à l'IA ; il montre à l'IA comment d'autres chefs ont utilisé cet outil exact par le passé.

Il examine la bibliothèque pour voir comment cet outil a été réellement utilisé dans de vraies recettes.
Il filtre des milliers d'exemples pour trouver les meilleures façons les plus courantes d'utiliser cet outil (regroupement par grappes de méthodes similaires) et élimine les cas confus ou étranges.
Le Résultat : L'IA reçoit une « fiche de triche » montrant les 2 ou 3 meilleures façons d'utiliser l'outil, garantissant qu'elle ne commettra pas d'erreur lors de l'assemblage du plat final.

Le Résultat Final

Lorsque vous combinez ces trois parties :

Planification : L'IA sait exactement quoi faire parce qu'elle a vérifié son travail par rapport à des « tests de goût ».
Récupération : Elle trouve les outils parfaits qui correspondent à la fois au travail et à la méthode.
Réutilisation : Elle sait exactement comment utiliser ces outils parce qu'elle a étudié des exemples réels.

L'Issue : Dans les expériences de l'article, cette méthode a permis à l'IA de mieux cuisiner (générer du code) que les méthodes précédentes. Elle a amélioré les taux de réussite de 11,52 % en moyenne sur différents types de tâches de codage et différents modèles d'IA. Essentiellement, TICoder transforme une IA confuse en un chef précis, bien planifié et expérimenté.

Résumé Technique : TICoder

Problématique

La génération de code au niveau du dépôt (repository-level) à l'aide de modèles de langage de grande taille (LLM) fait face à des défis importants en raison de la complexité des dépendances de code et de la limitation de la fenêtre de contexte. Bien que les approches existantes utilisent la génération augmentée par récupération (RAG) et des mécanismes de planification pour réutiliser les fonctions d'un dépôt, les auteurs identifient deux limitations critiques des méthodes de l'état de l'art (SOTA) actuelles :

Manque de guidage comportemental par les tests dans la planification : Les méthodes de planification existantes dérivent les étapes d'implémentation directement des exigences en langage naturel (NL). Cependant, les exigences en NL sont souvent vagues ou incomplètes, ce qui conduit à des plans peu fiables. Les méthodes actuelles de génération pilotées par les tests appliquent principalement les cas de test lors des phases de génération de code ou de post-génération, laissant inexploré leur potentiel pour guider le processus de planification.
Manque de conscience de l'implémentation au niveau du code lors de la réutilisation : Les stratégies de récupération existantes reposent fortement sur la similitude sémantique entre les étapes d'implémentation et les descriptions de fonctions. Elles négligent souvent la logique d'implémentation réelle ancrée dans le code. De plus, les fonctions récupérées sont fréquemment insérées dans les prompts sans comprendre comment elles sont réellement utilisées (modèles d'utilisation) au sein du dépôt, ce qui conduit à une réutilisation inefficace.

Méthodologie : Cadre TICoder

Les auteurs proposent TICoder, un cadre conçu pour améliorer les phases de planification et de réutilisation de la génération de code au niveau du dépôt. Le cadre se compose de trois étapes principales :

1. Planification itérative pilotée par les tests

Au lieu de générer des plans uniquement à partir d'exigences en NL, TICoder exploite les cas de test comme spécifications comportementales pour affiner les étapes d'implémentation. Cette étape utilise un mécanisme de « juge et de réflexion » impliquant deux rôles de LLM :

LLM-en-tant-que-Planificateur (LLM-as-a-Planner) : Génère une séquence initiale d'étapes d'implémentation basée sur l'exigence et les cas de test, guidée par des principes tels que la clarté, la conscience des conditions limites et les dépendances explicites.
LLM-en-tant-que-Juge (LLM-as-a-Judge) : Évalue les étapes générées selon trois dimensions : la couverture/cohérence fonctionnelle, l'indépendance et la granularité.
Affinement itératif : Si les étapes ne répondent pas aux seuils de qualité, le juge fournit un feedback et le planificateur affine les étapes. Cette boucle continue jusqu'à ce que le plan soit satisfaisant ou qu'une limite maximale d'itérations soit atteinte.

2. Réutilisation de code consciente de l'implémentation

Cette étape se concentre sur la récupération des fonctions appelées (callees) pertinentes et l'identification de la manière de les utiliser efficacement.

Récupération de fonctions appelées à double vue : Pour récupérer les fonctions, TICoder calcule un score de similitude conjoint combinant :
- Similitude Fonctionnelle ( $Sim_F$ ) : Similitude sémantique entre l'étape d'implémentation et la description de la fonction.
- Similitude d'Implémentation ( $Sim_I$ ) : Similitude entre une représentation de code de l'étape d'implémentation (générée par un LLM) et le code d'implémentation réel de la fonction.
- Le score final est une somme pondérée ( $Sim = \alpha \cdot Sim_F + \beta \cdot Sim_I$ ).
Sélection de modèles d'utilisation à deux étapes : Pour garantir que les fonctions sont utilisées correctement, TICoder sélectionne des modèles d'utilisation représentatifs du dépôt :
- Identification basée sur un graphe : Construit un graphe d'appels de dépôt (RCG) pour identifier toutes les fonctions appelantes pour une fonction appelée récupérée.
- Clustering basé sur la structure : Groupe les fonctions appelantes sur la base de l'ensemble des fonctions qu'elles invoquent (équivalence structurelle).
- Filtrage par perplexité : Au sein de chaque groupe, l'appelant le plus pertinent (plus faible perplexité) est sélectionné comme centre. Un filtre global classe ensuite ces centres par perplexité pour sélectionner les $n_p$ meilleurs modèles, équilibrant la richesse du contexte et l'efficacité des tokens.

3. Génération de code améliorée

La phase finale de génération de code intègre les étapes d'implémentation affinées, les fonctions appelées récupérées, les modèles d'utilisation sélectionnés, les cas de test et l'exigence originale dans un prompt unique pour que le LLM génère le code final.

Contributions clés

L'article revendique trois contributions primaires :

Cadre TICoder : Un nouveau cadre de génération de code au niveau du dépôt qui intègre la planification itérative pilotée par les tests et la réutilisation de code consciente de l'implémentation.
Stratégie de réutilisation consciente de l'implémentation : Un mécanisme de récupération à double vue (similitude fonctionnelle + d'implémentation) et une stratégie de sélection à deux étapes (clustering + filtrage par perplexité) pour identifier et réutiliser précisément les fonctions du dépôt.
Évaluation empirique approfondie : Des expériences complètes démontrant que TICoder surpasse les bases de référence SOTA à travers plusieurs LLM et benchmarks.

Résultats expérimentaux

Les auteurs ont évalué TICoder sur deux benchmarks largement utilisés, CoderEval (Python et Java) et DevEval (Python), en utilisant trois LLM de base : GPT-4o-mini, DeepSeek-V3 et Qwen2.5-Coder-7B.

Performance globale : TICoder a systématiquement surpassé toutes les bases de référence (incluant SimpleRAG, RepoCoder, AllianceCoder et RepoScope). Il a obtenu une amélioration moyenne de 11,52 % par rapport à la meilleure base de référence.
Signification statistique : Un test t bilatéral a confirmé que les gains de performance étaient statistiquement significatifs ( $p < 0,05$ ).
Étude d'ablation : La suppression de n'importe quel composant clé (planification, cas de test, affinement itératif, récupération à double vue ou modèles d'utilisation) a entraîné une dégradation des performances, validant la nécessité de chaque module.
- Notamment, la suppression du module de planification a causé une chute de 6,87 % du Pass@1.
- La suppression des cas de test lors de la phase de génération a causé une chute substantielle de 10,42 %.
Sensibilité aux hyperparamètres :
- Itérations : La performance s'est généralement améliorée avec les itérations mais de manière non monotone ; des itérations excessives pouvaient introduire du bruit.
- Poids de similitude : La similitude fonctionnelle était généralement plus importante, mais la similitude d'implémentation apportait des gains significatifs, particulièrement pour Java.
- Modèles d'utilisation : Un nombre modéré de modèles (par exemple, 2) a donné les meilleurs résultats ; trop peu de modèles limitaient le contexte, tandis que trop de modèles introduisaient du bruit.

Signification et Revendications

L'article affirme que TICoder répond aux limitations spécifiques des approches de planification RACG antérieures en incorporant explicitement les cas de test dans la phase de planification et en ancrant la récupération dans la logique réelle d'implémentation du code. Les auteurs soutiennent qu'en comblant le fossé entre les exigences en langage naturel et le code exécutable grâce aux spécifications comportementales (tests) et au contexte structurel (modèles d'utilisation), TICoder permet aux LLM de générer du code plus précis et contextuellement approprié dans des environnements de dépôts complexes. Le travail souligne qu'une génération réussie au niveau du dépôt nécessite non seulement de trouver du code similaire, mais aussi de comprendre comment ce code est spécifié de manière comportementale et intégré structurellement au sein du code source existant.