Hoe realtime spraak-AI werkt (STT → LLM → TTS, uitgelegd)

Hoe realtime spraak-AI werkt (STT → LLM → TTS, uitgelegd)
BACK TO BLOGS
ON THIS PAGE
Back to top

Wat gebeurt er tussen "hallo" en het antwoord van de medewerker, in begrijpelijke taal? Geen jargon, geen vage omschrijvingen.

Kort samengevat:

  • Realtime spraak-AI is een driestaps proces met twee coördinerende elementen. Audio komt binnen → spraak-naar-tekst zet het om in woorden → een LLM (Language Learning Machine) bepaalt wat ermee moet gebeuren → tekst-naar-spraak zet het antwoord weer om in audio. Daar omheen zit een systeem voor beurtwisseling (wanneer is de beller gestopt?) en het afhandelen van onderbrekingen (wat als ze ons onderbreken?). Dat is het hele proces.

  • Het hele proces moet binnen ongeveer 700 ms afgerond zijn, anders voelt het niet meer menselijk aan. Boven die drempelwaarde worden bellers ongemakkelijk, herhalen ze zichzelf en hangen ze op. Daaronder vergeten ze dat ze met een AI praten. De hele stack van Retell duurt ongeveer 600 ms van begin tot eind. Dat is geen toeval. Het is het resultaat van elke fase die naadloos overgaat in de volgende, in plaats van te wachten tot de vorige is afgerond.

  • De meeste vertraging zit verborgen op plekken waar je het niet verwacht. Niet in STT, niet in TTS, maar in beurtwisselingsbeslissingen en de tijd tot het eerste token in LLM. Als je build traag aanvoelt, zijn dat de twee plekken waar je als eerste moet kijken.

  • Streaming is de truc. STT genereert elke ~50 ms gedeeltelijke transcripties in plaats van te wachten op een complete zin. LLM streamt tokens zodra ze gegenereerd worden. TTS streamt audiofragmenten voordat het volledige antwoord beschikbaar is. Niets van dit alles werkt als een van de stappen wacht tot de vorige "klaar" is.

  • De stacks van 2026 lijken qua architectuur allemaal op elkaar. Wat "productieklaar" onderscheidt van "demo" is de kwaliteit van de orchestratie: VAD-tuning, beurtwisselingsmodellen, afhandeling van onderbrekingen en latentie van functieaanroepen. Daar gaat de daadwerkelijke investering in engineering naartoe.

Hoe realtime spraak-AI daadwerkelijk werkt

Zonder de marketing is een spraakassistent in feite een simpel proces. Audio komt binnen via de telefoon. Software zet het om in tekst. Een taalmodel leest die tekst, bepaalt wat er gezegd of gedaan moet worden en genereert een antwoord. Andere software zet het antwoord weer om in audio. De audio gaat weer de telefoon uit. De beller hoort het, zegt iets, en de cyclus herhaalt zich. Dat is alles. Dat is het hele product.

De reden dat het jaren duurde om die simpele lus werkend te krijgen, is dat alles in minder dan een seconde moet gebeuren. Elk onderdeel van de pipeline moet continu gestreamd worden. Elke overgang tussen fasen moet vrijwel direct plaatsvinden. Twee fasen moeten realtime beslissingen nemen: beurtwisseling ("is de beller al uitgepraat?") en het afhandelen van onderbrekingen ("de beller is net door me heen gaan praten, wat moet ik doen?"). Als er ook maar één fout gaat, valt het gesprek volledig stil, iets wat bellers direct merken, zelfs als ze niet precies kunnen uitleggen waarom.

Dit artikel is een nuchtere, marketingvrije versie van hoe een spraakassistent in 2026 daadwerkelijk werkt. We doorlopen een enkel gesprek van begin tot eind, bekijken waar de latentie zich schuilhoudt, bespreken de orkestratie die productieomgevingen van demo's scheidt en ruimen een aantal veelvoorkomende misvattingen uit de weg over wat er zich achter de schermen afspeelt.

Als je een projectmanager bent die wil begrijpen wat je engineers bouwen, dan is dit iets voor jou. Als engineer die een platform evalueert en overweegt het zelf te bouwen, dan is dit ook iets voor jou. Hoe dan ook: aan het einde weet je precies wat er gebeurt als iemand "hallo" zegt en een AI "hi" terugzegt.

