Jinsi tulivyounda mfumo wa wakati halisi wa AI ya sauti yenye mwitikio ndani ya miezi sita

Kwa AI ya sauti, kujua wakati wa kuzungumza ni vigumu kuliko inavyoonekana. Watu hubadilishana zamu kwa urahisi katika sehemu ndogo ya sekunde, lakini mifumo ya awali ya AI ya sauti haikuweza kuendana na mwendo huu. Usanifu wake wa zamu ulitegemea miundo midogo inayoitwa vitambuzi vya zamu, iliyokuwa na kazi ngumu: ikikisia mapema mno, mtumiaji hukatizwa; ikichelewa mno, jibu huhisi zito. LLM kubwa zaidi ingeweza kuanza kazi baada tu ya kitambuzi kufanya uamuzi wake.

GPT‑Live⁠, mfumo wetu wa sauti wa kizazi cha tatu, huondoa kitambuzi cha zamu kwenye njia ya sauti. Muundo wake wa sauti ni wa pande mbili, kumaanisha unaweza kusikiliza na kuzungumza kwa wakati mmoja. Hilo huondoa hitaji la kitambuzi tofauti na kufanya mazungumzo yahisi ya papo hapo na ya kawaida zaidi. Uwazaji wa kina au matumizi ya zana yanapohitajika, GPT‑Live inaweza pia kushauriana na miundo yetu ya AI ya kiwango cha juu zaidi, kama GPT‑5.5, bila kukatiza mtiririko wa mazungumzo. Kwa pamoja, uwezo huu huipa GPT‑Live mchanganyiko wa kipekee wa mwitikio wa mazungumzo na kiwango cha uwezo wa AI.

Kutoa matumizi haya kwa kiwango kikubwa kulihitaji usanifu mpya wa mfumo ulioboreshwa kwa ucheleweshaji mdogo. Tofauti na ujalizi wa kawaida wa ombi na jibu, mfumo wetu hutiririsha sauti inayoingia hadi kwenye muundo wa sauti na usemi unaotoka kurudi kwa mtumiaji, huku ukishughulikia ukabidhi kupitia njia tofauti isawazishaji. Katika miezi sita iliyopita, tulibuni upya ujalizi wa muundo, usimamizi wa muktadha na usafirishaji wa midia ili kudumisha mtiririko laini wa usemi kutoka mwanzo hadi mwisho.

Usanifu huu pia huweka mpaka ulio wazi kati ya njia kuu ya sauti na mantiki ya programu. Hili hurahisisha kubinafsisha tabia ya programu bila kuathiri mwitikio. Msingi huu unaendesha uwezo mbalimbali unaoongezeka katika Zungumza na ChatGPT, ikiwemo uwezo uliozinduliwa hivi karibuni wa kudhibiti kompyuta yako na kuratibu mawakala wako katika programu ya mezani ya ChatGPT.

Katika chapisho hili, tutaeleza kwa nini mifumo ya awali ya zamu haikuweza kutimiza mahitaji yetu na jinsi tulivyobuni mfumo mpya ili uwe na mwitikio katika kila safu. Tutazungumzia ujalizi wenye hali, usimamizi wa muktadha unaobadilika, ukabidhi usawazishaji na uboreshaji katika kiwango cha itifaki—vyote vikifanya kazi pamoja ili GPT‑Live ihisi kuwa ya moja kwa moja kweli.

Usanifu wa awali wa sauti ulirithi hali ya zamu ya LLM za maandishi, lakini kila zamu iliwakilishwa kama kifurushi mahususi cha sauti badala ya maandishi. Katika mifumo ya mfuatano, ubadilishaji wa usemi kuwa maandishi, LLM na ubadilishaji wa maandishi kuwa usemi viliendeshwa kwa mfululizo. Mpangilio huu uliongeza ucheleweshaji na kupuuza ishara kama toni na mwendo wa usemi.

Miundo ya sauti hadi sauti iliboresha mbinu hii kwa kuchakata sauti moja kwa moja. Kufunza muundo kuelewa na kuzalisha usemi moja kwa moja kuliuwezesha kuhifadhi maelezo yanayopotea katika unukuzi na kujibu haraka zaidi. Lakini bado mfumo ulitegemea kitambuzi cha zamu kuamua wakati ujalizi ungeanza. Muundo ulishughulikia sehemu kubwa zaidi ya mwingiliano, lakini mwingiliano huo uliendelea kutegemea zamu.

