Si ndërtuam për gjashtë muaj një sistem në kohë reale për IA zanore reaguese

Për IA-në zanore, të dish kur të flasësh është më e vështirë nga sa duket. Njerëzit ia kalojnë fjalën njëri-tjetrit pa mundim në një fraksion sekonde, por sistemet e mëparshme të IA-së zanore nuk arrinin ta ndiqnin këtë ritëm. Arkitektura e tyre me radhë mbështetej te modele të vogla të njohura si detektorë radhe, të cilët kishin një detyrë të vështirë: nëse hamendësonin shumë herët, përdoruesit i ndërpritej fjala; nëse hamendësonin shumë vonë, përgjigjja dukej e ngadaltë. Vetëm pasi detektori merrte vendimin e vet, LLM-ja shumë më e madhe mund të fillonte punën.

GPT‑Live⁠, sistemi ynë zanor i gjeneratës së tretë, e heq detektorin e radhës nga shtegu i audios. Modeli i tij zanor është full-duplex, që do të thotë se mund të dëgjojë dhe të flasë njëkohësisht. Kjo eliminon nevojën për një detektor të veçantë dhe e bën bisedën më të menjëhershme e të natyrshme. Kur nevojitet arsyetim më i thellë ose përdorimi i mjeteve, GPT‑Live mund të këshillohet edhe me modelet tona avangardë, si GPT‑5.5, pa ndërprerë rrjedhën e bisedës. Së bashku, këto aftësi i japin GPT‑Live një kombinim të paparë të reagimit dhe inteligjencës në bisedë.

Ofrimi i kësaj përvoje në shkallë të gjerë kërkoi një arkitekturë të re sistemi, të optimizuar për vonesë të ulët. Ndryshe nga inferenca tipike kërkesë-përgjigje, sistemi ynë transmeton audion hyrëse te modeli zanor dhe ligjëratën dalëse te përdoruesi, ndërsa delegimin e trajton në një shteg të veçantë asinkron. Gjatë gjashtë muajve të fundit, ripunuam inferencën e modelit, menaxhimin e kontekstit dhe transportin mediatik për ta mbajtur ligjëratën të rrjedhshme nga skaji në skaj.

Arkitektura krijon gjithashtu një kufi të qartë mes shtegut zanor bazë dhe logjikës së aplikacionit. Kjo e bën të lehtë personalizimin e sjelljes së aplikacionit pa ndikuar në shpejtësinë e reagimit. Kjo bazë fuqizon një gamë në rritje aftësish në ChatGPT Voice, përfshirë mundësinë e sapolançuar për të kontrolluar kompjuterin dhe për të bashkërenduar agjentët në aplikacionin ChatGPT për desktop.

Në këtë artikull, do të shpjegojmë pse sistemet e mëparshme me radhë nuk i përmbushnin nevojat tona dhe si e ndërtuam sistemin e ri për reagim të shpejtë në çdo shtresë. Do të trajtojmë inferencën me gjendje, menaxhimin dinamik të kontekstit, delegimin asinkron dhe optimizimin në nivel protokolli, të cilat bashkëveprojnë që GPT‑Live të duket vërtet drejtpërdrejt.

Arkitekturat e mëparshme zanore trashëguan natyrën me radhë të LLM-ve tekstuale, por çdo radhë përfaqësohej si një bllok i veçantë audioje dhe jo si tekst. Në sistemet në kaskadë, konvertimi i ligjëratës në tekst, LLM-ja dhe konvertimi i tekstit në ligjëratë kryheshin njëri pas tjetrit. Ky rend shtonte vonesë dhe shpërfillte sinjale si toni dhe ritmi.

Modelet ligjëratë-ligjëratë e përmirësuan këtë qasje duke e përpunuar audion drejtpërdrejt. Trajnimi i modelit për ta kuptuar dhe prodhuar ligjëratën në mënyrë të integruar i mundësoi të ruante hollësitë e humbura gjatë transkriptimit dhe të përgjigjej më shpejt. Por sistemi mbështetej ende te detektori i radhës për të vendosur se kur mund të fillonte inferenca. Modeli trajtonte një pjesë më të madhe të ndërveprimit, por ndërveprimi mbetej me radhë.

