Kuidas lõime kuue kuuga kiiresti reageeriva hääl-AI reaalajasüsteemi

Hääl-AI puhul on õige kõnehetke tuvastamine raskem, kui paistab. Inimesed annavad kõnevooru vaevata teisele üle sekundi murdosa jooksul, kuid varasemad hääl-AI süsteemid ei suutnud selle rütmiga sammu pidada. Nende voorupõhine arhitektuur tugines pisikestele mudelitele, mida nimetatakse voorudetektoriteks. Neil oli tänamatu ülesanne: kui nad otsustasid liiga vara, katkestati kasutaja; kui liiga hilja, tundus vastus aeglane. Alles pärast detektori otsust sai palju suurem LLM tööle asuda.

Meie kolmanda põlvkonna häälsüsteem GPT‑Live⁠ eemaldab voorudetektori kõnevoost. Selle häälmudel on täisdupleksne, mis tähendab, et see saab samal ajal kuulata ja rääkida. Nii pole eraldi detektorit vaja ning vestlus tundub vahetum ja loomulikum. Kui on vaja sügavamat arutlust või tööriistade kasutamist, saab GPT‑Live vestluse kulgu katkestamata kaasata ka meie tipptasemel mudeleid, näiteks GPT‑5.5. Koos annavad need võimed GPT‑Live’ile enneolematu kombinatsiooni vestluslikust reageerimiskiirusest ja nutikusest.

Sellise kogemuse pakkumine suures mahus nõudis uut, väikese viivituse jaoks optimeeritud süsteemiarhitektuuri. Erinevalt tavalisest päringu-vastuse inferentsist voogedastab meie süsteem sissetuleva heli häälmudelisse ja väljamineva kõne tagasi kasutajale, töödeldes delegeerimist eraldi asünkroonsel teel. Viimase kuue kuu jooksul kujundasime mudeli inferentsi, kontekstihalduse ja meediaedastuse ümber, et kõne liiguks sujuvalt algusest lõpuni.

Arhitektuur loob ka selge piiri keskse kõnevoo ja rakendusloogika vahele. Nii saab rakenduse käitumist hõlpsalt kohandada, ilma et reageerimiskiirus kannataks. Sellel alusel toimib ChatGPT Voice’is üha rohkem võimalusi, sealhulgas hiljuti lisatud arvuti juhtimine ja agentide koordineerimine ChatGPT töölauarakenduses.

Selles postituses selgitame, miks varasemad voorupõhised süsteemid meie vajadusi ei rahuldanud ja kuidas kujundasime uue süsteemi igal kihil kiiresti reageerivaks. Käsitleme olekupõhist inferentsi, dünaamilist kontekstihaldust, asünkroonset delegeerimist ja protokollitaseme optimeerimist, mis koos panevad GPT‑Live’i tunduma tõeliselt elavana.

Varasemad häälarhitektuurid pärisid tekstipõhiste LLM-ide voorupõhisuse, kuid teksti asemel esitati iga voor eraldi heliplokina. Kaskaadsüsteemides töötasid kõnetuvastus, LLM ja kõnesüntees üksteise järel. See järjestus lisas viivitust ning eiras selliseid vihjeid nagu hääletoon ja kõnetempo.

Kõnest-kõneks mudelid täiustasid seda lahendust, töödeldes heli otse. Mudeli õpetamine kõnet vahetult mõistma ja looma võimaldas säilitada transkriptsioonis kaduma minevaid üksikasju ning kiiremini vastata. Süsteem sõltus aga endiselt voorudetektorist, mis otsustas, millal inferents võis alata. Mudel kandis suhtluses suuremat rolli, kuid suhtlus jäi voorupõhiseks.

GPT‑Live annab vestluse juhtimise häälmudelile: heli liigub mudelisse ja sealt välja, samal ajal kui sügavam arutlus ja tööriistade kasutamine toimuvad asünkroonselt. Süsteemi põhiülesanne on hoida meediaring katkestusteta töös. Muu töö, näiteks tipptasemel mudelite kaasamine ja vestluse püsivalt salvestamine, toimub väljaspool reaalajavoogu.