Zestig seconden naar de pijpleiding

Hier is de liftversie.

Een spraakagent bestaat uit drie onderdelen op een rij met daar omheen nog twee andere onderdelen. De drie onderdelen op een rij zijn: STT → LLM → TTS . Spraak-naar-tekst zet de audio van de beller om in woorden. Een groot taalmodel leest die woorden (plus uw systeemprompt, het gesprek tot dan toe en een beschrijving van alle tools die de agent kan aanroepen) en bepaalt of er gesproken moet worden of dat er een functie aangeroepen moet worden. Tekst-naar-spraak zet het antwoord van het model weer om in audio.

De twee dingen die in die pijplijn verweven zijn, zijn beurtwisseling en onderbreking . Beurtwisseling is het systeem dat bepaalt wanneer de beller zijn of haar gedachte heeft afgerond, zodat de agent kan reageren. Dit is veel moeilijker dan het lijkt, omdat mensen constant midden in een zin pauzeren. Onderbreking is het systeem dat omgaat met een beller die de agent midden in een antwoord onderbreekt. Ook dit is moeilijker dan het lijkt, omdat je de spraakherkenning direct moet stoppen, moet stoppen met wat het model wilde zeggen en opnieuw moet beginnen met luisteren.

Waarom dit moeilijk is: elke fase moet streamen, en elke fase heeft een latentiebudget dat je niet mag overschrijden. Zorg dat de hele cyclus onder de ~700 ms blijft en het gesprek voelt natuurlijk aan. Ga je eroverheen, dan niet. Dat is de hele uitdaging.

Wat gebeurt er in 600 milliseconden: De zeven fasen van één enkele draai

Laten we een gespreksronde van begin tot eind doorlopen. De beller zegt: "Hallo, ik wil graag een schoonmaakbeurt boeken voor aanstaande dinsdagmiddag" — en 600 ms later antwoordt de medewerker. Dit is alles wat er daartussen gebeurt.

1. Audio komt binnen via de telefoon.

Het gesprek komt eerst binnen op uw telefonielaag: een SIP-trunk als u uw bestaande provider gebruikt, of een WebRTC-stream als u een Retell-nummer gebruikt. In beide gevallen verschijnt de audio van de beller als een stroom kleine pakketten, meestal van 20 ms per stuk. Vanaf het moment dat de beller begint te spreken, stromen deze pakketten met lijnsnelheid uw stack binnen. De netwerkroundtrip is het eerste onderdeel van de latentie die u niet kunt omzeilen: doorgaans 30-80 ms, afhankelijk van de locatie en provider, nog voordat er AI-werk heeft plaatsgevonden.

2. Spraakactiviteitsdetectie (VAD)

VAD is het lichtgewicht model dat bepaalt of de binnenkomende audio spraak of stilte is. Het wordt in milliseconden uitgevoerd op elk binnenkomend fragment. Waarom is dit belangrijk? Om twee redenen. Ten eerste: je wilt geen stilte naar je spraak-naar-spraak-systeem sturen – dat verspilt rekenkracht en verstoort de beurtwisseling. Ten tweede: VAD is het eerste signaal dat het beurtwisselingssysteem gebruikt om te bepalen wanneer de beller is gestopt met spreken. Een slechte VAD is een van de stille boosdoeners voor spraak-AI. Als je hem te strak afstelt, wordt de beller midden in een woord afgesneden. Als je hem te los afstelt, voelt de agent traag aan. Professionele systemen gebruiken hiervoor een klein neuraal netwerk dat specifiek is getraind op audio van telefoongesprekken, in plaats van een algemene energiedrempel.

3. Gedeeltelijke transcripties van spraak-naar-tekststromen

