Résumé technique : Compilation des flux de travail agentiques dans les poids des LLM

Énoncé du problème

Les frameworks d'orchestration d'agents (par exemple, LangGraph, CrewAI, OpenAI Agents SDK) se sont multipliés, dépassant collectivement les 290 000 étoiles sur GitHub. Ces systèmes reposent sur un orchestrateur externe situé au-dessus du modèle de langage de grande taille (LLM), injectant des instructions et prenant des décisions de routage à chaque étape. Bien que des travaux récents suggèrent que, pour les tâches procédurales, fournir simplement l'intégralité de la procédure dans l'invite système d'un modèle de pointe (prompting en contexte) surpasse l'orchestration, cette approche souffre de trois limitations critiques :

1. Coût : Elle nécessite un modèle de pointe pour chaque conversation et gonfle la consommation de tokens en intégrant la procédure dans chaque appel API.
2. Fenêtre de contexte : Elle consomme une capacité significative de la fenêtre de contexte.
3. Confidentialité : Elle expose les procédures propriétaires à des fournisseurs tiers.

L'alternative — compiler la procédure dans les poids d'un petit modèle affiné (créant un « agent souterrain ») — a été explorée dans des travaux académiques antérieurs (par exemple, SimpleTOD, FireAct, SynTOD) mais a connu une faible adoption par les développeurs. Cet article identifie trois barrières perçues à l'adoption : Qualité (un petit modèle peut-il égaler un modèle de pointe ?), Coût (l'hébergement autonome est-il réellement moins cher ?) et Flexibilité (le réentraînement est-il prohibitivement lent ?).

Méthodologie

Les auteurs proposent une architecture « souterraine » où l'orchestrateur est utilisé uniquement lors de la génération des données d'entraînement, et non à l'exécution. Le pipeline comprend :

1. Définition de la procédure : Représentation des flux de travail sous forme de graphes orientés ($F = (N, E, n_0, T)$) avec des nœuds (tours agent/utilisateur) et des arêtes (transitions).
2. Génération de données synthétiques : Parcours de tous les chemins valides à travers le diagramme de flux pour générer des conversations synthétiques à l'aide d'un modèle de pointe (Claude Sonnet 4.5). Le modèle génère un dialogue tour par tour basé sur des modèles d'invite de nœud et l'historique complet de la conversation.
3. Affinement complet des paramètres : Affinement de petits modèles (3B et 8B paramètres) sur ces conversations synthétiques en utilisant des mises à jour complètes des paramètres (rejetant les méthodes à faible rang comme LoRA, que les travaux antérieurs des auteurs [Dennis et al., 2026b] ont jugées insuffisantes pour l'intériorisation procédurale).
4. Déploiement à l'exécution : Le modèle compilé s'exécute sans aucun orchestrateur externe, recevant uniquement une invite système minimale. La procédure est implicite dans les poids du modèle.

Configuration d'évaluation :
L'étude évalue trois domaines de complexité croissante :

• Réservation de voyages : 14 nœuds, 3 hubs de décision, 86 chemins uniques.
• Support Zoom : 14 nœuds, structure parallèle, nécessitant des connaissances spécifiques au produit (interface utilisateur, codes d'erreur).
• Réclamations d'assurance : 55 nœuds, 6 hubs de décision, 2 381 chemins uniques, testant l'évolutivité.

Lignes de base :

• Orchestrateur LangGraph : Utilise Claude Sonnet 4.5 avec un suivi d'état explicite basé sur le diagramme de flux (la ligne de base du modèle de pointe).
• Ligne de base en contexte : Claude Sonnet 4.5 avec le diagramme de flux sérialisé dans l'invite système.
• Orchestrateur même modèle : Un modèle 3B avec orchestration explicite (utilisé pour isoler l'effet de la compilation).

Métriques :
Les conversations sont notées (échelle 1–5) sur la réussite de la tâche, la précision de l'information, la cohérence, la gestion élégante et le naturel, en utilisant une approche de type « LLM comme juge » (Claude Sonnet 4.5 et GPT-4.1).

Résultats clés

1. Qualité

• Compilation vs Orchestration même modèle : Une comparaison contrôlée sur la tâche de voyage a montré qu'un modèle 3B compilé surpasse significativement un modèle 3B avec orchestration explicite sur quatre des cinq métriques (réussite de la tâche, cohérence, gestion élégante, naturel ; $p < 0.001$).
• Petit modèle vs Orchestrateur de pointe :
  • Voyage (3B) : Le modèle 3B compilé a égalé l'orchestrateur LangGraph sur la réussite de la tâche et la cohérence, mais a pris du retard sur la gestion élégante et le naturel (atteignant environ 82 % de la qualité en contexte).
  • Zoom et Assurance (8B) : Le passage à un modèle 8B a réduit l'écart. Le modèle 8B compilé a atteint 87–98 % de la qualité de la ligne de base en contexte de pointe. Sur les réclamations d'assurance, il a surpassé l'orchestrateur LangGraph (construit sur un modèle environ 70 fois plus grand) en gestion élégante et en naturel.
• Taux d'échec : Les modèles compilés ont présenté des taux d'échec inférieurs à ceux de l'orchestrateur LangGraph dans les voyages (5,5 % contre 24 %) et l'assurance (9 % contre 17 %), principalement parce qu'ils éliminent les erreurs de routage inhérentes à l'orchestration au niveau des nœuds.

2. Coût

Les modèles compilés sont 128 à 462 fois moins chers par conversation que la ligne de base en contexte.

• Réduction par token : L'hébergement autonome d'un modèle 8B sur du matériel standard (A100) est environ 65 fois moins cher par token que les tarifs API de pointe.
• Réduction du volume de tokens : La ligne de base en contexte doit inclure la procédure complète dans chaque invite (surcoût passant de 2 à 7 fois avec la complexité). L'invite du modèle compilé est de taille constante.
• Seuil de rentabilité : Le coût unique de compilation (~50–80 $) est récupéré dans les 500 premières conversations.

3. Flexibilité

Le cycle de recompilation (génération de données, affinement, évaluation) prend 30 à 50 minutes sur du matériel de production (8× H200) ou 3 à 4 heures sur un seul A100. Cela est comparable à un cycle de construction CI/CD standard, réfutant l'hypothèse selon laquelle le réentraînement est un effort prohibitivement long et transformateur de paradigme.

Importance et revendications

L'article soutient que les barrières perçues à la compilation des flux de travail agentiques sont plus faibles que généralement supposé :

• Écart de qualité : L'écart entre un modèle 8B compilé et une ligne de base en contexte de pointe est faible (87–98 %), et le modèle compilé dépasse souvent un modèle de pointe orchestré via LangGraph.
• Écart de coût : L'avantage en coût est de deux ordres de grandeur et augmente avec la complexité de la procédure, car la taille de l'invite du modèle compilé reste constante tandis que l'invite en contexte s'allonge.
• Écart de flexibilité : L'adaptation est un cycle de déploiement (CI/CD), et non un goulot d'étranglement de réentraînement.

Les auteurs concluent que pour les connaissances procédurales nécessitant une persistance au-delà du contexte d'une seule conversation, « la structure persistante appartient aux poids, l'état transitoire appartient à l'invite ». La compilation est présentée comme la solution naturelle pour les tâches procédurales, offrant une qualité proche de celle des modèles de pointe à une fraction du coût et de la latence, tout en évitant les modes de défaillance structurels de l'orchestration externe (raisonnement fragmenté, erreurs de routage et style conversationnel contraint).