Kaip per šešis mėnesius sukūrėme sparčiai reaguojančio balso DI realiojo laiko sistemą

Balso DI nustatyti, kada kalbėti, yra sunkiau, nei gali pasirodyti. Žmonės be pastangų perduoda vienas kitam pokalbio eilę per sekundės dalį, tačiau ankstesnės balso DI sistemos nespėjo palaikyti tokio ritmo. Jų pokalbio eilėmis pagrįsta architektūra rėmėsi mažyčiais modeliais, vadinamais eilės detektoriais, kuriems teko nedėkinga užduotis: nusprendus per anksti, naudotojas nutraukiamas, o per vėlai – atsakas atrodo vangus. Tik detektoriui priėmus sprendimą galėjo pradėti veikti gerokai didesnis LLM.

Mūsų trečiosios kartos balso sistema GPT‑Live⁠ pašalina eilės detektorių iš garso kelio. Jos balso modelis yra visiškai dvikryptis, todėl gali klausytis ir kalbėti vienu metu. Taip nebereikia atskiro detektoriaus, o pokalbis tampa betarpiškesnis ir natūralesnis. Kai reikia gilesnio protavimo ar įrankių, GPT‑Live taip pat gali netrikdydama pokalbio eigos pasitelkti mūsų priešakinius modelius, pvz., GPT‑5.5. Šios galimybės suteikia GPT‑Live precedento neturintį pokalbio spartos ir intelekto derinį.

Norint tokią patirtį užtikrinti dideliu mastu, reikėjo naujos, mažai delsai optimizuotos sistemos architektūros. Kitaip nei vykdant įprastą užklausos ir atsako išvedimą, mūsų sistema srautiniu būdu siunčia gaunamą garsą į balso modelį, o sugeneruotą kalbą – naudotojui, užduotis perduodama atskiru asinchroniniu keliu. Per pastaruosius šešis mėnesius pertvarkėme modelio išvedimą, konteksto valdymą ir medijos perdavimą, kad kalba sklandžiai tekėtų nuo vieno galo iki kito.

Ši architektūra taip pat aiškiai atskiria pagrindinį balso kelią nuo programos logikos. Todėl programos veikimą lengva tinkinti nepaveikiant atsako spartos. Šis pagrindas suteikia galią vis gausesnėms ChatGPT Balsas funkcijoms, įskaitant neseniai pristatytą galimybę valdyti kompiuterį ir koordinuoti agentus ChatGPT darbalaukio programėlėje.

Šiame įraše paaiškinsime, kodėl ankstesnės pokalbio eilėmis pagrįstos sistemos neatitiko mūsų poreikių ir kaip sukūrėme naują sistemą, užtikrinančią spartų atsaką kiekviename lygmenyje. Aptarsime būseną išlaikantį išvedimą, dinaminį konteksto valdymą, asinchroninį užduočių perdavimą ir protokolo lygmens optimizavimą – visa tai kartu leidžia GPT‑Live atrodyti išties veikiančiai gyvai.

Ankstesnės balso architektūros perėmė tekstinių LLM pokalbio eilėmis pagrįstą veikimą, tik kiekvieną eilę atstojo ne tekstas, o atskiras garso duomenų blokas. Pakopinėse sistemose kalbos vertimas į tekstą, LLM ir teksto vertimas į kalbą buvo vykdomi nuosekliai. Toks nuoseklus vykdymas didino delsą ir nepaisė tokių ženklų kaip tonas bei kalbėjimo tempas.

Kalbos vertimo į kalbą modeliai patobulino šį metodą tiesiogiai apdorodami garsą. Išmokius modelį tiesiogiai suprasti ir generuoti kalbą, jis galėjo išsaugoti transkribuojant prarandamas detales ir atsakyti greičiau. Tačiau nustatydama, kada galima pradėti išvedimą, sistema vis dar rėmėsi eilės detektoriumi. Modelis atliko didesnę sąveikos dalį, tačiau sąveika ir toliau vyko pokalbio eilėmis.

GPT‑Live pokalbio valdymą patiki balso modeliui: garsas perduodamas į modelį ir iš jo, o gilesnis protavimas bei įrankių naudojimas vyksta asinchroniškai. Pagrindinė sistemos užduotis – palaikyti nenutrūkstamą medijos ciklą. Kiti darbai, pavyzdžiui, priešakinių modelių iškvietimas ir pokalbio išsaugojimas, atliekami už tiesioginio kelio ribų.

