Modèles en cascade vs fusionnés : Comment l’architecture détermine si votre agent vocal est prêt pour l’entreprise

ElevenAgents sont propulsés par un moteur d’orchestration à faible latence, conçu spécialement pour les conversations en temps réel, ajoutant moins de 100 ms de latence. Cette architecture combine le meilleur de la recherche ElevenLabs avec des LLM de pointe de fournisseurs comme OpenAI, Google et Anthropic, ainsi que des modèles open source sélectionnés et hébergés par ElevenLabs. En utilisant plusieurs modèles à différentes étapes de la chaîne de réponse, l’agent garantit des conversations à la fois très réactives et pertinentes. En exploitant dynamiquement les points forts de chaque modèle, nous assurons des performances fiables et évolutives sur une large gamme de tâches et de scénarios conversationnels en entreprise, tout en optimisant l’équilibre entre intelligence, rapidité et coût.

L’architecture de l’agent détermine sa capacité à être fiable en production, à s’adapter à des besoins métier spécifiques et à offrir une conversation naturelle. Une architecture fusionnée comme le modèle Realtime d’OpenAI peut sembler très réaliste lors d’échanges courts. Mais quand il faut garantir la conformité, diagnostiquer une réponse incorrecte ou intégrer un LLM plus performant dès sa sortie, un réseau fusionné unique offre peu de flexibilité.

Chez ElevenLabs, nous utilisons une architecture avancée basée sur la cascade. Nous combinons des composants spécialisés pour la reconnaissance vocale, le raisonnement et la génération vocale afin d’assurer un haut niveau d’intelligence et de fiabilité. Nous ajoutons la prosodie contextuelle, l’optimisation de la latence et une gestion intelligente des tours de parole pour des conversations fluides. Nous avons fait ce choix car les entreprises et gouvernements avec lesquels nous travaillons exigent des agents à la fois réalistes et fiables pour des tâches complexes en production.

Cet article présente les cinq principales architectures, leurs points forts, leurs limites et notre vision de la base idéale pour des agents déployés dans des workflows critiques.outils et d’une base de connaissances. Il est préférable de choisir des agents indépendants plutôt que des workflows lorsque le cas d’usage nécessite peu de vérifications d’une séquence stricte d’étapes ou lorsqu’il est important d’éviter les silos de connaissances entre agents. Les silos apparaissent lorsque certains outils, documents ou contextes historiques sont accessibles à certains sous-agents mais pas à d’autres. C’est inhérent aux workflows multi-agents et cela crée un compromis entre flexibilité et déterminisme.

Ce que les équipes évaluent lors du choix d’une architecture

• Formulent des requêtes de génération efficaces
• Récupèrent et intègrent les documents pertinents
• Génèrent et exécutent des appels d’outils pour enrichir les réponses
• Produisent des résultats pour l’évaluation et la collecte de données

Peut-il gérer des tâches complexes ? 

Même si d’autres facteurs comme la gestion de la simultanéité, les intégrations ou la qualité vocale comptent aussi, les axes ci-dessus dépendent directement de l’architecture de l’agent. Les équipes les plus performantes adaptent leur architecture pour optimiser ces aspects selon leur cas d’usage.

Les architectures en cascade sont construites en enchaînant des composants spécialisés : , un Large Language Model, et Text to Speech. Chaque étape peut être optimisée, testée et améliorée indépendamment.article précédent. Cela permet de retrouver efficacement des documents même si la dernière intervention de l’utilisateur est un suivi, une confirmation ou ne contient pas de question explicite.

Puis-je lui faire confiance en production ?

Cette modularité permet aux équipes d’intégrer les derniers LLM pour un meilleur raisonnement, d’appliquer des garde-fous explicites au niveau du texte, et de contrôler précisément la façon dont l’agent parle grâce à un TTS contextuel. Le principal compromis est que les architectures en cascade perdent souvent plus de signaux prosodiques – comme l’intonation, le rythme et l’émotion – car la parole est convertie en texte avant d’être régénérée. Ces indices peuvent être partiellement récupérés par une modélisation explicite, mais ils ne sont pas capturés aussi naturellement que dans les approches fusionnées. D’autres aspects, comme la latence et la gestion des tours de parole, peuvent généralement être optimisés pour atteindre des performances comparables dans les deux approches.