Zodra VAD zegt "dit is spraak", wordt de audio doorgestuurd naar een streaming STT-engine. Het sleutelwoord is streaming . De STT wacht niet tot de beller klaar is. Het genereert elke ~50 ms gedeeltelijke transcripties — onvolledige schattingen die worden aangepast naarmate er meer audio binnenkomt. Dus na 200 ms zou de transcriptie bijvoorbeeld kunnen zeggen: "Hallo, ik wil graag een afspraak maken." Na 400 ms: "Hallo, ik wil graag een schoonmaakafspraak maken voor." Na 700 ms de volledige zin. Moderne STT-systemen kunnen ook diarizatie (wie er spreekt — handig als er meer dan één persoon aan de lijn is), tussentijdse correctie (het aanpassen van "twee" naar "half drie" zodra er meer context is) en ruisbestendigheid voor bellers die de speaker gebruiken of zich op luchthavens bevinden.

Als je je afvraagt waar de meeste zelfgemaakte oplossingen stilletjes de mist in gaan, dan is dit er een van. De herkenningsnauwkeurigheid is prima in 2026. Het lastige zit hem in het streamen, de gedeeltelijke transcripties en de detectie van het einde van de spraak – geen van deze functies krijg je van een generieke API die "een audiobestand transcribeert".

4. Door beurtwisseling wordt bepaald wie klaar is.

Dit is de duistere kunst. Beurtwisseling is het model dat bepaalt wanneer de beller zijn gedachte heeft afgerond, zodat de medewerker kan reageren. Het is niet zomaar "wacht 500 ms na het laatste woord". Mensen pauzeren midden in een zin, halen adem, zeggen "uh" terwijl ze nadenken. Een naïeve time-out zal hen ofwel afkappen ("Hallo, ik wil graag boeken—" "Oké, wat wilt u boeken?") of traag aanvoelen ("...voor volgende dinsdagmiddag." [stilte] [stilte] "Oké, ik zal het even nakijken.").

Het productieantwoord van 2026 is een klein, snel neuraal model voor beurtwisseling dat de audiostream, het gedeeltelijke transcript en de gesprekscontext gebruikt om een waarschijnlijkheid te berekenen dat de beller zijn of haar beurt heeft beëindigd. Het model wordt tientallen keren per seconde bijgewerkt. Wanneer de betrouwbaarheid een drempelwaarde overschrijdt, begint de beurt van de agent. Het beurtwisselingsmodel van Retell verwerkt backchannels ("mm-hmm", "juist"), aarzelende pauzes en detectie van het einde van een uiting binnen een responstijd van ongeveer 600 ms. (Hoe onze beurtwisseling werkt.)

Als je één ding uit dit artikel meeneemt: het grootste verschil tussen "menselijk aanvoelen" en "robotachtig aanvoelen" zit hem in deze fase. Qua latency neemt het beurtelings spreken 150-300 ms van je totale reactietijd in beslag. Qua kwaliteit is het de belangrijkste factor die bepaalt of je bellers de agent respecteren.

5. De LLM kiest zelf wat hij/zij gaat doen.

Zodra de beller aan de beurt is, wordt het taalmodel opgeroepen met alle benodigde informatie: uw systeemprompt, het volledige transcript van het gesprek, alle opgehaalde kennis uit uw kennisbank en de lijst met beschikbare functies. Het model heeft bij elke beurt twee keuzes: een gesproken antwoord genereren of een tool aanroepen (de afspraak boeken, het gesprek doorverbinden, het klantrecord opzoeken).

De latentieparameter die hier van belang is, is de tijd tot het eerste token (TTFT) . Niet hoe lang het duurt voordat het volledige antwoord verschijnt, maar hoe lang het duurt voordat het eerste woord wordt gestreamd. Een goede 2026 LLM haalt de TTFT in 150-300 ms voor een typische spraakopdracht. Zodra de tokens beginnen te streamen, blijven ze streamen met een snelheid van 50-100 per seconde, wat sneller is dan de meeste mensen spreken. De TTS-fase begint dus voordat het model klaar is met denken. ( Prijsdetails voor de LLM-tier. )

Als het model ervoor kiest om een functie aan te roepen in plaats van te spreken, betaal je een andere latentie: de heen- en terugreis naar je webhook (het boeken van de afspraak in Cal.com, het schrijven van de lead in Salesforce). Voor de meeste vooraf ingestelde functies is dit snel — enkele honderden milliseconden. Voor trage API's van derden kan het langer duren, en de agent zegt dan meestal iets als "een momentje, ik controleer dat even" om de wachttijd te overbruggen. ( Boeking, doorverbinden, kennisbank. )

