Näin rakensimme responsiivisen äänitekoälyn reaaliaikaisen järjestelmän kuudessa kuukaudessa

Äänipohjaisen tekoälyn on vaikeampi tietää, milloin puhua, kuin voisi kuvitella. Ihmiset vaihtavat puhujaa vaivattomasti sekunnin murto-osassa, mutta aiemmat äänipohjaiset tekoälyjärjestelmät eivät pysyneet tämän rytmin mukana. Niiden vuoropohjainen arkkitehtuuri tukeutui pieniin vuorontunnistimiksi kutsuttuihin malleihin, joiden tehtävä oli epäkiitollinen: liian aikainen arvaus keskeyttää käyttäjän, liian myöhäinen tekee vastauksesta hitaan tuntuisen. Paljon suurempi suuri kielimalli pääsi töihin vasta tunnistimen tehtyä päätöksensä.

Kolmannen sukupolven äänijärjestelmämme GPT‑Live⁠ poistaa vuorontunnistimen äänipolulta. Sen äänimalli on kaksisuuntainen, eli se voi kuunnella ja puhua samanaikaisesti. Erillistä tunnistinta ei siis tarvita, ja keskustelu tuntuu välittömämmältä ja luonnollisemmalta. Kun tarvitaan syvempää päättelyä tai työkalujen käyttöä, GPT‑Live voi myös konsultoida edistyneitä mallejamme, kuten GPT‑5.5:tä, keskeyttämättä keskustelun kulkua. Yhdessä nämä ominaisuudet antavat GPT‑Livelle ennennäkemättömän yhdistelmän keskustelun responsiivisuutta ja älykkyyttä.

Tämän käyttökokemuksen tarjoaminen suuressa mittakaavassa vaati uuden, pientä viivettä varten optimoidun järjestelmäarkkitehtuurin. Tavallisesta pyyntö–vastaus-inferenssistä poiketen järjestelmämme suoratoistaa saapuvan äänen äänimalliin ja lähtevän puheen takaisin käyttäjälle sekä käsittelee delegoinnin erillisellä asynkronisella polulla. Viimeisten kuuden kuukauden aikana uudistimme mallin inferenssin, kontekstinhallinnan ja median siirron, jotta puhe virtaisi sujuvasti päästä päähän.

Arkkitehtuuri muodostaa myös selkeän rajan keskeisen äänipolun ja sovelluslogiikan välille. Näin sovelluksen toimintaa on helppo mukauttaa vasteaikaan vaikuttamatta. Tämä perusta tukee ChatGPT Voicen kasvavaa ominaisuusvalikoimaa, kuten äskettäin julkaistua mahdollisuutta hallita tietokonetta ja koordinoida agentteja ChatGPT:n työpöytäsovelluksessa.

Tässä kirjoituksessa kerromme, miksi aiemmat vuoropohjaiset järjestelmät eivät vastanneet tarpeitamme ja miten suunnittelimme uuden järjestelmän responsiiviseksi sen jokaisella tasolla. Käsittelemme tilallista inferenssiä, dynaamista kontekstinhallintaa, asynkronista delegointia ja protokollatason optimointia, jotka yhdessä saavat GPT‑Liven tuntumaan aidosti reaaliaikaiselta.

Aiemmat ääniarkkitehtuurit perivät tekstipohjaisten suurten kielimallien vuoropohjaisuuden, mutta tekstin sijaan kukin vuoro esitettiin erillisenä äänitiedostona. Ketjutetuissa järjestelmissä puheentunnistus, suuri kielimalli ja puhesynteesi suoritettiin peräkkäin. Tämä vaiheistus lisäsi viivettä ja jätti huomiotta esimerkiksi äänensävyn ja puheen rytmin.