GPT‑Live huupa muundo wa sauti udhibiti wa mazungumzo: sauti hutiririka kuingia na kutoka kwenye muundo, huku uwazaji wa kina na matumizi ya zana yakifanyika kwa njia isawazishaji. Kazi kuu ya mfumo ni kudumisha kitanzi cha midia kisichokatizwa. Kazi nyingine, kama kutumia miundo ya AI ya kiwango cha juu zaidi na kuhifadhi mazungumzo, hufanyika nje ya njia ya moja kwa moja.

Si rahisi kila wakati kudumisha kitanzi hiki cha midia bila kukatizwa. Ucheleweshaji wowote katika usafirishaji, uchakataji au ujalizi unaweza kusababisha kimya au hitilafu inayosikika. Mfumo wa awali wa zamu ungeweza kustahimili tofauti fulani katika muda wa kuwasili kwa kifurushi cha sauti. Hata hivyo, mfumo wa midia ya moja kwa moja lazima uwasilishe kila fremu ya sauti kwa wakati.

Kazi ya awali kwenye Zungumza na ChatGPT na Realtime API ilitupatia msingi muhimu. Tayari tulikuwa tumejenga upya miundombinu yetu ya sauti⁠ ili kutiririsha sauti na video moja kwa moja ndani na nje ya mifumo yetu kwa ucheleweshaji mdogo na unaotabirika zaidi. GPT‑Live iliendeleza zaidi usanifu huo kwa kutiririsha midia hadi kwenye muundo kupitia mfumo mpya wa ujalizi wenye hali, ulioundwa kwa mazungumzo endelevu.

Hata hivyo, ujalizi wa mtiririko ulikuwa sehemu moja tu ya suluhisho. Ili ufanye kazi vizuri katika uzalishaji, pia tulihitaji kuhakikisha sauti inawasilishwa kwa uhakika kutoka kwa mteja hadi kwenye mkusanyiko wa ujalizi na kushughulikia changamoto za kuhifadhi hali.

Uamuzi wetu wa mapema ulikuwa kutenganisha mtiririko wa midia na mantiki ya programu na biashara. Sauti husafiri kati ya mteja na muundo wa sauti kwenye njia maalumu ya haraka. Ukabidhi, matumizi ya zana na kazi nyingine za programu hufanyika nyuma ya mpaka wa RPC usawazishaji. Mwito wa zana au huduma ya upande wa nyuma iliyo polepole inaweza kuchelewesha matokeo yake, lakini haiwezi kukwamisha mtiririko wa midia.

Utenganishaji huu pia huupa mfumo mpaka ulio wazi wa ubinafsishaji. Programu zinaweza kubadilisha zana, sera na tabia ya upande wa nyuma bila kuathiri upande wa mbele wa midia unaodumisha mtiririko wa sauti. Njia ya moja kwa moja hubaki ndogo, ya kutabirika na inayolenga kazi ambayo lazima ifanyike kwa wakati halisi.

Tuliandika upande wa mbele wa midia na mantiki ya ujalizi katika Go, tukibadilisha utekelezaji wa awali wa Python wa asyncio. Hili liliboresha sana ulaini wa uwasilishaji wa fremu, huku p95 ya mfumo mpya ikilingana na p50 ya mfumo wa awali.

WebRTC hutoa msingi wa usafirishaji. Imeundwa kwa midia yenye ucheleweshaji mdogo na inaweza kuendelea kufanya kazi licha ya kupotea kwa pakiti, mkengeuko wa saa na mabadiliko ya muunganisho wa mteja. Pakiti zikichelewa, WebRTC inaweza kurefusha sauti kidogo ili kuzuia mapengo, kisha kuharakisha uchezaji kwa muda mfupi ili kurejea kwenye wakati halisi.

Kwa kupunguza uhifadhi wa muda na vizuizi kote kwenye mfumo, tunaweza kutoa mwitikio wa chini ya sekunde moja ambao watu hutarajia katika mazungumzo.