6. Tekst-naar-spraak streamt audio terug

Zodra de LLM de eerste paar tokens uitzendt, start TTS. Moderne spraakassistenten streamen audio in blokken van 200-400 ms, waardoor de beller het eerste woord hoort voordat het volledige antwoord is gegenereerd. Dit is de truc die ervoor zorgt dat het hele proces snel aanvoelt: elke fase genereert output voordat de vorige fase is voltooid.

Het spraakmenu van 2026 kent drie niveaus: stemmen van het Retell-platform en Cartesia voor snelle, natuurlijke spraak met lage latentie voor $ 0,015/min; ElevenLabs voor merkstemmen van de hoogste kwaliteit voor $ 0,040/min; en een lange reeks stemklonen voor premium toepassingen. De tijd tot het eerste geluid (TTFA) is de belangrijkste indicator: in productieomgevingen is dit 100-200 ms. In blinde tests met standaardstemmen kunnen de meeste bellers ze niet betrouwbaar van een menselijke stem onderscheiden. Wat spraak-AI in 2026 onderscheidt, is niet langer de stem zelf, maar de timing.

7. Afhandeling van verstoringen door binnenvaartschepen

Bovenstaand proces werkt prima, totdat de beller doet wat mensen nu eenmaal doen: onderbreken. Ze beginnen door de agent heen te praten. Misschien realiseerden ze zich dat ze woensdag bedoelden in plaats van dinsdag. Misschien zijn ze geïrriteerd. Hoe dan ook, de agent moet onmiddellijk stoppen met praten, de rest van het geplande antwoord laten vallen en snel weer beginnen met luisteren.

Dit is een vorm van ongeoorloofde communicatie, en het is wederom een stille doodsteek voor spraak-AI. Een naïef model blijft de rest van de TTS voorlezen terwijl de beller aan het woord is – het meest frustrerende gevoel tijdens een telefoongesprek. Een goed model kort de TTS in tot één audiofragment (minder dan 100 ms), negeert wat het LLM-model wilde zeggen en start een nieuwe spraak-naar-spraakstroom vanaf de nieuwe audio van de beller. Extra punten als het model weet wat er vóór de onderbreking is gezegd, zodat het zichzelf niet herhaalt.

Tel het budget bij elkaar op: netwerk (50 ms) + VAD/beurtwisseling (200 ms) + LLM TTFT (250 ms) + TTS TTFA (100 ms) = ongeveer 600 ms. Zo voelt een spraakassistent menselijk aan. Geen van deze getallen is magisch. Ze zijn gewoon het resultaat van agressief streamen en niet wachten op dingen die niet hoeven te wachten.

Hoe "realtime" eruitziet op productieschaal

Drie bedrijven die momenteel precies met deze pijpleiding werken, zijn het bestuderen waard.

Pine Park Health. Eerstelijnszorg voor seniorenwoningen. Het heen en weer bellen van patiënten zorgde voor een enorme drukte in hun agenda. Ze plaatsten een Retell-spraakassistent voor hun afsprakenplanning – dezelfde spraakgestuurde workflow (STT) → spraakgestuurde communicatie (LLM) → tekst-naar-spraak (TTS) als alle andere aanbieders, maar dan zo strak georganiseerd dat bellers niet afhaakten. De NPS voor afsprakenplanning steeg met 38%. Hun medisch personeel hoefde niet langer de helft van de dag aan de telefoon door te brengen.

SWTCH. Bedrijf voor het opladen van elektrische voertuigen. Wanneer een bestuurder strandt bij een defecte laadpaal, is "we bellen u morgen terug" geen antwoord. Ze schakelen Lucas – een medewerker van Retell – in. Lucas neemt binnen enkele seconden op, begeleidt bestuurders bij dringende probleemoplossing en doet dit 24/7 via hetzelfde zevenstappenproces. De kosten voor ondersteuning daalden met meer dan 50%.

