💬 NLP

Skill-as-Pseudocode: Refactoring Skill Libraries to Pseudocode for LLM Agents

L'article propose Skill-as-Pseudocode (SaP), une méthode automatique qui convertit des bibliothèques de compétences en markdown libre en pseudocode typé avec vérification déterministe, permettant aux agents LLM d'atteindre des taux de réussite nettement supérieurs et une réduction de l'utilisation des jetons sur le benchmark ALFWorld en fournissant des signatures typées claires et des modèles d'appel concrets.

Auteurs originaux : Xinze Li, Yuhang Zang, Yixin Cao, Aixin Sun

Publié 2026-05-28

📖 5 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Xinze Li, Yuhang Zang, Yixin Cao, Aixin Sun

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 enseigniez à un robot très intelligent mais littéral comment faire des tâches ménagères, comme nettoyer une maison ou organiser une cuisine. Vous donnez au robot un manuel d'instructions gigantesque et désordonné, écrit en anglais standard (Markdown).

Le Problème : La "Boucle Confuse"
Chaque fois que le robot doit faire quelque chose, il doit parcourir de longs paragraphes de texte pour déterminer deux choses :

Quel est le tâche (par exemple, « déplacer la tasse »).
Exactement comment le dire au système informatique de la maison (par exemple, le système n'accepte que la commande move mug to shelf, et non put mug on shelf).

Parce que les instructions sont enfouies dans des paragraphes, le robot fait souvent de mauvaises suppositions. Il essaie de « mettre » la tasse, la maison répond « Rien ne se passe », et le robot se confond. Il retourne alors lire le manuel, fait une mauvaise supposition à nouveau, et reste coincé dans une boucle d'échec. Cela gaspille du temps et épuise l'énergie du robot (ou les « tokens », en termes d'IA).

La Solution : "Compétence-comme-Pseudocode" (SaP)
Les auteurs de cet article ont créé un système appelé Compétence-comme-Pseudocode (SaP). Imaginez cela comme un « traducteur » qui prend le manuel humain désordonné et le réécrit en une triche propre et structurée pour le robot.

Voici comment le traducteur fonctionne, en utilisant une analogie simple :

1. Le Détective (Recherche de Motifs)

Imaginez un bibliothécaire qui parcourt des centaines de manuels d'instructions différents. Il remarque que de nombreux manuels disent la même chose de manières différentes.

Le Manuel A dit : « Allez à la cuisine, prenez le sel et mettez-le dans le placard. »
Le Manuel B dit : « Trouvez le sel sur le comptoir et déplacez-le vers l'armoire. »

Le bibliothécaire réalise qu'il s'agit en réalité de la même action sous-jacente. Il regroupe ces instructions similaires dans un « cluster ».

2. L'Architecte (Élaboration du Plan)

Pour chaque groupe d'instructions similaires, le système demande à une IA de rédiger un Contrat Typé.

Au lieu d'un paragraphe, ce contrat ressemble à une fonction informatique : move_object(from: "counter", to: "cabinet").
Il liste clairement : Quelles entrées sont nécessaires ? Que se passe-t-il ensuite ? Quelles sont les règles ?

3. L'Inspecteur de Sécurité (Les Quatre Vérifications)

Avant que le système ne permette au robot d'utiliser ce nouveau plan, un Inspecteur de Sécurité strict effectue quatre vérifications spécifiques pour s'assurer que la traduction est parfaite :

Couverture : Avons-nous manqué des détails importants du texte original ?
Liaison : Savons-nous exactement d'où obtenir le « sel » ou la « tasse » à partir de la phrase originale ?
Remplacement : Si nous remplaçons l'ancien paragraphe par ce nouveau plan, le reste du manuel conserve-t-il son sens ?
Risque : Cette nouvelle instruction indique-t-elle accidentellement au robot de faire quelque chose de dangereux (comme supprimer un fichier ou casser une fenêtre) ?

Si le plan passe les quatre vérifications, il est approuvé. S'il échoue même à une seule, il est jeté pour éviter que le robot ne se confonde.

4. La Livraison (Le "Paquet")

Lorsque le robot doit effectuer une tâche, il ne reçoit pas l'ancien manuel désordonné. Au lieu de cela, il reçoit un Paquet composé de trois parties, présentées dans le bon ordre :

Le Modèle "Comment-Faire" : Les mots exacts que le robot doit taper à l'ordinateur de la maison (par exemple, move {object} to {target}).
La Signature "Quoi" : Un résumé clair de ce que fait la compétence.
Le Contexte : Le reste des instructions, maintenant nettoyé pour qu'il ne contredise pas le nouveau modèle.

Les Résultats

Les chercheurs ont testé cela sur un jeu appelé ALFWorld, où un agent IA doit résoudre des énigmes ménagères.

Ancienne Méthode (Graphe de Compétences) : Le robot lisait le manuel désordonné, faisait de mauvaises suppositions, restait coincé dans des boucles et échouait souvent.
Nouvelle Méthode (SaP) : Le robot obtenait la « triche » propre. Il savait exactement quoi faire et comment le dire immédiatement.

Le Résultat :

Le robot a résolu 82 jeux sur 134 avec la nouvelle méthode, contre seulement 47 avec l'ancienne méthode.
Il a également utilisé 22 % de mémoire en moins et effectué 14 % d'appels en moins au cerveau de l'IA car il n'avait pas à relire le manuel encore et encore lorsqu'il restait coincé.

En Bref :
L'article montre que si vous cessez de donner aux agents IA de longs paragraphes désordonnés et leur donnez plutôt des instructions structurées et vérifiées « de type code », ils cessent de se confondre, cessent de faire des erreurs et accomplissent la tâche beaucoup plus rapidement. Le système agit comme un éditeur rigoureux qui transforme la prose humaine en plans prêts pour les robots.

Résumé Technique : Compétence-Comme-Pseudo-code (SaP)

Énoncé du Problème

Les agents modernes basés sur les LLM dépendent de bibliothèques de compétences — des collections de documents procéduraux (généralement en Markdown) que les agents récupèrent et suivent lors de l'exécution de tâches. Cependant, ces bibliothèques sont actuellement rédigées sous forme de prose libre. Cette représentation crée un goulot d'étranglement significatif : l'agent doit ré-déduire à chaque récupération à la fois le schéma d'entrée (ce que fait la compétence) et la syntaxe d'invocation concrète (comment l'appeler).

Les auteurs observent que ce format riche en prose induit une boucle « confus → ré-récupérer → toujours confus ». Lorsqu'un agent émet une action partiellement correcte basée sur une description en prose, l'environnement renvoie souvent un retour d'information non informatif (par exemple, « Rien ne se passe »). L'agent ré-récupère alors la même prose, échoue à extraire le détail manquant et répète le cycle. Cette boucle entraîne à la fois des échecs de tâches et une inflation des coûts d'appels LLM. Bien que des catalogues typés comme OpenAPI existent, ils ne constituent pas la surface de déploiement standard pour les compétences d'agents, qui restent en Markdown.

Méthodologie : Compétence-Comme-Pseudo-code (SaP)

Les auteurs proposent Skill-as-Pseudocode (SaP), un pipeline automatique qui convertit les bibliothèques de compétences Markdown en pseudo-code typé avec un contrôle de qualité déterministe. L'idée centrale est que deux signaux spécifiques court-circuitent la boucle récupération-action :

Un Contrat Typé : Une signature structurée exposant le déclencheur, les schémas d'entrée/sortie et les conditions pré/post.
Modèles d'Actions Concrètes : Les séquences exactes de tokens acceptées par l'environnement (par exemple, move {obj} to {target}), distinctes du contrat abstrait.

Le Pipeline

Le pipeline SaP traite une bibliothèque de compétences parentes (documents Markdown) en cinq étapes plus deux passes de post-vérification conscientes du LLM :

Analyseur (Parser) : Divise les documents Markdown en unités procédurales (sections sous des en-têtes).
Proposeur de Candidats : Regroupe les unités d'un ou plusieurs parents en clusters candidats basés sur des verbes, objets et liens de code partagés, en utilisant un clustering basé sur des embeddings.
Extracteur de Contrat (LLM) : Pour chaque cluster, un seul appel LLM rédige un contrat JSON typé strict ( $\kappa$ ).
Vérificateur (Déterministe) : Un vérificateur déterministe à quatre contrôles évalue le projet de contrat. Un contrat n'est promu que s'il passe :
- Couverture : Les chaînes de déclencheur et d'E/S du contrat doivent être présentes dans le texte de l'unité parente.
- Liaison : Chaque entrée requise dans le contrat doit avoir un segment correspondant dans le texte parent.
- Remplacement : L'unité parente doit être syntaxiquement remplaçable par un espace réservé invoke(κ, args) sans briser le flux de contrôle.
- Risque : Le contrat ne doit pas contenir d'effets secondaires dangereux (par exemple, rm -rf, égress réseau non déclaré).
Refaçonnage : Les contrats validés sont intégrés (inlinés) dans les compétences parentes.
- Extraction de Liaison (BE) : Une passe LLM qui vérifie si une unité spécifique est une véritable instance du contrat et extrait les liaisons d'arguments spécifiques. Les correspondances erronées sont écartées.
- Nettoyage de Réécriture (RC) : Une passe LLM qui détecte et réécrit les conflits de prose résiduels (par exemple, un bloc d'exemple utilisant un verbe comme put alors que l'environnement exige move) pour s'aligner sur le contrat vérifié.

Substitution au Moment de la Récupération

Au moment de l'inférence, l'agent récupère un groupe de compétences substitué plutôt que de la prose brute. Pour une compétence parente récupérée, le système remplace le contenu original par :

Modèles d'Actions : Séquences de commandes concrètes et exécutables avec les liaisons extraites (placées en premier).
Squelette Réécrit : La structure parente avec des espaces réservés invoke(κ, args).
Contrat Inliné : La signature typée et le schéma pour la compétence enfant invoquée.

Crucialement, le système emploie un pool de récupération hiérarchique uniquement. Les contrats enfants promus sont stockés en interne et ne sont accessibles que via l'espace réservé invoke du parent. Exposer les enfants comme résultats de niveau supérieur autonomes est évité, car cela prive l'agent du contexte nécessaire (les modèles d'actions du parent).

Contributions Clés

Recadrage de l'Amélioration des Compétences : L'article recadre l'optimisation des bibliothèques de compétences comme un problème de conversion prose-à-pseudo-code typé avec contrôle de qualité déterministe, complétant les travaux existants sur le routage typé qui supposent que les contrats existent déjà.
Le Pipeline SaP : Une architecture novatrice comportant un vérificateur déterministe à quatre contrôles et deux passes de post-vérification conscientes du LLM (BE et RC), chacune protégée par des contrôles post-déterministes pour garantir la sécurité et la cohérence.
Interface de Récupération Hiérarchique : Un mécanisme de récupération qui délivre un groupe structuré (contrat typé + modèle concret) par invocation, séparant le « quoi » (contrat) du « comment » (modèle).
Validation Empirique : Démonstration que SaP améliore simultanément les taux de réussite des tâches et réduit les coûts en tokens/appels LLM par rapport à la ligne de base Graph-of-Skills (GoS).

Résultats

Des expériences ont été menées sur le split non vu d'ALFWorld (134 jeux) utilisant gpt-4o-mini et un sous-ensemble de SkillsBench (10 tâches) utilisant gpt-5-codex.

Performance ALFWorld : Sur trois graines (402 jeux appariés), SaP a remporté 82/402 jeux contre 47/402 pour la ligne de base GoS. Cela représente une augmentation relative de la récompense de 74% (McNemar $p = 8.2 \times 10^{-5}$ ).
Gains d'Efficacité : SaP a atteint ces gains tout en réduisant les tokens d'entrée de 22,8%, les tokens de sortie de 17,3% et les appels LLM de 14,5% par jeu.
Analyse du Mécanisme : L'amélioration est attribuée à la rupture de la boucle « récupération-action ». Les agents SaP ont émis significativement moins d'erreurs « Rien ne se passe » et de demandes de ré-récupération. La justesse des actions post-récupération est passée de 20,5% (GoS) à 29,3% (SaP).
Ablation : Le retrait de la séparation hiérarchique (exposer les enfants comme résultats autonomes) a causé une chute de 27% de la récompense, confirmant la nécessité de la structure de groupe parent-enfant. Les passes BE et RC ont été montrées comme réparant des modes d'échec distincts (appartenance de cluster erronée et conflits de syntaxe, respectivement).

Signification et Revendications

L'article revendique que la représentation en prose elle-même, plutôt qu'un manque de factorisation, constitue le goulot d'étranglement dominant pour les agents LLM consommant des bibliothèques de compétences. En automatisant la conversion de la prose en pseudo-code typé avec vérification déterministe, SaP fournit aux agents un signal « quoi » (contrat) et « comment » (modèle) dans une seule réponse.

Les auteurs positionnent SaP comme une solution côté producteur au problème du routage typé. Alors que les travaux existants supposent que les contrats sont rédigés à la main, SaP les récupère à partir de la prose. La méthodologie est présentée comme une approche disciplinée où chaque extraction LLM est une hypothèse vérifiée par des règles déterministes, plutôt qu'une sortie boîte noire.

L'article note modestement que, bien que le pipeline soit architecturalement pris en charge pour les API typées (OpenAPI), l'évaluation empirique actuelle est limitée aux bibliothèques Markdown. De plus, le mécanisme de remplacement est statique (syntaxique) plutôt que dynamique (expansion à l'exécution), s'appuyant sur l'interface de récupération pour fournir les contrats enfants à la demande. Les résultats suggèrent que pour les bibliothèques de compétences statiques, le coût de la conversion prose-à-structure peut être payé au moment de l'indexation plutôt qu'à chaque récupération, améliorant considérablement l'efficacité et la fiabilité des agents.