Kaskad- vs Fuserade modeller: Hur arkitekturen avgör om din röstagent är redo för företag

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 pålitlig den är i drift, hur väl den kan anpassas till specifika affärskrav och hur naturligt den låter i samtal. En fusionsbaserad arkitektur som OpenAIs Realtime-modell kan låta imponerande verklighetstrogen i korta utbyten. Men när team behöver säkerställa regelefterlevnad, felsöka ett misslyckat svar eller byta till en starkare LLM när en sådan lanseras nästa månad, ger en enda fuserad nätverksmodell få möjligheter att göra förändringar.

Hos ElevenLabs använder vi en avancerad kaskadbaserad arkitektur. Vi använder specialiserade komponenter för taligenkänning, resonemang och talgenerering för hög intelligens och tillförlitlighet. Vi lägger till kontextuell prosodi, optimering för låg fördröjning och smart turordning så att samtalen flyter naturligt. Vi har byggt det så här eftersom de företag och myndigheter vi samarbetar med kräver agenter som både låter realistiska och kan litas på i produktion med komplexa uppgifter.

Den här artikeln går igenom de fem huvudarkitekturerna, vad de är bra på, var de brister och hur vi ser på grunden för agenter som används i viktiga arbetsflöden.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 utvärderar när de väljer arkitektur

• 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

Klarar den komplexa uppgifter? 

Ä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.

Kan jag lita på den i produktion?

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.

Avvägningar mellan kaskad- och fuserade arkitekturer 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.”
• Speech to Text”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.

Den vanligaste kritiken mot kaskadarkitekturer är att de tappar prosodiska signaler. Talet omvandlas till text, och intonation, rytm och känsla måste återskapas i utdata. Dessa signaler kan delvis återskapas genom explicit modellering, men de fångas inte lika naturligt som i fuserade lösningar. Andra aspekter, som fördröjning och turordning, kan oftast optimeras till likvärdig nivå i båda tillvägagångssätten.dynamisk 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

Fuserade arkitekturer fungerar på ett helt annat sätt. I en enda multimodal nätverksmodell sker igenkänning, resonemang och generering. Ljud in, ljud ut – utan någon insyn mellan stegen.

Att det saknas mellanliggande steg är både en fördel och en begränsning. Fuserad arkitektur kan bevara prosodiska signaler naturligt, eftersom talet aldrig bryts ner till text. Men det är svårt att införa skyddsräcken, byta ut enskilda komponenter eller inspektera mellanresultat för felsökning. Det är också svårt att finjustera STT för branschspecifika termer eller byta till en annan LLM för starkare resonemang och verktygsanvändning. Systemet är ett enda nätverk, och team är begränsade till de resonemangsförmågor som modellen har från början – vilket idag innebär lättare kärnor som inte matchar de starkaste LLM:erna vid komplexa uppgifter.

De fem arkitekturernaDatainsamling 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.

1. Grundläggande kaskad

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.

Ljud transkriberas, LLM genererar ett textsvar och TTS läser upp det. Alla steg arbetar med ren text, så du kan se, testa och styra allt.

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.

Exempel på användningsområden:

Detta är metoden bakom

2. Avancerad kaskad

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.
• Expressive Mode

LLM instruerar sedan TTS om hur talet ska levereras – inte bara vad som ska sägas – till exempel "lugnt", "med eftertryck" eller "med brådska", och anpassar tonen dynamiskt under samtalet. Turordningssystemet använder samma signaler för att avgöra när agenten ska svara eller lämna över. Talmodellerna ligger i samma stack utan nätverksfördröjning mellan komponenterna, så svaren blir snabba.

Arkitekturen behåller allt från grundläggande kaskad: full transparens, skyddsräcken på textnivå, möjlighet att byta ut komponenter, domänanpassning och tillgång till de starkaste modellerna för verktygsanvändning och resonemang. Den lägger till betydligt bättre prosodi, lägre fördröjning och smartare turordning. Team kan integrera en ny LLM samma vecka den släpps, eller finjustera STT för vårdtermer, utan att behöva bygga om andra delar.

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.

3. Hybrid kaskad och fuserad

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

Vissa arkitekturer skickar akustiska egenskaper (uttal, känsla, ton) från talet direkt in i LLM som inbäddningar, istället för att först omvandla till text. TTS förblir modulär.

Detta ger LLM rikare information om

Exempel på användningsområden:

Säkerhet och trygghet

4. Sekventiell fuserad

Skyddsräcken

En enda multimodal modell hanterar igenkänning, resonemang och generering i ett svep, en tur i taget. Det är arkitekturen bakom modeller som OpenAIs Realtime API.

Prosodin kan vara stark. Eftersom talet aldrig omvandlas till text bevarar modellen tempo, intonation och känslomässiga signaler naturligt. Korta samtal kan låta väldigt flytande.

Men det är svårt att införa skyddsräcken utan textlager, det finns få mellanresultat för felsökning och det är svårt att byta till en bättre LLM eller finjustera STT för din bransch. Resonemangskärnorna är ofta lättare än de starkaste LLM:erna, så komplexa verktygsanrop och flerstegsuppgifter blir lidande. När uppgiften kräver att lösa ett komplext problem räcker inte bara prosodi.

Exempel på användningsområden:

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.

5. Duplex fuserad

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.