Puheesta puheeksi -mallit paransivat lähestymistapaa käsittelemällä ääntä suoraan. Kun malli koulutettiin ymmärtämään ja tuottamaan puhetta suoraan, se pystyi säilyttämään litteroinnissa katoavia yksityiskohtia ja vastaamaan nopeammin. Järjestelmä tukeutui silti vuorontunnistimeen päättääkseen, milloin inferenssi voitiin aloittaa. Malli hoiti suuremman osan vuorovaikutuksesta, mutta vuorovaikutus pysyi vuoropohjaisena.

GPT‑Live antaa äänimallille keskustelun hallinnan: ääni virtaa malliin ja siitä ulos, kun taas syvempi päättely ja työkalujen käyttö tapahtuvat asynkronisesti. Järjestelmän tärkein tehtävä on ylläpitää katkeamatonta mediasilmukkaa. Muu työ, kuten edistyneiden mallien kutsuminen ja keskustelun tallentaminen, tehdään reaaliaikaisen polun ulkopuolella.

Tämän mediasilmukan pitäminen katkeamattomana ei ole aina yksinkertaista. Siirron, käsittelyn tai inferenssin viive voi kuulua taukona tai äänihäiriönä. Aiempi vuoropohjainen järjestelmä sieti jonkin verran vaihtelua siinä, milloin äänitiedosto saapui. Reaaliaikaisen mediajärjestelmän on kuitenkin toimitettava jokainen äänikehys ajallaan.

Aiempi työmme ChatGPT Voicen ja Realtime API:n parissa loi tärkeän perustan. Olimme jo rakentaneet ääni-infrastruktuurimme uudelleen⁠, jotta ääntä ja videota voitiin suoratoistaa suoraan järjestelmiimme ja niistä ulos pienemmällä ja ennakoitavammalla viiveellä. GPT‑Live vei suunnittelun pidemmälle suoratoistamalla median mallille asti uuden, jatkuvaan keskusteluun rakennetun tilallisen inferenssijärjestelmän kautta.

Suoratoistava inferenssi oli kuitenkin vain osa ratkaisua. Jotta ratkaisu toimisi hyvin tuotannossa, meidän oli myös varmistettava äänen luotettava toimitus asiakasohjelmasta inferenssipinoon ja ratkaistava tilallisuuden haasteet.

Yksi varhaisista päätöksistämme oli erottaa mediavirta selkeästi sovellus- ja liiketoimintalogiikasta. Ääni kulkee asiakasohjelman ja äänimallin välillä erillistä nopeaa polkua pitkin. Delegointi, työkalujen käyttö ja muu sovellustyö tapahtuvat asynkronisen RPC-rajan takana. Hidas työkalukutsu tai taustapalvelu voi viivästyttää omaa tulostaan mutta ei pysäyttää mediavirtaa.

Tämä erottelu muodostaa järjestelmään myös selkeän mukautusrajan. Sovellukset voivat muuttaa työkalujaan, käytäntöjään ja taustajärjestelmänsä toimintaa vaikuttamatta median käyttöliittymään, joka pitää äänen liikkeessä. Reaaliaikainen polku pysyy pienenä, ennakoitavana ja keskittyy työhön, joka on tehtävä reaaliajassa.

Kirjoitimme median käyttöliittymän ja inferenssilogiikan Go-kielellä ja korvasimme aiemman Pythonin asyncio-toteutuksen. Tämä paransi kehysten toimituksen tasaisuutta merkittävästi: uuden järjestelmän p95 vastasi aiemman järjestelmän p50:tä.

WebRTC muodostaa siirron perustan. Se on suunniteltu viiveettömään mediaan ja pystyy jatkamaan toimintaansa pakettihäviöistä, kellopoikkeamista ja asiakasohjelman yhteysmuutoksista huolimatta. Jos paketit saapuvat myöhässä, WebRTC voi venyttää ääntä huomaamattomasti aukkojen välttämiseksi ja nopeuttaa sitten toistoa hetkeksi päästäkseen takaisin reaaliaikaan.

Minimoimalla puskuroinnin ja estot koko järjestelmässä voimme saavuttaa alle sekunnin vasteajan, jota ihmiset odottavat keskustelulta.

