Kako smo v šestih mesecih zgradili sistem za odzivno glasovno UI, ki deluje v realnem času

Pri glasovni umetni inteligenci je težje, kot se zdi, vedeti, kdaj spregovoriti. Ljudje si besedo brez težav predajo v delčku sekunde, prejšnji glasovni sistemi umetne inteligence pa temu ritmu niso mogli slediti. Njihova arhitektura z govornimi izmenjavami je temeljila na majhnih modelih, imenovanih detektorji izmenjav, ki so imeli nehvaležno nalogo: če uganejo prezgodaj, prekinejo uporabnika; če uganejo prepozno, je odziv počasen. Šele po odločitvi detektorja je lahko veliko večji veliki jezikovni model začel delovati.

GPT‑Live⁠, naš glasovni sistem tretje generacije, odstrani detektor izmenjav iz zvočne poti. Njegov glasovni model je polnodupleksen, kar pomeni, da lahko hkrati posluša in govori. S tem odpade potreba po ločenem detektorju, pogovor pa deluje bolj neposredno in naravno. Ko je potrebno globlje sklepanje ali uporaba orodij, se lahko GPT‑Live brez prekinitve toka pogovora posvetuje tudi z našimi prelomnimi modeli, kot je GPT‑5.5. Te zmožnosti skupaj dajejo GPT‑Live edinstveno kombinacijo pogovorne odzivnosti in inteligence.

Za zagotavljanje te izkušnje v velikem obsegu je bila potrebna nova sistemska arhitektura, optimizirana za majhno zakasnitev. Za razliko od običajnega sklepanja po načelu zahteva–odgovor naš sistem pretaka dohodni zvok v glasovni model in odhodni govor nazaj uporabniku, delegiranje pa obravnava po ločeni asinhroni poti. V zadnjih šestih mesecih smo prenovili sklepanje modela, upravljanje konteksta in prenos predstavnostnih vsebin, da bi govor od začetka do konca tekel gladko.

Arhitektura ustvarja tudi jasno mejo med osrednjo glasovno potjo in aplikacijsko logiko. Tako je mogoče vedenje aplikacije preprosto prilagoditi brez vpliva na odzivnost. Ta temelj poganja vse več zmožnosti Glasovnega ChatGPT‑ja, vključno z novo možnostjo upravljanja računalnika in usklajevanja agentov v namizni aplikaciji ChatGPT.

V tem prispevku bomo pojasnili, zakaj prejšnji sistemi z govornimi izmenjavami niso izpolnjevali naših potreb in kako smo novi sistem na vseh ravneh zasnovali za odzivnost. Obravnavali bomo sklepanje s stanjem, dinamično upravljanje konteksta, asinhrono delegiranje in optimizacijo na ravni protokola, ki skupaj zagotavljajo, da GPT‑Live deluje resnično v živo.

Prejšnje glasovne arhitekture so podedovale izmenično naravo besedilnih velikih jezikovnih modelov, vendar je bila vsaka izmenjava predstavljena kot ločen zvočni blok namesto besedila. V kaskadnih sistemih so si pretvorba govora v besedilo, veliki jezikovni model in pretvorba besedila v govor sledili zaporedno. To zaporedje je povečalo zakasnitev in prezrlo znake, kot sta ton in tempo.

Modeli za pretvorbo govora v govor so ta pristop izboljšali z neposredno obdelavo zvoka. Ko smo model naučili izvorno razumeti in ustvarjati govor, je lahko ohranil podrobnosti, izgubljene pri prepisovanju, in se odzval hitreje. Toda sistem se je pri odločanju, kdaj se lahko začne sklepanje, še vedno zanašal na detektor izmenjav. Model je obravnaval več interakcije, vendar je ta še vedno temeljila na govornih izmenjavah.

GPT‑Live nadzor nad pogovorom prepusti glasovnemu modelu: zvok teče v model in iz njega, globlje sklepanje ter uporaba orodij pa potekata asinhrono. Glavna naloga sistema je vzdrževati neprekinjeno zanko predstavnostnih vsebin. Druga opravila, kot sta priklic prelomnih modelov in trajno shranjevanje pogovora, potekajo zunaj poti v živo.

