🤖 AI

Protocode: Prototype-Driven Interpretability for Code Generation in LLMs

Ce document propose une approche pilotée par des prototypes qui utilise une analyse basée sur l'AST pour échantillonner automatiquement des démonstrations de haute qualité pour l'apprentissage en contexte (In-Context Learning), améliorant ainsi simultanément l'interprétabilité et la performance des grands modèles de langage dans les tâches de génération de code.

Auteurs originaux : Krishna Vamshi Bodla, Haizhao Yang

Publié 2026-01-22

📖 6 min de lecture🧠 Analyse approfondie

CC0 1.0

Auteurs originaux : Krishna Vamshi Bodla, Haizhao Yang

Article original placé dans le domaine public sous CC0 1.0 (http://creativecommons.org/publicdomain/zero/1.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 d'enseigner à un robot très intelligent, mais légèrement confus, comment écrire du code informatique. Vous ne pouvez pas simplement lui donner un manuel ; au lieu de cela, vous lui montrez d'abord quelques exemples de bon code. C'est ce qu'on appelle l'Apprentissage en Contexte (In-Context Learning - ICL). Le robot observe vos exemples et tente de copier le style et la logique pour résoudre un nouveau problème.

Le problème est le suivant : Quels exemples devriez-vous montrer au robot ?

Si vous montrez de mauvais exemples au robot, il sera confus et écrira un code buggé. Si vous lui montrez des exemples parfaits, il excellera. Mais trouver les « exemples parfaits » est difficile. La plupart des gens choisissent simplement des exemples qui se ressemblent en surface, mais cela ne fonctionne pas toujours.

Ce document présente une nouvelle méthode appelée Protocode pour résoudre cela. Voyez cela comme un « Sélecteur d'Exemples Intelligent » qui utilise une carte spéciale pour trouver les meilleurs exemples.

Voici comment cela fonctionne, décomposé en concepts simples :

1. La Carte « Manifold » (Trouver la forme des données)

Imaginez que tous les différents problèmes de programmation (comme « trier une liste » ou « calculer une racine carrée ») sont des points flottant dans une immense pièce multidimensionnelle.

L'ancienne méthode : Les gens choisissent généralement le point le plus proche de celui qu'ils essaient de résoudre. Mais parfois, le point le plus proche est un exemple « piège » qui semble similaire mais possède une logique totalement différente.
La méthode Protocode : Les auteurs ont réalisé que ces points ne sont pas simplement dispersés au hasard ; ils forment des formes invisibles et courbes (comme une feuille de papier froissée) appelées manifolds (variétés).
L'analogie : Imaginez que les données soient une chaîne de montagnes. L'ancienne méthode choisit simplement le sommet le plus proche. Protocode examine la forme de la chaîne de montagnes elle-même. Il trouve les « prototypes » — les exemples les plus représentatifs, les plus parfaits, qui se situent précisément au cœur d'une vallée ou d'un sommet spécifique. Il utilise une technique appelée Apprentissage de Manifold Pièce par Pièce (Piecewise-Linear Manifold Learning) pour tracer ces formes avec précision, garantissant que l'exemple choisi est véritablement représentatif de ce type de problème, et non un simple voisin aléatoire.

2. L'Ancre « Proxy » (L'Aimant)

Une fois la carte tracée, le système doit choisir le meilleur exemple pour chaque catégorie (comme « boucles Python » ou « classes Java »).

L'analogie : Imaginez que vous avez un aimant (appelé Proxy) pour chaque type de code. Vous jetez tous vos exemples d'entraînement dans la pièce. L'aimant attire les exemples qui lui appartiennent.
La magie : Le système ne se contente pas de choisir le plus proche ; il apprend à déplacer les aimants pour qu'ils attirent les meilleurs exemples et repoussent les mauvais. Cela se fait grâce à une astuce mathématique appelée Perte de Proxy-Anchor (Proxy-Anchor Loss). Cela garantit que l'exemple choisi est un « champion » pour son groupe, faisant de lui l'enseignant le plus fiable pour le robot.

3. La Vision « Rayons X » (Analyse AST)

Une fois que le robot a écrit du code en utilisant ces exemples intelligents, comment savoir pourquoi il a écrit ce qu'il a écrit ?

Le problème : Généralement, le code de l'IA est une « boîte noire ». Nous voyons l'entrée et la sortie, mais nous ne savons pas quelle partie de l'exemple a influencé le robot pour qu'il écrive une ligne spécifique.
La solution : Les auteurs utilisent un outil appelé Arbre de Syntaxe Abstraite (AST - Abstract Syntax Tree). Voyez le code non pas comme une phrase, mais comme un arbre généalogique.
- Les « feuilles » sont les mots individuels (tokens).
- Les « branches » sont les structures (comme les instructions if, les boucles ou les fonctions).
L'analogie : Les auteurs projettent des rayons X sur le code. Ils tracent l'« influence » en remontant de la sortie du robot vers l'exemple spécifique qui l'a influencé.
- Résultat : Ils peuvent dire : « Le robot a utilisé cette structure de boucle for spécifique parce qu'il a été fortement influencé par l'Exemple A, mais il a utilisé ce bloc de gestion d'erreurs parce qu'il a été influencé par l'Exemple B. »
- Cela rend le code interprétable. Vous pouvez voir exactement quelle partie du code est « sûre » et quelle partie pourrait être risquée parce qu'elle a été copiée d'un exemple plus faible.