Selle meediaringi katkestusteta töös hoidmine pole alati lihtne. Iga viivitus edastuses, töötluses või inferentsis võib muutuda kuuldavaks pausiks või moonutuseks. Varasem voorupõhine süsteem talus mõningast kõikumist selles, millal heliplokk kohale jõudis. Reaalajas töötav meediasüsteem peab aga edastama iga helikaadri õigel ajal.

Varasem töö ChatGPT Voice’i ja Realtime API kallal andis meile olulise aluse. Olime juba oma häältaristu ümber ehitanud⁠, et voogedastada heli ja videot otse süsteemidesse ning neist välja väiksema ja paremini prognoositava viivitusega. GPT‑Live arendas seda lahendust edasi, voogedastades meedia uue, pidevaks vestluseks loodud olekupõhise inferentsisüsteemi kaudu mudelini välja.

Vooginferents oli siiski vaid osa lahendusest. Et see tootmiskeskkonnas hästi toimiks, pidime tagama ka heli usaldusväärse edastamise kliendist inferentsipinusse ja lahendama olekupõhisusega kaasnevad probleemid.

Üks meie varaseid otsuseid oli eraldada meediavoog rakendus- ja äriloogikast. Heli liigub kliendi ja häälmudeli vahel mööda eraldi kiirteed. Delegeerimine, tööriistade kasutamine ja muu rakendustöö toimuvad asünkroonse RPC-piiri taga. Aeglane tööriistakutse või taustteenus võib viivitada oma tulemusega, kuid ei saa meediavoogu peatada.

See eraldatus annab süsteemile ka selge kohandamispiiri. Rakendused saavad muuta oma tööriistu, reegleid ja taustsüsteemi käitumist, mõjutamata heli liikumise eest vastutavat meediaesiliidest. Reaalajatee püsib väike ja prognoositav ning keskendub tööle, mis peab toimuma reaalajas.

Kirjutasime meediaesiliidese ja inferentsiloogika Go-s, asendades varasema Pythoni asyncio teostuse. See muutis kaadrite edastamise märksa sujuvamaks: uue süsteemi p95 võrdus eelmise süsteemi p50-ga.

Edastuse aluseks on WebRTC. See on loodud väikese viivitusega meedia jaoks ning suudab tööd jätkata ka paketikadude, kellanihke ja kliendi ühenduse muutuste korral. Kui paketid saabuvad hilja, võib WebRTC lünkade vältimiseks heli märkamatult venitada ja seejärel taasesitust korraks kiirendada, et reaalajale järele jõuda.

Vähendades kogu süsteemis puhverdamist ja blokeerimist, suudame pakkuda alla sekundilist reageerimiskiirust, mida inimesed vestluselt ootavad.

Olekupõhise inferentsiga kaasnevad omad käitamise kompromissid. Häälseanss võib püsida aktiivne kaua, kuid selle kontekst kasvab pidevalt ning mudelieksemplare käivitatakse ja suletakse nõudluse järgi.

Nende probleemide lahendamiseks lõime mudelieksemplaride vahel sujuva üleandmismehhanismi. Kui üleminek on vajalik, saame olemasoleva mudelieksemplari kõrval asenduse ette valmistada, eeltäita selle seansi praeguse kontekstiga, käitada inferentsi mõlemal paralleelselt ja ümber lülituda, kui uus eksemplar on täiesti valmis.

Sama põhimehhanism toetab ka konteksti dünaamilist tihendamist. Vestluse jätkudes võib kogunenud kontekst lõpuks ületada mudeli kontekstipiirangu. Tihendamine võib konteksti piirangu sisse mahutamiseks vähendada, kuid see toiming võtab aega. Kuna see muudab varasemat konteksti, muudab see kehtetuks ka mudeli võtme-väärtuse (KV) vahemälu, kuhu talletatakse varem töödeldud sõneüksuste tähelepanuvõtmed ja -väärtused. Selle oleku taastamine nõuab uut eeltäitmist ja tekitab lisaviivituse.

Selle asemel käsitleme tihendamist järjekordse hallatud üleminekuna. Algse mudelieksemplari vestlemise ajal tihendab süsteem konteksti ja valmistab uue kontekstiga ette asendava mudelieksemplari. Kui see eksemplar on valmis, saame sellele ümber lülituda ilma meediakatkestuseta. Nii saab süsteem toetada pikaajalisi kõnesid ja vajaduse korral konteksti tihendada.