GPT‑Live ia jep modelit zanor kontrollin e bisedës: audioja hyn dhe del nga modeli, ndërsa arsyetimi më i thellë dhe përdorimi i mjeteve kryhen në mënyrë asinkrone. Detyra kryesore e sistemit është të mbajë një cikël mediatik të pandërprerë. Punë të tjera, si thirrja e modeleve avangardë dhe ruajtja e bisedës, kryhen jashtë shtegut drejtpërdrejt.

Mbajtja pa ndërprerje e këtij cikli mediatik nuk është gjithmonë e thjeshtë. Çdo vonesë në transport, përpunim ose inferencë mund të shndërrohet në një pauzë ose artefakt të dëgjueshëm. Një sistem i mëparshëm me radhë mund të toleronte disa ndryshime në kohën kur mbërrinte një bllok audioje. Megjithatë, një sistem mediatik drejtpërdrejt duhet ta dërgojë çdo kuadër audioje në kohë.

Puna e mëparshme me ChatGPT Voice dhe Realtime API na dha një bazë të rëndësishme. E kishim rindërtuar tashmë infrastrukturën tonë zanore⁠ për të transmetuar audio dhe video drejtpërdrejt në sistemet tona dhe prej tyre, me vonesë më të ulët e më të parashikueshme. GPT‑Live e çoi më tej këtë arkitekturë, duke e transmetuar median deri te modeli përmes një sistemi të ri inferencash me gjendje, të ndërtuar për biseda të vazhdueshme.

Megjithatë, inferenca me transmetim ishte vetëm një pjesë e zgjidhjes. Që të funksiononte mirë në prodhim, duhej gjithashtu të siguronim dërgimin e besueshëm të audios nga klienti te infrastruktura e inferencës dhe të përballonim sfidat e ruajtjes së gjendjes.

Një vendim i hershëm ishte ta ndanim posaçërisht rrjedhën mediatike nga logjika e aplikacionit dhe e biznesit. Audioja lëviz mes klientit dhe modelit zanor nëpër një shteg të posaçëm e të shpejtë. Delegimi, përdorimi i mjeteve dhe punë të tjera të aplikacionit ndodhin pas një kufiri asinkron RPC. Një thirrje e ngadaltë e një mjeti ose një shërbim backend mund ta vonojë rezultatin e vet, por nuk mund ta bllokojë rrjedhën mediatike.

Kjo ndarje i jep sistemit edhe një kufi të qartë për personalizim. Aplikacionet mund të ndryshojnë mjetet, politikat dhe sjelljen e backend-it pa ndikuar në ndërfaqen e përparme mediatike që mban audion në lëvizje. Shtegu drejtpërdrejt mbetet i vogël, i parashikueshëm dhe i përqendruar te puna që duhet të kryhet në kohë reale.

Ndërfaqen e përparme mediatike dhe logjikën e inferencës i shkruam në Go, duke zëvendësuar një implementim të mëparshëm në Python me asyncio. Kjo përmirësoi ndjeshëm rrjedhshmërinë e dërgimit të kuadrove: p95 i sistemit të ri përputhej me p50 të sistemit të mëparshëm.

WebRTC siguron bazën e transportit. Është projektuar për media me vonesë të ulët dhe mund të vazhdojë të funksionojë pavarësisht humbjes së paketave, devijimit të orës dhe ndryshimeve në lidhjen e klientit. Nëse paketat mbërrijnë me vonesë, WebRTC mund ta zgjasë lehtë audion për të shmangur boshllëqet dhe më pas ta përshpejtojë shkurtimisht riprodhimin për t’u kthyer në kohë reale.

Duke minimizuar ruajtjen në bufer dhe bllokimin në të gjithë sistemin, mund të ofrojmë reagimin nën një sekondë që njerëzit presin nga biseda.

