Kaskad- vs Fusionsmodeller: Jämförelse av arkitekturer bakom konversationsagenter

ElevenAgents drivs av en låglatens orkestreringsmotor som är byggd för samtal i realtid och lägger till mindre än 100 ms fördröjning. Arkitekturen kombinerar det bästa från ElevenLabs forskning med avancerade LLM:er från ledande leverantörer som OpenAI, Google och Anthropic, samt utvalda open source-modeller som hostas av ElevenLabs. Genom att använda flera modeller i olika steg av svarskedjan säkerställer agenten att samtalen blir både snabba och kontextmedvetna. Genom att dynamiskt utnyttja varje modells styrkor tillsammans uppnår vi pålitlig och skalbar prestanda för olika företagsuppgifter och samtalsscenarier, samtidigt som vi optimerar balansen mellan intelligens, hastighet och kostnad.

Agentens arkitektur avgör hur naturliga, smarta och konsekventa svaren blir, och om agenten beter sig förutsägbart över tid. Till exempel kan en agent med fusionbaserad arkitektur låta väldigt verklighetstrogen i korta samtal, men ha svårare att resonera eller hålla sig konsekvent i längre konversationer.

Hos ElevenLabs använder vi en kaskadbaserad arkitektur där specialiserade komponenter för taligenkänning, resonemang och talgenerering kopplas ihop. OpenAI:s Realtime-modell använder istället en fusionbaserad metod där dessa steg slås ihop i ett enda nätverk.

I det här inlägget går vi igenom de fem vanligaste arkitekturerna för konversationsagenter idag, förklarar deras grundidéer, för- och nackdelar, och hur team väljer mellan dem beroende på mål.verktyg och en kunskapsbas. Självständiga agenter passar bäst när ditt användningsområde inte kräver att du följer en strikt sekvens av steg, eller när det är viktigt att undvika kunskapssilor mellan agenter. Kunskapssilor uppstår när vissa verktyg, dokument eller historik bara är tillgängliga för vissa underagenter. Detta är vanligt i multi-agent arbetsflöden och innebär en avvägning mellan flexibilitet och förutsägbarhet.

Vad team optimerar för när de bygger agenter

• Bygger effektiva genereringsförfrågningar
• Hämtar och använder relevanta dokument
• Skapar och utför verktygsanrop för att informera agentens svar
• Levererar resultat för utvärdering och datainsamling

Bygga samtalskontext 

Även om team också bryr sig om saker som samtidighet, integrationer och röstkvalitet, kan faktorerna ovan påverkas mer direkt av agentens arkitektur. De mest framgångsrika teamen anpassar sin arkitektur för att optimera dessa faktorer för sitt användningsområde.

Kaskadbaserade arkitekturer byggs genom att koppla ihop specialiserade komponenter: , en Large Language Model och Text to Speech. Varje steg kan optimeras, testas och uppgraderas separat.tidigare inlägg. Det gör att dokument kan hämtas pålitligt även när det senaste användarinlägget är en följdfråga, ett bekräftande svar eller saknar en tydlig fråga.

Att hämta information är dock bara ett sätt för agenter att interagera med externa system.

Den här modulariteten gör det möjligt att använda de senaste LLM:erna för bättre resonemang, lägga till tydliga regler på textnivå och styra hur agenten pratar med kontextuell TTS. Nackdelen är att kaskadarkitekturer ofta tappar prosodiska ledtrådar – som intonation, rytm och känsla – eftersom talet först blir text innan det återskapas. Vissa ledtrådar kan återskapas med explicit modellering, men inte lika naturligt som i fusionmodeller. Andra aspekter, som fördröjning och turordning, kan oftast optimeras till liknande nivåer i båda metoderna.

Fusion-baserade metoder slår istället ihop dessa steg i en enda multimodal modell. Ljud går in och ljud kommer ut, med taligenkänning, resonemang och generering i samma nätverk. Ju fler verktyg som läggs till, desto större blir modellens ansvar att välja rätt verktyg i rätt ordning. I Agent Builder beskriver verktygets beskrivning vad verktyget gör och vilka fält det returnerar. Det är denna information som språkmodellen använder för att förstå kontexten kring användningen. När det är definierat ska de specifika villkoren för att använda verktyget anges i agentens systemprompt. Till exempel:

• Verktygsbeskrivning för lookup_order: ”Hämtar en kunds orderdetaljer via order-ID. Returnerar orderstatus, köpta varor, leveransadress och spårningsnummer.”
• Instruktion i systemprompt: ”Efter att ha verifierat kundens identitet, använd verktyget lookup_order för att hämta orderdetaljer.”

Den här designen gör att fusion-baserade arkitekturer kan bevara och återskapa prosodi mer effektivt, eftersom modellen bearbetar uttal och intonation direkt. Men fusionsmodeller är svårare att testa och styra, eftersom mellanresultat inte syns. De bygger ofta också på lättare LLM-kärnor, vilket begränsar resonemang och verktygsanvändning jämfört med kaskadmetoder där man kan använda de starkaste modellerna som finns.Prompting Guide. Inom detta ramverk kan flera typer av verktyg definieras, främst:

• Webhook-verktyg som anropar externa API:er.
• Klientverktyg som skickar verktygsanrop som händelser via samtalswebsocket.
• Systemverktyg för inbyggda åtgärder som samtalsöverföringar.
• MCP-verktyg som kopplar till Model Context Protocol-servrar.

De fem möjliga arkitekturernadynamisk variabel. Denna information sparas som enkla nyckel-värde-par, hämtade från verktygets svar med fördefinierade mappningar. När de är satta kan dessa variabler användas i agentens systemprompt, framtida verktygsparametrar och arbetsflödesvillkor. Denna återkoppling ger agenten ett slags arbetsminne som utvecklas under interaktionen.

1. Grundläggande kaskad

När exekvering och orkestrering är på plats är nästa steg att förstå hur man mäter prestanda.

I enkla kaskadarkitekturer transkriberas ljudet, LLM:en ger ett textsvar och TTS läser upp exakt det som skickas. Eftersom varje steg arbetar med ren text får teamen full insyn och kontroll. Skyddsräcken kan sättas på textnivå, verktygsanrop och API-integrationer hanteras direkt av LLM:en, och deterministiska flöden kan styra samtal och affärslogik på ett mer förutsägbart sätt.

Agenten uppfattar dock inte nyanser i talet som ton, rytm och känsla, vilket kan göra samtalet mindre naturligt.Datainsamling och Utvärderingskriterier in i bilden. Datainsamling låter dig extrahera strukturerad information från en samtalstranskription för vidare analys och sammanställning. Kunder exporterar ofta dessa resultat till sitt företags datalager för rapportering eller vidare bearbetning. Till exempel kan en Sales Development Agent automatiskt extrahera prospektinformation från ett samtal för att skapa eller uppdatera ett lead i CRM-systemet. Utvärderingskriterier avgör om ett samtal anses lyckat. Om alla kriterier är uppfyllda markeras samtalet som lyckat, annars flaggas det som misslyckat. Det säkerställer att samtalen alltid håller uppsatta kvalitets- och integritetskrav och ger snabb återkoppling. När ett samtal avslutas och webhooken triggas bearbetar agenten den slutliga transkriptionen, inklusive verktygsanrop och metadata, genom en LLM tillsammans med alla konfigurerade datainsamlingspunkter och utvärderingskriterier. Modellen använder denna kombinerade prompt för att avgöra om varje kriterium är uppfyllt och för att extrahera angivna datapunkter för vidare analys. Eftersom LLM:en tolkar dessa konfigurationer direkt i sin prompt är det viktigt att de är tydligt och konsekvent formulerade så att modellen kan förstå och tillämpa dem korrekt. Vi rekommenderar därför följande bästa praxis för att skriva utvärderingskriterier och datainsamlingsbeskrivningar.

Möjliga användningsområden:

1. Kundsupport en mening eller en kort punkt är bättre än flera mål i ett kriterium.
2. Säljhjälp formulera målet så att det går att avgöra utifrån transkriptionen (vad som sades, vad agenten gjorde, vad användaren frågade). Undvik mål som kräver extern kontext som LLM:en inte har.
3. AI-receptionister LLM:en vet redan att målet måste vara uppfyllt för att markeras som lyckat, inte uppfyllt för misslyckat och okänt om det inte går att avgöra från transkriptionen. Målet bör därför vara tydligt definierat så att ”uppfyllt” och ”inte uppfyllt” är klart; om det är otydligt kan modellen välja okänt eller felaktig klassificering.
4. NPC:er i underhållning och spel ibland skickas många utvärderingskriterier samtidigt. Långa kriterier kan skapa brus och leda till hallucinationer.
5. Ersättning för IVR all motivering från LLM:en om ett kriterium är uppfyllt eller inte ges på samma språk som kriteriebeskrivningen, så tänk på det.

2. Avancerad kaskad

1. Beskriv exakt vad som ska extraheras: beskrivningen är den viktigaste signalen för LLM:en. Säg vad fältet betyder, när det ska sättas och vad som gäller om det är oklart (t.ex. ”Lämna tomt om kunden aldrig angav ett önskat datum”).
2. Matcha förväntad typ: värdet från LLM:en kommer alltid att matcha datatypen för insamlingspunkten (t.ex. boolean, string, integer osv). Beskrivningen bör därför stämma med det. Till exempel: ”Extrahera antal beställda varor” för integer, och ”Ja/nej om kunden accepterade erbjudandet” för boolean.
3. Använd enum där det går: för string-typ, om värdemängden är fast, använd enum i schemat; det begränsar modellen och minskar felaktiga svar.
4. Ett extraktionsmål per punkt: Packa inte in flera olika fakta i en beskrivning; dela upp i separata punkter så att varje samtal har ett tydligt extraktionsmål.
5. Håll beskrivningarna korta: Beskrivningar kan vara några meningar; det behövs inga långa stycken. Transkriptionen finns redan i användarmeddelandet, så schema + kort beskrivning räcker.

Avancerade kaskadarkitekturer inför kontextuell TTS, där LLM:en inte bara bestämmer vad som ska sägas utan även hur, och skickar instruktioner som "säg detta lugnande" eller "svara med betoning" till TTS-modellen. Agenten talar mer realistiskt och varierat, men behåller samma skyddsräcken, deterministiska flöden, verktygsanvändning och spårbarhet som en enkel kaskad.

Detta är metoden bakom

Möjliga användningsområden är mer uttrycksfulla versioner av:

Kundsupport ger ett visuellt gränssnitt för att designa komplexa samtalsflöden. Det resulterar i det logiska objekt som orkestratorn använder för att hantera flera underagenter, verktyg och överföringar under en självständig agentidentitet. Workflows innebär ytterligare komponenter utöver de som redan beskrivits för självständiga agenter, bland annat hur:

• Systemprompter och underagenters samtalsmål samverkar.
• Förflyttning genom olika övergångspunkter i grafen avgörs.

Specialiserade samtalsmål

Vissa kaskadarkitekturer skickar akustiska egenskaper (t.ex. uttal, känsla, ton) från det inkommande talet direkt in i LLM:en som inbäddningar. Det här bevarar mer av användarens ursprungliga avsikt samtidigt som TTS förblir modulärt. Verktygsanvändning och regler är fortfarande möjliga, men den sammanslagna ASR+LLM-blocket är svårare att granska än en ren texthantering, och LLM:en kan inte bytas ut lika enkelt som i en kaskadmodell.

Ovanpå denna gemensamma grund introducerar Workflows specialiserade underagenter som verkar i en riktad graf. Varje underagent får ett smalt definierat mål och utökar grundkonfigurationen med ytterligare promptinstruktioner, verktyg och kunskapskällor som bara är relevanta för dess roll. Istället för att omdefiniera hela samtalsinställningen lägger underagenter till sin avsikt ovanpå basagenten via promptkomposition och selektiv kontextutökning. Samtalshistoriken bevaras mellan underagentövergångar för att hålla kontinuitet, men varje underagent arbetar med en avsiktligt begränsad vy av systemet. Kunskapsbaser och verktyg exponeras selektivt, vilket skapar tydliga silor och förhindrar läckage mellan ansvarsområden. För att förstärka denna isolering byggs orkestratorobjektet om vid varje övergång, som om det vore en självständig agent. Det säkerställer att den aktiva underagentens prompt, konfiguration och tillgängliga funktioner är helt förutsägbara. Denna design gör att Workflows kan bibehålla global konsekvens samtidigt som lokal specialisering stöds, vilket ger förutsägbart beteende, tydlig ansvarsfördelning och exakt kontroll över hur kontext, kunskap och åtgärder används i varje steg av interaktionen.