Qu'ont-ils découvert ?

Les chercheurs ont testé cela sur plusieurs modèles d'IA différents (comme Qwen, Llama et StarCoder) en utilisant un test de code standard appelé MBPP.

De meilleurs résultats : Lorsqu'ils ont utilisé leur « Sélecteur d'Exemples Intelligent » (Protocode), les robots ont écrit un meilleur code. Ils ont réussi plus de tests (spécifiquement la métrique pass@10, qui vérifie si le code correct apparaît parmi les 10 meilleures propositions) par rapport à l'utilisation d'exemples aléatoires ou de simplement choisir les « plus proches ».
Le danger des mauvais exemples : Ils ont découvert que si vous choisissiez les mauvais exemples (des démonstrations ICL mal choisies), le robot performait en réalité moins bien que si vous ne lui aviez donné aucun exemple du tout. Cela prouve que la qualité importe plus que la quantité.
Compréhension du code : L'analyse par « rayons X » a montré que le robot était le plus confiant dans les parties structurées du code (comme les structures de données et les fonctions), mais qu'il peinait parfois avec la gestion complexe des erreurs, quel que soient les exemples utilisés.

L'essentiel

Ce document traite de la manière d'apprendre à l'IA à devenir un meilleur élève en lui donnant de meilleurs exemples de devoirs.

Ne vous contentez pas de choisir des exemples similaires ; choisissez ceux qui représentent véritablement la « forme » du problème.
Utilisez les mathématiques pour trouver les exemples « champions » de chaque catégorie.
Regardez sous le capot pour voir exactement quels exemples ont influencé les décisions de l'IA, rendant le code plus sûr et plus facile à comprendre.

En faisant cela, les développeurs peuvent accorder plus de confiance à l'IA, sachant exactement pourquoi elle a généré un morceau de code spécifique et s'assurant qu'elle n'a pas simplement copié une mauvaise habitude provenant d'un mauvais exemple.

Résumé technique : Interprétabilité pilotée par des prototypes pour la génération de code dans les LLM

Problématique

Bien que les grands modèles de langage (LLM) aient considérablement fait progresser les capacités de génération de code, leur dépendance aux solutions automatisées introduit des risques de code sous-optimal ou peu sécurisé. Un fossé critique existe dans l'interprétabilité de ces modèles, spécifiquement pour les tâches de génération de code. Les méthodes d'interprétabilité existantes sont souvent génériques ou trop coûteuses en termes de calcul lorsqu'elles sont appliquées au code. Par exemple, des méthodes comme ASTrust nécessitent de stocker les distributions de probabilité sur l'ensemble du vocabulaire à chaque étape de génération, ce qui entraîne une faible scalabilité avec la longueur de la sortie. Inversement, des méthodes comme Code-Q nécessitent un échantillonnage répété, introduisant un surcoût d'inférence significatif. De plus, la sélection des démonstrations d'apprentissage en contexte (ICL) est connue pour impacter de manière critique la performance du modèle ; des exemples mal choisis peuvent dégrader la performance en dessous de celle du modèle de base, pourtant des stratégies d'échantillonnage efficaces et fondées sur des principes restent peu explorées.

Méthodologie

Les auteurs proposent Protocode, un cadre qui unifie l'échantillonnage ICL piloté par des prototypes avec une attribution ancrée dans l'arbre de syntaxe abstraite (AST) afin d'améliorer à la fois la performance du modèle et l'interprétabilité. La méthodologie se compose de deux étapes principales :

1. Échantillonnage de prototypes via l'apprentissage conjoint de variétés et de métriques

Au lieu d'utiliser des résumés statistiques (par exemple, les moyennes de classe) qui échouent à capturer la géométrie intrinsèque des données, les auteurs adoptent une perspective de variété (manifold). Ils supposent que les représentations de haute dimension résident sur des variétés de faible dimension.

Construction de la variété : La méthode emploie un apprentissage de variété par morceaux linéaires. Elle décompose les variétés non linéaires en régions localement linéaires en construisant des sous-variétés linéaires de dimension $m$ autour de points ancres. Cela est réalisé en ajoutant de manière itérative des voisins les plus proches et en vérifiant la qualité de la reconstruction via l'analyse en composantes principales (PCA).
Apprentissage de métrique : Pour garantir que les prototypes soient discriminants entre les classes, les auteurs intègrent la perte Proxy-Anchor. Cela introduit des vecteurs proxys apprenables au niveau de la classe pour optimiser la cohésion intra-classe et la séparation inter-classe.
Optimisation conjointe : Un réseau neuronal $h_\theta$ est entraîné pour optimiser conjointement l'objectif d'apprentissage de variété (préservant la structure géométrique locale) et la perte Proxy-Anchor (imposant la séparation des classes). Après l'entraînement, les vecteurs proxys mis à jour par impulsion (momentum) sont projetés sur leurs instances d'entraînement les plus proches pour servir de démonstrations ICL (prototypes) finales.

