AutoGen : Cadres de conversation multi-agents pour l'IA financière

Après que Gorilla a montré qu'un seul LLM peut apprendre à appeler des milliers d'API avec précision, la question naturelle est : que se passe-t-il lorsque vous donnez à plusieurs LLM des rôles distincts et les laissez communiquer entre eux ? AutoGen (Wu et al., 2023) répond à cette question en construisant un cadre pour la conversation multi-agents, et le lire aujourd'hui semble opportun — la plupart des systèmes d'IA financière en production que je vois conçus impliquent par défaut au moins trois agents.

L'article

AutoGen: Enabling Next-Gen LLM Applications via Multi-Agent Conversation (Wu, Bansal, Zhang et al., Microsoft Research, 2023) propose un cadre où des « agents conversables » — chacun soutenu par une combinaison d'un LLM, d'outils et d'une intervention humaine — s'envoient des messages jusqu'à ce qu'une tâche soit accomplie. Le cadre introduit deux types d'agents intégrés : AssistantAgent (piloté par un LLM) et UserProxyAgent (qui peut exécuter du code et relayer l'intervention humaine), plus un GroupChatManager qui gère les tours de parole dans les ensembles plus vastes.

L'idée centrale est ce que les auteurs appellent la « programmation de conversation » : au lieu d'écrire manuellement la logique d'orchestration dans le code, vous spécifiez ce que chaque agent doit faire via des instructions système en langage naturel et laissez le passage de messages gérer le flux de contrôle. L'article démontre cela à travers la résolution de problèmes mathématiques, le QA augmenté par récupération (RAG), la prise de décision ALFWorld et une application de recherche opérationnelle appelée OptiGuide.

Idées clés