Užtikrinti, kad šis medijos ciklas nenutrūktų, ne visada paprasta. Bet kokia perdavimo, apdorojimo ar išvedimo delsa gali virsti girdima pauze ar iškraipymu. Ankstesnė sistema, paremta pokalbio eilėmis, galėjo toleruoti nedidelius garso duomenų bloko gavimo laiko svyravimus. Tačiau tiesioginės medijos sistema kiekvieną garso kadrą turi pristatyti laiku.

Ankstesnis darbas su ChatGPT Balsas ir Realtime API suteikė mums svarbų pagrindą. Jau buvome iš naujo sukūrę balso infrastruktūrą⁠, kad galėtume tiesiogiai srautiniu būdu perduoti garsą ir vaizdą į savo sistemas bei iš jų su mažesne ir lengviau prognozuojama delsa. GPT‑Live šią architektūrą išplėtė: per naują būseną išlaikančią išvedimo sistemą, sukurtą nepertraukiamam pokalbiui, medija srautiniu būdu perduodama iki pat modelio.

Vis dėlto srautinis išvedimas buvo tik dalis sprendimo. Kad sistema patikimai veiktų produkcinėje aplinkoje, taip pat turėjome užtikrinti, kad garsas būtų patikimai pristatomas iš kliento į išvedimo infrastruktūrą, ir išspręsti būsenos išlaikymo keliamus sunkumus.

Vienas pirmųjų mūsų sprendimų buvo aiškiai atskirti medijos srautą nuo programos ir verslo logikos. Garsas tarp kliento ir balso modelio perduodamas specialiu sparčiuoju keliu. Užduočių perdavimas, įrankių naudojimas ir kiti programos darbai vyksta už asinchroninės RPC ribos. Lėtas įrankio iškvietimas ar galinė paslauga gali uždelsti savo rezultatą, tačiau negali sustabdyti medijos srauto.

Šis atskyrimas taip pat suteikia sistemai aiškią tinkinimo ribą. Programos gali keisti savo įrankius, politikas ir galinių sistemų veikimą nepaveikdamos medijos sąsajos, atsakingos už nepertraukiamą garso perdavimą. Tiesioginis kelias išlieka nedidelis, nuspėjamas ir sutelktas į darbus, kuriuos būtina atlikti realiuoju laiku.

Medijos sąsają ir išvedimo logiką parašėme Go kalba, pakeisdami ankstesnę Python asyncio realizaciją. Tai gerokai pagerino kadrų pristatymo sklandumą: naujosios sistemos p95 prilygo ankstesnės sistemos p50.

WebRTC suteikia perdavimo pagrindą. Jis sukurtas mažos delsos medijai ir gali veikti toliau praradus paketus, nukrypus laikrodžiams ar pasikeitus kliento ryšiui. Jei paketai vėluoja, WebRTC gali nežymiai ištempti garsą, kad neliktų tarpų, o tada trumpam paspartinti atkūrimą ir vėl pasivyti realųjį laiką.

Visoje sistemoje sumažinę buferizavimą ir blokavimą, galime pasiekti trumpesnį nei sekundės atsako laiką, kurio žmonės tikisi kalbėdamiesi.

Būseną išlaikantis išvedimas turi savų eksploatacinių kompromisų. Balso seansas gali ilgai išlikti aktyvus, tačiau jo kontekstas nuolat didėja, o modelio egzemplioriai paleidžiami ir išjungiami pagal paklausą.

Šioms problemoms spręsti sukūrėme sklandaus darbo perdavimo tarp modelio egzempliorių mechanizmą. Kai reikia pereiti prie kito egzemplioriaus, kartu su esamu galime parengti pakaitinį modelio egzempliorių, iš anksto įkelti į jį dabartinio seanso kontekstą, lygiagrečiai vykdyti išvedimą abiejuose ir persijungti, kai naujasis egzempliorius bus visiškai paruoštas.

Tas pats pagrindinis mechanizmas taip pat palaiko dinaminį konteksto tankinimą. Pokalbiui tęsiantis, sukauptas kontekstas galiausiai gali viršyti modelio konteksto ribą. Tankinimas gali sumažinti kontekstą tiek, kad jis tilptų į nustatytą ribą, tačiau ši operacija užtrunka. Kadangi ši operacija pakeičia ankstesnį kontekstą, ji taip pat panaikina modelio rakto ir reikšmės (KV) podėlio, kuriame saugomi anksčiau apdorotų leksemų dėmesio raktai ir reikšmės, galiojimą. Norint iš naujo sukurti šią būseną, reikia dar kartą atlikti pradinį užpildymą, todėl atsiranda papildoma delsa.