2. Attribution par gradient de prototype pour une interprétabilité ancrée dans l'AST

Pour remédier à la surcharge de mémoire des méthodes basées sur la probabilité des tokens, les auteurs proposent un mécanisme d'attribution qui évite de stocker l'intégralité des distributions du vocabulaire.

Mécanisme d'attribution : L'influence est estimée à l'aide du gradient de la similitude entre les plongements (embeddings) des prototypes échantillonnés et les plongements des tokens du code généré. Plus précisément, le produit scalaire entre le vecteur moyen du prototype et la représentation latente d'un token est calculé, et son gradient par rapport au plongement du token sert de score de confiance.
Analyse AST : Ces scores de confiance par token sont propagés à travers l'arbre de syntaxe abstraite (AST). Le processus aligne les tokens sur les nœuds terminaux de l'AST, qui sont ensuite agrégés hiérarchiquement en nœuds non terminaux, puis regroupés en huit Catégories de Syntaxe interprétables par l'humain (ex: Décisions, Structures de données, Itérations, Gestion des exceptions). Cela permet une interprétabilité tant locale (au niveau du nœud) que globale (au niveau de la catégorie).

Contributions clés

Cadre unifié : L'article affirme être le premier à unifier l'échantillonnage ICL piloté par des prototypes avec l'attribution ancrée dans l'AST pour l'interprétabilité du code.
Stratégie d'échantillonnage efficace : L'approche proposée d'apprentissage conjoint de variété et de métrique échantillonne des démonstrations ICL qui sont à la fois fidèles géométriquement à la structure locale des données et sémantiquement discriminantes, évitant ainsi les coûts de calcul de l'échantillonnage répété ou du stockage complet des probabilités du vocabulaire.
Attribution économisant la mémoire : En utilisant l'attribution par gradient de prototype plutôt que les probabilités de tokens, la méthode permet une cartographie de confiance sensible à la syntaxe sans la surcharge de mémoire qui croît mal avec la longueur de la sortie.
Explications ancrées dans la syntaxe : Le cadre fournit un système d'explication post-hoc qui segmente le code généré en régions syntaxiques interprétables, identifiant quelles parties du code sont le plus influencées par les démonstrations sélectionnées.

Résultats expérimentaux

Les auteurs ont évalué leur méthode sur les ensembles de test MBPP et MBPP+ en utilisant six LLM, incluant des modèles génériques (Qwen3, Llama3.2, Falcon3) et des modèles spécialisés dans le code (Starcoder, Qwen2.5-Coder, CodeLlama).

Performance : La méthode d'échantillonnage basée sur les prototypes a systématiquement surpassé le modèle de base (sans ICL) et les autres stratégies d'échantillonnage (basées sur la diversité, la similitude et le few-shot MBPP) sur la plupart des modèles sur la métrique pass@10. Par exemple, sur le jeu de données MBPP, la méthode proposée a atteint un pass@10 de 0,122 pour CodeLlama-7B, contre 0,116 pour le modèle de base.
Sensibilité aux démonstrations : Les résultats ont souligné que les modèles de génération de code sont très sensibles à la qualité des démonstrations ICL. Des démonstrations mal choisies (par exemple, issues d'un échantillonnage basé sur la similitude ou la diversité dans certains contextes) ont impacté négativement la performance, produisant parfois des résultats inférieurs au modèle de base.
Insights de l'analyse AST : L'analyse a révélé des schémas de fiabilité distincts selon les catégories de syntaxe. Les modèles affichent généralement une confiance élevée dans la Portée (Scope), les Structures de données et les Fonctions. À l'inverse, la Gestion des exceptions a systématiquement reçu les scores de confiance les plus bas sur tous les modèles, suggérant une limitation systémique dans la génération d'une logique robuste de gestion d'erreurs.

Signification et affirmations

L'article souligne que les stratégies d'échantillonnage efficaces pour l'ICL ne sont pas simplement optionnelles mais critiques pour la performance du modèle. Les auteurs affirment que leur approche démontre que des prototypes de haute qualité, géométriquement fidèles, font plus que simplement améliorer la précision ; ils améliorent également l'interprétabilité du processus de génération. En liant des régions syntaxiques spécifiques du code aux prototypes échantillonnés, les développeurs peuvent mieux comprendre le « pourquoi » derrière la sortie d'un modèle.

Les auteurs restent modestes quant à la portée de leur travail, notant que les prototypes ont été échantillonnés exclusivement à partir du jeu de données Magicoder-OSS-Instruct. Ils suggèrent que, bien que leur méthode serve de métrique globale pour classer la qualité des jeux de données concernant l'efficacité des prototypes, des travaux futurs pourraient étendre cela à des ensembles de données plus larges. De plus, ils proposent que le cadre puisse être étendu vers une « interprétabilité pré-hoc » par conception, en utilisant potentiellement le pilotage par prototype pour influencer le comportement du modèle, bien que cela reste une direction future plutôt qu'une implémentation actuelle.