Inferenca me gjendje ka kompromiset e veta operacionale. Një sesion zanor mund të mbetet aktiv për një kohë të gjatë, por konteksti i tij rritet vazhdimisht dhe instancat e modelit aktivizohen e çaktivizohen sipas kërkesës.

Për t’i trajtuar këto çështje, ndërtuam një mekanizëm të pandërprerë dorëzimi mes instancave të modelit. Kur nevojitet një kalim, mund të nxehim një instancë zëvendësuese të modelit krahas asaj ekzistuese, ta mbushim paraprakisht me kontekstin aktual të sesionit, të kryejmë inferencë paralelisht në të dyja dhe të kalojmë tek e reja kur të jetë plotësisht gati.

I njëjti mekanizëm bazë mbështet edhe kompaktimin dinamik të kontekstit. Me vazhdimin e një bisede, konteksti i akumuluar mund ta tejkalojë përfundimisht kufirin e kontekstit të modelit. Kompaktimi mund ta zvogëlojë kontekstin që të përshtatet brenda kufirit, por veprimi kërkon kohë. Dhe, për shkak se ndryshon kontekstin e mëparshëm, ai e bën të pavlefshme edhe memorien e përkohshme key-value (KV) të modelit, e cila ruan çelësat dhe vlerat e vëmendjes nga tokenët e përpunuar më parë. Rindërtimi i kësaj gjendjeje kërkon një mbushje të re paraprake, duke sjellë vonesë shtesë.

Në vend të kësaj, kompaktimin e trajtojmë si një tjetër kalim të menaxhuar. Ndërsa instanca fillestare e modelit vazhdon bisedën, sistemi kompakton kontekstin dhe përgatit një instancë zëvendësuese të modelit me kontekstin e ri. Pasi ajo instancë të jetë gati, mund të kalojmë tek ajo pa asnjë ndërprerje të medias. Kjo i lejon sistemit të mbështesë thirrje afatgjata, duke bërë kompaktim sa herë nevojitet.

Puna e rëndë mbetet jashtë shtegut drejtpërdrejt, ndaj biseda nuk e humbet ritmin as gjatë dorëzimit.

Aftësia e GPT‑Live për të thirrur modelet ekzistuese avangardë i jep shumë fuqi, duke e shkëputur praktikisht «të folurit» nga «të menduarit» më i thellë. Por që kjo arkitekturë me dy modele të ndihej si një sistem i vetëm, duhej të zgjidhnim dy probleme inxhinierike të ndërlidhura.

Së pari, rezultatet duhet të kthehen aq shpejt sa të jenë të dobishme në shkëmbimin në vazhdim, ndaj duhej të minimizonim vonesën përgjatë gjithë shtegut të delegimit, nga drejtimi dhe përpunimi i kërkesës deri te inferenca dhe thirrjet e mjeteve. Njëkohësisht, sistemeve të tjera në produkt u duhen ende mesazhe të veçanta, ndaj duhej ta paraqitnim bisedën në vazhdim në një formë që ato mund ta kuptonin.

Kur dërgohet një delegim, optimizojmë kohën deri kur modeli avangardë prodhon diçka të dobishme për bisedën. Modeli zanor mund ta mbajë shkurtimisht shkëmbimin në lëvizje ndërsa një model avangardë arsyeton ose përdor mjete, por nuk mund të fshehë një përgjigje tepër të ngadaltë. Prandaj, të gjithë ciklin e delegimit—drejtimin, përpunimin e kërkesës, inferencën dhe thirrjet e mjeteve—e trajtuam si pjesë të buxhetit të reagimit.

Optimizimi i parë është përgatitja e modelit avangardë dhe e çdo mjeti që i nevojitet përpara se të kërkohet delegimi. Kur nis një sesion zanor, serveri i aplikacionit krijon një sesion inference për modelin avangardë dhe e mbush paraprakisht me kontekstin fillestar të bisedës, duke siguruar që kërkesa të jetë përpunuar plotësisht para kërkesës së parë të deleguar.