Ohranjanje neprekinjene predstavnostne zanke ni vedno preprosto. Vsaka zamuda pri prenosu, obdelavi ali sklepanju se lahko spremeni v slišen premor ali motnjo. Prejšnji sistem na podlagi govornih izmenjav je lahko dopuščal nekaj odstopanja pri času prihoda zvočnega bloka. Sistem predstavnostnih vsebin v živo pa mora vsako zaključeno zvočno enoto dostaviti pravočasno.

Predhodno delo pri Glasovnem ChatGPT in Realtime API-ju nam je zagotovilo pomemben temelj. Svojo glasovno infrastrukturo smo že prenovili⁠, da zvok in video neposredno pretaka v naše sisteme in iz njih z manjšo ter predvidljivejšo zakasnitvijo. GPT‑Live je to zasnovo nadgradil in predstavnostne vsebine pretakal vse do modela prek novega sklepnega sistema s stanjem, zasnovanega za neprekinjen pogovor.

Vendar je bilo pretočno sklepanje le del rešitve. Za dobro delovanje v produkciji smo morali zagotoviti tudi zanesljivo dostavo zvoka od odjemalca do sklada za sklepanje in obvladati izzive ohranjanja stanja.

Že zgodaj smo se odločili, da tok predstavnostnih vsebin namensko ločimo od aplikacijske in poslovne logike. Zvok med odjemalcem in glasovnim modelom potuje po namenski hitri poti. Delegiranje, uporaba orodij in druga aplikacijska opravila potekajo za asinhrono mejo RPC. Počasen klic orodja ali zaledna storitev lahko zakasni svoj rezultat, ne more pa ustaviti pretoka predstavnostnih vsebin.

Ta ločitev sistemu zagotavlja tudi jasno mejo za prilagajanje. Aplikacije lahko spreminjajo svoja orodja, pravilnike in delovanje zaledja, ne da bi vplivale na predstavnostni čelni del, ki skrbi za neprekinjen pretok zvoka. Pot v živo ostaja majhna, predvidljiva in osredotočena na delo, ki mora potekati v realnem času.

Predstavnostni čelni del in logiko sklepanja smo napisali v jeziku Go ter z njima nadomestili prejšnjo izvedbo Python asyncio. To je občutno izboljšalo tekočnost dostave okvirjev, saj je p95 novega sistema enak p50 prejšnjega.

WebRTC zagotavlja temelj za prenos. Zasnovan je za predstavnostne vsebine z majhno zakasnitvijo in lahko deluje tudi ob izgubi paketov, odklonu ure ter spremembah povezave odjemalca. Če paketi prispejo pozno, lahko WebRTC zvok neopazno raztegne, da prepreči vrzeli, nato pa predvajanje za kratek čas pospeši in znova ujame realni čas.

Z zmanjšanjem medpomnjenja in blokiranja po vsem sistemu lahko dosežemo odzivnost pod eno sekundo, kar pri pogovoru ljudje tudi pričakujejo.

Sklepanje s stanjem prinaša svoje operativne kompromise. Glasovna seja lahko ostane dejavna dolgo časa, vendar njen kontekst nenehno raste, primerki modela pa se zaganjajo in ustavljajo glede na povpraševanje.

Za reševanje teh vprašanj smo izdelali mehanizem za nemoteno predajo med primerki modela. Ko je potreben prehod, lahko ob obstoječem primerku modela ogrejemo nadomestnega, ga vnaprej napolnimo s trenutnim kontekstom seje, vzporedno izvajamo sklepanje na obeh in preklopimo, ko je novi primerek povsem pripravljen.

Isti osnovni mehanizem podpira tudi dinamično kompaktiranje konteksta. Med nadaljevanjem pogovora lahko nakopičeni kontekst nazadnje preseže omejitev konteksta modela. Kompaktiranje lahko kontekst zmanjša toliko, da ustreza omejitvi, vendar postopek zahteva čas. Ker spremeni pretekli kontekst, razveljavi tudi predpomnilnik ključev in vrednosti (KV) modela, v katerem so shranjeni ključi in vrednosti pozornosti iz že obdelanih žetonov. Obnova tega stanja zahteva novo predhodno polnjenje in povzroči dodatno zamudo.