Tilalliseen inferenssiin liittyy omia toiminnallisia kompromisseja. Ääni-istunto voi jatkua pitkään, mutta sen konteksti kasvaa jatkuvasti ja malli-ilmentymiä käynnistetään ja sammutetaan kysynnän mukaan.

Näiden haasteiden ratkaisemiseksi rakensimme saumattoman vaihtomekanismin malli-ilmentymien välille. Kun siirtymää tarvitaan, voimme lämmittää korvaavan malli-ilmentymän nykyisen rinnalla, esitäyttää sen istunnon nykyisellä kontekstilla, suorittaa inferenssiä molemmilla rinnakkain ja vaihtaa uuteen ilmentymään, kun se on täysin valmis.

Sama perusmekanismi tukee myös dynaamista kontekstin tiivistämistä. Keskustelun jatkuessa sen kertynyt konteksti voi lopulta ylittää mallin kontekstirajan. Kontekstin tiivistäminen voi pienentää sen rajan mukaiseksi, mutta toiminto vie aikaa. Koska se muuttaa aiempaa kontekstia, se myös mitätöi mallin avain-arvo- eli KV-välimuistin, johon tallennetaan aiemmin käsiteltyjen saneiden tarkkaavaisuusavaimet ja -arvot. Tämän tilan rakentaminen uudelleen vaatii uuden esitäytön, mikä lisää viivettä.

Sen sijaan käsittelemme kontekstin tiivistämistä uutena hallittuna siirtymänä. Alkuperäisen malli-ilmentymän jatkaessa keskustelua järjestelmä tiivistää kontekstin ja valmistelee korvaavan malli-ilmentymän uudella kontekstilla. Kun uusi ilmentymä on valmis, voimme siirtyä siihen mediavirtaa katkaisematta. Näin järjestelmä voi tukea pitkiä puheluita ja tiivistää kontekstia aina tarvittaessa.

Raskas työ tehdään reaaliaikaisen polun ulkopuolella, joten keskustelu jatkuu katkeamatta myös vaihdon aikana.

GPT‑Live saa paljon tehoa kyvystään kutsua nykyisiä edistyneitä malleja. Näin ”puhuminen” voidaan käytännössä erottaa syvemmästä ”ajattelusta”. Jotta tämä kahden mallin arkkitehtuuri tuntuisi yhdeltä järjestelmältä, meidän oli kuitenkin ratkaistava kaksi toisiinsa liittyvää teknistä ongelmaa.

Tulosten on ensinnäkin palattava riittävän nopeasti, jotta niistä on hyötyä käynnissä olevassa keskustelussa. Siksi viive oli minimoitava koko delegointipolulla reitityksestä ja kehotteen käsittelystä inferenssiin ja työkalukutsuihin. Samalla tuotteen muut järjestelmät tarvitsevat edelleen erillisiä viestejä, joten käynnissä oleva keskustelu oli esitettävä niiden ymmärtämässä muodossa.

Kun delegointi lähetetään, optimoimme ajan siihen, että edistynyt malli tuottaa keskustelulle jotain hyödyllistä. Äänimalli voi pitää keskustelua hetken käynnissä edistyneen mallin päätellessä tai käyttäessä työkaluja, mutta se ei pysty peittämään rajattoman hidasta vastausta. Siksi sisällytimme koko delegointisilmukan – reitityksen, kehotteen käsittelyn, inferenssin ja työkalukutsut – vasteaikabudjettiin.

Ensimmäinen optimointi on valmistella edistynyt malli ja sen tarvitsemat työkalut ennen delegointipyyntöä. Ääni-istunnon alkaessa sovelluspalvelin luo edistyneelle mallille inferenssi-istunnon ja esitäyttää sen keskustelun alkukontekstilla. Näin kehote on käsitelty kokonaan ennen ensimmäistä delegoitua pyyntöä.

Pidämme inferenssi-istunnon käytettävissä koko äänikeskustelun ajan ja käytämme peräkkäisissä pyynnöissä vakaata istuntokohdistusta. Yhdessä kehotteen välimuistitallennuksen kanssa nämä tekniikat lyhentävät viivettä, mutta suorittajan viasta palautuminen säilyy helppona.

