Barge-in die wel werkt: spraakdetectie afstellen op telefoonaudio

Eén detector, twee totaal verschillende taken

Spraakdetectie klinkt als één ding, en in de meeste codebases is het ook één component. Maar het moet twee vragen beantwoorden die vrijwel niets met elkaar te maken hebben, en het afstellen alsof het één instelling is, is precies waar het misgaat.

De eerste vraag is: is de beller klaar met zijn beurt, en mag ik nu antwoorden? Dat is beurtdetectie, die draait terwijl je agent stil is, en fout zitten kost je een lange ongemakkelijke stilte of een doormidden gehakte zin. De tweede vraag is: praat de beller op dit moment terwijl ik zelf praat, en moet ik dus stoppen? Dat is barge-in, die draait terwijl je agent spreekt, en fout zitten levert je een agent op die over mensen heen walst of een agent die stilvalt zodra er een vrachtwagen langsrijdt.

Waarom studio-instellingen het op een telefoonlijn begeven

Vrijwel elke gepubliceerde benchmark voor een spraakdetector draait op schone, breedbandige audio met één spreker, opgenomen via een fatsoenlijke microfoon. Een telefoongesprek is niets van dat alles. Klassieke telefonie geeft je acht kilohertz smalband. Daarmee verdwijnt het grootste deel van het frequentiebereik dat medeklinkers onderscheidbaar maakt, en wat overblijft wordt ook nog gecomprimeerd.

Daar komt bij dat het kanaal van de beller zelden stil is, ook niet als de beller dat wel is. Er wordt bewust comfortruis bijgemengd zodat de lijn niet dood klinkt. Er staat een televisie aan, er rijdt een auto, er is een kantoortuin, er huilt een peuter. Er is wachtmuziek van een systeem waarin de beller zelf ook wacht. Een detector die is afgesteld om in een studio goed te werken leest een flink deel daarvan als spraak, en elke valse detectie onderbreekt je agent of overtuigt hem ervan dat de beller nog praat terwijl die op antwoord wacht.

De valse onderbreking, en wat je daarna doet

De nuttigste knop op dit hele terrein is een minimale onderbrekingsduur: een regel die zegt dat een flard gedetecteerde spraak op het bellerkanaal pas als onderbreking telt als ze lang genoeg duurt om een woord te zijn. Een kuch, een deur, een lettergreep uit andermans gesprek zakken alle drie voor die test en je agent praat gewoon door.

agent speaking:  "Your appointment is confirmed for Tues-"
  [vad]   speech detected on caller channel   0.12s
  [turn]  below minimum interruption duration (0.30s)
  [vad]   caller channel silent again          0.19s
  ---> not an interruption. agent keeps speaking.

agent speaking:  "Your appointment is confirmed for Tues-"
  [vad]   speech detected on caller channel   0.34s
  [turn]  interruption committed, agent stops
  [stt]   caller said: "sorry, Wednesday"
  ---> real interruption. agent yields.

Op onze eigen keten ligt die drempel op 300 milliseconden, naar beneden bijgesteld vanaf de 500 die het framework standaard aanhoudt. Wij gaan bewust onder die standaard zitten, omdat een werkelijk ongeduldige beller op een echte telefoonlijn resoluut begint te praten, en een halve seconde wachten voordat je de beurt afstaat lang genoeg is om twee mensen tegelijk aan het woord te hebben, wat precies de situatie is die barge-in moet voorkomen.

De interessantere vraag is wat er gebeurt als er tóch een valse detectie doorheen glipt, want dat gebeurt altijd. Naïeve implementaties stoppen de agent midden in een zin, wachten op een transcriptie die nooit komt omdat het geluid geen spraak was, en laten beide partijen in stilte achter tot de beller iets zegt. Die beller heeft geen idee dat de agent die zin ooit nog zou afmaken.

[turn]  interruption committed, agent stops mid-sentence
  [stt]   ...no transcript. line noise, not speech.
  [turn]  false interruption timeout reached  (1.5s)
  ---> agent resumes its own sentence instead of standing there

De oplossing is een tijdslimiet met een hervatting: leverde een onderbreking binnen anderhalve seconde geen transcriptie op, behandel die dan als vals en laat de agent zijn eigen zin afmaken. Dat verandert een dood gesprek in een nauwelijks merkbare hapering, en dat is het verschil tussen een agent die wankel overkomt en een agent die beheerst overkomt.

De knop waar je werkelijk aan draait