Todėl tankinimą laikome dar vienu valdomu perėjimu. Kol pradinis modelio egzempliorius tęsia pokalbį, sistema sutankina kontekstą ir parengia pakaitinį modelio egzempliorių su naujuoju kontekstu. Kai tas egzempliorius paruoštas, galime persijungti nenutraukdami medijos srauto. Taip sistema gali palaikyti ilgai trunkančius skambučius ir prireikus tankinti kontekstą.

Sudėtingi darbai atliekami už tiesioginio kelio ribų, todėl net perduodant darbą pokalbis nė akimirkai nenutrūksta.

Galimybė iškviesti esamus priešakinius modelius suteikia GPT‑Live daug galios ir iš esmės atskiria „kalbėjimą“ nuo gilesnio „mąstymo“. Tačiau norint, kad ši dviejų modelių architektūra būtų suvokiama kaip viena sistema, reikėjo išspręsti dvi susijusias inžinerines problemas.

Pirma, rezultatai turi grįžti pakankamai greitai, kad būtų naudingi vykstančiame pokalbyje, todėl turėjome sumažinti delsą visame užduoties perdavimo kelyje – nuo nukreipimo ir užklausos apdorojimo iki išvedimo bei įrankių iškvietimų. Kartu kitoms produkto sistemoms vis dar reikia atskirų pranešimų, todėl vykstantį pokalbį turėjome pateikti joms suprantama forma.

Perduodami užduotį optimizuojame laiką, per kurį priešakinis modelis pateikia ką nors naudinga pokalbiui. Kol priešakinis modelis protauja ar naudoja įrankius, balso modelis gali trumpai tęsti pokalbį, tačiau negali paslėpti neribotai lėto atsako. Todėl visą užduoties perdavimo ciklą – nukreipimą, užklausos apdorojimą, išvedimą ir įrankių iškvietimus – įtraukėme į atsako laiko biudžetą.

Pirmasis optimizavimo žingsnis – parengti priešakinį modelį ir visus jam reikalingus įrankius dar prieš paprašant perduoti užduotį. Prasidėjus balso seansui, programų serveris sukuria priešakinio modelio išvedimo seansą ir iš anksto užpildo jį pradiniu pokalbio kontekstu, kad užklausa būtų visiškai apdorota dar prieš pirmąją perduotą užduotį.

Tada šį išvedimo seansą išlaikome visą balso pokalbį, o vėlesnėms užklausoms taikome pastovų seanso susiejimą. Kartu su užklausų podėliu šie metodai sumažina delsą, o sutrikus darbininkui veikimą vis tiek lengva atkurti.

Naudingo rezultato gavimo laikui įtakos turi ir protavimo pastangos, išvesties ribos, įrankių schemos bei modelio ir įrankių sąveikos ciklai, todėl šiuos parametrus pakoregavome, kad atsakai būtų spartesni. Sumažinę užduoties perdavimo kelyje būtinų darbų apimtį, suteikėme balso modeliui galimybę greitai įtraukti mūsų priešakinių modelių rezultatus.

Nors balso modelis apdoroja nenutrūkstamus kalbos srautus, daugelis aplinkinių sistemų, įskaitant ChatGPT pokalbio sąsają ir dalį mūsų analizės bei saugos infrastruktūros, vis dar veikia pagal naudotojo ir asistento pokalbio eiles. Todėl programų serveris persidengiantį ir kartais dviprasmišką pokalbį išskaido į atskirus pranešimus.

Gaudamas garsą serveris pagal dalines transkripcijas ir laiko signalus nustato, kuris kalbėtojas tuo metu kalba, ir sudaro pranešimų eilę. Naujausias pranešimas lieka preliminarus: gavus daugiau kalbos gali pasikeisti jo tekstas, laikas ir priskirtas kalbėtojas. Kai kalbėtojas kalba pakankamai ilgai, kad priskyrimas būtų patikimas, serveris galutinai patvirtina atitinkamą pranešimą.

Kalbėtojų persidengimas šį procesą apsunkina. Trumpas asistento patvirtinimas naudotojui kalbant (pvz., „mhm“ ar „gerai“) nebūtinai turėtų tapti atskiru pranešimu. Tačiau prasminga asistento replika dažnai turėtų juo tapti. Taip pat teikiame pirmenybę rodomų asistento atsakymų nuoseklumui, net jei naudotojas įsiterpia.

