Résumé technique : Attribution des gains de sortie structurée dans l'appel de fonctions

1. Énoncé du problème

Les interventions basées sur le prompting, en particulier l'injection de compétences dérivées de trajectoires, améliorent souvent les scores des modèles de langage (LLM) sur les benchmarks d'appel de fonctions comme le Berkeley Function Calling Leaderboard (BFCL) et API-Bank. Cependant, une augmentation brute du score ne permet pas de distinguer deux mécanismes distincts :

1. Transfert procédural : Le modèle a réellement appris une procédure réutilisable pour sélectionner les bons outils et arguments.
2. Alignement d'interface : Le modèle a simplement appris à se conformer au format de sortie spécifique (ex: clés de wrapper JSON, syntaxe de schéma) privilégié par l'évaluateur.

Les pratiques d'évaluation actuelles confondent souvent ces mécanismes. Un prompt de compétence peut améliorer les scores simplement en instruisant le modèle à utiliser une clé JSON spécifique (ex: "name" au lieu de "function") que le scoreur accepte, même si la sélection de l'outil sous-jacente reste inchangée ou se dégrade. Inversement, des appels sémantiquement corrects peuvent être pénalisés pour de mineures déviations de formatage. L'article soutient que sans attribuer les gains à leurs causes spécifiques, les affirmations de « compétence agentique transférable » sont injustifiées.

2. Méthodologie : Le protocole d'attribution à quatre couches

Les auteurs proposent un protocole rigoureux à quatre couches pour auditer les gains de compétences pré-ajoutés par prompt. Ce protocole va au-delà de la simple comparaison de scores pour isoler la source de l'amélioration.

Couche 1 : Rescoring canonisé

Les auteurs introduisent le rescoring canonisé pour séparer l'« aliasing de clés de wrapper » du changement réel de politique de tâche.

• Mécanisme : Le scoring standard de BFCL traite certaines clés JSON (ex: "name") comme correctes et d'autres (ex: "function", "function_name") comme des erreurs, même si les arguments sont identiques. Le protocole normalise ces clés vers une forme canonique avant d'évaluer l'exactitude de l'AST (Arbre de Syntaxe Abstraite).
• But : Déterminer si un gain est simplement le résultat du passage du modèle à l'alias de clé « correct » plutôt qu'à la sélection du bon outil.

Couche 2 : Contrôles de format uniquement

Cette couche teste si un contrat d'interface explicite peut reproduire les gains observés.

• Mécanisme : Les auteurs comparent les « Compétences Complètes » (contenant à la fois des instructions procédurales et des contraintes de format) aux prompts « Format-Seul » (contenant uniquement les instructions de schéma JSON/wrapper attendues, dépouillées de la logique de tâche).
• But : Si un prompt de format seul égale ou dépasse la performance d'un prompt de compétence complète, le gain est attribué à l'alignement d'interface, et non à l'apprentissage procédural.

Couche 3 : Induction réparée et équilibrée

Cette couche examine si les gains sont des artefacts du pipeline d'extraction (ex: sélection biaisée de démonstrations ou styles d'extracteurs spécifiques).

• Mécanisme :
  • Extraction Réparée : Les compétences sont ré-extraites en utilisant une autre famille de modèles (Qwen3-32B) et un pool équilibré de démonstrations à scores hauts/bas, plutôt que l'extraction originale via GPT-4o basée uniquement sur des scores élevés.
  • Induction Équilibrée : Le protocole teste si les gains persistent lorsque le pool de démonstrations est équilibré, supprimant le biais vers les exemples conformes au format.
• But : Déterminer si la « compétence » est robuste ou si les gains originaux étaient pilotés par des biais de démonstration spécifiques et non généralisables.

Couche 4 : Vérifications de portabilité

Cette couche teste la généralisabilité des gains à travers différents contextes.

• Mécanisme :
  • Trans-famille : Tester des compétences extraites d'une famille de modèles (ex: Qwen) sur d'autres (ex: Llama, Gemma).
  • Trans-benchmark : Tester sur API-Bank (utilisant la syntaxe entre crochets) et des benchmarks de raisonnement (MATH-500, MultiHop-RAG).
  • Contrôles Génériques : Comparer les compétences extraites à des prompts procéduraux génériques de longueur équivalente.
• But : Vérifier si les gains restants représentent une procédure transférable ou s'ils sont spécifiques au modèle source et au contrat.

3. Résultats clés