Ujalizi wenye hali una maafikiano yake ya kiutendaji. Kipindi cha sauti kinaweza kuendelea kwa muda mrefu, lakini muktadha wake huongezeka daima, huku mifano ya muundo ikiwashwa na kuzimwa kulingana na mahitaji.

Ili kushughulikia masuala haya, tulitengeneza utaratibu laini wa kukabidhiana kati ya mifano ya muundo. Mabadiliko yanapohitajika, tunaweza kuandaa mfano mbadala wa muundo sambamba na uliopo, kuujaza mapema kwa muktadha wa sasa wa kipindi, kuendesha ujalizi kwenye yote miwili sambamba na kuhamia kwa mpya ikiwa tayari kabisa.

Utaratibu huo pia unawezesha ukandamizaji wa mutadha unaobadilika. Mazungumzo yanapoendelea, muktadha wake uliokusanyika unaweza hatimaye kuzidi kikomo cha muktadha cha muundo. Ukandamizaji wa mutadha unaweza kupunguza ukubwa wa muktadha ili utoshee ndani ya kikomo, lakini operesheni hiyo huchukua muda. Na kwa sababu hubadilisha muktadha wa awali, pia hubatilisha akiba ya thamani-ufunguo (KV) ya muundo, ambayo huhifadhi funguo na thamani za umakinifu kutoka kwa tokeni zilizochakatwa awali. Kujenga upya hali hiyo kunahitaji ujazaji mpya wa awali, hivyo kuongeza ucheleweshaji.

Badala yake, tunachukulia ukandamizaji wa mutadha kama mabadiliko mengine yanayodhibitiwa. Mfano asili wa muundo unapoendelea kuzungumza, mfumo hukandamiza muktadha na kuandaa mfano mbadala wa muundo kwa muktadha mpya. Mfano huo ukiwa tayari, tunaweza kuhamia kwake bila kukatiza midia. Hili huwezesha mfumo kuhimili simu za muda mrefu, ukikandamiza muktadha inapohitajika.

Kazi nzito hubaki nje ya njia ya moja kwa moja, kwa hivyo hata wakati wa makabidhiano, mazungumzo hayaachi kutiririka.

Uwezo wa GPT‑Live kutumia miundo ya AI ya kiwango cha juu zaidi iliyopo huipa nguvu kubwa, kwa kutenganisha “kuzungumza” na “kufikiri” kwa kina zaidi. Lakini kufanya usanifu huu wa miundo miwili uhisi kama mfumo mmoja kulihitaji kutatua matatizo mawili ya uhandisi yanayohusiana.

Kwanza, matokeo lazima yarudi haraka vya kutosha ili yafae katika mazungumzo yanayoendelea, kwa hivyo tulihitaji kupunguza ucheleweshaji katika njia nzima ya ukabidhi—kuanzia uelekezaji na uchakataji wa maelekezo hadi ujalizi na miito ya zana. Wakati huohuo, mifumo mingine katika bidhaa bado inahitaji ujumbe mahususi, kwa hivyo tulihitaji kuwakilisha mazungumzo yanayoendelea kwa njia ambayo mifumo hiyo ingeelewa.

Ukabidhi unapotumwa, tunaboresha muda unaochukua kabla ya muundo wa AI ya kiwango cha juu zaidi kutoa kitu kinachofaa katika mazungumzo. Muundo wa sauti unaweza kuendeleza mazungumzo kwa muda mfupi huku muundo wa AI ya kiwango cha juu zaidi ukifanya uwazaji au kutumia zana, lakini hauwezi kuficha jibu lolote lililochelewa kupita kiasi. Kwa hivyo, tulihesabu kitanzi kizima cha ukabidhi—uelekezaji, uchakataji wa maelekezo, ujalizi na miito ya zana—katika bajeti ya mwitikio.

Hatua ya kwanza ya uboreshaji ni kuandaa muundo wa AI ya kiwango cha juu zaidi na zana zozote unazohitaji kabla ya ukabidhi kuombwa. Kipindi cha sauti kinapoanza, seva ya programu huanzisha kipindi cha ujalizi kwa muundo wa AI ya kiwango cha juu zaidi na kukijaza mapema kwa muktadha wa kwanza wa mazungumzo, ili kuhakikisha maelekezo yamechakatwa kikamilifu kabla ya ombi la kwanza lililokabidhiwa.