Myös päättelyn määrä, tulostusrajat, työkaluskeemat sekä mallin ja työkalun väliset edestakaiset kutsut vaikuttavat siihen, milloin keskustelu saa hyödyllisen tuloksen. Säädimme näitä tekijöitä nopeuttaaksemme vastauksia. Minimoimalla delegointipolulla tarvittavan työn mahdollistimme sen, että äänimalli voi hyödyntää edistyneiden malliemme tuloksia nopeasti.

Vaikka äänimalli käsittelee jatkuvia puhevirtoja, monet sitä ympäröivät järjestelmät toimivat yhä käyttäjän ja avustajan puheenvuorojen pohjalta. Näitä ovat esimerkiksi ChatGPT:n keskustelukäyttöliittymä sekä osa analytiikka- ja turvallisuusinfrastruktuuristamme. Siksi sovelluspalvelin jäsentää päällekkäisen ja ajoittain monitulkintaisen keskustelun erillisiksi viesteiksi.

Äänen saapuessa palvelin päättelee osittaisten litterointien ja ajoitussignaalien avulla, kenellä on puheenvuoro, ja muodostaa viestijonon. Uusin viesti pysyy alustavana: sen teksti, ajoitus ja puhujamääritys voivat muuttua puheen jatkuessa. Kun puhujalla on ollut puheenvuoro riittävän pitkään luotettavaa tunnistusta varten, palvelin viimeistelee vastaavan viestin.

Puhujien päällekkäisyys mutkistaa tätä. Avustajan lyhyestä kuittauksesta käyttäjän puhuessa (esim. “mm hmm,” tai “okay”) ei välttämättä pitäisi muodostaa omaa viestiä. Avustajan sisällöllisestä välihuomautuksesta taas usein pitäisi. Samoin painotamme näytettävien avustajan vastausten johdonmukaisuutta silloinkin, kun käyttäjä puhuu välissä.

Jokaisessa segmentointikäytännössä tasapainotellaan ajantasaisuuden ja varmuuden välillä. Liian aikainen vahvistaminen pirstoo historian ja tekee järjestyksestä epävakaan. Liian pitkä odotus taas viivästyttää litterointeja ja niistä riippuvia ominaisuuksia. Siksi järjestelmä ylläpitää keskustelusta kahta toisiinsa liittyvää näkymää: nykytilan alustavaa näkymää ja vahvistettua tallennetta sanotusta. Sovelluksen käyttöliittymän keskustelunäkymä pystyy käsittelemään päivityksiä, joten se käyttää alustavaa näkymää. Analytiikkaputkeen kirjaaminen puolestaan edellyttää lopullista litterointia.

Näin muu ChatGPT saa keskustelusta vakaan näkymän ilman, että reaaliaikaiselle äänipolulle pakotetaan vuorottelua.

Responsiivisuus alkaa heti, kun käyttäjä napsauttaa painiketta. GPT‑Livessä järjestelmän on muodostettava mediapolku ja alettava syöttää ääntä mallin läpi ennen kuin keskustelu voi alkaa. Siksi käynnistysjakson jokainen osa on kriittisellä polulla.

Kuten edellä todettiin, WebRTC tarjoaa vahvan reaaliaikaisen perustan, mutta tavallisen WebRTC-istunnon käynnistäminen vaatii yllättävän monta protokollakättelyä ja edestakaista verkkoyhteyttä. WebRTC kehitettiin ennen kuin edestakaisten yhteyksien minimoinnista tuli QUICin kaltaisia myöhempiä protokollia ohjaava tavoite. Siksi sen taustalla olevat protokollat tekevät yhdessä käytettyinä toisinaan samaa työtä toistamiseen. Esimerkiksi jokaisessa protokollassa oli oma palvelunestohyökkäysten torjuntamekanisminsa, vaikka sitä ei aina tarvittu koko WebRTC-pinon yhteydessä.