Kiekvienoje segmentavimo politikoje tenka rinktis tarp naujumo ir tikrumo. Per anksti patvirtinus pranešimus, istorija suskaidoma, o tvarka tampa nestabili; per ilgai laukiant, vėluoja transkripcijos ir nuo jų priklausančios funkcijos. Todėl sistema palaiko du susijusius pokalbio vaizdus: preliminarų dabartinės būsenos vaizdą ir patikimą įrašą to, kas buvo pasakyta. Programos sąsajoje rodomas pokalbio vaizdas gali būti naujinamas, todėl jame naudojamas preliminarus vaizdas. Tačiau analitikos duomenų srautui registruoti reikia galutinės transkripcijos.

Taip likusi ChatGPT dalis gauna stabilų pokalbio vaizdą, o tiesioginiame balso kelyje nereikia versti pašnekovų griežtai kalbėti paeiliui.

Atsako sparta svarbi nuo pat akimirkos, kai naudotojas spusteli mygtuką. Naudojant GPT‑Live, prieš pradedant pokalbį sistema turi sukurti medijos kelią ir pradėti perduoti garsą per modelį. Todėl kiekviena paleidimo sekos dalis patenka į kritinį kelią.

Kaip minėta, WebRTC suteikia tvirtą realiojo laiko pagrindą, tačiau norint pradėti įprastą WebRTC seansą reikia stebėtinai daug protokolinių ryšio užmezgimų ir tinklo ciklų. WebRTC atsirado anksčiau, nei dėmesys tinklo ciklų mažinimui suformavo vėlesnius protokolus, tokius kaip QUIC. Todėl kartu naudojami jo pagrindiniai protokolai kartais kartoja tą patį darbą. Pavyzdžiui, kiekvienas protokolas turėjo savo apsaugos nuo DoS mechanizmą, net kai visame WebRTC dėkle jo nereikėjo.

Išanalizavome dėklą ir sukūrėme sutrumpinto WebRTC tinklo ciklo protokolą (WARP⁠(atsidaro naujame lange)), kuris sumažina medijos ir duomenų paleidimą nuo šešių tinklo ciklų iki vieno. WARP tai pasiekia keliais atgalinį suderinamumą išlaikančiais protokolo patobulinimais: DTLS ryšio užmezgimą įterpia į ICE (SPED⁠(atsidaro naujame lange)), naudoja spartesnį DTLS 1.3⁠(atsidaro naujame lange) ryšio užmezgimą, iš anksto suderina SCTP ryšio užmezgimą (SNAP⁠(atsidaro naujame lange)) ir iš anksto suderina duomenų kanalus, užuot naudojęs DCEP⁠(atsidaro naujame lange).

WARP sukūrėme kaip atvirų specifikacijų rinkinį, bendradarbiaudami su WebRTC bendruomenės nariais, kad šis darbas būtų naudingas platesnei ekosistemai. Pasiūlymus plėtojame IETF TSVWG darbo grupėje. WARP palaikymas jau įtrauktas į libwebrtc ir Pion, o darbai vyksta ir kitose WebRTC realizacijose.

Optimizavus medijos ryšio užmezgimą išryškėjo viena likusi delsa – signalizavimo mainai, kuriais prieš WebRTC prisijungimą bendrinami SDP parametrai. Kad pašalintume šiuos mainus iš kritinio kelio, sukūrėme funkciją, kurią vadiname Instant Connect. Ji iš anksto suderina šiuos parametrus nerezervuodama serverio pajėgumų ir nereikalaudama keisti esamų WebRTC realizacijų.

Instant Connect veikia kartu su standartiniu signalizavimo procesu. Jei iš anksto suderinti parametrai galioja, serveris gali sukurti seansą gavęs pirmąjį medijos paketą. Jei jie pasenę ar netinkami, signalizavimo procesas jau būna pradėtas, todėl klientas gali grįžti prie jo nepatirdamas papildomos delsos.

Kartu Instant Connect ir WARP gerokai sutrumpina laiką nuo naudotojo ketinimo iki tiesioginio medijos srauto. Pašalinus SDP mainus iš kritinio kelio, o WARP sutrumpinus perdavimo ryšio užmezgimą, klientas dabar gali pradėti seansą vienu UDP paketu. Serveris gali atsakyti iš karto, todėl likusi sistema gali pradėti daryti tai, kas iš tiesų svarbu naudotojui: klausytis ir atsakyti.