• Gain de précision sur le benchmark MATH : une configuration AutoGen à deux agents (un assistant LLM plus un proxy d'exécution de code) atteint 69,48 % sur l'ensemble de test MATH, contre 55,18 % pour GPT-4 utilisé seul — un gain de 14 points grâce à l'ajout du retour d'exécution du code.
• L'humain dans la boucle est prioritaire : le UserProxyAgent possède un mode human_input_mode configurable — ALWAYS, NEVER ou TERMINATE — ce qui signifie que vous pouvez augmenter ou réduire la surveillance sans changer la logique de l'agent.
• Chat de groupe dynamique : le GroupChatManager sélectionne le prochain interlocuteur en fonction de l'état de la conversation plutôt que selon un ordre circulaire fixe, ce qui permet aux flux de travail de bifurquer en réponse aux résultats émergents.
• Gain de sécurité OptiGuide : l'ajout d'un agent SafeGuard à un flux d'optimisation de la chaîne d'approvisionnement a amélioré le score F1 de détection de code dangereux de 8 points de pourcentage sur GPT-4 et de 35 points sur GPT-3.5, tout en réduisant la base de code de l'utilisateur de 430 lignes à 100.
• Récupération interactive : dans les tâches de QA, l'agent assistant pouvait demander un contexte supplémentaire en émettant un signal UPDATE CONTEXT ; cela s'est produit dans environ 19,4 % des questions sur Natural Questions, et le score F1 global était de 23,40 %.
• Composabilité par conception : tout agent AutoGen est lui-même un « outil » valide qu'un autre agent peut appeler, de sorte que les pipelines hiérarchiques se composent sans code de liaison spécial.

Ce qui tient la route — et ce qui ne tient pas

Les résultats de MATH et ALFWorld sont solides — des comparaisons contrôlées et reproductibles par rapport à des références nommées avec de véritables benchmarks. Le chiffre de 69,48 % est significatif car il isole le bénéfice du retour d'exécution de code au sein d'une boucle de conversation structurée.

Ce qui est plus faible, c'est l'analyse du coût et de la latence, ou plutôt son absence. Chaque tour de GroupChat déclenche un appel LLM complet avec l'historique accumulé de la conversation. Un flux de travail à quatre agents avec dix rounds signifie au minimum quarante appels LLM, chacun avec une fenêtre de contexte croissante. L'article ne rapporte jamais le coût en jetons ni la latence pour aucune de ses applications. Dans un pipeline comptable en direct traitant des milliers de transactions, cette omission n'est pas académique — elle détermine si l'approche est viable ou non.

La métaphore de la programmation de conversation est également plus fragile qu'elle n'en a l'air dans les démos. Le GroupChatManager sélectionne le prochain intervenant en demandant au LLM de choisir parmi une liste d'agents. Cette sélection est elle-même une étape de génération de texte probabiliste, ce qui signifie que le flux de contrôle peut mal tourner de manières subtiles qui ne lèvent pas d'exceptions. Pour un agent d'écriture dans le grand livre — où l'ordre des opérations compte et où un appel d'outil mal placé pourrait corrompre une écriture de journal — la sélection non déterministe de l'intervenant est un réel risque.

Enfin, les tâches d'évaluation sont toutes des sessions uniques à court horizon. Il n'y a aucune expérience où les agents accumulent un état sur plusieurs jours, gèrent des instructions contradictoires ou doivent résoudre des conflits entre une ancienne mémoire d'agent et une nouvelle écriture au grand livre. Ce sont exactement les scénarios qui surviennent dans les flux de travail comptables réels.

Pourquoi cela est important pour l'IA financière

L'intérêt des systèmes multi-agents pour l'IA financière est évident : le rapprochement, l'imputation et le reporting sont naturellement des préoccupations distinctes. Un pipeline Beancount pourrait avoir un LedgerReaderAgent qui interroge le grand livre en lecture seule, un ReconcilerAgent qui compare les transactions aux relevés bancaires, un WriterAgent qui propose de nouvelles écritures, et un ReviewerAgent qui les vérifie par rapport aux règles du plan comptable avant qu'une écriture ne soit validée. Le modèle UserProxyAgent d'AutoGen est la bonne abstraction pour le WriterAgent — il peut exécuter l'écriture réelle dans le grand livre et renvoyer le résultat sous forme de message que le ReviewerAgent inspecte.

Le résultat du SafeGuard d'OptiGuide est la conclusion la plus directement transférable : l'ajout d'un agent de vérification dédié pour intercepter les actions dangereuses a considérablement amélioré la détection, et cette détection s'est produite à l'intérieur de la boucle de conversation plutôt que comme un audit post-hoc. C'est exactement l'architecture que je souhaiterais pour la sécurité des écritures Beancount — un vérificateur qui bloque la validation, et non un vérificateur qui alerte après coup.

Le problème de la sélection non déterministe de l'intervenant est soluble : vous pouvez surcharger le GroupChatManager avec une fonction Python déterministe qui route en fonction du contenu du message. Mais il faut savoir le faire, et l'article ne met pas cela en avant comme une préoccupation.

Que lire ensuite

• AgentBench: Evaluating LLMs as Agents (Liu et al., arXiv:2308.03688, ICLR 2024) — évalue les LLM dans huit environnements d'agents distincts, notamment la navigation Web, le codage et la manipulation de bases de données ; l'écart entre les modèles commerciaux et open-source est la conclusion clé et informe directement sur les modèles de base à utiliser pour les pipelines d'agents financiers.
• TradingAgents: Multi-Agents LLM Financial Trading Framework (arXiv:2412.20138) — instancie directement le modèle AutoGen pour les marchés financiers avec des agents spécialisés d'analyste, de chercheur, de trader et de gestionnaire de risques ; les résultats du ratio de Sharpe et du drawdown maximal donnent les premiers chiffres réels de performance pour les systèmes financiers multi-agents.
• AGENTLESS: Demystifying LLM-based Software Engineering Agents (Xia et al., arXiv:2407.01514) — soutient qu'une approche simple et sans agent en deux phases (localiser, puis réparer) surpasse les cadres multi-agents complexes sur SWE-bench ; un contrepoids utile à l'idée que multiplier les agents est toujours bénéfique.