Analysoimme pinon ja kehitimme WebRTC Abridged Roundtrip Protocol -protokollan (WARP⁠(avautuu uudessa ikkunassa)), joka vähentää median ja datan käynnistämiseen tarvittavat edestakaiset verkkoyhteydet kuudesta yhteen. WARP saavuttaa tämän taaksepäin yhteensopivilla protokollaparannuksilla: DTLS-kättely siirretään ICE:n mukana (SPED⁠(avautuu uudessa ikkunassa)), käytetään nopeampaa DTLS 1.3⁠(avautuu uudessa ikkunassa) -kättelyä, SCTP-kättely neuvotellaan ennakkoon (SNAP⁠(avautuu uudessa ikkunassa)) ja datakanavat neuvotellaan ennakkoon DCEP⁠(avautuu uudessa ikkunassa):n käytön sijaan.

Suunnittelimme WARPin avoimiksi määrityksiksi yhdessä WebRTC-yhteisön yhteistyökumppaneiden kanssa, jotta työ hyödyttäisi laajempaa ekosysteemiä. Edistämme ehdotuksia IETF:n TSVWG-työryhmässä. WARP-tuki on jo lisätty sekä libwebrtc- että Pion-toteutukseen, ja työ on käynnissä muissakin WebRTC-toteutuksissa.

Mediakättelyn optimoinnin jälkeen yksi jäljellä oleva viive erottui: signalointivaihto, jolla SDP-parametrit jaetaan ennen WebRTC-yhteyden muodostamista. Poistaaksemme tämän vaihdon kriittiseltä polulta kehitimme Instant Connectiksi kutsumamme ratkaisun. Se neuvottelee parametrit ennakkoon varaamatta palvelinkapasiteettia ja muuttamatta nykyisiä WebRTC-toteutuksia.

Instant Connect toimii tavallisen signalointivirran rinnalla. Jos ennakkoon neuvotellut parametrit ovat kelvolliset, palvelin voi muodostaa istunnon ensimmäisen mediapaketin saapuessa. Jos ne ovat vanhentuneet tai virheelliset, signalointi on jo käynnissä, joten asiakasohjelma voi siirtyä vararatkaisuun ilman lisäviivettä.

Yhdessä Instant Connect ja WARP lyhentävät huomattavasti aikaa käyttäjän aikomuksesta reaaliaikaisen mediavirran alkamiseen. Kun SDP-vaihto on poistettu kriittiseltä polulta ja WARP tiivistää siirtokättelyn, asiakasohjelma voi nyt käynnistää istunnon yhdellä UDP-paketilla. Palvelin voi vastata välittömästi, jolloin muu järjestelmä pääsee tekemään käyttäjälle tärkeää työtä: kuuntelemaan ja vastaamaan.

Järjestelmä voi vaikuttaa paperilla nopealta mutta silti takellella todellisessa ääniliikenteessä. Ennen kuin päästimme GPT‑Liven keskustelemaan käyttäjien kanssa, teimme hiljaisen testin, jossa pieni ja vähitellen kasvava osuus tuotannon ChatGPT Voice -istunnoista ohjattiin sekä nykyiseen edistyneeseen äänitilaan että uuteen järjestelmäämme. Edistynyt äänitila palveli käyttäjiä tavalliseen tapaan, kun taas varjopolku suoritti inferenssiä vain luku -tilassa. Näin järjestelmä altistui todellisille asiakasohjelmille, verkoille, istuntojen pituuksille ja maantieteelliselle jakaumalle ilman, että käyttäjien kuulema sisältö muuttui.