Les compromis entre architectures en cascade et fusionnées Plus on ajoute d’outils, plus le modèle doit raisonner pour choisir la bonne séquence d’outils. Dans l’Agent Builder, la description de l’outil précise ce qu’il fait et les champs qu’il retourne. C’est cette information que le modèle de langage utilise pour comprendre le contexte d’utilisation. Une fois défini, les conditions spécifiques d’utilisation de l’outil doivent figurer dans le prompt système de l’agent. Par exemple :

• Description de l’outil pour lookup_order : « Récupère les détails d’une commande client via son ID. Retourne le statut de la commande, les articles achetés, l’adresse de livraison et le numéro de suivi. »
• Speech to Text« Après avoir vérifié l’identité du client, appelez l’outil lookup_order pour récupérer les détails de sa commande. »

Ce design permet aux architectures fusionnées de mieux préserver et restituer la prosodie, car le modèle traite directement la prononciation et l’intonation. Cependant, les modèles fusionnés sont plus difficiles à tester et à contrôler, car les sorties intermédiaires ne sont pas accessibles. Ils reposent aussi souvent sur des LLM plus légers, ce qui limite le raisonnement et l’utilisation d’outils par rapport aux approches en cascade qui peuvent utiliser les modèles les plus puissants disponibles.Guide du Prompt. Dans ce cadre, plusieurs types d’outils peuvent être définis, principalement :

• Outils webhook qui appellent des API externes.
• Outils client qui envoient des requêtes d’outils comme événements via le websocket de conversation.
• Outils système pour des actions intégrées comme les transferts d’appel.
• Outils MCP qui se connectent à des serveurs Model Context Protocol.

La critique classique des architectures en cascade est la perte des indices prosodiques. La parole est réduite à du texte, et l’intonation, le rythme et l’émotion doivent être reconstruits à la sortie. Ces indices peuvent être partiellement récupérés via une modélisation explicite, mais ils ne sont pas capturés aussi naturellement qu’avec une approche fusionnée. D’autres aspects, comme la latence et la gestion des tours de parole, peuvent généralement être optimisés pour atteindre des performances similaires dans les deux approches.variable dynamique. Ces informations sont stockées sous forme de paires clé-valeur simples, extraites de la réponse de l’outil via des mappings prédéfinis. Une fois définies, ces variables peuvent être réutilisées dans le prompt système, les paramètres d’outils futurs ou les conditions de workflow. Cette boucle de rétroaction donne à l’agent une mémoire de travail qui évolue au fil des interactions.

1. Cascade basique

Les architectures fusionnées adoptent une approche fondamentalement différente. La reconnaissance, le raisonnement et la génération se font dans un seul réseau multimodal. L’audio entre, l’audio sort, sans couche intermédiaire vérifiable.

Cette absence d’étapes intermédiaires est à la fois un atout et une limite. L’architecture fusionnée peut préserver naturellement les indices prosodiques, car la parole n’est jamais transformée en texte. Cependant, il est difficile d’appliquer des garde-fous, de remplacer des composants ou d’inspecter les sorties intermédiaires pour le débogage. Il est aussi compliqué d’ajuster le STT pour un vocabulaire métier ou d’intégrer un autre LLM pour un raisonnement plus poussé. Le système est un seul réseau, et les équipes sont limitées aux capacités de raisonnement intégrées, qui aujourd’hui restent plus légères que les LLM de pointe pour les tâches complexes.

