Résumé technique : Décomposition de tâches structurée à l'exécution pour les systèmes de codage agentiques

Énoncé du problème

Les systèmes de codage agentiques actuels (par exemple, ceux construits sur AutoGen, LangGraph et Claude Code) reposent fréquemment sur des prompts monolithiques pour encoder la logique des tâches, le flux de contrôle et la génération de sorties. Bien que des cadres récents aient introduit des abstractions programmatiques pour l'orchestration, leurs stratégies de décomposition de tâches sont généralement statiques, ce qui signifie que la structure de la tâche est fixée au moment de la conception.

Cette approche architecturale entraîne trois défis principaux en ingénierie de production :

1. Comportement fragile : Les systèmes peinent à s'adapter lorsque les sorties intermédiaires sont invalides ou lorsque des conditions de branchement émergent à l'exécution.
2. Faible capacité de débogage : Les échecs sont difficiles à isoler au sein d'un seul contexte de prompt de grande taille.
3. Récupération coûteuse : Lorsqu'une étape échoue, le système nécessite souvent une réexécution complète du pipeline ou la réexécution de toutes les sous-tâches en aval, entraînant des coûts élevés en tokens et une latence accrue.

La question centrale abordée est de savoir si la décomposition de tâches seule réduit les coûts de récupération, ou si le branchement à l'exécution basé sur des signaux intermédiaires validés constitue le mécanisme nécessaire pour l'efficacité.

Méthodologie

Les auteurs proposent la Décomposition de tâches structurée à l'exécution (RSTD), un motif architectural qui externalise les décisions de partitionnement des tâches depuis le texte de prompt statique vers un flux de contrôle exécutable.

Architecture de base

Le système sépare l'orchestration, la gestion de l'état et l'inférence des LLM en trois couches distinctes :

1. Moteur de décomposition : Gère le partitionnement des tâches à l'exécution en utilisant une logique conditionnelle rédigée par le développeur. Les décisions de branchement sont résolues dynamiquement en fonction des signaux à l'exécution :
   • Résultats de la validation de schéma.
   • Contenu de la sortie (par exemple, résultats non vides ou seuils de confiance).
   • Statut d'achèvement des sous-tâches.
2. Opérateurs de jugement : Les appels LLM sont limités à des tâches de raisonnement uniques avec des exigences de sortie explicites et validées par schéma. Si la validation échoue, le système déclenche un prompt de réparation ciblé plutôt qu'une réexécution complète du pipeline.
3. Gestionnaire d'état : Persiste les résultats intermédiaires validés, indexés par l'identifiant de la sous-tâche. Les sous-tâches en aval accèdent à l'état précédent explicitement par clé, assurant un contexte limité par appel.

Configuration expérimentale

Les auteurs ont évalué la RSTD par rapport à deux lignes de base sur deux charges de travail d'ingénierie logicielle (10 exécutions chacune) :

• Monolithique : Toute la logique de tâche encodée dans un seul prompt.
• Décomposition statique : Le même graphe de sous-tâches que la RSTD, mais exécuté séquentiellement sans branchement à l'exécution (exécution fixe).
• RSTD : L'approche proposée avec branchement contrôlé à l'exécution et réessai sélectif.

Charges de travail :

1. Débogage de code multi-fichiers : Un pipeline Python avec trois bugs causalement ordonnés répartis sur deux fichiers.
2. Analyse de cause racine (RCA) Kubernetes : Diagnostic d'un événement OOMKill impliquant l'analyse de logs, la détection d'anomalies et la planification de la remédiation.

Métriques : Consommation de tokens (coût de réessai), latence et exactitude. Les taux d'échec naturels de validation de schéma étaient faibles (0–2 %), le « coût de réessai » a donc été mesuré dans le cadre d'un échec simulé (entrée amont structurellement malformée) pour isoler les coûts de récupération architecturaux.

Résultats clés

1. La décomposition statique ne garantit pas une réduction des coûts

Contrairement à l'hypothèse selon laquelle la décomposition des tâches est intrinsèquement plus efficace, la ligne de base de Décomposition statique a souvent augmenté les coûts de réessai par rapport à la ligne de base Monolithique.

• RCA Kubernetes : Le coût de réessai statique était de 1 632 ± 145 tokens, dépassant la ligne de base Monolithique (904 ± 17 tokens) de 80,5 %. Cela s'est produit parce que l'exécution séquentielle fixe a forcé la réexécution de toutes les sous-tâches en aval (3, 4 et 5) lors d'un échec de la sous-tâche 3.
• Débogage multi-fichiers : Le coût de réessai statique (933 tokens) était 32,7 % plus élevé que celui du Monolithique (703 tokens) en raison de la réexécution en cascade des tâches en aval.

2. La RSTD réalise des économies de récupération significatives

En réessayant uniquement la sous-tâche échouée tout en préservant l'état amont valide, la RSTD a considérablement réduit les coûts de récupération :

• RCA Kubernetes : Le coût de réessai RSTD est tombé à 436 ± 132 tokens, soit une réduction de 51,7 % par rapport au Monolithique et une réduction de 73,2 % par rapport à la Décomposition statique.
• Débogage multi-fichiers : Le coût de réessai RSTD était de 460 tokens, soit une réduction de 34,6 % par rapport au Monolithique.

3. Surcharge et exactitude

• Exactitude : Toutes les configurations ont atteint 100 % d'exactitude sur les 10 exécutions pour les deux charges de travail.
• Surcharge de base : La RSTD entraîne un coût de tokens de base plus élevé lors d'une exécution réussie (par exemple, 2 225 tokens contre 703 tokens pour le débogage) en raison de multiples appels API et de la surcharge du cadre.
• Latence : La surcharge du cadre représentait environ 18 % de la latence totale en temps réel. L'écart de latence entre les agents monolithiques et décomposés était principalement dû à des allers-retours API supplémentaires plutôt qu'à une inefficacité de l'orchestration.

Importance et revendications

L'article revendique que le branchement à l'exécution, et non la structure de décomposition seule, est le mécanisme principal pour réduire les coûts de récupération dans les systèmes agentiques.

• Distinction architecturale : La RSTD se distingue des cadres existants (DSPy, LangGraph, AutoGen) par l'externalisation du flux de contrôle. Contrairement aux assertions DSPy, qui optimisent les prompts au sein d'un module, la RSTD empêche les sorties malformées d'atteindre les sous-tâches en aval en verrouillant les transitions d'état.
• Implications opérationnelles :
  • Réessai sélectif : Permet une récupération rentable en isolant les échecs à des sous-tâches individuelles.
  • AgentOps ciblés : Les limites des sous-tâches fournissent des points d'instrumentation naturels pour la surveillance et le débogage.
  • Substitution de modèle : L'architecture permet d'assigner différents modèles à des sous-tâches spécifiques sans reconfigurer la couche d'orchestration.

Les auteurs concluent que, bien que la RSTD introduise une surcharge fixe pour les exécutions réussies, elle constitue le motif supérieur pour les scénarios de production où les taux d'échec sont non négligeables ou où les sous-tâches impliquent une réingestion coûteuse de contexte. L'étude met en évidence que la simple décomposition statique des tâches est insuffisante ; un flux de contrôle dynamique, verrouillé par validation, est nécessaire pour prévenir les coûts de réexécution en cascade.