Më pas, e mbajmë atë sesion inference të disponueshëm gjatë gjithë bisedës zanore dhe përdorim afinitet të qëndrueshëm sesioni për kërkesat pasuese. Së bashku me ruajtjen e kërkesave në memorie të përkohshme, këto teknika e përmirësojnë vonesën, ndërsa rikuperimi nga dështimi i një worker-i mbetet i lehtë.

Përpjekja e arsyetimit, kufijtë e rezultatit, skemat e mjeteve dhe vajtje-ardhjet mes modelit e mjeteve ndikojnë gjithashtu në kohën kur biseda merr një rezultat të dobishëm, ndaj i rregulluam këto leva për përgjigje më të shpejta. Duke minimizuar punën e nevojshme në shtegun e delegimit, i mundësuam modelit zanor të përfshinte shpejt rezultatet nga modelet tona avangardë.

Edhe pse modeli zanor punon me rrjedha të vazhdueshme ligjërate, shumë prej sistemeve përreth tij vazhdojnë të funksionojnë me radhë përdoruesi dhe asistenti, përfshirë ndërfaqen e bisedës së ChatGPT dhe pjesë të infrastrukturës sonë të analizës e sigurisë. Prandaj, serveri i aplikacionit e zbërthen bisedën e mbivendosur dhe herë-herë të paqartë në mesazhe të veçanta.

Ndërsa mbërrin audioja, serveri përdor transkripte të pjesshme dhe sinjale kohore për të përcaktuar se cili folës e ka fjalën dhe për të krijuar një radhë mesazhesh. Mesazhi më i ri mbetet i përkohshëm; teksti, koha dhe përcaktimi i folësit mund të ndryshojnë ndërsa mbërrin më shumë ligjëratë. Pasi një folës e ka mbajtur fjalën mjaftueshëm gjatë që atribuimi të jetë i besueshëm, serveri e përfundon mesazhin përkatës.

Mbivendosja e folësve e ndërlikon këtë proces. Një pohim i shkurtër nga asistenti ndërsa përdoruesi flet (p.sh. “mm hmm,” ose “okay”) nuk duhet domosdoshmërisht të bëhet mesazh më vete. Megjithatë, një ndërhyrje me përmbajtje nga asistenti shpesh duhet të jetë mesazh më vete. Po kështu, u japim përparësi përgjigjeve koherente të asistentit në ekran, edhe kur përdoruesi flet në mes.

Çdo politikë segmentimi balancon aktualitetin me sigurinë. Përfundimi shumë herët krijon histori të fragmentuar dhe renditje të paqëndrueshme; pritja shumë e gjatë vonon transkriptet dhe veçoritë që varen prej tyre. Prandaj, sistemi mban dy pamje të ndërlidhura të bisedës: një pamje paraprake të gjendjes aktuale dhe një regjistër përfundimtar të asaj që u tha. Pamja e bisedës në ndërfaqen e aplikacionit mund të përpunojë përditësime, ndaj përdor pamjen paraprake. Por regjistrimi në rrjedhën e analizës kërkon një transkript përfundimtar.

Kjo i jep pjesës tjetër të ChatGPT një pamje të qëndrueshme të shkëmbimit, pa imponuar marrjen e radhës në shtegun zanor drejtpërdrejt.

Reagimi i shpejtë nis sapo përdoruesi klikon butonin. Me GPT‑Live, sistemi duhet të vendosë shtegun mediatik dhe të fillojë furnizimin e modelit me audio para se të nisë biseda. Kjo e vendos çdo pjesë të sekuencës së nisjes në shtegun kritik.

Siç u përmend më lart, WebRTC ofron një bazë të fortë për kohë reale, por nisja e një sesioni standard WebRTC kërkon një numër befasues negociimesh protokolli dhe vajtje-ardhjesh në rrjet. WebRTC i paraprin përqendrimit te minimizimi i vajtje-ardhjeve, i cili formësoi protokollet e mëvonshme si QUIC. Si pasojë, protokollet e tij bazë ndonjëherë përsërisin punë kur përdoren së bashku. Për shembull, çdo protokoll përfshinte mekanizmin e vet kundër DoS-it, edhe kur ai nuk nevojitej në kontekstin e plotë të infrastrukturës WebRTC.

