Il est important d’examiner attentivement comment et où les décisions sont prises dans votre système agentique.
Déléguer davantage de décisions à un LLM permet au système de se généraliser potentiellement à davantage de tâches, mais au prix éventuel de la vitesse, de la fiabilité et de la robustesse.
Dans la mesure du possible, essayez d’extraire autant que possible le processus décisionnel du LLM pour l’intégrer explicitement au code logiciel. Cela vaut particulièrement pour les workflows à haut risque et/ou en production.
Lors de la conception d’un système agentique basé sur un LLM, l’un des choix les plus importants concerne la part du processus décisionnel confiée à un modèle LLM par rapport à celle intégrée explicitement au logiciel.
Pour mieux comprendre, nous pouvons considérer ce choix comme un spectre entre les approches suivantes :
Les architectures basées sur un routeur définissent explicitement l’ordre et la logique dans le code, ce qui garantit la testabilité, la prévisibilité et la robustesse pour les tâches relevant d’un domaine restreint (on les appelle aussi « agents de workflow »).
Les agents orchestrateurs s’appuient sur de grands modèles de langage (LLM) pour déterminer dynamiquement le déroulement des tâches à l’aide de prompts en langage naturel. Ils conviennent idéalement aux interactions ouvertes, pour lesquelles une logique prédéfinie est insuffisante ou impossible.
Pour les workflows de production à haut risque, nous recommandons généralement de privilégier les fonctionnalités basées sur un routeur et de réserver les orchestrateurs aux applications exigeant des conversations flexibles et polyvalentes.
Architectures basées sur un routeur
Les systèmes agentiques à routeur :
Définissent explicitement le flux décisionnel dans le code ou le logiciel et utilisent un LLM pour déterminer l’itinéraire suivi par ce logiciel.
Se rapprochent des systèmes logiciels traditionnels, car ils suivent des parcours clairs et prévisibles qui produisent des résultats plus cohérents.
Sont parfaitement adaptés aux tâches pouvant être définies de manière stricte.
Voici un exemple simplifié d’agent de réservation pour un chatbot de compagnie aérienne utilisant l’« approche par routeur ». Le LLM nous aide à classer l’intention de la question parmi trois choix possibles, mais c’est finalement notre logiciel qui associe cette intention à un modèle de réponse textuelle. Le LLM étant fortement contraint, l’utilisateur bénéficiera d’un comportement plus cohérent.
Architectures d’orchestration
Contrairement au système à routeur, les systèmes agentiques d’orchestration :
Définissent les flux logiques au moyen de prompts en langage naturel plutôt que dans le logiciel. Remarque : par rapport à un langage de programmation, le langage naturel est intrinsèquement ambigu et flexible, ce qui constitue à la fois un avantage et un inconvénient, comme nous le verrons plus loin. Nous considérons cela comme « une intention plutôt qu’une instruction ».
Peuvent proposer plusieurs options de traitement, le LLM déterminant l’ordre et la méthode d’exécution.
Peuvent créer dynamiquement de nouveaux parcours logiques difficiles à définir explicitement dans un logiciel.
Cette ambiguïté peut produire des résultats incohérents, mais, lorsqu’elle fonctionne, elle peut sembler « magique ».
L’exemple suivant applique une approche d’orchestration au même problème simplifié de compagnie aérienne. Au lieu de laisser le logiciel déterminer la réponse appropriée, la prise de décision est déléguée à la couche LLM. Nous avons ici un système multi-agents dans lequel un agent orchestrateur « principal » trie la requête de l’utilisateur et la transmet à un agent spécialement conçu pour modifier les vols, qui fournit ensuite la réponse à l’utilisateur.
Dans cet exemple, la couche LLM joue les rôles de classificateur, de routeur et de rédacteur de la réponse. Dans l’exemple du routeur, elle jouait uniquement le rôle de classificateur, le logiciel se chargeant du reste.
Dans la mesure du possible, nous recommandons les approches basées sur un routeur, car elles offrent les avantages suivants :
Rapidité et efficacité : les calculs locaux offrent une vitesse supérieure à celle des orchestrateurs dépendant d’API externes. Il est également bien moins coûteux de traiter votre logique « IF/ELSE » en Python que de payer un fournisseur de LLM pour la faire passer par son modèle de 400 milliards de paramètres.
Testabilité et prévisibilité : le débogage, les tests et la maintenance sont nettement plus simples grâce aux pratiques logicielles établies.
Transparence et fiabilité : une moindre variation du comportement simplifie le dépannage. Une plus grande part du flux de l’application est également exprimée dans un logiciel transparent et géré par versions, contrairement aux poids opaques et ininterprétables d’un LLM.
Les approches à routeur présentent l’inconvénient de pouvoir être rigides et peu flexibles, et de rencontrer des difficultés face à des problèmes plus ouverts. Un chatbot qui fournit toujours exactement les mêmes réponses peut être jugé ennuyeux ou figé par ses utilisateurs.
Les conceptions d’orchestration offrent de puissantes capacités :
Planification : elles peuvent planifier dynamiquement les réponses.
Sélection d’outils/transfert à un agent : sélectionner les outils appropriés ou déléguer des tâches à des agents.
Combinaison itérative des résultats : itérer et recombiner les résultats de manière créative.
Détermination de l’achèvement : déterminer quand suffisamment d’informations ont été recueillies pour finaliser une réponse.
L’utilisation de frameworks tels que Pydantic-AI ou le SDK Agents d’OpenAI permet de mettre en œuvre l’orchestration simplement et rapidement. Cette approche convient donc parfaitement aux démonstrations et aux preuves de concept.
Cette approche présente les inconvénients suivants :
Nous n’avons aucune garantie que les étapes de planification du LLM et les actions qui en découlent seront correctes ou appropriées. Le système à routeur présente le même problème, mais son comportement est plus prévisible puisqu’il est davantage contraint.
Pour des tâches simples et bien définies, il est peu probable que nous ayons besoin de toutes les capacités d’un système multi-agents. Par exemple, dans notre exemple d’agent de compagnie aérienne, une personne interagissant avec un service d’assistance aérienne ne souhaite probablement effectuer qu’un nombre limité de types de requêtes.
Comme davantage de logique est contenue dans le LLM, celui-ci est beaucoup plus susceptible de subir un jailbreak ou d’être exploité par des acteurs malveillants.
Cette approche abstrait la prise de décision dans le LLM et rend donc votre système plus difficile à comprendre, même si des outils de surveillance tels que Langfuse ou Braintrust peuvent partiellement y remédier.
Note au lecteur : bien que les capacités des modèles évoluent rapidement, les éléments ci-dessous ne devraient guère changer à court terme.
Déterminez la portée de votre problème.
Pouvez-vous facilement représenter la logique décisionnelle souhaitée dans un schéma ?
Votre application ne tolère-t-elle aucun échec ni comportement inattendu ?
Répondre « oui » à l’une des questions ci-dessus suggère que les fonctionnalités de routeur seraient préférables.
Dans la mesure du possible, nous recommandons d’utiliser des approches à routeur aussi longtemps qu’elles le permettent et d’appliquer un principe général : si une partie de votre système peut être exprimée dans du code, exprimez-la dans du code. Autrement dit, n’utilisez pas excessivement les LLM lorsqu’ils ne sont pas nécessaires.
Lorsque les limites de ces approches sont atteintes, certains avantages ouverts de l’orchestrateur peuvent être reproduits de manière contrainte. Par exemple :
Sélection d’outils/transfert à un agent : facilement mis en œuvre au moyen de branches conditionnelles ou de classificateurs LLM.
Détermination de l’achèvement : de simples classificateurs LLM peuvent vérifier que la réponse est complète avant de la renvoyer à l’utilisateur.
La « planification » et la « combinaison itérative des résultats » sont toutefois indéniablement beaucoup plus difficiles à réaliser dans un système à routeur rigide. Lorsqu’une tâche exige ces capacités, selon un classificateur LLM ou une autre logique, nous suggérons donc de créer dans votre système une branche d’orchestration moins contrainte.
Votre choix entre une architecture à routeur et une architecture d’orchestration doit refléter la clarté, la complexité et le style d’interaction de votre application. Les approches basées sur un routeur offrent actuellement fiabilité, efficacité et facilité de test pour les tâches clairement définies. Les orchestrateurs offrent davantage de flexibilité pour des interactions conversationnelles plus larges.
À mesure que les LLM progresseront, l’équilibre entre ces approches pourra évoluer. Nous privilégions les architectures à routeur ou hybrides pour les charges de travail en production et réservons les orchestrateurs aux problèmes ouverts exigeant des interactions dynamiques et proches de celles d’un humain.