4. Sekventiell Fusion

Styr arbetsflödesövergångar med LLM-villkor

I sekventiella fusionsarkitekturer hanterar en enda multimodal modell igenkänning, resonemang och talgenerering. Modellen lyssnar tills användaren är klar och producerar sedan ljud direkt. Genom att bearbeta ljudet från början till slut fångar dessa arkitekturer naturligt signaler som uttal, tempo och intonation, vilket ofta ger mer flytande och uttrycksfullt tal.

Nackdelen är att skyddsräcken är svårare att sätta utan textlager, verktygsanvändning begränsas av enklare resonemangskärnor och insynen är begränsad utan tydliga mellanresultat.

När ett samtal går vidare till ett nytt steg aktiveras en version av agenten som är anpassad för just det steget. Varje steg har egna instruktioner och tillgång bara till den kunskap och de verktyg som är relevanta för dess ansvar. Till exempel kan ett återbetalningssteg hänvisa till återbetalningspolicy utan att ärva irrelevant kontext från onboarding eller triage. Förflyttning mellan steg styrs av tydliga övergångsvillkor. Dessa avgör när ansvaret ska flyttas och gör att routingbeslut kan ske naturligt under samtalets gång. För att hålla kontinuitet är användarupplevelsen sömlös över övergångarna, där varje steg ärver relevant samtalskontext utan att visa överlämningsmekaniken. Skyddsmekanismer övervakar också övergångarna för att förhindra icke-produktiva loopar, så att arbetsflödet förblir stabilt och målinriktat.

Säkerhet och trygghet

5. Duplex Fusion

Skyddsräcken

I duplex fusionsarkitekturer behandlar modellen in- och utdata samtidigt. Det kan ge det mest mänskliga samtalsflödet, med mer äkta överlappande tal i korta samtal, men innebär också stor komplexitet. Skyddsräcken är svårare att sätta, prat i munnen och avbrott kan orsaka fel, och insynen är minimal jämfört med kaskadbaserade arkitekturer.

Efterlevande datahantering

Ibland kan talare dela känslig information med en agent som omfattas av särskilda lagrings- och hanteringskrav, till exempel medicinska data som kräver HIPAA-anpassad hantering. För dessa fall erbjuder vi Zero Retention Mode (ZRM) på agent- eller arbetsytanivå. När det är aktiverat behandlas all samtalsdata endast i minnet och sparas aldrig permanent. När samtalet och bearbetningen är klar sparas ingen information av ElevenLabs. Det innebär att transkriptioner, ljudinspelningar och analysresultat inte finns tillgängliga i Agents Dashboard, och policyn gäller både kundsystem och interna loggar. Även om data inte sparas behandlas den under samtalet, och eventuella konfigurerade webhooks efter samtalet får utdata, så att kunder kan lagra transkriptioner eller analysresultat i sina egna system om det behövs.

Välja rätt arkitektur för ditt användningsområde

Det finns ingen arkitektur som passar alla konversationsagenter. Varje variant har sina styrkor och avvägningar, från förutsägbarheten och kontrollen i kaskadmodeller till den naturliga prosodin i fusion-modeller.

I det här inlägget har vi gått igenom hur ElevenLabs Agents hanterar samtalskontext, verktyg, utvärdering och strukturerade arbetsflöden för att leverera pålitliga upplevelser i realtid i stor skala. När kunder använder agenter i allt mer komplexa miljöer fortsätter vi att utveckla vår orkestreringsmotor – från konfigurerbara utvärderingsmodeller och bättre övergångskontroller till djupare insyn i promptkomposition och tokenanvändning i olika steg.

Vårt Forward Deployed Engineering-team samarbetar nära med kunder för att säkerställa att dessa funktioner utvecklas i takt med verkliga behov. Nästa generations agenter kommer att ge ännu större transparens, förutsägbarhet och flexibilitet – utan att kompromissa med den låga latens som möjliggör samtal i realtid.