Mahukas töö jääb reaalajateest kõrvale, mistõttu ei katke vestluse rütm isegi üleandmise ajal.

GPT‑Live’i võime kasutada olemasolevaid tipptasemel mudeleid annab sellele palju jõudu, eraldades sisuliselt „rääkimise” põhjalikumast „mõtlemisest”. Et see kahe mudeli arhitektuur mõjuks ühe süsteemina, tuli aga lahendada kaks omavahel seotud inseneriprobleemi.

Esiteks peavad tulemused naasma piisavalt kiiresti, et neist oleks käimasolevas vestluses kasu. Seetõttu pidime vähendama viivitust kogu delegeerimisteel alates suunamisest ja viipade töötlemisest kuni inferentsi ja tööriistakutseteni. Samal ajal vajavad toote teised süsteemid endiselt eraldiseisvaid sõnumeid, mistõttu pidime esitama käimasoleva vestluse neile arusaadaval kujul.

Delegeerimisel optimeerime aega hetkeni, mil tipptasemel mudel loob vestluse jaoks midagi kasulikku. Häälmudel saab vestlust lühikest aega jätkata, kuni tipptasemel mudel arutleb või tööriistu kasutab, kuid lõputult aeglast vastust ei suuda see varjata. Seepärast arvestasime reageerimisaja eelarvesse kogu delegeerimistsükli: suunamise, viipade töötlemise, inferentsi ja tööriistakutsed.

Esimene optimeerimisvõte on tipptasemel mudeli ja vajalike tööriistade ettevalmistamine enne delegeerimispäringut. Häälseansi alguses loob rakendusserver tipptasemel mudelile inferentsiseansi ja eeltäidab selle vestluse algkontekstiga, tagades, et viip on enne esimest delegeeritud päringut täielikult töödeldud.

Seejärel hoiame seda inferentsiseanssi kogu häälvestluse vältel kasutusvalmis ja kasutame järjestikuste päringute jaoks püsivat seansisidusust. Koos viipade vahemällu salvestamisega vähendavad need võtted viivitust, säilitades lihtsa taastumise töötaja tõrkest.

Kasuliku tulemuse vestlusse jõudmise aega mõjutavad ka arutluse põhjalikkus, väljundipiirangud, tööriistaskeemid ning mudeli ja tööriista vahelised päringuringid. Kiiremate vastuste saamiseks kohandasime ka neid tegureid. Vähendades delegeerimisteel vajaliku töö hulka, võimaldasime häälmudelil meie tipptasemel mudelite tulemusi kiiresti vestlusse kaasata.

Kuigi häälmudel töötab pidevate kõnevoogudega, kasutavad paljud seda ümbritsevad süsteemid endiselt kasutaja ja assistendi voorusid. Nende hulka kuuluvad ChatGPT vestlusliides ning osad meie analüüsi- ja ohutustaristust. Seetõttu eraldab rakendusserver kattuva ja vahel mitmeti mõistetava vestluse üksikuteks sõnumiteks.

Heli saabudes kasutab server osalisi transkriptsioone ja ajastussignaale, et järeldada, kelle kõnevoor parajasti on, ning koostada sõnumijärjekord. Uusim sõnum jääb esialgseks: lisanduva kõne põhjal võivad muutuda selle tekst, ajastus ja kõnelejale omistamine. Kui kõneleja on hoidnud kõnevooru piisavalt kaua, et omistus oleks usaldusväärne, kinnitab server vastava sõnumi.

Kõnelejate kattumine muudab selle keerulisemaks. Assistendi lühike kinnitus kasutaja kõne ajal (nt „mm hmm” või „okei”) ei peaks tingimata muutuma eraldi sõnumiks. Sisuline assistendi vahemärkus peaks seda aga sageli tegema. Samuti eelistame kuvatavate assistendi vastuste sidusust isegi siis, kui kasutaja vahele räägib.