Les cinq architecturescollecte de données et les critères d’évaluation entrent en jeu. La collecte de données permet d’extraire des informations structurées à partir de la transcription pour analyse ou agrégation. Les clients exportent souvent ces données vers leur data lakehouse pour le reporting ou l’enrichissement. Par exemple, un Agent commercial peut extraire automatiquement les informations d’un prospect pour créer ou mettre à jour une fiche dans le CRM. Les critères d’évaluation, eux, déterminent si un appel est considéré comme réussi. Si tous les critères sont remplis, l’appel est marqué comme réussi ; sinon, il est signalé comme échec. Cela garantit que les conversations respectent toujours les standards de qualité et d’intégrité, tout en fournissant un retour rapide. Une fois l’appel terminé et le webhook post-appel déclenché, l’agent traite la transcription finale, y compris les exécutions d’outils et les métadonnées, via un LLM avec tous les points de collecte et critères d’évaluation configurés. Le modèle utilise ce prompt combiné pour déterminer si chaque critère est rempli et pour extraire les données demandées pour analyse. Comme le LLM interprète ces configurations directement dans son prompt, il est important de les formuler clairement et de façon cohérente pour qu’il les comprenne et les applique correctement. Nous recommandons donc les bonnes pratiques suivantes pour rédiger les critères d’évaluation et les descriptions de collecte de données.

1. Cascade basique

1. Support client une phrase ou une puce courte vaut mieux que plusieurs objectifs dans un même critère.
2. Assistants commerciaux formulez l’objectif pour que le succès ou l’échec soit déterminé à partir de la transcription (ce qui a été dit, ce que l’agent a fait, ce que l’utilisateur a demandé). Évitez les objectifs nécessitant un contexte externe que le LLM n’a pas.
3. Réceptionnistes IA le LLM sait déjà que pour marquer comme réussi l’objectif doit être atteint, comme échec il ne doit pas l’être, et comme inconnu il ne doit pas pouvoir le déterminer à partir de la transcription. L’objectif doit donc être rédigé pour que « atteint » ou « non atteint » soit bien défini ; si c’est ambigu, le modèle risque de pencher vers inconnu ou une mauvaise classification.
4. PNJ pour jeux vidéo et divertissement parfois, de nombreux critères d’évaluation sont envoyés ensemble. Des critères trop longs ajoutent du bruit et peuvent provoquer des hallucinations.
5. Remplacement d’IVR toute explication fournie par le LLM sur la réussite ou non d’un critère sera dans la même langue que la description du critère, il faut donc en tenir compte.

L’audio est transcrit, le LLM génère une réponse texte, puis le TTS la vocalise. Chaque étape fonctionne sur du texte brut, ce qui permet de tout voir, tester et contrôler.

1. Décrivez précisément ce qu’il faut extraire : la description est le principal signal pour le LLM. Indiquez ce que signifie le champ, dans quelle situation il doit être renseigné, et quoi faire si ce n’est pas clair (ex : « Laissez vide si le client n’a jamais indiqué de date préférée »).
2. Respectez le type attendu : la valeur fournie par le LLM correspondra toujours au type de donnée assigné au point de collecte (ex : booléen, chaîne, entier, etc.). La description doit donc être alignée. Par exemple : « Extraire le nombre d’articles demandés » pour un entier, et « Oui/non si le client a accepté l’offre » pour un booléen.
3. Utilisez des enums si possible : pour les chaînes, si la liste de valeurs est fixe, utilisez enum dans le schéma ; cela contraint le modèle et réduit les sorties invalides.
4. Un objectif d’extraction par item : Ne regroupez pas plusieurs faits non liés dans la même description ; séparez-les pour que chaque item ait une cible d’extraction claire.
5. Gardez les descriptions courtes : Quelques phrases suffisent ; pas besoin de longs paragraphes. La transcription est déjà dans le message utilisateur, donc le schéma + une courte description suffisent.

Exemples d’utilisation :

C’est l’approche utilisée dans

2. Cascade avancée

Support client offrent une interface visuelle pour concevoir des parcours conversationnels complexes. Cela produit au final l’objet logique utilisé par l’orchestrateur pour gérer plusieurs sous-agents, outils et transferts sous un identifiant d’agent indépendant. Les Workflows ajoutent des éléments à prendre en compte en plus de ceux des agents indépendants, notamment comment :

• Les prompts système et les objectifs conversationnels des sous-agents interagissent.
• Mode Expressif