Analizuam infrastrukturën dhe zhvilluam WebRTC Abridged Roundtrip Protocol (WARP⁠(hapet në një dritare të re)), i cili e zvogëlon nisjen e medias dhe të të dhënave nga gjashtë vajtje-ardhje në rrjet në vetëm një. WARP e arrin këtë me një sërë përmirësimesh protokolli të pajtueshme me versionet e mëparshme: bartjen e negocimit DTLS mbi ICE (SPED⁠(hapet në një dritare të re)), përdorimin e negocimit më të shpejtë DTLS 1.3⁠(hapet në një dritare të re), negocimin paraprak të SCTP-së (SNAP⁠(hapet në një dritare të re)) dhe negocimin paraprak të kanaleve të të dhënave në vend të përdorimit të DCEP⁠(hapet në një dritare të re).

WARP e projektuam si një grup specifikimesh të hapura, duke punuar me bashkëpunëtorë nga komuniteti WebRTC, që nga kjo punë të përfitojë ekosistemi më i gjerë. Po i çojmë përpara propozimet përmes grupit të punës TSVWG të IETF-së. Mbështetja për WARP është shtuar tashmë si në libwebrtc, ashtu edhe në Pion, ndërsa puna vazhdon në implementime të tjera WebRTC.

Pas optimizimit të negocimit mediatik, spikati një vonesë e mbetur: shkëmbimi i sinjalizimit që përdoret për të ndarë parametrat SDP para se WebRTC të lidhet. Për ta hequr atë shkëmbim nga shtegu kritik, zhvilluam atë që e quajmë Instant Connect. Ai i negocion këta parametra paraprakisht, pa rezervuar kapacitet serveri dhe pa ndryshuar implementimet ekzistuese WebRTC.

Instant Connect funksionon krahas rrjedhës standarde të sinjalizimit. Nëse parametrat e negociuar paraprakisht janë të vlefshëm, serveri mund ta krijojë sesionin kur mbërrin paketa e parë mediatike. Nëse janë të vjetruar ose të pavlefshëm, rrjedha e sinjalizimit është tashmë në proces, ndaj klienti mund të kalojë tek ajo pa vonesë shtesë.

Së bashku, Instant Connect dhe WARP e zvogëlojnë ndjeshëm kohën nga synimi i përdoruesit deri te rrjedha mediatike drejtpërdrejt. Me shkëmbimin SDP jashtë shtegut kritik dhe WARP që ngjesh negocimin e transportit, klienti tani mund të nisë një sesion me një paketë të vetme UDP. Serveri mund të përgjigjet menjëherë, duke i mundësuar pjesës tjetër të sistemit të fillojë punën për të cilën interesohet vërtet përdoruesi: të dëgjojë dhe të përgjigjet.

Një sistem mund të duket i shpejtë në teori, por të ngecë përballë trafikut real zanor. Para se ta lejonim GPT‑Live të bisedonte me përdoruesit, kryem një test të heshtur që drejtonte një pjesë të vogël dhe gradualisht në rritje të sesioneve të ChatGPT Voice në prodhim si te përvoja ekzistuese e modalitetit të zërit të avancuar, ashtu edhe te sistemi ynë i ri. Modaliteti i zërit të avancuar vazhdoi t’u shërbente përdoruesve si zakonisht, ndërsa shtegu hije kryente inferencën në modalitet vetëm për lexim. Kjo e ekspozoi sistemin ndaj klientëve, rrjeteve, kohëzgjatjeve të sesioneve dhe shpërndarjes gjeografike reale, pa ndryshuar atë që dëgjonin përdoruesit.