Iga segmenteerimispoliitika teeb kompromissi värskuse ja kindluse vahel. Liiga varane kinnitamine tekitab killustunud ajaloo ja ebastabiilse järjestuse; liiga pikk ootamine viivitab transkriptsioonide ja neist sõltuvate funktsioonidega. Seetõttu haldab süsteem vestlusest kaht seotud vaadet: praeguse oleku esialgset vaadet ja öeldu lõplikku kirjet. Rakenduse kasutajaliidese vestlusvaade suudab uuendusi töödelda, seega kasutab see esialgset vaadet. Analüüsikonveierisse logimine nõuab aga lõplikku transkriptsiooni.

Nii saab ülejäänud ChatGPT vestlusest stabiilse ülevaate, ilma et reaalajas kõnevoole surutaks peale voorupõhisust.

Kiire reageerimine algab kohe, kui kasutaja nuppu klõpsab. GPT‑Live’i puhul peab süsteem enne vestluse algust looma meediatee ja hakkama heli mudelisse edastama. Seetõttu on käivitusjada iga osa kriitilisel teel.

Nagu eespool märgitud, annab WebRTC reaalajasuhtluseks tugeva aluse, kuid tavalise WebRTC-seansi käivitamine nõuab üllatavalt palju protokolli ühenduse ja edasi-tagasi võrguringe. WebRTC loodi enne seda, kui hilisemate protokollide, näiteks QUIC-i kujundamisel hakati keskenduma võrguringide vähendamisele. Seetõttu kordavad selle alusprotokollid koos kasutamisel mõnikord sama tööd. Näiteks sisaldas iga protokoll oma DoS-vastast mehhanismi isegi siis, kui seda polnud kogu WebRTC-pinu kontekstis vaja.

Analüüsisime pinu ja töötasime välja protokolli WebRTC Abridged Roundtrip Protocol (WARP⁠(avaneb uues aknas)), mis vähendab meedia ja andmete käivitamiseks vajalike võrguringide arvu kuuelt ühele. WARP saavutab selle tagasiühilduvate protokollitäiustustega: DTLS-ühenduse kaasamine ICE-sse (SPED⁠(avaneb uues aknas)), kiirema DTLS 1.3⁠(avaneb uues aknas) kätluse kasutamine, SCTP-ühenduse eelläbirääkimine (SNAP⁠(avaneb uues aknas)) ning andmekanalite eelläbirääkimine DCEP⁠(avaneb uues aknas)-i kasutamise asemel.

Koostasime WARP-i avatud spetsifikatsioonide kogumina koostöös WebRTC kogukonna partneritega, et sellest tööst saaks kasu kogu ökosüsteem. Edendame ettepanekuid IETF-i TSVWG töörühmas. WARP-i tugi on juba lisatud nii libwebrtc-le kui ka Pionile ning töö käib ka teistes WebRTC teostustes.

Pärast meediaühenduse optimeerimist jäi silma veel üks viivitus: SDP-parameetrite jagamiseks kasutatav signaliseerimisvahetus, mis peab toimuma enne WebRTC ühenduse loomist. Selle vahetuse kriitiliselt teelt eemaldamiseks töötasime välja lahenduse, mida nimetame Instant Connectiks. See lepib parameetrid eelnevalt kokku ilma serverivõimsust reserveerimata ja olemasolevaid WebRTC teostusi muutmata.

Instant Connect töötab standardse signaliseerimisvoo kõrval. Kui eelnevalt kokkulepitud parameetrid kehtivad, saab server esimese meediapaketi saabudes seansi luua. Kui need on aegunud või kehtetud, on signaliseerimisvoog juba käimas, seega saab klient kasutada varulahendust ilma lisaviivituseta.

Instant Connect ja WARP vähendavad koos märgatavalt aega kasutaja kavatsusest reaalajas meediavoo alguseni. Kuna SDP-vahetus pole enam kriitilisel teel ja WARP koondab edastuskätluse, saab klient nüüd alustada seanssi ühe UDP-paketiga. Server saab kohe vastata ja ülejäänud süsteem võib alustada kasutajale tegelikult olulise tööga: kuulamise ja vastamisega.