Le LLM indique ensuite au TTS comment délivrer la parole – pas seulement quoi dire – par exemple « de façon rassurante », « avec insistance », « avec urgence », en adaptant le ton dynamiquement tout au long de la conversation. Le système de gestion des tours de parole utilise les mêmes signaux, permettant à l’agent de savoir quand répondre ou céder la parole. Les modèles vocaux sont regroupés dans une seule pile sans latence réseau entre les composants, ce qui maintient une faible latence.

L’architecture conserve tout ce qui fait la force de la cascade basique : transparence totale, garde-fous au niveau texte, interchangeabilité des composants, adaptation au domaine et accès aux meilleurs modèles de raisonnement et d’outils. Elle ajoute une prosodie, une latence et une gestion des tours de parole nettement meilleures. Les équipes peuvent intégrer un nouveau LLM de pointe dès sa sortie, ou ajuster le STT pour le vocabulaire médical, sans avoir à reconstruire les autres composants.

Sur cette base commune, les Workflows introduisent des sous-agents spécialisés opérant dans un graphe orienté. Chaque sous-agent reçoit un objectif précis et enrichit la configuration de base avec des instructions de prompt, des outils et des sources de connaissances spécifiques à son rôle. Plutôt que de redéfinir tout le contexte, les sous-agents ajoutent leur intention via la composition de prompts et l’extension sélective du contexte. L’historique de conversation est conservé lors des transitions pour maintenir la continuité, mais chaque sous-agent fonctionne avec une vue volontairement limitée du système. Les bases de connaissances et outils sont exposés de façon sélective, créant des silos clairs qui évitent les fuites entre responsabilités. Pour renforcer cette isolation, l’objet orchestrateur est reconstruit à chaque transition comme s’il s’agissait d’un agent indépendant. Cela garantit que l’état du prompt, la configuration et les capacités du sous-agent actif restent entièrement déterministes. Ce design permet aux Workflows de maintenir une cohérence globale tout en favorisant la spécialisation locale, pour un comportement prévisible, une séparation claire des responsabilités et un contrôle précis sur le contexte, la connaissance et les actions à chaque étape de l’interaction.

3. Cascade hybride et fusionnée

Piloter les transitions de workflow avec des conditions LLM

Certaines architectures transmettent les caractéristiques acoustiques (prononciation, émotion, ton) de la voix directement au LLM sous forme d’embeddings, au lieu de convertir d’abord en texte. Le TTS reste modulaire.

Cela donne au LLM une information plus riche sur

Exemples d’utilisation :

Sécurité et protection

4. Fusion séquentielle

Garde-fous

Un seul modèle multimodal gère la reconnaissance, le raisonnement et la génération en une seule passe, un tour à la fois. C’est l’architecture derrière des modèles comme l’API Realtime d’OpenAI.

La prosodie peut être très bonne. Comme la parole n’est jamais transformée en texte, le modèle préserve naturellement le rythme, l’intonation et les indices émotionnels. Les conversations courtes peuvent sembler très fluides.

Mais il est difficile d’appliquer des garde-fous sans couche texte, il y a peu de sorties intermédiaires pour le débogage, et peu de flexibilité pour intégrer un meilleur LLM ou ajuster le STT à votre domaine. Les cœurs de raisonnement sont généralement plus légers que les LLM de pointe, donc les tâches complexes ou multi-étapes sont limitées. Quand la tâche exige de résoudre un problème complexe, la prosodie seule ne suffit pas.

Exemples d’utilisation :

Il n’existe pas d’architecture universelle pour les agents conversationnels. Chaque variante a ses forces et ses compromis, de la prévisibilité et du contrôle des modèles en cascade à la prosodie naturelle des modèles fusionnés.

5. Fusion duplex

Notre équipe Forward Deployed Engineering travaille en étroite collaboration avec les clients pour faire évoluer ces capacités au rythme des déploiements réels. La prochaine génération d’Agents offrira encore plus de transparence, de déterminisme et d’adaptabilité, sans compromis sur la faible latence qui rend la conversation en temps réel possible.