Résumé Technique : Diagnostiquer les lacunes de connaissances dans l'utilisation d'outils par les LLM

Énoncé du Problème

Les modèles de langage de grande taille (LLM) pour le code fonctionnent de plus en plus comme des agents qui doivent invoquer des bibliothèques logicielles et des API pour résoudre des tâches complexes. Un défi critique surgit lorsque ces agents sont confrontés à des API nouvelles — des fonctions ou interfaces absentes de leurs données de pré-entraînement en raison de mises à jour de versions de bibliothèques, de changements de rupture ou de nouveaux packages émergents. L'utilisation réussie de ces API requiert plus que le simple rappel d'un nom de fonction ; elle exige la coordination de types de connaissances hétérogènes :

• Déclaratives : Signatures, types de paramètres et chemins de modules.
• Procédurales : Composition correcte au sein de flux de travail et résolution d'importation.
• Ancrées (Grounded) : Exemples d'exécution concrets et détails d'implémentation.

L'infrastructure d'évaluation existante pour l'acquisition d'API nouvelles est fondamentalement limitée. Les benchmarks actuels sont souvent statiques (se dégradant rapidement à mesure que les modèles absorbent de nouvelles données), reposent sur des métriques agrégées grossières (ex: pass@k) qui occultent les causes profondes de l'échec, et synthétisent fréquemment des tâches artificielles qui ne reflètent pas l'évolution réelle des bibliothèques. Par conséquent, il reste mal compris quels composants de connaissances spécifiques sont appris par différents paradigmes d'adaptation (ex: Génération Augmentée par Récupération [RAG] vs Fine-Tuning) et quels composants manquants mènent à des modes de défaillance spécifiques.

Méthodologie : NOVELAPIBENCH

Pour répondre à ces limitations, les auteurs introduisent NOVELAPIBENCH, un benchmark entièrement automatisé, dynamique et basé sur l'exécution, conçu pour diagnostiquer les lacunes de connaissances des LLM de code. Le cadre fonctionne via un pipeline en quatre étapes :

1. Découverte d'API Nouvelles : Étant donné une bibliothèque cible $L$ et un modèle de base $M$, le système identifie les API introduites dans les versions de la bibliothèque publiées après la date de coupure de connaissances de $M$. Il compare les surfaces d'API publiques entre la version pré-coupure ($v_{old}$) et la version post-coupure ($v_{new}$) par introspection et analyse AST, en filtrant les entrées privées, obsolètes ou sans source.
2. Extraction de Connaissances : Pour chaque API nouvelle, le système décompose la connaissance en quatre composants distincts :
   • $S$ (Surface) : Noms entièrement qualifiés et signatures de paramètres (types, valeurs par défaut, descriptions).
   • $E$ (Exemplaires) : Exemples d'utilisation canoniques extraits de la documentation et de GitHub, validés dans un bac à sable (sandbox).
   • $M_{prose}$ (Prose de Mécanisme) : Descriptions en langage naturel de l'algorithme ou de la conception sous-jacente.
   • $M_{code}$ (Code de Mécanisme) : Code source d'implémentation extrait par AST.
3. Génération de Tâches : Le système génère des tâches de codage exécutables avec des bancs d'essai (test harnesses) à difficulté contrôlée. Crucialement, chaque banc inclut un espion d'API cible auto-injecté qui patche tous les alias de l'API cible. Cela garantit que la réussite du test nécessite un appel réel à l'API cible, empêchant les modèles de contourner la tâche via un mimétisme structurel.
4. Filtrage de Qualité et de Nouveauté : Les tâches sont filtrées pour s'assurer que la solution de référence est valide, que le modèle de base ne peut pas les résoudre sans aide (nouveauté empirique) et que la tâche est soluble avec le paquet de connaissances complet.

Taxonomie des Échecs :
Une contribution clé est une taxonomie automatisée des échecs qui classifie les erreurs d'exécution en six catégories mutuellement exclusives, liant des erreurs spécifiques à des connaissances manquantes :

1. WrongAPISelection (Mauvaise Sélection d'API) : L'API cible n'est jamais invoquée (hallucination ou utilisation d'un symbole frère).
2. WrongImport (Mauvaise Importation) : Symbole correct mais chemin d'importation erroné ou manquant.
3. WrongSyntax (Mauvaise Syntaxe) : Syntaxe Python invalide.
4. WrongParam (Mauvais Paramètre) : Appel correct mais arguments incorrects.
5. WrongShapeDtype (Mauvais Shape/Type) : Violation de contrat à l'intérieur du corps de l'API (ex: discordance de forme/shape).
6. WrongLogic (Mauvaise Logique) : La structure du programme environnant est incorrecte malgré un usage correct de l'API.

Contributions Clés

1. Benchmarking Dynamique : Un benchmark régénérable qui s'adapte à n'importe quel modèle de base et à toute l'évolution des bibliothèques, garantissant que les tâches restent véritablement nouvelles.
2. Diagnostic Granulaire : Une taxonomie automatisée des échecs qui connecte des erreurs d'exécution spécifiques à des composants de connaissances manquants à travers les paradigmes de récupération, de fine-tuning et d'édition de connaissances.
3. Étude Empirique Systématique : Une évaluation à grande échelle couvrant environ 800 API nouvelles à travers 5 domaines, 4 modèles de base et plusieurs méthodes d'adaptation (RAG, SFT, RAFT, GRACE, MEMIT, AlphaEdit).