L'application de ce protocole à BFCL et API-Bank sur 8 modèles Qwen3 (0.6B–235B) et d'autres familles produit plusieurs conclusions contre-intuitives :

• L'alignement d'interface domine : Dans de nombreux cas, les prompts de format seul égalent ou dépassent les prompts de compétence complète. Par exemple, sur Qwen3-8B, un prompt de format seul a généré un gain de 21,3 points de pourcentage (pp), surpassant le gain de +11,3 pp de la compétence complète@235B. Cela suggère que la « compétence » enseignait principalement au modèle comment encapsuler la sortie, et non comment résoudre la tâche.
• La canonisation révèle la sensibilité : Le scoring standard montrait de grands gains et de grands préjudices. Après un rescoring canonisé, plusieurs cellules « nuisibles » sont devenues neutres, et les gains positifs ont considérablement diminué. Par exemple, le gain de la compétence@235B du modèle 14B est passé de -11,7 pp à -1,0 pp après canonisation, indiquant que le préjudice original était largement dû à la sensibilité de l'alias de clé.
• Sensibilité à l'induction : Les plus grands gains observés (ex: +17,7 pp pour 1.7B, +11,3 pp pour 8B) ont largement disparu ou se sont inversés lors de l'utilisation d'une induction réparée/équilibrée. Lorsque l'extraction était effectuée à partir d'un pool de démonstrations équilibré plutôt que de haute performance, les gains ont disparu, suggérant que les améliorations originales étaient pilotées par un biais de démonstration plutôt que par une extraction de compétence robuste.
• Les prompts génériques reproduisent les gains : Sur API-Bank, des prompts procéduraux génériques de longueur identique ont presque reproduit les gains des compétences extraites (à 0,5 pp près), indiquant davantage que la formulation spécifique de la « compétence » n'était pas le principal moteur de la performance.
• Échec de la trans-famille : Les compétences extraites de Qwen3 ont souvent échoué ou dégradé la performance lorsqu'elles étaient appliquées à des modèles Llama ou Gemma, alors que les indices de format seul fonctionnaient parfois mieux. Ce manque de portabilité mine les affirmations de transfert procédural universel.

4. Contributions

L'article apporte trois contributions principales :

1. Formulation : Il cadre l'attribution du gain de compétence en appel de fonctions comme un problème de rapport, distinguant les changements de politique de tâche de l'alignement d'interface dans les audits de sortie structurée.
2. Protocole : Il propose et instancie un protocole d'attribution à quatre couches (rescoring canonisé, contrôles de format seul, extraction robuste à l'induction et vérifications de portabilité) pour évaluer rigoureusement l'injection de compétences.
3. Résultats empiriques : Il démontre que dans les contextes de type BFCL/API-Bank, de nombreux gains apparents sont mieux attribués à l'alignement d'interface qu'à un transfert procédural robuste. Il publie BFCL-CANONICAL (un ensemble de données/métriques) et une recette de rapport pratique pour les affirmations futures.

5. Signification et affirmations

L'article ne prétend pas que la conformité au format est sans importance ; il soutient plutôt que la conformité au format est une capacité d'ingénierie distincte du raisonnement procédural.

• Clarification des métriques : Les auteurs affirment qu'un score de sortie structurée seul ne peut certifier qu'un modèle a appris une procédure transférable. Une amélioration de score peut simplement refléter que le modèle a appris à « parler la langue de l'évaluateur ».
• Standards de rapport : L'article recommande que les futures affirmations de « compétence transférable » doivent survivre au protocole à quatre couches. Si un gain disparaît sous la canonisation, les contrôles de format seul ou l'induction équilibrée, il doit être rapporté comme alignement d'interface ou adaptation au contrat de prompt, et non comme une compétence agentique réutilisable.
• Diagnostic constructif : Les conclusions sont présentées comme un diagnostic constructif pour le domaine. En séparant l'alignement d'interface du transfert procédural, les chercheurs peuvent mieux comprendre ce que leurs benchmarks mesurent réellement et éviter de surestimer les capacités des méthodes d'injection de compétences.

Les auteurs concluent que, bien que l'alignement d'interface soit précieux pour le déploiement, attribuer les gains au transfert procédural sans passer par ces vérifications rigoureuses constitue une erreur d'attribution. Le protocole préserve la valeur d'ingénierie de l'alignement de format tout en réservant la revendication plus forte de transfert procédural uniquement aux preuves résiduelles qui survivent à tous les contrôles.