Medische datasystemen. Incasso. Gereguleerd, gevoelig voor de toon, onvergeeflijk als gesprekken mislopen. Ze zetten Retell-medewerkers in voor inkomende gesprekken en verwerken nu 100% van het inkomende volume, waarbij slechts 30% van de gesprekken wordt doorverbonden naar een medewerker. Ze innen maandelijks zo'n $280.000. De workflow is dezelfde als die we zojuist hebben besproken. Het verschil zit hem in de discipline van de orkestratie en een reeks kleine beslissingen over beurtwisseling, ingrijpen en promptontwerp. ( Meer klantverhalen vindt u hier. )

De rode draad door alle drie: geen van hen probeerde de pipeline opnieuw uit te vinden. Ze kozen een platform dat de orchestratie al had opgelost, concentreerden zich op de onderdelen die specifiek waren voor hun bedrijf – de prompt, de kennisbank, de functie-eindpunten – en brachten het op de markt.

Waar de latentie naartoe gaat (en waar de meeste builds de mist in gaan)

Als je niets anders onthoudt van dit artikel, onthoud dan dit: STT en TTS zijn niet waar de meeste latentie zich schuilhoudt. Die zijn snel. De twee plekken waar latentie daadwerkelijk optreedt, zijn beurtwisseling en LLM-tijd tot het eerste token.

Hieronder een typische budgetverdeling voor 2026 voor één gespreksronde in een productieomgeving:

  • Netwerkresponstijd (round-trip): 30-80 ms. Dit hangt voornamelijk af van de geografische locatie en uw SIP-provider. Hier kunt u weinig aan doen.

  • VAD + beurtwisseling: 150-300 ms. Dit is de grootste variabele. Een slecht beurtwisselingsmodel kost je 500 ms of meer aan waargenomen latentie zonder dat dit ooit in een benchmark zichtbaar is.

  • Definitief transcript van STT: 50-100 ms na het einde van de spraak. Streaming verbergt het grootste deel hiervan in de vorige fase.

  • Tijd tot eerste token bij LLM: 150–400 ms. Sterk afhankelijk van modelkeuze en promptgrootte.

  • Tijd tot eerste audio bij TTS: 100-200 ms.

  • Functieaanroep (indien uitgevoerd): 100-500 ms, afhankelijk van de API.

Een productieklare stack verwerkt de spraak- of stilzwijgende onderdelen hiervan in ongeveer 600 ms. Een middelmatige stack doet er 1,2 tot 1,8 seconden over. De middelmatige stack voelt aan als praten met een chatbot die tekst voorleest. De goede stack voelt aan als praten met een persoon.

De twee belangrijkste factoren om te optimaliseren zijn: kies een snel LLM-model met een lage TTFT (GPT 4.1, Claude 4.6 Sonnet en Gemini 3.0 Flash halen allemaal de productiedoelstellingen) en gebruik een beurtwisselingsmodel dat is getraind op echte gespreksgegevens, niet op een vaste drempelwaarde voor stilte. (Waarom latentie belangrijk is)

Veelvoorkomende misvattingen over hoe dit in de praktijk werkt

Een paar dingen die het vermelden waard zijn.

"Het zijn gewoon drie API's die aan elkaar zijn geplakt." Dat klopt, totdat je probeert het realtime te laten aanvoelen. Dan realiseer je je dat de verbinding belangrijker is dan de API's zelf. De orchestratielaag — VAD-tuning, beurtwisselingsmodel, streamingcoördinatie, afhandeling van inkomende gesprekken, routering van functieaanroepen — is waar productieklare stacks zich daadwerkelijk bevinden. Je kunt STT-leveranciers in een dag wisselen. Je kunt de orchestratielaag niet vervangen zonder de helft van het systeem te herschrijven.

"Grotere LLM = betere spraakagent." Niet echt. Voor de meeste spraaktoepassingen is een snel model uit het middensegment met een goede prompt beter dan een traag topmodel. De tijd tot het eerste token is belangrijker dan de pure kwaliteit van de redenering, omdat de perceptie van de beller bijna volledig wordt bepaald door de latentie. Retell laat je LLM's wisselen met een dropdownmenu, juist omdat het juiste antwoord afhangt van de toepassing: voor complexe redeneringen is de Claude 4.6 Sonnet geschikt, voor grote volumes en goedkope toepassingen de GPT 5 nano, voor meertalige toepassingen de Gemini 3.0 Flash, en de standaard is de GPT 4.1.