Résultats Expérimentaux

1. Efficacité des Composants de Connaissance (RQ1)

• Les exemples d'utilisation ($E$) sont le composant autonome le plus fort : Fournir uniquement des exemples a augmenté le pass@1 de 3,1 % à 18,2 %, principalement en résolvant les erreurs de WrongAPISelection.
• Les signatures ($S$) constituent l'ancre la plus fiable : La cellule de surface ($S$) a atteint 21,7 % de pass@1, surpassant tous les composants isolés, en réduisant les erreurs de sélection d'API.
• La prose de mécanisme ($M_{prose}$) aide à la désambiguïsation sémantique : Lorsqu'elle est combinée aux signatures ($S+M_{prose}$), elle réduit davantage les erreurs de logique, mais a un impact minimal en tant que composant autonome.
• Le code source ($M_{code}$) introduit du bruit : L'ajout du code source d'implémentation a souvent dégradé les performances. Il a considérablement augmenté les erreurs de WrongImport, suggérant que le code source brut introduit un bruit de chemin de module qui confond les modèles plutôt que de résoudre les erreurs résiduelles.
• Configuration Optimale : Les meilleures configurations à deux composants associaient les signatures ($S$) avec soit la prose de mécanisme, soit les exemples, selon le domaine et le modèle de base. Les paquets complets ($S+E+M_{prose}+M_{code}$) ont souvent sous-performé en raison de l'interférence négative du code source.

2. Impact de la Tâche et du Modèle de Base (RQ2)

• Régularité des Tâches : Les exemples ($E$) étaient très efficaces pour les tâches régulières et modélisables (ex: fixtures de science des données) mais préjudiciables pour les tâches hétérogènes (ex: AI4Science) où les exemples divergeaient de l'exigence spécifique. La prose de mécanisme ($M_{prose}$) était plus stable à travers les types de tâches.
• Préférences des Modèles de Base : Le composant secondaire optimal dépendait de la force intrinsèque du modèle de base. Les modèles dont les signatures ($S$) étaient déjà fortes bénéficiaient davantage de la prose ; les modèles dépendant des exemples bénéficiaient de structures d'appel explicites.
• Modèles Orientés Raisonnement : Les modèles de base orientés raisonnement (ex: R1-Distill) étaient plus résistants au bruit d'importation introduit par le code source, probablement grâce à leur capacité à re-résoudre les identifiants plutôt qu'à copier les chemins.

3. Adaptation Paramétrique vs Récupération (RQ3)

• Non-internalisation des Faits Volatils : Aucun paradigme d'adaptation paramétrique (SFT, RAFT, GRACE, MEMIT, AlphaEdit) n'a pleinement internalisé la connaissance des API nouvelles. Lorsque le paquet de connaissances externes était retiré lors de l'inférence, les performances chutaient drastiquement (ex: SFT passait de 85,5 % à 3,3 %), échouant à combler l'écart avec les méthodes basées sur la récupération.
• Apprentissage de Métas-Compétences Procédurales : Le fine-tuning n'a pas mémorisé les détails de l'API (signatures, chemins) mais a plutôt appris une compétence procédurale transférable : comment utiliser efficacement les paquets de connaissances fournis.
  • SFT/RAFT/AlphaEdit ont considérablement réduit les erreurs de WrongAPISelection et WrongImport lorsqu'un paquet était présent, déplaçant les échecs vers WrongLogic.
  • Cette compétence de "valorisation du paquet" s'est transférée aux bibliothèques hors-distribution (OOD), mais pas la connaissance spécifique du chemin de module. Les modèles entraînés sur une bibliothèque pouvaient identifier l'API correcte dans une nouvelle bibliothèque, mais échouaient souvent à résoudre le chemin d'importation correct, entraînant un pic d'erreurs de WrongImport.

Signification et Revendications

L'article soutient que l'acquisition de contenu (identifier l'API et son contrat) et la réalisation procédurale (l'intégrer dans le code avec les bons imports et la bonne logique) sont des sous-compétences distinctes.

• La Récupération (Retrieval) est essentielle pour fournir des faits volatils et peu structurés (noms d'API, signatures, chemins) qu'il est difficile pour les modèles d'inférer ou de mémoriser.
• L'Ajustement Paramétrique (Fine-tuning) est efficace pour améliorer l'intégration procédurale de ces faits — apprendre au modèle comment utiliser correctement les preuves récupérées.

Les auteurs concluent que l'architecture optimale pour adapter les LLM de code aux nouvelles API n'est pas un choix entre RAG et fine-tuning, mais une combinaison : des unités de récupération compactes et à haute valeur (ex: signatures + prose de mécanisme) couplées à des adaptateurs entraînés sur des tâches d'utilisation d'API hétérogènes pour maîtriser l'intégration procédurale. Les méthodes actuelles de type "localiser et éditer" n'atteignent pas encore ce front pionnier. Le travail suggère que les progrès futurs pourraient nécessiter une supervision au niveau du processus (ex: apprentissage par renforcement ancré sur l'exécution) pour mieux combler le fossé entre l'identification d'une API et sa mise en œuvre correcte.