Come OpenAI fornisce intelligenza artificiale vocale a bassa latenza su scala

La tecnologia di intelligenza artificiale vocale può essere considerata naturale solo se le conversazioni si svolgono al ritmo della parlata. Quando la rete si frappone, le persone percepiscono immediatamente le pause goffe, le interruzioni tronche o le intrusioni ritardate. Ciò è importante per ChatGPT voice, per gli sviluppatori che utilizzano l'API in tempo reale, per gli agenti che lavorano in flussi di lavoro interattivi e per i modelli che devono elaborare l'audio mentre l'utente sta ancora parlando.

A scala OpenAI, ciò si traduce in tre requisiti concreti: raggiungere più di 900 milioni di utenti attivi settimanali, avere una connessione rapida per consentire all'utente di iniziare a parlare non appena la sessione inizia e avere un tempo di ritorno multimediale basso e stabile, con bassa jitter e perdita di pacchetti, in modo che il turn-taking sia fluido.

Il team di OpenAI incaricato delle interazioni AI in tempo reale ha recentemente reimpostato la sua pila WebRTC per affrontare tre vincoli che si sono scontrati a scala: la terminazione multimediale per sessione a un porto non si adatta bene all'infrastruttura di OpenAI, le sessioni ICE (Interactive Connectivity Establishment) e DTLS (Datagram Transport Layer Security) statali richiedono una proprietà stabile e l'instradamento globale deve mantenere bassa la latenza nel primo salto.

WebRTC è uno standard aperto per l'invio di audio, video e dati a bassa latenza tra browser, app mobili e server. È spesso associato alle chiamate peer-to-peer, ma è anche una base pratica per i sistemi client-server in tempo reale, poiché standardizza le parti difficili dei media interattivi: ICE per l'istituzione della connettività e il through NAT (Network Address Translation), DTLS e SRTP (Secure Real-time Transport Protocol) per il trasporto criptato, la negoziazione dei codec per la compressione e la decodifica dell'audio, RTCP (Real-time Transport Control Protocol) per il controllo della qualità e le funzionalità client-side come l'annullamento dell'eco e la gestione della jitter.

Questa standardizzazione è importante per i prodotti di intelligenza artificiale. Senza WebRTC, ogni client avrebbe bisogno di una risposta diversa su come stabilire la connettività attraverso i NAT, criptare i media, negoziare i codec e adattarsi alle condizioni di rete in evoluzione. Con WebRTC, possiamo costruire su uno stack di protocolli che è già implementato tra i browser e le piattaforme mobili, concentrandomo il nostro lavoro sull'infrastruttura che collega i media in tempo reale ai modelli.

Ci basiamo anche sull'ecosistema WebRTC stesso, comprese le implementazioni open-source mature e il lavoro standard che mantiene i browser, le app mobili e i server interoperabili. Il lavoro fondamentale di Justin Uberti (uno degli architetti originali di WebRTC) e Sean DuBois (creatore e manutentore di Pion) ha reso possibile per i team come il nostro costruire su un'infrastruttura multimediale testata piuttosto che reinventare il comportamento di trasporto, crittografia e controllo della congestione a basso livello.

Per l'intelligenza artificiale, la proprietà più importante è che l'audio arrivi come flusso continuo. Un agente parlante può iniziare a trascrivere, ragionare, chiamare strumenti o generare discorsi mentre l'utente sta ancora parlando, anziché attendere il caricamento completo. Questa è la differenza tra un sistema che sembra conversazionale e uno che sembra un sistema di comunicazione push-to-talk.

Una volta scelto WebRTC, la prossima domanda è stata dove terminarlo (dove accettare e possedere la connessione WebRTC - ad esempio, ai margini) e come connettere quelle sessioni al back-end dell'inferenza. La terminazione è importante perché determina come gestiamo lo stato della sessione in tempo reale, il trasporto multimediale, l'instradamento, la latenza e l'isolamento dei guasti.

Un SFU (Selective Forwarding Unit) o unità di inoltro selettivo, è un server multimediale che riceve un flusso WebRTC da ogni partecipante e invia selettivamente i flussi agli altri. In questo modello, l'SFU termina una connessione WebRTC separata per ogni partecipante e l'intelligenza artificiale si unisce come un altro partecipante alla sessione. Ciò può essere adatto per prodotti che sono intrinsecamente multiparty, come le chiamate di gruppo, le lezioni o le riunioni collaborative. Mantiene i codec audio, i messaggi RTCP, i canali di dati, la registrazione e le policy per flusso in un unico luogo.

Anche nei prodotti client-to-AI, un SFU è spesso il punto di partenza predefinito, poiché consente ai team di riutilizzare un unico sistema provato per la segnalazione, l'inoltro multimediale, la registrazione, l'osservabilità e le estensioni future, come il passaggio umano o l'aggiunta di altri partecipanti.

Il nostro carico di lavoro è diverso. La maggior parte delle sessioni è 1:1: un utente che parla con un modello o un'applicazione che parla con un agente in tempo reale - con sensibilità alla latenza su ogni turno. Per questo tipo di traffico, abbiamo scelto un modello di tipo "transceiver": un servizio WebRTC edge termina la connessione client e quindi converte i media ed eventi in protocolli interni più semplici per inferenza del modello, trascrizione, generazione di discorsi, utilizzo di strumenti e orchestrazione.

In questo design, il transceiver è l'unico servizio che possiede lo stato della sessione WebRTC, compresi i controlli di connettività ICE, la handshake DTLS, le chiavi di crittografia SRTP e il ciclo di vita della sessione. La "terminazione" qui significa che il transceiver è l'endpoint che completa quegli accordi e crittografa o decrittografa i media. Mantenere quello stato in un unico luogo ha reso più facile ragionare sulla proprietà della sessione e ha consentito ai servizi back-end di scalare come servizi comuni anziché agire come peer WebRTC.

Dopo aver scelto il modello transceiver, la nostra prima implementazione è stata un unico servizio Go costruito su Pion che gestiva sia la segnalazione che la terminazione multimediale. Questo alimenta ChatGPT voice, il punto finale WebRTC dell'API in tempo reale e un certo numero di progetti di ricerca.

Operativamente, il servizio transceiver svolge due compiti: la segnalazione (la negoziazione SDP, la selezione dei codec, le credenziali ICE e la configurazione della sessione) e i media (la terminazione delle connessioni WebRTC downstream e il mantenimento delle connessioni upstream ai servizi back-end per l'inferenza e l'orchestrazione).

Volevamo che il servizio funzionasse come il resto della nostra infrastruttura: su Kubernetes, dove i carichi di lavoro possono scalare su e giù e spostarsi tra gli host man mano che la domanda cambia. Ma il modello WebRTC convenzionale a un porto per sessione si adatta male a quell'ambiente, poiché