"Streaming is een leuke extra." Het is de hele architectuur. Zonder streaming wacht je tot de beller klaar is, dan wacht je tot STT klaar is, dan wacht je tot LLM klaar is, dan wacht je tot TTS klaar is, en dan ben je al meer dan 3 seconden kwijt voordat er ook maar één byte audio terugkomt. De reden dat spraakagenten in 2026 menselijk aanvoelen, is dat elke fase al output begint te produceren voordat de vorige fase is afgerond.

"Je hebt een op maat getraind model nodig om dit voor jouw specifieke toepassing te laten werken." Bijna altijd nee. De 2026-stack is zo ontworpen dat het model generiek blijft en je prompt, kennisbank en functies de aanpassingen verzorgen. Op maat getrainde modellen zijn trager om te ontwikkelen, trager in het uitvoeren van inferenties en verouderd zodra er een nieuw basismodel beschikbaar komt. De meeste teams die "een op maat getraind model nodig hadden" hadden eigenlijk een betere prompt en een betere kennisbank nodig.

"De stem is het moeilijkste." Eigenlijk is het nu een van de makkelijkste onderdelen. Standaard TTS-stemmen zijn in blinde tests functioneel niet te onderscheiden van menselijke stemmen. De moeilijkste onderdelen zijn beurtwisseling en het onderbreken van gesprekken – dingen die bellers zich niet bewust merken, maar die ze absoluut voelen.

Wat volgt?

Realtime spraak-AI is een streamingpipeline: audio-in → STT → LLM → TTS → audio-uit, met beurtwisseling en inmenging. Elke fase genereert output voordat de vorige fase is voltooid, de hele cyclus duurt minder dan 700 ms en de orkestratie is wat de productieversie van de demoversie onderscheidt. Dat is de architectuur. Het is geen magie. Het zijn een paar specifieke technische problemen die goed zijn opgelost.

De meeste operators hoeven dit niet zelf te bouwen. Ze moeten het echter wel goed genoeg begrijpen om te weten wat ze kopen, waar ze om moeten vragen en waar de bouw mis kan gaan als ze de verkeerde leverancier kiezen. Als dit artikel je al een heel eind op weg heeft geholpen, zit je goed.

Als u de pipeline in actie wilt zien, kunt u het beste zelf iets bouwen. Meld u gratis aan op dashboard.retellai.com — nieuwe accounts ontvangen $10 aan tegoed, goed voor ongeveer 90 minuten gesprekstijd. Of boek een demo en we laten u de orchestratie zien aan de hand van uw daadwerkelijke belvolume. Wilt u de latency zelf ervaren? Bel dan onze live demo-lijn en spreek met een agent die de bovenstaande pipeline gebruikt.

Veelgestelde vragen

V: Wat betekent STT → LLM → TTS eigenlijk? A: Het zijn de drie kernstappen van een spraakgestuurde AI-pipeline. STT (spraak-naar-tekst) zet de audio van de beller om in tekst. Het LLM (groot taalmodel) leest die tekst plus uw systeemprompt en bepaalt wat er gezegd moet worden of welke functie moet worden aangeroepen. TTS (tekst-naar-spraak) zet het antwoord weer om in audio. Voeg daar de beurtwisseling en de afhandeling van onderbrekingen aan toe en dat is de complete stack.

V: Hoe snel moet realtime spraak-AI zijn? A: Een responstijd van minder dan ~700 ms is de drempel waarbij een gesprek menselijk aanvoelt. Daarboven beginnen bellers te onderbreken, zichzelf te herhalen en op te hangen. Productiesystemen zoals Retell draaien op ongeveer 600 ms.

V: Waar gaat de latentie eigenlijk naartoe? A: Voornamelijk naar beurtwisseling en LLM-tijd tot het eerste token, niet naar STT of TTS. Een typisch budget: netwerk 50 ms, VAD/beurtwisseling 200 ms, LLM TTFT 250 ms, TTS eerste audio 100 ms. STT loopt parallel met de spraak van de beller, dus voegt er bijna niets aan toe.