Kisha tunadumisha kipindi hicho cha ujalizi katika mazungumzo yote ya sauti na kutumia mshikamano thabiti wa kipindi kwa maombi yanayofuata. Pamoja na uhifadhi wa maelekezo kwenye akiba, mbinu hizi hupunguza ucheleweshaji huku hitilafu ya kitekelezaji ikiendelea kurekebishika kwa urahisi.

Juhudi za uwazaji, vikomo vya matokeo, miundo ya zana na safari za kwenda na kurudi kati ya muundo na zana pia huathiri muda wa kupokea matokeo muhimu, kwa hivyo tulirekebisha vipengele hivi ili kupata majibu ya haraka. Kwa kupunguza kazi inayohitajika kwenye njia ya ukabidhi, tuliwezesha muundo wa sauti kujumuisha haraka matokeo kutoka kwenye miundo yetu ya AI ya kiwango cha juu zaidi.

Ingawa muundo wa sauti hushughulikia mitiririko endelevu ya usemi, mifumo mingi inayouzunguka bado hutumia zamu za mtumiaji na msaidizi, ikiwemo kiolesura cha mazungumzo cha ChatGPT na sehemu za miundombinu yetu ya uchanganuzi na usalama. Kwa hivyo, seva ya programu hutenganisha mazungumzo yanayoingiliana na ambayo wakati mwingine hayako wazi kuwa ujumbe mahususi.

Sauti inapowasili, seva hutumia nakala sehemu na ishara za muda kutambua anayezungumza na kuunda foleni ya ujumbe. Ujumbe mpya zaidi hubaki wa muda; maandishi, muda na mzungumzaji wake vinaweza kubadilika kadiri usemi zaidi unavyowasili. Mzungumzaji akiendelea kuzungumza kwa muda wa kutosha ili utambulisho wake uaminike, seva hukamilisha ujumbe unaohusika.

Wazungumzaji wanapoingiliana, hali hii huwa tata zaidi. Itikio fupi la msaidizi wakati mtumiaji anazungumza (k.m. “mm hmm,” au “okay”) si lazima liwe ujumbe wake binafsi. Hata hivyo, mara nyingi mwingilio wenye maudhui wa msaidizi unapaswa kuwa ujumbe wake binafsi. Vivyo hivyo, tunatanguliza mshikamano wa majibu ya msaidizi yanayoonyeshwa hata mtumiaji anapozungumza katikati.

Kila sera ya ugawaji husawazisha upya wa taarifa na uhakika. Kukamilisha mapema mno husababisha historia iliyogawanyika na mpangilio usiotulia; kusubiri kwa muda mrefu mno huchelewesha nakala na vipengele vinavyozitegemea. Kwa hivyo, mfumo hudumisha mitazamo miwili inayohusiana ya mazungumzo: mtazamo wa muda wa hali ya sasa na rekodi rasmi ya yaliyosemwa. Mwonekano wa mazungumzo katika kiolesura cha programu unaweza kushughulikia masasisho, kwa hivyo hutumia mtazamo wa muda. Lakini kurekodi kwenye mkondo wa uchanganuzi kunahitaji nakala ya mwisho.

Hili huipa sehemu nyingine ya ChatGPT mtazamo thabiti wa mazungumzo bila kulazimisha zamu kwenye njia ya sauti ya moja kwa moja.

Mwitikio huanza pindi tu mtumiaji anapobofya kitufe. Kwa GPT‑Live, mfumo lazima uanzishe njia ya midia na kuanza kupitisha sauti kwenye muundo kabla ya mazungumzo kuanza. Hivyo, kila sehemu ya mchakato wa kuanza huwa kwenye njia muhimu.

Kama ilivyoelezwa hapo juu, WebRTC hutoa msingi thabiti wa wakati halisi, lakini kuanzisha kipindi cha kawaida cha WebRTC huhitaji makubaliano mengi ya itifaki na safari nyingi za mtandao za kwenda na kurudi. WebRTC ilitangulia mkazo wa kupunguza safari za kwenda na kurudi ulioathiri itifaki za baadaye kama QUIC. Kwa hiyo, wakati mwingine itifaki zake za msingi hurudia kazi zinapotumiwa pamoja. Kwa mfano, kila itifaki ilikuwa na utaratibu wake wa kuzuia DoS, hata wakati haukuhitajika katika muktadha wa mkusanyiko mzima wa WebRTC.

