PolyAI har udgivet Dialog-RSN-1, en dialogmodel der opfatter kundens tale direkte i stedet for at vente på en teksttransskription. Det nye er fusionen: turn-taking, talegenkendelse, funktionkald og svargenerering styres i ét audio-native lag på inputsiden, mens stemmen udadtil fortsat styres separat via tekst-til-tale. Ifølge selskabet kører modellen allerede i produktion med svartider under 300 millisekunder og har givet højere containment hos en restaurantkæde samt lavere latenstid hos et forsikringsselskab. Målgruppen nu: større virksomheder med mange opkald — via PolyAIs egen platform.
Hvad audio-native betyder i praksis
De fleste callbot-løsninger har været kaskader: først tale-til-tekst (ASR), så forståelse og beslutning i en sprogmodel, og til sidst tale ud igen via TTS. Svagheden: når kun ASR’ens “bedste gæt” sendes videre, forsvinder tonefald, tøven og usikkerhed, før hjernen (LLM’en) ser noget som helst. Den anden lejr — fuld speech-to-speech — holder lyden hele vejen, men indkapsler ofte stemmen i selve modellen og gør det sværere at styre udtale, brandstemme og compliance på output.
Dialog-RSN-1 vælger en midtervej. Den er audio-bevidst på input og læser rå lyd, men overlader output til en separat og styrbar TTS. I praksis: systemet kan reagere på pauser, suk og rytme i samtalen, mens man stadig kan styre stemmen med præcise SSML-prompter, talehastighed og ordbetoning. Små ting med stor effekt på oplevelsen. Et host, en halv sætning.
Arkitektur og performance under motorhjelmen
PolyAI beskriver en request-baseret model, ikke en altid-streamende. En høj-recall VAD og timere afgør, hvornår modellen skal spørges, og det første output-token markerer turstatus: EMPTY, ONGOING eller COMPLETE. Med andre ord: billige akustiske cues vælger tidspunktet for at spørge, mens modellen — med hele konteksten — tager selve turbeslutningen.
For at komme under 300 ms nævnes flere teknikker: prefill af attention-cache mens brugeren taler, append-only promptskabelon for at undgå cache-invalidering, routing af samme opkalder til samme GPU, en finjusteret spekulativ “drafter” med gennemsnitlig accept på 3,9 tokens, og auto-reasoning lært i reinforcement-fasen. Ifølge kilden peger latency-målet på A100-klassen og kandidatstørrelser omkring 8B tætte til 30B sparse parametre.
Hvor solide er påstandene
Alt ovenstående stammer fra PolyAIs egen udmelding via MarkTechPost. Der er endnu ikke offentlig adgang til deres Dialog-Eval benchmark, som de planlægger at open-source. Derfor bør sub-300 ms og effektgevinster betragtes som leverandør-rapporterede, indtil uafhængige tests foreligger. Fair nok — men mål selv i et POC-miljø, inklusive netværk, TTS og teleinfrastruktur, ikke kun modelinferenstid.
Et forbehold mere: request-baseret probing kræver stram koordinering mellem VAD, timere, modelkald og TTS-start. Fejlmargin her kan give afbrydelser, “double talk” eller kunstig tøven. Det kan fikses, men ikke gratis.
Produkt og levering
Dialog-RSN-1 er engelsksproget ved lancering. Leveres via PolyAIs platform. Ikke som open weights eller offentlig API. Eksisterende kunder kan aktivere den nu; nye kan søge early access. Målgruppen er de store, høj-volumen miljøer, ikke hobbyister eller SMB.
Det skubber beslutningen over i enterprise-køb: kontrakter, DPA’er, datalokalitet og revisionsadgang. Og ja, leverandørafhængighed. Forhandl dataejerskab, eksport af logs og auditspor før en bred udrulning.
Rapporterede effekter og indbyggede begrænsninger
PolyAI rapporterer en relativ containment-forbedring på 11 procentpoint hos en restaurantgruppe samt 37 procent lavere latenstid hos en forsikringskunde. Containment betyder typisk andelen af opkald, der løses uden at nå en menneskelig agent. En meningsfuld KPI — men tricky. Små ændringer i routing, åbningstider, måleperioder og callsammensætning kan flytte tallet. Baselines og stikprøvestørrelser er ikke offentliggjort.
Konklusionen er enkel: brug tallene som signal, ikke som facit. Gentag målingerne i egen drift med klare definitioner for FRT, FCR, P95-latens og korrekthed for function calling. Gerne blindtest på udvalgte flows. Ellers måler man konfiguration, ikke model.
Hvad det betyder for integration og hverdag
IVR-integration ændrer sig en smule. Når input er audio-native, får modelkaldet værdi af rå lyd, men man bevarer kontrol over TTS-udgangen. Det gør det nemmere at matche eksisterende brandstemmer. CRM- og ticket-systemer skal bindes tæt via function calling. Her ligger styrke — og risiko. Et forkert værktøjsopkald kan lave rod i ordrer, betalinger eller aftaler.
Drift og omkostninger
PolyAI peger på A100-optimering og et spænd fra cirka 8B til 30B aktive parametre afhængigt af arkitektur. Det siger noget om GPU-klassens størrelse og prisspænd. Fordi arkitekturen er request-baseret, behøver man ikke en dedikeret GPU låst til hver samtale, men routing og opgaveplanlægning bliver kritisk, så man udnytter cache og locality effektivt. Dårlig routing = højere P95.
Cost-tradeoff mod kaskader er mindre lige til end man tror. Ja, man sparer typisk ASR→LLM roundtrips og tab af prosodi, men man betaler i strengere krav til latency-målinger, akustiske fejlkilder og GPU-nærhed. Sammenlign totalen: tele-gateway, VAD, model, function-kald, TTS, logging. Ikke kun modelprisen pr. minut.
Sikkerhed, risici og governance
Function calling er fantastisk, indtil det ikke er det. Hallucinationer eller fejlklassificeret intent kan udløse et forkert kald. Indfør streng validering af hvilke værktøjer modellen må kalde, schema-validering af input, og et menneske-i-loop på højrisikohandlinger. Auditability er en reel udfordring, når input er rå lyd. Der er brug for sikre transskripter (efterfølgende), tidsstemplede beslutningslogs og mulighed for at genskabe en session.
Compliance afhænger af branche. Finans og kortdata: PCI DSS. Sundhed: HIPAA i USA. I EU: GDPR. Nogle regioner opererer med PDPA-lignende rammer. Rå lyd kan indeholde mere personfølsomt end en trimmed transskription — baggrundslyde, navne, tredjeparter. Det kræver tydelige retention-politikker, kryptering i transit og i hvile, samt adgangsstyring. Og i visse flows: maskering af betalingsoplysninger, før de overhovedet rammer modellen.
Konkurrentbilledet
Alternativerne findes. GPT Realtime og Gemini Live tilbyder fuld-dupleks samtaler og speech-to-speech-oplevelser. De holder lyden hele vejen, men gør ofte output-stemmen sværere at kontrollere i detaljer, fordi den er indlejret i modellen. Kaskade-stakke (klassisk ASR + LLM) giver deterministisk TTS-kontrol men taber akustiske nuancer. Dialog-RSN-1 lægger sig midt imellem: audio ind, kontrollerbar TTS ud.
PolyAI rapporterede 100+ enterprise-kunder og 2.000+ live-deployments ved Series D i december 2025. Det er et stærkt markedssignal, men selskabsrapporteret. For købere betyder det primært, at leverandøren er battle-tested i store miljøer — vurderet udefra. Ikke et bevis for netop denne models overlegenhed.
Hvad beslutningstagere konkret bør gøre nu
Start med et smalt POC: 2–3 opkaldstyper med klar forretningsværdi. Sæt målene på forhånd: FRT, FCR, containment-rate, P95-latens, korrekthed for function calling, samt klage-rate. Aftal også rollback-kriterier. Ingen skam i at rulle tilbage, hvis P95 løber.
Planlæg en phased udrulning. Hold et menneske i loop på høje risikotransaktioner, sæt grænser for værktøjsopkald, og overvåg turn-taking-fejl og “double talk”. Udfør desuden sikkerhedsreview med fokus på dataflow for rå lyd, kryptering, nøglehåndtering samt retention og sletning.
Kort opsummering
Det lovende: lavere latenstid, bedre håndtering af samtalens rytme, og fortsat kontrol over TTS-stemmen. Det, der holder igen: leveringsmodellen er lukket, kun engelsk ved launch, og effekttallene er endnu ikke uafhængigt verificeret. Drift og compliance er ikke småting — især ikke med rå audio i kredsløb.
Bundlinje? Audio-native input med separat stemmekontrol er et klogt kompromis. Men først når man måler hele kæden — tele, VAD, model, TTS — ser man, om det faktisk føles hurtigere.
Praktisk tjekliste til teknisk due diligence
- Latensmåling end-to-end: mål P50/P95 fra kundeord til første byte i TTS. Med netværk og VAD-timers.
- Turn-taking-test: mål afbrydelser, “double talk”, respons på pauser og små ytringer.
- TTS-kontrol: bevis for SSML-understøttelse, udtaleordbøger, tempo og prosodisk konsistens.
- Function calling-sikkerhed: schema-validering, værktøjshvidlister, rollbacks, sandbox mod produktionssystemer.
- Observability: per-opkald trace med tidsstempler for VAD, modelkald, function, TTS-start/-slut.
- Data og compliance: kryptering, retention-politikker for rå lyd og transskripter, adgangsstyring, auditlogge.
- Cost-model: GPU-routing, cache-hit-rate, trafikmønstre, TCO vs. kaskader eller speech-to-speech.
Metode og kilder
Alle tekniske påstande om Dialog-RSN-1, arkitektur, turn-taking-token og performance er fra PolyAIs udmelding via MarkTechPost. Kaskade- og speech-to-speech-tradeoffs er velbeskrevne i industrien og understøttes også i den nævnte kilde. Performance- og kundeeffekt-tal er leverandør-rapporterede og bør valideres i uafhængige tests, når Dialog-Eval bliver offentlig — eller i egne piloter.
Governance- og compliance-henvisninger følger etablerede standarder: PCI DSS for betalingskort, HIPAA for sundhedsdata i USA, GDPR i EU, og PDPA-lignende rammer i udvalgte regioner. Krav og tolkning varierer pr. branche og jurisdiktion, så lokal juridisk vurdering er nødvendig.
Åbne spørgsmål
Til testadgang: eksisterende kunder kan aktivere nu, nye kan søge early access. Uafhængige benchmarks må ventes på eller laves i egne ringfence-deployments med klar måleplan.
Sidste ord
Dialog-RSN-1 ændrer valget mellem kaskade og speech-to-speech. Hurtigere samtaler, mindre friktion og stadig fuld stemmekontrol. Det svære er ikke slides. Det er driften. Forskellen mærkes først, når man sidder med det i hænderne.