Zato kompaktiranje obravnavamo kot še en upravljan prehod. Medtem ko se prvotni primerek modela še naprej pogovarja, sistem kompaktira kontekst in pripravi nadomestni primerek modela z novim kontekstom. Ko je ta primerek pripravljen, lahko preklopimo brez prekinitve toka predstavnosti. Tako lahko sistem podpira dolgotrajne klice in po potrebi izvede kompaktiranje.

Zahtevna opravila ostajajo zunaj poti v živo, zato pogovor niti med predajo ne izgubi ničesar.

Možnost GPT‑Live, da prikliče obstoječe prelomne modele, mu daje veliko moč, saj dejansko loči »govorjenje« od poglobljenega »razmišljanja«. Da bi ta arhitektura z dvema modeloma delovala kot enoten sistem, smo morali rešiti dva povezana inženirska izziva.

Prvič, rezultati se morajo vrniti dovolj hitro, da so uporabni v tekočem pogovoru, zato smo morali zmanjšati zakasnitev na celotni poti delegiranja, od usmerjanja in obdelave poziva do sklepanja in klicev orodij. Hkrati drugi sistemi v produktu še vedno potrebujejo ločena sporočila, zato smo morali tekoči pogovor predstaviti v njim razumljivi obliki.

Ko pošljemo delegirano opravilo, optimiziramo čas, dokler prelomni model ne ustvari nečesa uporabnega za pogovor. Glasovni model lahko med sklepanjem ali uporabo orodij prelomnega modela za kratek čas ohranja tok pogovora, ne more pa prikriti nepredvidljivo počasnega odziva. Zato smo celotno zanko delegiranja – usmerjanje, obdelavo poziva, sklepanje in klice orodij – vključili v časovni okvir odzivnosti.

Prva optimizacija je priprava prelomnega modela in vseh potrebnih orodij, še preden je zahtevano delegiranje. Ko se začne glasovna seja, aplikacijski strežnik ustvari sejo sklepanja za prelomni model in jo vnaprej napolni z začetnim kontekstom pogovora, da je poziv v celoti obdelan že pred prvo delegirano zahtevo.

To sejo sklepanja nato ohranimo razpoložljivo ves čas glasovnega pogovora in za zaporedne zahteve uporabljamo stabilno pripadnost seji. Skupaj s predpomnjenjem pozivov te tehnike zmanjšajo zakasnitev, napako delavca pa je še vedno mogoče preprosto odpraviti.

Na čas prejema uporabnega rezultata vplivajo tudi napor sklepanja, omejitve izhoda, sheme orodij in povratni klici med modelom in orodjem, zato smo te vzvode prilagodili za hitrejše odzive. Z zmanjšanjem dela na poti delegiranja smo glasovnemu modelu omogočili, da hitro vključi rezultate naših prelomnih modelov.

Čeprav glasovni model obdeluje neprekinjene tokove govora, številni okoliški sistemi še vedno delujejo z govornimi izmenjavami uporabnika in pomočnika, vključno s pogovornim uporabniškim vmesnikom ChatGPT ter deli naše analitične in varnostne infrastrukture. Aplikacijski strežnik zato prekrivajoč se in občasno dvoumen pogovor razčleni na ločena sporočila.

Med prihajanjem zvoka strežnik z delnimi prepisi in časovnimi signali ugotavlja, kdo govori, ter gradi čakalno vrsto sporočil. Najnovejše sporočilo ostane začasno; njegovo besedilo, čas in dodeljeni govorec se lahko ob prihodu dodatnega govora še spremenijo. Ko govorec govori dovolj dolgo, da je pripis zanesljiv, strežnik dokonča ustrezno sporočilo.

Prekrivanje govorcev to dodatno zaplete. Kratka potrditev pomočnika med uporabnikovim govorom (npr. »mm hmm« ali »OK«) ne bi nujno smela postati samostojno sporočilo. Vsebinsko pomemben pomočnikov medklic pa bi pogosto moral. Podobno dajemo prednost povezanosti prikazanih odgovorov pomočnika, tudi če uporabnik vmes spregovori.