Yksi ensimmäisistä havainnoista oli, ettei kapasiteettia voinut pelkistää GPU:n suoritustehoksi. Ääni-istunnot pysyvät avoinna ja lähettävät kehyksiä jatkuvasti, joten suorittimella toimivien virrankäsittelijöiden, jonojen ja verkkopolkujen on skaalauduttava inferenssin mukana. Todellisella kuormalla yksi tukikomponenteista saavutti kapasiteettinsa ennen kuormitustestien ennustetta, jolloin inferenssipyynnöt kasaantuivat ja viive kasvoi entisestään. Muutimme kapasiteettia koskevan kysymyksen muodosta ”Kuinka monta pyyntöä GPU pystyy käsittelemään?” muotoon ”Kuinka monta samanaikaista istuntoa järjestelmä pystyy ylläpitämään niin, että jokainen kehys pysyy aikataulussa?”

Testi nosti myös maantieteellisen sijainnin keskeiseksi kysymykseksi. Istunnon ohjaaminen kaukana sijaitsevaan kapasiteettiin voi lisätä viivettä useissa käynnistyksen ja suoratoiston vaiheissa. Aloimme validoida mallien käyttöönottoja yhdessä alueellisen kapasiteetin ja liikenteenohjauksen määritysten kanssa sekä eritellä viivettä lähdealueen mukaan. Inferenssin siirtäminen lähemmäs käyttäjiä auttoi, mutta vahvisti myös laajemman opetuksen: päästä päähän -vasteaika riippuu polun jokaisesta palvelusta, ei vain mallipalvelimesta.

Muita vikoja ilmeni vain realististen istuntojen koko elinkaaren aikana. Pitkään jatkuvat istunnot paljastivat muistiin ja pysyvään tallennukseen kohdistuvia paineita. Uudelleenyhdistämiset koettelivat kontekstin tiivistämistä ja tilan palauttamista. Tavalliset asiakasohjelman yhteyden katkeamiset paljastivat kilpailutilanteita sulkemiskättelyssä. Näitä ongelmia ilmeni harvoin lyhyissä kuormitustesteissä, koska ne riippuivat ajasta, kertyneestä tilasta ja toiminnasta palvelurajojen yli.

Lopuksi tuotantotestaus pakotti meidät parantamaan havainnoitavuutta ja käyttöönoton hallintaa. Löysimme mittareita, joissa eri viivelähteet sekoittuivat, koontinäyttöjä, joiden yhteenvetotiedot peittivät yksittäisten moottorien ongelmat, sekä määrityseroja testattujen ja käyttöönotettujen järjestelmien välillä. Lisäsimme tämän vuoksi tarkempaa telemetriaa, vertailun toimiviksi tiedettyihin määrityksiin, vaiheittaisen liikenteen kasvatuksen sekä mahdollisuuden eristää tai poistaa nopeasti käytöstä yksittäisiä polkuja. Hiljaisesta testistä tuli varhainen julkaisuharjoitus: siinä ei testattu vain järjestelmän liikennekapasiteettia vaan myös sitä, kuinka nopeasti pystyimme havaitsemaan ja rajaamaan viat sekä palautumaan niistä.

GPT‑Liven tuominen ChatGPT:n mittakaavaan vaati täysin uuden järjestelmän, joka rakennettiin yhden perusperiaatteen ympärille: äänen on virrattava. Suoratoistava inferenssi syöttää ääntä jatkuvasti kaksisuuntaiselle mallille. Erillinen mediapolku varmistaa kehysten luotettavan toimituksen. Asynkroninen delegointi mahdollistaa syvemmän ajattelun rinnakkain. Optimoitu siirto pitää käyttökokemuksen responsiivisena käyttäjälle.

GPT‑Liven taustalla oleva arkkitehtuuri on jo kehittymässä laajemmaksi reaaliaikaisen vuorovaikutuksen alustaksi. Se tukee ChatGPT Voicea tämän laajentuessa keskusteluista agenttien koordinointiin, ja se toimii myös tulevan GPT‑Live API:n perustana. Ajan myötä se mahdollistaa äänikokemusten ulottamisen yhä useampiin laitteisiin, sovelluksiin ja modaliteetteihin tinkimättä välittömyydestä, joka saa äänikeskustelun tuntumaan elävältä.

Jos haluat ratkaista tällaisia teknisiä ongelmia, tule meille töihin⁠.