Graphes de tâches atomiques : planification du travail des agents en tant que graphes de dépendances
Comment le framework Atomic Task Graph décompose les tâches des agents en nœuds typés, simule des plans, et ne répare que les sous-graphes défaillants afin d’aider les petits modèles ouverts à concurrencer.
Sources: This New AI Framework Turned 7B Models Into GPT-4 Competitors (Without Any Training)
La plupart des tentatives visant à rendre les agents LLM plus fiables commencent par l’utilisation d’un modèle plus grand. Le cadre Atomic Task Graph (ATG), proposé par des chercheurs de l’Université Tsinghua et de l’Université de technologie du Sud de la Chine, part d’une autre approche : il modifie la manière dont l’agent organise son travail. Selon l’étude, des modèles open source de 7B et 8B intégrés dans ATG surpassent GPT-4 lorsqu’ils exécutent une boucle ReAct standard sur deux benchmarks d’agents bien connus, sans aucun ajustement fin, apprentissage par renforcement ou mise à jour des poids. Ci-dessous : pourquoi les chaînes de raisonnement linéaires échouent, comment ATG les remplace par un graphe de dépendances, et quels concepts vous pouvez emprunter pour vos propres agents.
Pourquoi les boucles linéaires des agents échouent sur des tâches longues
Prenons par exemple une demande telle que « produire un rapport de ventes pour 2024 avec des graphiques ». Un agent de type ReAct traite cela comme une longue séquence d’étapes, chacune dépendant de la précédente.
Step 1
↓
Find database
↓
Query data
↓
Analyze numbers
↓
Create graphs
↓
Write report
La chaîne fonctionne tant que chaque étape réussit. Les problèmes commencent lorsque l’une d’elles échoue. Si la requête à la base de données échoue, toutes les étapes suivantes s’appuient alors sur des données manquantes ou incorrectes.
Database query
↓
Everything after it becomes wrong
À ce stade, l’agent peut soit recommencer depuis le début, soit continuer avec les informations dont il dispose. Beaucoup choisissent la seconde option, ce qui est une source majeure d’hallucinations : le modèle invente des données plausibles pour combler les lacunes, et chaque décision ultérieure hérite de cette erreur.
Le contexte ne cesse de s’agrandir
Le deuxième problème concerne la manière dont ces agents conservent leur état. Après chaque action, la réflexion, l’appel à outil et l’observation sont tous ajoutés à un transcripte en perpétuelle expansion.
User
↓
Thought
↓
Action
↓
Observation
↓
Thought
↓
Action
↓
Observation
↓
Thought
↓
Action
Finalement, le modèle analyse des pages entières d’historique. Le contexte devient bruyant, et les erreurs initiales restent visibles, ce qui continue d’influencer les décisions ultérieures. Comme dans un jeu de téléphone, chaque étape déforme légèrement le plan jusqu’à ce qu’il s’éloigne de la réalité.
L’idée principale : un graphe plutôt qu’une chaîne
ATG remplace la séquence unique par un graphe de tâches. Chaque nœud représente une unité de travail, et chaque arête enregistre une dépendance entre deux unités.
Report
/ \
Analysis Charts
/ \
Database Statistics
La structure rend l’indépendance visible : les tâches non liées n’attendent plus, et une erreur dans une branche ne rend pas les tâches apparentées invalides.
Comment ATG construit et exécute le graphe
Le framework fonctionne en cinq étapes.
1. Décomposition récursive en tâches atomiques
Tout commence par la demande de l’utilisateur.
Create sales report
ATG divise cet objectif en sous-tâches.
Create sales report
↓
Load data
↓
Analyze sales
↓
Create charts
↓
Write summary
Il continue ensuite à diviser toute sous-tâche qui reste trop large, comme l’étape d’analyse.
Analyze sales
↓
Revenue
↓
Profit
↓
Growth
↓
Regional trends
La décomposition s’arrête lorsque chaque nœud feuille correspond à une seule invocation d’outil, par exemple :
SQL query
Python calculation
Matplotlib chart
Markdown writer
Ces nœuds feuille représentent les tâches atomiques : des unités suffisamment petites pour que leur division supplémentaire ne soit pas pertinente. La règle d’arrêt est importante : un nœud vague laisse trop de marge à l’improvisation, tandis qu’une seule requête SQL produit un résultat précis et vérifiable.
2. Entrées et sorties explicites pour chaque nœud
Chaque nœud dispose d’une interface, similaire à une signature de fonction. Au lieu d’une instruction telle que « effectuer l’analyse », le planificateur décrit ce que le nœud consomme et ce qu’il produit.
def analyze_sales(data):
return summary
Cette bribe est indicative, et non du code de framework, mais elle illustre le contrat. Comme le graphe ne dépend que de ce contrat, un nœud peut être réessayé ou remplacé par un autre outil sans que ses voisins ne s’en aperçoivent, ce qui est la même propriété qui rend le code modulaire facile à maintenir.
3. Exécution parallèle de branches indépendantes
Un agent séquentiel exécute les tâches une après l’autre, même lorsque certaines d’entre elles ne sont pas liées.
Task A
↓
Task B
↓
Task C
Si B et C n’ont besoin que du résultat de A et non l’un de l’autre, ATG peut l’exprimer directement.
Task A
/ \
Task B Task C
\ /
Task D
B et C peuvent alors s’exécuter en même temps, avec D qui attend les deux. L’étude montre des chemins d’exécution nettement plus courts dans tous les tests évalués, ce qui découle naturellement du regroupement des étapes indépendantes en étapes parallèles.
4. Une simulation avant d’utiliser des outils réels
Au préalable de toute exécution, ATG simule internement l’ensemble du plan, en demandant essentiellement au modèle si celui-ci fonctionnerait s’il était mis en œuvre tel qu’établi. La simulation cherche à détecter :
- des étapes manquantes
- le mauvais outil attribué à un nœud
- des dépendances incorrectes entre les nœuds
- des incohérences d’interface, où la sortie d’un nœud ne correspond pas à l’entrée du nœud suivant
- des chemins d’exécution qui ne peuvent pas être effectivement terminés
- des violations des contraintes de la tâche
C’est l’équivalent, pour l’agent, de l’exécution de tests avant déploiement, et c’est peu coûteux car aucun outil externe n’est sollicité. Cependant, la qualité de cette vérification dépend uniquement du modèle qui la met en œuvre : le modèle ayant rédigé le plan peut présenter des points aveugles, il faut donc le considérer comme un filtre et non comme une garantie.
5. Réparation ciblée du sous-graphe défectueux
Le aspect le plus distinctif réside dans la manière dont ATG gère les pannes en temps de exécution. Prenons un graphe simple :
Database
↓
Analysis
↓
Charts
↓
Report
Supposons que le nœud d’analyse échoue. Un agent conventionnel réagit souvent en abandonnant ses progrès et en recommençant.
Database
↓
Analysis
↓
Charts
↓
Report
↓
Start over
ATG, quant à lui, conserve le même graphe et bloque tous les nœuds qui ont déjà produit un résultat valide. Le diagramme ci-dessous est intentionnellement identique à l’original : la structure ne change pas, seul le nœud d’analyse est marqué pour être retravaillé, tandis que les nœuds de base de données, de graphique et de rapport restent tels quels.
Database
↓
Analysis
↓
Charts
↓
Report
Seul le sous-graphe défaillant est régénéré, et une fois qu’il fonctionne correctement, le graphe continue avec le nouveau résultat.
Database
↓
New Analysis
↓
Charts
↓
Report
Ceci correspond à une compilation incrémentale appliquée à la planification. Notez que si l’analyse corrigée produit des chiffres différents, les nœuds suivants qui en dépendent doivent malgré tout être exécutés à nouveau ; ce qui est épargné, ce sont les étapes précédentes et les branches non liées.
Pourquoi des contextes plus petits réduisent les hallucinations
Dans un cycle ReAct, chaque étape a accès à l’historique complet. Dans ATG, chaque nœud ne reçoit que les entrées déclarées par son interface, ce qui diminue le bruit et limite les risques que des erreurs antérieures s’infiltrent.
L’étude quantifie cela sur ALFWorld :
- Avec ReAct, 42,86 % des trajectoires contenaient des actions hallucinées
- Avec ATG, ce chiffre est tombé à 12,14 %
Cela représente une réduction relative d’environ 72 %, obtenue sans modifier le modèle de base.
Ce que montrent les benchmarks
L’évaluation a utilisé trois modèles ouverts :
- Mistral 7B
- Gemma 7B
- Llama 3 8B
et trois benchmarks d’agents :
- ALFWorld
- WebShop
- ScienceWorld
La comparaison principale oppose Llama 3 8B avec ATG à GPT-4 avec ReAct. Sur ALFWorld, la version de base GPT-4 a obtenu :
GPT-4 + ReAct
41.24
alors que le petit modèle avec ATG a obtenu :
Llama 3 8B + ATG
63.65
Sur WebShop, la version de base GPT-4 a atteint :
GPT-4 + ReAct
64.34
et Llama 3 8B avec ATG a atteint :
Llama 3 8B + ATG
68.36
Ces sont les chiffres rapportés dans l’article. Les résultats de GPT-4 concernent une version de base ReAct, donc cette comparaison montre dans quelle mesure la structure peut compenser la taille du modèle, et non que un modèle de 8B soit généralement plus performant que GPT-4.
Pourquoi cette idée résonne avec les ingénieurs logiciels
La stratégie par défaut du secteur a été d’augmenter les modèles, les clusters et les budgets. ATG se demande plutôt comment organiser le travail de manière plus efficace, ce qui relève davantage d’une question d’ingénierie logicielle que d’apprentissage automatique. Cela fait écho à Git, aux graphes de dépendances, aux systèmes de construction, aux planificateurs de tâches, à l’optimisation des compilateurs et aux systèmes distribués. La plupart des logiciels ont cessé d’être strictement séquentiels il y a longtemps ; les agents rattrapent ce retard.
Un exemple concret : créer un site web
Si l’on demande à un agent de créer un site web, un agent linéaire a tendance à produire un plan comme celui-ci :
Think
↓
Write HTML
↓
Write CSS
↓
Write JavaScript
↓
Debug
↓
Deploy
Un planificateur de type ATG produirait plutôt un arbre de composants indépendants :
Website
│
├── HTML
├── CSS
├── Images
├── API
└── Tests
Chaque branche peut être développée séparément. Si le CSS est endommagé, seul le nœud CSS est régénéré. Cela semble évident, pourtant la plupart des agents actuels ne fonctionnent pas de cette manière. Les patterns défensifs associés sont abordés dans une architecture contre l’accumulation d’hallucinations dans les graphes d’agents.
Lorsqu’un graphe de tâches n’est pas utile
La planification, la simulation et la tenue à jour des nœuds ajoutent une charge inutile. Pour des tâches nécessitant deux ou trois appels d’outils, une boucle ReAct simple est plus appropriée. Le graphe s’avère utile lorsque les tâches sont longues, partiellement indépendantes et coûteuses à relancer, et uniquement si le planificateur les décompose de manière judicieuse : un mauvais graphe exécuté efficacement reste un mauvais plan.
Points clés
- Les boucles linéaires permettent à une étape échouée de corrompre tout ce qui suit, et les enregistrements croissants amplifient les erreurs initiales.