Vsak pravilnik segmentiranja zahteva kompromis med svežino in gotovostjo. Prezgodnja potrditev ustvari razdrobljeno zgodovino in nestabilen vrstni red, predolgo čakanje pa zakasni prepise in funkcije, ki so od njih odvisne. Sistem zato vzdržuje dva povezana pogleda pogovora: domnevni pogled trenutnega stanja in verodostojen zapis izrečenega. Pogovorni pogled v uporabniškem vmesniku aplikacije lahko obdeluje posodobitve, zato uporablja domnevni pogled. Beleženje v analitični cevovod pa zahteva dokončen prepis.

Tako ima preostali del ChatGPT stabilen pogled na pogovor, ne da bi pot v živo omejili na govorne izmenjave.

Odzivnost se začne takoj, ko uporabnik klikne gumb. Pri GPT‑Live mora sistem vzpostaviti pot predstavnostnih vsebin in začeti dovajati zvok skozi model, preden se pogovor lahko začne. Zato je vsak del zagonskega zaporedja na kritični poti.

Kot smo že omenili, WebRTC zagotavlja trden temelj za delovanje v realnem času, vendar zagon običajne seje WebRTC zahteva presenetljivo veliko protokolnih usklajevanj in povratnih poti po omrežju. WebRTC je nastal pred osredotočenostjo na zmanjševanje povratnih poti, ki je oblikovala poznejše protokole, kot je QUIC. Zato njegovi temeljni protokoli pri skupni uporabi včasih ponavljajo delo. Vsak protokol je na primer vključeval lasten mehanizem proti napadom DoS, tudi kadar ta v okviru celotnega sklada WebRTC ni bil potreben.

Analizirali smo sklad in razvili skrajšani protokol povratnih poti WebRTC (WARP⁠(odpre se v novem oknu)), ki zagon predstavnostni in podatkov s šestih omrežnih povratnih poti skrajša na eno samo. WARP to doseže z nizom vzvratno združljivih izboljšav protokola: prenosom usklajevanja DTLS skupaj z ICE (SPED⁠(odpre se v novem oknu)), uporabo hitrejšega usklajevanja DTLS 1.3⁠(odpre se v novem oknu), vnaprejšnjim dogovorom usklajevanja SCTP (SNAP⁠(odpre se v novem oknu)) in vnaprejšnjim dogovorom o podatkovnih kanalih namesto uporabe DCEP⁠(odpre se v novem oknu).

WARP smo skupaj s sodelavci iz skupnosti WebRTC zasnovali kot nabor odprtih specifikacij, da lahko to delo koristi širšemu ekosistemu. Predloge razvijamo v delovni skupini TSVWG organizacije IETF, podpora za WARP pa je že dodana v libwebrtc in Pion, medtem ko delo poteka tudi pri drugih izvedbah WebRTC.

Po optimizaciji usklajevanja predstavnosti je izstopala še ena zamuda: signalizacijska izmenjava za posredovanje parametrov SDP, preden se WebRTC lahko poveže. Da bi to izmenjavo odstranili s kritične poti, smo razvili rešitev, ki ji pravimo Instant Connect. Te parametre dogovori vnaprej, ne da bi rezervirala strežniške zmogljivosti ali zahtevala spremembe obstoječih izvedb WebRTC.

Instant Connect deluje vzporedno s standardnim signalizacijskim tokom. Če so vnaprej dogovorjeni parametri veljavni, lahko strežnik vzpostavi sejo ob prihodu prvega predstavnostnega paketa. Če so zastareli ali neveljavni, signalizacijski tok že poteka, zato lahko odjemalec uporabi nadomestno pot brez dodatne zakasnitve.

Instant Connect in WARP skupaj močno skrajšata čas od uporabnikove namere do pretoka predstavnostnih vsebin v živo. Ker izmenjava SDP ni več na kritični poti, WARP pa strne usklajevanje prenosa, lahko odjemalec zdaj začne sejo z enim samim paketom UDP. Strežnik se lahko odzove takoj, preostali sistem pa začne opravljati tisto, kar je uporabniku zares pomembno: poslušati in odgovarjati.