Një nga mësimet e para ishte se kapaciteti nuk mund të reduktohej vetëm te kapaciteti përpunues i GPU-së. Sesioni zanor qëndron hapur dhe dërgon vazhdimisht kuadro, ndaj përpunuesit e transmetimit në CPU, radhët dhe shtigjet e rrjetit duhet të shkallëzohen krahas inferencës. Nën ngarkesë reale, një komponent mbështetës arriti ngopjen më herët nga sa parashikonin vlerësimet e testit tonë të ngarkesës, duke bërë që kërkesat e inferencës të grumbulloheshin dhe vonesa të shtohej. Pyetjen për kapacitetin e ndryshuam nga «Sa kërkesa mund të përballojë një GPU?» në «Sa sesione të njëkohshme mund të mbështesë sistemi duke e mbajtur çdo kuadër në orar?»

Testi tregoi gjithashtu se gjeografia ishte një shqetësim parësor. Drejtimi i një sesioni te një kapacitet i largët mund të shtojë vonesë në disa pika gjatë nisjes dhe transmetimit. Filluam t’i verifikonim publikimet e modeleve bashkë me kapacitetin rajonal dhe konfigurimin e drejtimit të trafikut, pastaj ta analizonim vonesën sipas gjeografisë së burimit. Afrimi i inferencës me përdoruesit ndihmoi, por përforcoi edhe mësimin më të gjerë: reagimi nga skaji në skaj varet nga çdo shërbim në shteg, jo vetëm nga serveri i modelit.

Dështime të tjera u shfaqën vetëm gjatë cikleve realiste të jetës së sesioneve. Sesionet afatgjata nxorën në pah trysninë mbi memorien dhe ruajtjen e qëndrueshme. Rilidhjet vunë në provë kompaktimin dhe rikthimin e gjendjes. Shkëputjet e zakonshme të klientëve zbuluan konflikte kohore në negocimin e mbylljes. Këto probleme shfaqeshin rrallë në testet e shkurtra të ngarkesës, sepse vareshin nga koha, gjendja e akumuluar dhe sjellja përtej kufijve të shërbimeve.

Së fundi, testimi në prodhim na detyroi të përmirësonim vëzhgueshmërinë dhe kontrollet e publikimit. Gjetëm metrika që bashkonin burime të ndryshme vonese, panele ku të dhënat e përmbledhura fshihnin motorë individualë problematikë dhe devijime konfigurimi mes sistemeve të testuara dhe atyre të vëna në përdorim. Si përgjigje, shtuam telemetri më të imët, verifikim kundrejt konfigurimeve të provuara, rritje graduale me faza dhe mundësinë për të izoluar ose çaktivizuar shpejt shtigje individuale. Testi i heshtur u bë një provë e hershme e lançimit, jo vetëm për sasinë e trafikut që mund të pranonte sistemi, por edhe për shpejtësinë me të cilën mund të zbulonim, kufizonim dhe kapërcenim një dështim.

Sjellja e GPT‑Live në shkallën e ChatGPT kërkoi një sistem krejtësisht të ri, të ndërtuar rreth një parimi themelor: zëri duhet të rrjedhë pa ndërprerje. Inferenca me transmetim e furnizon vazhdimisht modelin full-duplex me audio. Një shteg i posaçëm mediatik siguron dërgimin e besueshëm të kuadrove. Delegimi asinkron mundëson që mendimi më i thellë të zhvillohet paralelisht. Transporti i optimizuar e mban përvojën reaguese deri te përdoruesi.

Arkitektura pas GPT‑Live po shndërrohet tashmë në një platformë më të gjerë për ndërveprim në kohë reale. Ajo fuqizon ChatGPT Voice teksa zgjerohet nga biseda në bashkërendim me agjentë dhe do të mbështesë API-në e ardhshme GPT‑Live. Me kalimin e kohës, ajo do t’u mundësojë përvojave zanore të shtrihen në më shumë pajisje, aplikacione dhe modalitete, pa humbur menjëhershmërinë që e bën bisedën zanore të duket drejtpërdrejt.

Nëse dëshironi të zgjidhni probleme inxhinierike të këtij lloji, ejani të punoni me ne⁠.