Popieriuje sistema gali atrodyti sparti, tačiau susidurti su trikdžiais apdorodama tikrą balso srautą. Prieš leisdami GPT‑Live kalbėtis su naudotojais, atlikome tylųjį bandymą: nedidelę, palaipsniui didinamą produkcinių ChatGPT Balsas seansų dalį nukreipėme ir į esamą išplėstinį balso režimą, ir į naująją sistemą. Išplėstinis balso režimas ir toliau įprastai aptarnavo naudotojus, o šešėliniu keliu išvedimas buvo vykdomas tik skaitymo režimu. Taip sistema susidūrė su tikrais klientais, tinklais, skirtingos trukmės seansais ir geografiniu pasiskirstymu, tačiau naudotojų girdimas turinys nepasikeitė.

Viena pirmųjų pamokų buvo ta, kad pajėgumo negalima vertinti vien pagal GPU pralaidumą. Balso seansai lieka atviri ir nuolat siunčia kadrus, todėl kartu su išvedimu turi būti plečiami ir CPU srautų apdorojimo komponentai, eilės bei tinklo keliai. Esant tikrai apkrovai, pagalbinis komponentas pasiekė pajėgumo ribą anksčiau, nei prognozavo apkrovos bandymai, todėl kaupėsi išvedimo užklausos ir didėjo delsa. Pajėgumo klausimą „Kiek užklausų gali apdoroti GPU?“ pakeitėme į „Kiek vienalaikių seansų sistema gali palaikyti, kiekvieną kadrą apdorodama laiku?““

Bandymas taip pat parodė, kad geografija yra vienas svarbiausių veiksnių. Nukreipus seansą į tolimą infrastruktūrą, delsa gali padidėti keliose paleidimo ir srautinio perdavimo vietose. Modelių diegimą pradėjome tikrinti kartu su regioniniais pajėgumais ir srauto nukreipimo konfigūracija, o delsą skaidyti pagal šaltinio geografinę vietą. Išvedimo perkėlimas arčiau naudotojų padėjo, bet kartu patvirtino platesnę išvadą: bendras atsako greitis priklauso nuo kiekvienos kelyje esančios paslaugos, ne tik nuo modelio serverio.

Kitos klaidos išryškėjo tik per tikrovišką visą seanso gyvavimo ciklą. Ilgai trunkantys seansai atskleidė atminties ir duomenų išsaugojimo apkrovą. Pakartotinis prisijungimas išbandė tankinimą ir būsenos atkūrimą. Įprasti klientų atsijungimai atskleidė varžymosi sąlygas užbaigimo patvirtinimo procese. Per trumpus apkrovos bandymus šios problemos pasireikšdavo retai, nes priklausė nuo laiko, sukauptos būsenos ir veikimo skirtingų paslaugų sandūrose.

Galiausiai bandymai produkcinėje aplinkoje privertė mus pagerinti stebimumą ir diegimo valdymą. Aptikome metrikų, kurios suplakdavo skirtingus delsos šaltinius, suvestinių, kurių bendri rodikliai slėpė atskirus netinkamai veikiančius modulius, ir išbandytų bei įdiegtų sistemų konfigūracijų neatitikimų. Todėl įdiegėme išsamesnę telemetriją, tikrinimą pagal patikimas konfigūracijas, laipsnišką srauto didinimą ir galimybę greitai izoliuoti ar išjungti atskirus kelius. Tylusis bandymas tapo ankstyva paleidimo repeticija: tikrinome ne tik sistemos galimą priimti srautą, bet ir kaip greitai galime aptikti bei suvaldyti gedimą ir po jo atkurti veikimą.

Norint pritaikyti GPT‑Live ChatGPT mastui, reikėjo visiškai naujos sistemos, sukurtos pagal vieną esminį principą: balsas turi sklisti nenutrūkstamai. Srautinis išvedimas nuolat tiekia garsą visiškai dvikrypčiam modeliui. Specialusis medijos kelias užtikrina patikimą kadrų pristatymą. Asinchroninis užduočių perdavimas leidžia lygiagrečiai vykdyti gilesnį mąstymą. Optimizuotas perdavimas užtikrina spartų atsaką visame kelyje iki naudotojo.

GPT‑Live architektūra jau tampa platesne sąveikos realiuoju laiku platforma. Ji suteikia galią ChatGPT Balsas, kuris nuo pokalbių pereina prie agentinio koordinavimo, ir taps būsimos GPT‑Live API pagrindu. Ilgainiui ji leis balso funkcijas naudoti daugiau įrenginių, programėlių ir modalumų, neprarandant betarpiškumo, dėl kurio balso pokalbis atrodo vykstantis gyvai.

Jei norite spręsti tokio pobūdžio inžinerines problemas, prisijunkite prie mūsų komandos⁠.