Tulichanganua mkusanyiko huo na kutengeneza WebRTC Abridged Roundtrip Protocol (WARP⁠(fungua katika dirisha jipya)), inayopunguza uanzishaji wa midia na data kutoka safari sita za mtandao za kwenda na kurudi hadi moja tu. WARP hufanikisha hili kupitia maboresho kadhaa ya itifaki yanayooana na mifumo ya awali: kuambatanisha makubaliano ya DTLS kwenye ICE (SPED⁠(fungua katika dirisha jipya)), kutumia makubaliano ya haraka zaidi ya DTLS 1.3⁠(fungua katika dirisha jipya), kujadiliana mapema kuhusu makubaliano ya SCTP (SNAP⁠(fungua katika dirisha jipya)) na kujadiliana mapema kuhusu vituo vya data badala ya kutumia DCEP⁠(fungua katika dirisha jipya).

Tulibuni WARP kama seti ya vipimo huria, tukishirikiana na washirika kutoka jumuiya ya WebRTC ili mfumo mpana zaidi unufaike na kazi hii. Tunaendeleza mapendekezo kupitia kikundi cha kazi cha TSVWG cha IETF, na usaidizi wa WARP tayari umeongezwa kwenye libwebrtc na Pion, huku juhudi zikiendelea katika utekelezaji mwingine wa WebRTC.

Baada ya kuboresha makubaliano ya midia, ucheleweshaji mmoja uliobaki ulijitokeza: ubadilishanaji wa ishara unaotumiwa kushiriki vigezo vya SDP kabla WebRTC haijaunganishwa. Ili kuondoa ubadilishanaji huo kwenye njia muhimu, tulitengeneza kile tunachokiita Instant Connect. Hujadiliana kuhusu vigezo hivi mapema bila kuhifadhi uwezo wa seva wala kubadilisha utekelezaji uliopo wa WebRTC.

Instant Connect huendeshwa sambamba na mtiririko wa kawaida wa ishara. Ikiwa vigezo vilivyojadiliwa mapema ni halali, seva inaweza kuanzisha kipindi pakiti ya kwanza ya midia inapowasili. Ikiwa vimepitwa na wakati au si halali, mtiririko wa ishara tayari unaendelea, kwa hivyo mteja anaweza kurudi kwenye njia ya kawaida bila ucheleweshaji wa ziada.

Kwa pamoja, Instant Connect na WARP hupunguza sana muda kati ya nia ya mtumiaji na kuanza kwa mtiririko wa moja kwa moja wa midia. Ubadilishanaji wa SDP ukiwa nje ya njia muhimu na WARP ikifupisha makubaliano ya usafirishaji, sasa mteja anaweza kuanzisha kipindi kwa pakiti moja ya UDP. Seva inaweza kujibu mara moja, hivyo kuruhusu mfumo mwingine uanze kufanya kazi ambayo mtumiaji anajali hasa: kusikiliza na kujibu.

Mfumo unaweza kuonekana wa haraka kinadharia lakini ukakwama unapopokea trafiki halisi ya sauti. Kabla ya kuruhusu GPT‑Live izungumze na watumiaji, tulifanya jaribio kimya lililoelekeza sehemu ndogo iliyoongezwa hatua kwa hatua ya vipindi vya uzalishaji vya Zungumza na ChatGPT kwenye hali ya sauti mahiri iliyokuwepo na mfumo wetu mpya kwa pamoja. Hali ya sauti mahiri iliendelea kuwahudumia watumiaji kama kawaida, huku njia kivuli ikiendesha ujalizi katika hali ya kusoma pekee. Hili liliuweka mfumo katika hali ya kushughulikia wateja, mitandao, urefu wa vipindi na usambazaji wa kijiografia wa kweli bila kubadilisha walichosikia watumiaji.