Sistem je lahko na papirju videti hiter, a se ob resničnem glasovnem prometu vseeno ustavi. Preden smo modelu GPT‑Live omogočili pogovor z uporabniki, smo izvedli tihi preizkus, pri katerem smo majhen in postopoma naraščajoč delež produkcijskih sej Glasovnega ChatGPT‑ja usmerili tako v obstoječo izkušnjo naprednega glasovnega načina kot v naš novi sistem. Napredni glasovni način je uporabnikom še naprej deloval kot običajno, medtem ko je senčna pot izvajala sklepanje samo za branje. Tako smo sistem izpostavili resničnim odjemalcem, omrežjem, dolžinam sej in geografski porazdelitvi, ne da bi spremenili, kaj so slišali uporabniki.

Eno prvih spoznanj je bilo, da zmogljivosti ni mogoče zvesti zgolj na prepustnost grafičnih procesorjev. Glasovne seje ostajajo odprte in neprekinjeno pošiljajo okvirje, zato se morajo ob sklepanju sorazmerno povečevati tudi obdelovalniki tokov na strani osrednjega procesorja (CPE), čakalne vrste in omrežne poti. Pri resnični obremenitvi se je podporna komponenta nasičila prej, kot so napovedale ocene obremenitvenih preizkusov, zato so se zahteve za sklepanje kopičile, zakasnitev pa povečevala. Vprašanje o zmogljivosti smo spremenili iz »Koliko zahtev lahko obdela grafični procesor?« v »Koliko sočasnih sej lahko sistem vzdržuje, ne da bi kateri koli okvir zamudil rok?«

Preizkus je pokazal tudi, da je geografija ključnega pomena. Usmerjanje seje k oddaljenim zmogljivostim lahko povzroči zamude na več mestih med zagonom in pretakanjem. Uvajanje modelov smo začeli preverjati skupaj z regionalnimi zmogljivostmi in nastavitvami usmerjanja prometa, nato pa zakasnitev razčlenili glede na izvorno geografsko območje. Premik sklepanja bližje uporabnikom je pomagal, obenem pa potrdil širše spoznanje: odzivnost od začetka do konca je odvisna od vsake storitve na poti, ne le od strežnika modela.

Druge napake so se pokazale šele v življenjskih ciklih stvarnih sej. Dolgotrajne seje so razkrile obremenitve pomnilnika in trajnega shranjevanja. Ponovne povezave so obremenile kompaktiranje in obnovitev stanja. Običajne prekinitve povezav odjemalcev so razkrile tekmovalne pogoje pri usklajevanju zaustavitve. Te težave so se pri kratkih obremenitvenih preizkusih pojavile le redko, saj so bile odvisne od časa, nakopičenega stanja in vedenja onkraj meja storitev.

Nazadnje nas je produkcijsko preizkušanje prisililo, da izboljšamo zmožnost opazovanja in nadzor nad uvajanjem. Odkrili smo metrike, ki so združevale različne vire zakasnitev, nadzorne plošče, katerih skupni podatki so skrivali posamezne nedelujoče pogone, ter razhajanja nastavitev med preizkušenimi in uvedenimi sistemi. Zato smo dodali podrobnejšo telemetrijo, preverjanje glede na preizkušene konfiguracije, postopno povečevanje prometa ter možnost hitre osamitve ali onemogočenja posameznih poti. Tihi preizkus je postal zgodnja vaja pred zagonom: ne le za preverjanje, koliko prometa sistem lahko sprejme, temveč tudi, kako hitro lahko napako zaznamo, omejimo in odpravimo.

Za razširitev GPT‑Live na raven ChatGPT smo potrebovali povsem nov sistem, zgrajen okoli enega temeljnega načela: glas mora teči. Pretočno sklepanje polnodupleksnemu modelu neprekinjeno dovaja zvok. Namenska pot predstavnostnih vsebin zagotavlja zanesljivo dostavo okvirjev. Asinhrono delegiranje omogoča, da poglobljeno razmišljanje poteka vzporedno. Optimiziran prenos ohranja izkušnjo odzivno vse do uporabnika.

Arhitektura GPT‑Live že postaja širša platforma za interakcijo v realnem času. Poganja Glasovni ChatGPT, ki se iz pogovora širi v agentsko usklajevanje, in bo temelj prihodnjega API-ja GPT‑Live. Sčasoma bo omogočila glasovne izkušnje v več napravah, aplikacijah in modalnostih, ne da bi pri tem izgubile neposrednost, zaradi katere glasovni pogovor deluje v živo.

Če želite reševati takšne inženirske izzive, vabljeni k sodelovanju⁠.