Paberil võib süsteem näida kiire, kuid tegeliku kõnekoormuse korral ikkagi takerduda. Enne kui lubasime GPT‑Live’il kasutajatega vestelda, tegime vaikse testi, mis suunas väikese ja järk-järgult kasvava osa ChatGPT Voice’i tootmisseanssidest nii olemasolevasse täiustatud häälrežiimi kui ka meie uude süsteemi. Täiustatud häälrežiim teenindas kasutajaid tavapäraselt edasi, samal ajal kui varitee käitas inferentsi kirjutuskaitstud režiimis. Nii puutus süsteem kokku tegelike klientide, võrkude, seansipikkuste ja geograafilise jaotusega, ilma et kasutajate kuuldav kogemus oleks muutunud.

Üks esimesi õppetunde oli see, et läbilaskevõimet ei saanud taandada GPU läbilaskele. Häälseansid püsivad avatuna ja saadavad pidevalt kaadreid, seega peavad koos inferentsiga skaleeruma ka protsessoripoolsed vootöötlejad, järjekorrad ja võrguteed. Tegeliku koormuse all saavutas üks tugikomponent oma piiri varem, kui meie koormustestide hinnangud ennustasid. Seetõttu hakkasid inferentsipäringud kuhjuma ja viivitus järjest kasvama. Muutsime läbilaskevõime küsimuse „Mitut päringut suudab GPU töödelda?” küsimuseks „Mitut samaaegset seanssi suudab süsteem käigus hoida nii, et iga kaader jõuab kohale õigel ajal?”

Test näitas ka, et geograafiline asukoht on esmatähtis. Seansi suunamine kaugel asuvasse taristusse võib lisada viivitust nii käivitamise kui ka voogedastuse mitmes etapis. Hakkasime mudelite juurutamist valideerima koos piirkondliku võimsuse ja liikluse suunamise seadistusega ning seejärel analüüsisime viivitust lähtepiirkondade kaupa. Inferentsi kasutajatele lähemale toomine aitas, kuid kinnitas ka üldisemat õppetundi: läbiv reageerimiskiirus sõltub igast teel olevast teenusest, mitte ainult mudeliserverist.

Teised tõrked ilmnesid alles realistlike seansside kogu elutsükli jooksul. Pikaajalised seansid tõid esile mälu- ja püsimahu koormuse. Taasühendumised panid proovile tihendamise ja oleku taastamise. Tavapärased kliendi ühenduse katkestused paljastasid konkurentsiolukordi sulgemisprotsessi käigus. Lühikestes koormustestides ilmnesid need probleemid harva, sest need sõltusid ajast, kuhjunud olekust ja käitumisest teenustevahelistel piiridel.

Lõpuks sundis tootmiskeskkonnas testimine meid parandama jälgitavust ja juurutamise juhtimist. Leidsime mõõdikuid, mis segasid kokku eri viivitusallikad, töölaudu, mille koondnäitajad varjasid üksikuid tõrkuvaid mootoreid, ning seadistuserinevusi testitud ja juurutatud süsteemide vahel. Seetõttu lisasime üksikasjalikuma telemeetria, võrdluse teadaolevalt toimivate seadistustega, etapiviisilise liikluse suurendamise ning võimaluse üksikuid teid kiiresti isoleerida või keelata. Vaiksest testist sai varajane käivitamisproov, mis ei näidanud üksnes süsteemi vastuvõetava liikluse hulka, vaid ka seda, kui kiiresti suudame tõrke tuvastada, piirata ja sellest taastuda.

GPT‑Live’i viimine ChatGPT mastaapi nõudis täiesti uut süsteemi, mis rajati ühele põhimõttele: hääl peab katkematult liikuma. Vooginferents varustab täisdupleksmudelit pidevalt heliga. Eraldi meediatee tagab kaadrite usaldusväärse edastamise. Asünkroonne delegeerimine võimaldab põhjalikumal mõttetööl paralleelselt jätkuda. Optimeeritud edastus tagab kiire reageerimise kuni kasutajani välja.

GPT‑Live’i aluseks olev arhitektuur on juba kujunemas laiemaks reaalajasuhtluse platvormiks. See toetab ChatGPT Voice’i arengut vestlusest agentide koordineerimiseni ning saab aluseks tulevasele GPT‑Live’i API-le. Aja jooksul võimaldab see häälkogemusi kasutada rohkemates seadmetes, rakendustes ja modaalsustes, kaotamata vahetust, mis paneb häälvestluse tunduma elavana.

Kui soovid lahendada selliseid inseneriprobleeme, tule tööta meiega⁠.