Mojawapo ya mafunzo ya kwanza ni kwamba uwezo haungeweza kupimwa kwa utendaji wa GPU pekee. Vipindi vya sauti hubaki wazi na kutuma fremu mfululizo, kwa hivyo vidhibiti vya mitiririko upande wa CPU, foleni na njia za mtandao lazima zipanuke sambamba na ujalizi. Chini ya mzigo halisi, kijenzi kimoja saidizi kilifikia kikomo mapema kuliko makadirio ya majaribio yetu ya mzigo, hivyo maombi ya ujalizi yakajikusanya na ucheleweshaji ukaongezeka zaidi. Tulibadili swali kuhusu uwezo kutoka “GPU inaweza kushughulikia maombi mangapi?” hadi “Mfumo unaweza kuendesha vipindi vingapi kwa wakati mmoja huku kila fremu ikifika kwa wakati?”

Jaribio hilo pia lilifanya jiografia kuwa suala la msingi. Kuelekeza kipindi kwenye uwezo ulio mbali kunaweza kuongeza ucheleweshaji katika sehemu kadhaa wakati wa kuanza na kutiririsha. Tulianza kuthibitisha utoaji wa miundo pamoja na uwezo wa kikanda na usanidi wa uelekezaji wa trafiki, kisha tukachanganua ucheleweshaji kulingana na eneo la chanzo. Kusogeza ujalizi karibu na watumiaji kulisaidia, lakini pia kulisisitiza funzo pana zaidi: mwitikio wa mwanzo hadi mwisho hutegemea kila huduma kwenye njia, si seva ya muundo pekee.

Hitilafu nyingine zilijitokeza tu katika mizunguko halisi ya vipindi. Vipindi vya muda mrefu vilifichua shinikizo kwenye kumbukumbu na uhifadhi endelevu. Miunganisho upya ilijaribu ukandamizaji wa mutadha na urejeshaji wa hali. Kukatika kwa kawaida kwa wateja kulifichua migongano katika makubaliano ya kuzima. Matatizo haya hayakutokea mara nyingi katika majaribio mafupi ya mzigo kwa sababu yalitegemea muda, hali iliyokusanyika na tabia inayovuka mipaka ya huduma.

Hatimaye, majaribio ya uzalishaji yalitulazimu kuboresha ufuatiliaji na vidhibiti vya utoaji. Tuligundua vipimo vilivyochanganya vyanzo tofauti vya ucheleweshaji, dashibodi ambazo majumuisho yake yalificha injini mahususi zenye hitilafu na tofauti za usanidi kati ya mifumo iliyojaribiwa na iliyotumika. Kwa hiyo, tuliongeza telemetria ya kina zaidi, uthibitishaji dhidi ya usanidi unaojulikana kuwa mzuri, ongezeko la hatua kwa hatua na uwezo wa kutenga au kuzima njia mahususi haraka. Jaribio hilo kimya likawa mazoezi ya mapema ya uzinduzi—si tu ya kiasi cha trafiki ambacho mfumo ungeweza kupokea, bali pia ya kasi yetu ya kugundua, kudhibiti na kurekebisha hitilafu.

Kupanua GPT‑Live hadi kiwango cha ChatGPT kulihitaji mfumo mpya kabisa uliojengwa kwa kanuni moja ya msingi: sauti lazima itiririke. Ujalizi wa mtiririko huendelea kuupatia muundo wa pande mbili sauti. Njia maalumu ya midia huhakikisha fremu zinawasilishwa kwa uhakika. Ukabidhi usawazishaji huruhusu fikra za kina zaidi ziendeshwe sambamba. Usafirishaji ulioboreshwa hudumisha mwitikio hadi kwa mtumiaji.

Usanifu wa GPT‑Live tayari unakuwa jukwaa pana zaidi la mwingiliano wa wakati halisi. Unaendesha Zungumza na ChatGPT inapopanuka kutoka mazungumzo hadi uratibu wa kiwakala, na utakuwa msingi wa API inayokuja ya GPT‑Live. Baada ya muda, utaruhusu matumizi ya sauti kuenea kwenye vifaa, programu na mbinu zaidi bila kupoteza mwitikio unaofanya mazungumzo ya sauti yahisi kuwa ya moja kwa moja.

Ikiwa ungependa kutatua matatizo ya uhandisi ya aina hii, njoo ufanye kazi nasi⁠.