Zodra je de twee taken uit elkaar haalt, zien de instellingen er niet langer uit als een configuratiebestand maar als een productbeslissing. Ze wegen stuk voor stuk dezelfde twee faalvormen tegen elkaar af, en er is geen combinatie die ze allebei wegneemt.

Dit weegt zwaarder dan het lijkt, omdat de vloer van de beurtdetectie een harde ondergrens is voor hoe snel je agent überhaupt kan antwoorden. Zet je die hoog om valse onderbrekingen te bestrijden, dan heb je stilletjes de vlotheid van het hele product afgetopt, op een manier die geen enkele modelupgrade ooit terughaalt. Dat argument hebben we ontleed in het latency-budget van een telefoongesprek, waar beurtdetectie de grootste afzonderlijke post in een gat van een seconde blijkt te zijn.

Wie aan de knop zit: keten of aanbieder

Hier zit een structurele tweesprong waar teams op stuklopen als ze van architectuur wisselen. In een klassieke keten van herkenning, model en synthese bepaal jij de beurtwisseling: de detector draait aan jouw kant en jij bepaalt elke drempelwaarde. In een native-audio realtime-model hoort de beurtwisseling bij de aanbieder, en krijg jij de knoppen die hij beschikbaar stelt.

Aan de realtime-kant stellen we de beurtdetectie-parameters van de aanbieder per assistant beschikbaar in plaats van ze te verbergen, met het bereik begrensd zodat een typefout geen gesprek kan opleveren dat nooit de beurt afstaat. Bij een waarde buiten bereik loggen we een waarschuwing en houden we de standaard aan, want een foute configuratie hoort terug te vallen op verstandig gedrag in plaats van een lopend gesprek onderuit te halen.

llm_config.turn_detection = {
  "threshold":           0.5,    // 0.0 - 1.0    hoeveel signaal als spraak telt
  "prefix_padding_ms":   300,    // 0 - 2000     audio bewaard van vóór de aanzet
  "silence_duration_ms": 200     // 100 - 2000   stilte voordat de beurt sluit
}

Twee van die parameters stellen we bewust helemaal niet beschikbaar, en die reden is het waard om te benoemen: de aanroepen die een modelantwoord aanmaken en onderbreken vormen de bouwstenen van de gesprekslus. Een klant een van beide laten uitzetten levert een assistant op die geen gesprek kan voeren, en dat is een supportticket en geen functie.

Ook de standaardwaarden verschillen per model op manieren die je makkelijk mist. Waar een realtime-model dat dicht tegen tekst aan zit een beurt al na tweehonderd milliseconden stilte kan sluiten, zetten wij een native-audiomodel standaard op een aanzienlijk langer venster en op de minst schrikachtige gevoeligheidsstand die er is, juist zodat een geluid op de achtergrond tijdens een pauze geen beurt opent. De getallen van de ene aanbieder overnemen bij de andere is een betrouwbare manier om een werkende agent kapot te laten aanvoelen.

Waarom we de clouddetector uit het gesprekspad haalden

Er is een populaire optie op dit terrein: beurtdetectie uitbesteden aan een gehoste dienst die met een slimmer model voorspelt of een zin inhoudelijk af is, en niet alleen akoestisch stil. Dat werkt bij twijfelgevallen echt beter. Wij hebben hem gedraaid, en in juli 2026 zijn we bewust teruggegaan naar detectie die lokaal draait.

Drie redenen, in volgorde van hoe zwaar ze wogen. Ten eerste zette het een netwerkverzoek naar een dienst van derden rechtstreeks in het pad van het lopende gesprek, en dat is juist de plek in een telefoniesysteem waar een extra afhankelijkheid het minst welkom is. Ten tweede zat er een verzoeklimiet aan die bij ons volume ruim voldoende was en de schaal waarvoor we bouwen niet zou overleven, waarmee het een plafond wordt in plaats van een bouwsteen. Ten derde, en dat gaf de doorslag: als die dienst traag antwoordde, viel het framework zonder iets te melden terug op gewone lokale detectie, waardoor ons beurtgedrag stilletjes meeveranderde met de reactietijd van iemand anders.

Dat is dezelfde redenering die we op failover en op configuratie in het algemeen toepassen: een systeem dat luid faalt is veiliger dan een systeem dat stil terugvalt. Het is ook waarom de lokale detectorinstellingen hierboven platformbreed zijn en niet per assistant. Ze beschrijven hoe onze agents naar een telefoon luisteren, en dat hoort niet per klant te verschillen zonder een gesprek over het waarom.