V: Wat is streaming en waarom is het belangrijk? A: Elke fase van de pipeline genereert output voordat de vorige fase is voltooid. STT genereert gedeeltelijke transcripties elke ~50 ms. LLM streamt tokens zodra ze worden gegenereerd. TTS streamt audio in blokken van 200-400 ms. Zonder streaming wacht elke fase op de vorige en duurt het meer dan 3 seconden voordat er ook maar één byte audio naar de beller wordt teruggestuurd.

V: Wat is beurtwisseling en waarom is het moeilijk? A: Beurtwisseling is het systeem dat bepaalt wanneer de beller is uitgesproken, zodat de agent kan reageren. Het is moeilijk omdat mensen midden in een zin pauzeren, ademhalen en "uh" zeggen terwijl ze nadenken. Een simpele time-out onderbreekt bellers of voelt traag aan. De oplossing van 2026 is een klein neuraal model dat is getraind op echte audio-opnamen van gesprekken en dat een waarschijnlijkheid tientallen keren per seconde bijwerkt.

V: Wat is het afhandelen van een onderbreking? A: Dat is wat er gebeurt als de beller door de agent heen begint te praten. Een goed werkend systeem stopt TTS binnen 100 ms, negeert de rest van het geplande antwoord en start een nieuwe spraak-naar-spraakstream met de nieuwe audio van de beller. Een slecht werkend systeem blijft doorpraten – het meest vervelende gevoel tijdens een telefoongesprek.

V: Moet ik de pipeline zelf bouwen? A: Vrijwel nooit in 2026. De orchestratie — VAD, beurtwisseling, barge-in, streamingcoördinatie, routing van functieaanroepen — is het onderdeel waar serieuze technische investeringen in gaan. De meeste teams die het zelf proberen te bouwen, eindigen met een tragere, slechtere versie van wat er kant-en-klaar beschikbaar is. Bouw de onderdelen die specifiek zijn voor uw bedrijf: prompt, kennisbank, functie-eindpunten, workflows.

V: Maakt de keuze van het LLM-model zoveel uit? A: Ja, maar vooral voor de tijd tot het eerste token, niet zozeer voor de kwaliteit. Een snel model uit het middensegment met een goede prompt is in de meeste gevallen beter dan een traag topmodel. Met Retell kun je LLM-modellen wisselen via een dropdownmenu: GPT 4.1 is de standaard, Claude 4.6 Sonnet voor complexere redeneerfuncties, GPT 5 nano voor een laag volume en Gemini 3.0 Flash voor meertalige toepassingen. ( Prijzen. )

V: Hoe past het aanroepen van functies in de pipeline? A: Wanneer het LLM besluit een functie aan te roepen in plaats van te spreken, verstuurt het platform een HTTPS-webhook met gestructureerde argumenten die het model uit het gesprek heeft gehaald, en wacht vervolgens op het antwoord. Deze heen-en-terugreis zorgt voor vertraging – meestal een paar honderd milliseconden voor snelle API's, meer voor trage. Bij langere wachttijden zegt de agent doorgaans "een momentje, ik controleer het even" om de wachttijd te overbruggen.

V: Wat is het verschil tussen spraak-AI en een IVR? A: Een IVR is een vast keuzemenu (druk op 1 voor facturering). Spraak-AI werkt volgens hetzelfde principe: open spraak als invoer, LLM-redenering in het midden, natuurlijk antwoord als uitvoer. Bellers hoeven niet door menu's te navigeren. Ze praten gewoon.

ROI Calculator
Estimate Your ROI from Automating Calls

See how much your business could save by switching to AI-powered voice agents.

All done! 
Your submission has been sent to your email
Oops! Something went wrong while submitting the form.
   1
   8
20
Oops! Something went wrong while submitting the form.

ROI Result

2,000

Total Human Agent Cost

$5,000
/month

AI Agent Cost

$3,000
/month

Estimated Savings

$2,000
/month
Live Demo
Probeer onze live demo

Een demodemonummer van Retell Clinic Office

Bedankt! Je inzending is ontvangen!
Oeps! Er is iets misgegaan bij het verzenden van het formulier.

Read Other Blogs

Revolutionize your call operation with Retell