Points Clés
- Efficacité des Tokens : La consommation chute de 884 000 à seulement 1 160 tokens par requête, avec une hausse de précision de 50 % sur les tâches complexes.
- Technologie : Framework SkillWeaver basé sur la Skill-Aware Decomposition (SAD), construit sur le modèle Qwen2.5 à 7 milliards de paramètres.
- Limite Opérationnelle : Le planificateur ne gère pas les erreurs runtime ; une défaillance API en milieu de chaîne bloque l'intégralité du processus d'exécution.
Le problème du bruit informationnel
Lorsqu'un modèle de langage doit orchestrer des milliers d'outils externes, la méthode brutale ne fonctionne pas. Déverser l'intégralité de la bibliothèque de fonctions disponibles dans un seul prompt génère une charge insoutenable : lors des tests en laboratoire, des pics de 884 000 tokens ont été atteints uniquement pour permettre à l'agent de "voir" les options à sa disposition. C'est un goulot d'étranglement que SkillWeaver promet d'éliminer radicalement, en faisant basculer l'approche du statique vers le dynamique.
La logique de la décomposition
Le cœur du système repose sur la Skill-Aware Decomposition. Plutôt que de tout charger, l'algorithme découpe la requête de l'utilisateur en un graphe d'exécution à nœuds. Pour chaque sous-objectif, il ne récupère que les outils réellement pertinents, en ignorant le bruit de fond. Le résultat du test, mené sur un benchmark propriétaire de 300 requêtes multi-étapes puisant dans 2 209 outils réels de l'écosystème MCP, est sans appel : consommation réduite à 1 160 tokens et un bond de précision de 50 %. Un constat technique important émerge : les modèles de grande taille, livrés à eux-mêmes sans guidage structurel tel que SAD, tendent à fragmenter les tâches en étapes microscopiques et superflues, dégradant la performance finale au lieu de l'améliorer.
Code fermé, templates ouverts
Développé dans les laboratoires de Shanghai, le projet n'a pas encore publié le code source complet. Toutefois, les templates de prompts utilisés sont déjà accessibles publiquement et s'avèrent reproductibles via des bibliothèques standards comme LangChain ou via des scripts Python personnalisés. Un vide structurel non négligeable subsiste cependant : la gestion des erreurs en runtime est absente du planificateur. Si un appel API échoue durant l'exécution d'une étape intermédiaire, l'ensemble de la chaîne logique s'interrompt sans protocole de récupération automatique.
