Il est important d’examiner attentivement comment et où les décisions sont prises dans votre système agentique.
Confier davantage de décisions à un LLM peut permettre au système de se généraliser à plus de tâches, mais au détriment possible de la vitesse, de la fiabilité et de la robustesse.
Dans la mesure du possible, essayez de transférer autant que possible le processus décisionnel du LLM vers du code logiciel explicite. Cela est particulièrement vrai pour les flux de travail à risque élevé ou en production.
Lors de la conception d’un système agentique fondé sur un LLM, l’un des choix les plus importants consiste à déterminer dans quelle mesure la prise de décision relève d’un modèle LLM plutôt que d’un logiciel explicite.
Pour mieux comprendre, nous pouvons envisager ce choix comme un spectre entre les approches suivantes :
Les architectures fondées sur un routeur définissent explicitement l’ordre et la logique dans le code, ce qui assure la testabilité, la prévisibilité et la robustesse pour les tâches d’un domaine restreint (on les appelle aussi « agents de flux de travail »).
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 requêtes en langage naturel. Ils conviennent parfaitement aux interactions ouvertes pour lesquelles une logique prédéfinie est insuffisante ou impossible.
Pour les flux de travail à risque élevé en production, nous recommandons généralement d’utiliser davantage de fonctions fondées sur un routeur et de réserver les orchestrateurs aux applications exigeant des conversations polyvalentes et flexibles.
Architectures fondées sur un routeur
Les systèmes agentiques à routeur :
Définissent explicitement le déroulement décisionnel dans le code ou le logiciel et utilisent un LLM pour déterminer quelle voie ce logiciel doit emprunter.
Ressemblent davantage aux systèmes logiciels traditionnels, car leurs parcours clairs et prévisibles produisent des résultats plus cohérents.
Sont idéaux pour les tâches qui peuvent être définies rigoureusement.
Voici un exemple simplifié d’un agent conversationnel de réservation aérienne qui utilise l’« approche du 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. Comme le LLM est fortement contraint, l’utilisateur bénéficie d’un comportement plus cohérent.
Architectures d’orchestrateur
Contrairement au système à routeur, les systèmes agentiques à orchestrateur :
Définissent les flux logiques au moyen de requêtes en langage naturel plutôt que d’un logiciel. Remarque : comparativement à un langage de programmation, le langage naturel est intrinsèquement ambigu et flexible (des caractéristiques à la fois positives et négatives, comme nous le verrons plus loin). Nous considérons cette approche comme « l’intention plutôt que l’instruction ».
Peuvent offrir 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’orchestrateur au même problème aérien simplifié. 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 multiagent dans lequel un agent orchestrateur « principal » trie la demande de l’utilisateur et la transmet à un agent conçu spécialement pour modifier les vols, lequel fournit finalement 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 seulement le rôle de classificateur (le logiciel s’occupant du reste).
Dans la mesure du possible, nous recommandons une approche fondée sur un routeur, car elle offre les avantages suivants :
Vitesse et efficacité : les calculs locaux offrent une vitesse supérieure à celle des orchestrateurs qui dépendent d’API externes. Il est aussi beaucoup moins coûteux de traiter votre logique « IF/ELSE » en Python que de payer un fournisseur de LLM pour l’acheminer dans son modèle à 400 milliards de paramètres.
Testabilité et prévisibilité : le débogage, les tests et la maintenance sont nettement plus faciles grâce aux pratiques logicielles établies.
Transparence et fiabilité : une moindre variation du comportement simplifie le dépannage. Une plus grande partie du flux de l’application est également exprimée dans un logiciel transparent et contrôlé par version, plutôt que dans les poids opaques et ininterprétables d’un LLM.
Les approches à routeur ont pour inconvénients d’être parfois rigides et peu flexibles, et d’avoir de la difficulté à résoudre des problèmes plus ouverts. Un agent conversationnel qui fournit toujours exactement les mêmes réponses pourrait être jugé ennuyant ou stagnant par ses utilisateurs.
Les conceptions à orchestrateur offrent de puissantes capacités :
Planification : elles peuvent planifier les réponses de manière dynamique.
Sélection d’outils et transfert à un agent : sélectionner les outils appropriés ou déléguer des tâches à des agents.
Combinaison itérative des résultats : réitérer et recombiner les résultats de façon créative.
Détermination de l’achèvement : déterminer quand suffisamment d’information a été recueillie pour finaliser une réponse.
Des cadres comme Pydantic-AI ou le SDK Agents d’OpenAI rendent l’orchestration simple et rapide à mettre en œuvre. Cette approche convient donc très bien aux démonstrations et aux validations de principe.
Les inconvénients de cette approche sont les suivants :
Rien ne garantit 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 comme il est plus contraint, son comportement est plus prévisible.
Pour les tâches simples et bien définies, il est peu probable que nous ayons besoin de toute la puissance d’un système multiagent. Par exemple, dans notre scénario d’agent de compagnie aérienne, les personnes qui interagissent avec un système d’assistance aérienne ne souhaitent probablement effectuer qu’un nombre limité de types de demandes.
Comme le LLM contient davantage de logique, des acteurs malveillants peuvent beaucoup plus facilement contourner ses protections ou l’exploiter.
Cette approche dissimule la prise de décision dans le LLM et rend donc votre système plus difficile à comprendre (bien que des outils de surveillance comme Langfuse ou Braintrust puissent aider en partie).
Note au lecteur : même si la capacité des modèles évolue rapidement, les éléments ci-dessous ne changeront probablement pas dans un avenir rapproché.
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 tolère-t-elle mal les échecs ou les comportements inattendus?
Répondre « oui » à l’une ou l’autre des questions ci-dessus suggère que les fonctions de routeur conviendraient mieux.
Dans la mesure du possible, nous recommandons d’utiliser des approches à routeur aussi longtemps qu’elles le permettent. En règle générale, si une partie de votre système peut être exprimée dans le code, faites-le (c’est-à-dire, n’utilisez pas les LLM à outrance lorsqu’ils ne sont pas nécessaires).
Lorsque ces approches atteignent leurs limites, certains avantages ouverts des orchestrateurs peuvent être reproduits de façon contrôlée. Par exemple :
Sélection d’outils et transfert à un agent : mise en œuvre facilement au moyen de branchements conditionnels ou de classificateurs LLM.
Détermination de l’achèvement : de simples classificateurs LLM peuvent vérifier l’exhaustivité d’une réponse avant de la transmettre à 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 une branche d’orchestrateur moins contrainte dans votre système.
Votre choix entre une architecture à routeur et une architecture d’orchestrateur doit refléter la clarté, la complexité et le style d’interaction de votre application. Les approches fondées sur un routeur offrent actuellement fiabilité, efficacité et facilité de test pour les tâches clairement définies. Les orchestrateurs offrent une plus grande flexibilité pour les interactions conversationnelles plus générales.
À mesure que les LLM progresseront, l’équilibre entre ces approches pourrait é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 qui exigent une interaction dynamique et naturelle.