AIREITERUn agente vocale che aspetta il silenzio prima di iniziare a ragionare può essere rapido e, allo stesso tempo, sembrare artificiale. GPT-Live affronta il problema alla radice: ascolto e parlato procedono lungo un flusso continuo, mentre ricerca, strumenti e ragionamento più approfondito vengono eseguiti a fianco — non dentro — il ciclo audio. Il risultato è un’interazione più naturale, ma anche un sistema molto più complesso da gestire.
Architettura dell’API full-duplex GPT-Live in un minuto
GPT-Live non è semplicemente un endpoint speech-to-speech più veloce. OpenAI lo descrive come un sistema vocale full-duplex, capace di elaborare l’audio in ingresso mentre genera quello in uscita, prendere decisioni sull’interazione molte volte al secondo e delegare il lavoro più complesso a un modello frontier. Secondo l’analisi tecnica di OpenAI, il sistema è costruito attorno a inferenza in streaming, una conversazione stateful, trasporto WebRTC e attività asincrone eseguite al di fuori del percorso multimediale.
Il modello pratico è questo:
| Livello | Responsabilità | Conseguenza progettuale |
|---|---|---|
| Percorso multimediale | Trasferire i frame audio tra client e modello vocale | Mantenerlo breve, prevedibile e indipendente dalle API di business |
| Modello vocale full-duplex | Ascoltare, parlare, fare pause, gestire le interruzioni e i tempi della conversazione | Non usare il rilevamento dei turni basato sul silenzio come controllore principale |
| Livello di delega | Eseguire ricerca, ragionamento e strumenti in modo asincrono | Trattare il lavoro delegato come un job in background sensibile alla latenza |
| Livello applicativo | Convalidare strumenti, permessi, conferme e regole di business | Non consentire mai che una risposta fluida autorizzi un’azione rilevante |
| Registro di prodotto | Gestire trascrizioni, analisi e messaggi dell’interfaccia | Tenere separate le viste provvisorie da quelle definitive della conversazione |
Il cambiamento più importante riguarda la gestione del tempo. In un agente vocale tradizionale, l’applicazione aspetta il turno dell’utente, lo invia a un modello e riproduce la risposta. Nell’architettura GPT-Live, invece, la sessione vocale resta attiva mentre diversi tipi di attività vengono eseguiti contemporaneamente.
Il vecchio modello a turni va lasciato sullo sfondo
I sistemi vocali a cascata eseguono in sequenza speech-to-text, un language model e text-to-speech. I modelli speech-to-speech nativi eliminano alcuni passaggi intermedi, ma un voice-activity detector separato può comunque decidere che l’utente ha finito prima di avviare l’inferenza. Una breve pausa per pensare può sembrare la fine del turno; un rumore di fondo può essere interpretato come l’inizio di uno nuovo.
L’approccio full-duplex di GPT-Live sposta questo problema temporale all’interno del modello vocale. Il modello può continuare ad ascoltare mentre parla, rilevare un’interruzione, fermarsi, riprendere o produrre un breve cenno di conferma. I confini tra i turni non scompaiono del tutto: semplicemente, non possono più bloccare il ciclo audio in tempo reale.
Cosa cambia nel percorso live di GPT-Live
L’inferenza continua sostituisce il blocco basato sui turni
In una sessione full-duplex, input e output sono flussi continui, non blocchi audio alternati. Il modello può ricevere nuovo parlato mentre la risposta precedente viene ancora riprodotta e decidere se l’audio in ingresso è un’interruzione significativa, una breve conferma o semplice rumore di fondo.
Questo cambia anche la logica del client. Il client deve poter inviare, ricevere, annullare e sostituire eventi audio contemporaneamente. Una semplice astrazione del tipo await response() non è adatta: nasconde proprio gli eventi più importanti, come l’inizio del parlato, l’avvio dell’audio dell’assistente, il rilevamento di un’interruzione, la richiesta di uno strumento, l’annullamento della risposta e la chiusura della sessione.
I segnali dell’attività vocale restano utili per interfaccia, analisi e sicurezza. L’errore architetturale consiste nell’usare il VAD come unica autorità per decidere quando può iniziare l’inferenza del modello.
Audio veloce, lavoro fuori dal percorso principale
L’analisi tecnica di OpenAI separa il percorso audio dedicato dalla logica applicativa. L’audio viaggia direttamente tra client e modello vocale, mentre chiamate agli strumenti, controlli delle policy, persistenza e operazioni backend passano attraverso un confine asincrono.
Questo confine impone una regola precisa: una ricerca lenta nel CRM può ritardare la propria risposta, ma non deve impedire ai frame audio di arrivare puntuali. WebRTC fornisce il trasporto multimediale a bassa latenza; i servizi applicativi non dovrebbero interporsi in modo sincrono tra ogni frame del microfono e il modello.
Il livello vocale può pronunciare qualcosa di breve mentre un’attività delegata è in esecuzione, ma una frase riempitiva non sostituisce un job con limiti chiari. Ogni strumento deve avere una scadenza, regole di annullamento e uno stato sicuro in caso di risultato non disponibile.
La delega separa reattività e intelligenza
GPT-Live può delegare ricerca, ragionamento approfondito o attività complesse a un modello frontier. Nei post di lancio e nelle analisi tecniche, OpenAI identifica GPT-5.5 come modello delegato al lancio. Il modello vocale resta responsabile dell’interazione immediata; il modello frontier gestisce le attività che non si adattano bene a un ciclo vocale a bassa latenza.
In produzione, la delega dovrebbe essere trattata come una pipeline autonoma:
- Rilevare che la richiesta richiede ricerca, ragionamento o uno strumento.
- Fornire un breve riscontro o mettere in pausa senza bloccare il percorso multimediale.
- Avviare il job in background con il contesto pertinente della conversazione.
- Annullarlo se l’utente cambia direzione o termina la sessione.
- Convalidare il risultato nell’applicazione.
- Reinserire un risultato sintetico nella sessione live.
Pre-inizializzare la sessione di inferenza delegata, mantenere l’affinità della sessione e memorizzare nella cache il contesto ripetuto può ridurre il tempo necessario per ottenere un output utile. Il budget end-to-end comprende routing, elaborazione del prompt, inferenza del modello, chiamate agli strumenti e ogni passaggio tra modello e strumento, non soltanto la latenza dei token del modello.
Le sessioni stateful richiedono una seconda architettura
Una lunga conversazione vocale non è una sequenza di richieste usa e getta. Il contesto cresce, i worker del modello possono cambiare e la sessione potrebbe richiedere una compattazione. OpenAI descrive il riscaldamento di una nuova istanza del modello, il suo pre-caricamento con il contesto corrente e il passaggio alla nuova istanza solo quando è pronta. In questo modo, il cambiamento infrastrutturale non diventa percepibile per chi sta chiamando.
La compattazione del contesto presenta un problema simile. Riassumere i turni precedenti modifica il contesto che alimenta la cache key-value del modello. Ricostruire quella cache in primo piano causerebbe una pausa. Un approccio più sicuro consiste nel compattare il contesto in parallelo, preparare una nuova istanza e mantenere operativa quella precedente fino a quando il passaggio non è pronto.
Per il backend di un agente vocale, lo stato della sessione deve quindi includere più di una semplice trascrizione:
- Stato corrente dell’audio e della risposta
- Chiamate agli strumenti attive e token di annullamento
- Affinità con l’istanza del modello o con il worker
- Messaggi provvisori e definitivi
- Stato della compattazione del contesto
- Stato di riconnessione e ripristino
- Stato di sicurezza e delle conferme
Il contratto API è un sistema di eventi, non una richiesta con risposta
Il full-duplex modifica il protocollo interno anche se l’API esterna finisce per offrire metodi SDK familiari. L’applicazione deve distinguere esplicitamente eventi che spesso vengono confusi:
| Evento | Significato | Risposta corretta |
|---|---|---|
| Annullamento | Interrompere un’operazione in sospeso | Annullare il job e liberare le risorse |
| Interruzione | L’utente parla mentre è in corso l’output | Fermare o rivedere l’audio dell’assistente senza chiudere la sessione |
| Chiusura della sessione | La chiamata o la conversazione è terminata | Chiudere stato multimediale, strumenti, persistenza e fatturazione |
| Errore dello strumento | Un’azione delegata non è stata completata | Spiegarlo in modo sicuro e proporre un’alternativa |
| Riconnessione | Il percorso multimediale è stato interrotto | Ripristinare lo stato senza duplicare le azioni |
GPT-Live può funzionare in modo continuo, ma il resto del prodotto ha comunque bisogno di messaggi per interfaccia, analisi e sistemi di sicurezza. OpenAI descrive il mantenimento di una vista speculativa, modificabile man mano che arrivano le trascrizioni, e di un registro autorevole finalizzato in un secondo momento. È un pattern utile: mostrare sottotitoli reattivi senza trattare ogni trascrizione parziale come un fatto immutabile.
Cosa devono riprogettare i team che sviluppano agenti vocali
Separare l’adapter multimediale dall’orchestrazione dell’agente
Il trasporto specifico del provider e la gestione degli eventi dovrebbero stare dietro un adapter. L’applicazione dovrebbe consumare eventi normalizzati come user_audio_started, assistant_interrupted, tool_requested, confirmation_required e response_completed.
Configurare separatamente model ID, voce, prompt, schemi degli strumenti e limiti di costo. Non è soltanto una protezione in vista della migrazione: permette al team di testare oggi un modello Realtime documentato, mantenendo al tempo stesso un obiettivo esplicito per le semantiche GPT-Live.
Per quanto riguarda gli strumenti, il modello propone e l’applicazione convalida. Pagamenti, modifiche agli account, cancellazioni, variazioni degli indirizzi, triage medico, operazioni finanziarie e procedure di identificazione richiedono regole di conferma esterne alla sicurezza con cui il modello parla.
Scegliere il trasporto in base a dove viene gestito l’audio
WebRTC è la scelta naturale per client browser e mobile che acquisiscono e riproducono direttamente l’audio. WebSocket può restare utile per pipeline multimediali controllate dal server, ma non bisogna presumere che ogni modello realtime accetti la stessa struttura di sessione su qualunque trasporto.
Un issue relativo a un’integrazione OpenClaw documenta un possibile problema pratico: trattare gpt-live-1 come una normale sessione Realtime GA via WebSocket ha prodotto una risposta invalid_model, mentre il flusso browser GPT-Live proposto utilizzava una struttura di sessione WebRTC distinta. L’issue è un resoconto d’implementazione, non un contratto dell’API OpenAI, ma rafforza una regola progettuale: identificare la famiglia del modello e negoziare esplicitamente il tipo di sessione supportato.
Misurare i frame consegnati in tempo, non solo la latenza dei token
Nel post tecnico di OpenAI si legge che, durante i test in produzione, un componente di supporto dello streaming ha raggiunto la saturazione prima della capacità delle GPU. L’unità di capacità utile era il numero di sessioni concorrenti sostenibili con consegna puntuale dei frame, non il numero di richieste per GPU.
Monitorare almeno:
- Ritardi e perdite dei frame audio
- Tempo necessario per ottenere il primo audio riproducibile
- Tempo tra l’interruzione e l’arresto dell’audio
- Sessioni concorrenti per regione
- Riconnessioni e chiamate duplicate agli strumenti
- Tempo di completamento della delega
- Frequenza di timeout e annullamenti degli strumenti
- Correzioni dal testo provvisorio a quello definitivo
- Sessioni abbandonate e spesa per sessione
Anche la naturalezza presenta un problema di controllo. Gli utenti possono apprezzare le interruzioni e i brevi cenni di conferma in un contesto, ma trovarli invadenti in un altro. Un primo resoconto di un utente ha riassunto il rischio senza mezzi termini: “It's literally cutting her off constantly lmao” (@AutismCapital). Va letto come un promemoria: la politica di barge-in deve essere calibrata su conversazioni reali, non su demo preparate.
GPT-Live o Realtime attuale: come decidere
Il catalogo ufficiale dei modelli OpenAI presenta oggi GPT-Live 1 come una soluzione per conversazioni vocali naturali ed espressive, sottolineando la gestione fluida delle interruzioni. Quel catalogo, però, non equivale a un contratto d’integrazione completo: la pagina separata dell’API GPT-Live analizzata qui resta un modulo di notifica privo di dettagli su endpoint, limiti di velocità o soglie operative. Prima di definire il piano di lancio, i team dovrebbero verificare la documentazione per sviluppatori aggiornata e l’abilitazione disponibile per il proprio account.
| Esigenza | Scelta pratica |
|---|---|
| Rilasciare subito un agente vocale documentato | Usare lo stack Realtime documentato dietro un adapter |
| Preservare la sovrapposizione naturale e la gestione dei turni affidata al modello come requisito fondamentale | Progettare per il modello di eventi full-duplex di GPT-Live e verificare prima l’accesso |
| Audio da browser o mobile | Preferire il percorso WebRTC supportato dal provider |
| Azioni aziendali complesse | Mantenere strumenti asincroni e conferme gestite dall’applicazione |
| Conversazioni lunghe | Realizzare prima del lancio gestione dei passaggi, compattazione, riconnessione e stato persistente |
Vale la pena adottare questa architettura anche prima che il modello sia disponibile per tutti gli account. Media continua, eventi normalizzati, strumenti asincroni e annullamento esplicito migliorano qualsiasi agente vocale costruito su un modello realtime tradizionale.
FAQ sull’API full-duplex GPT-Live
GPT-Live è la stessa cosa di GPT-Realtime?
No. OpenAI presenta GPT-Live come una famiglia distinta di modelli per le conversazioni vocali, mentre GPT-Realtime è la famiglia di API realtime documentata. Capacità audio simili non garantiscono semantiche di sessione, trasporti o model ID identici.
Full-duplex significa che il modello non aspetta mai?
No. Significa che il sistema può ascoltare e parlare contemporaneamente. Il modello può comunque fare una pausa, restare in silenzio, chiedere chiarimenti o rimandare un risultato delegato quando è più sicuro o utile farlo.
Gli sviluppatori hanno ancora bisogno del VAD?
Sì, per l’esperienza multimediale, le analisi, i sottotitoli e i segnali di sicurezza. Il VAD non dovrebbe essere l’unico gate a costringere il modello in una sequenza rigida di turno dell’utente e turno dell’assistente.
Quale trasporto dovrebbe usare un agente vocale?
Va usato il trasporto supportato dallo specifico client e dal modello scelto. WebRTC è in genere adatto all’audio diretto da browser o mobile; le pipeline multimediali backend possono usare WebSocket quando previsto dalla documentazione. Non bisogna dedurre il supporto al trasporto dal nome del modello.
Cosa conviene costruire prima di avere la conferma dell’accesso?
Adapter, schema degli eventi normalizzato, livello di convalida degli strumenti, modello di annullamento, telemetria dei costi, fallback e ripristino delle sessioni lunghe. Questi componenti resteranno utili anche se il contratto API finale di GPT-Live dovesse cambiare.
Scegliere l’architettura, non il nome del modello
La scelta destinata a durare è smettere di trattare la voce come un semplice involucro request-response attorno a un modello di testo. Il percorso audio deve restare sempre disponibile, il lavoro lento va spostato dietro confini asincroni, interruzioni e annullamenti devono diventare eventi di prima classe e la trascrizione deve poter essere corretta prima di diventare autorevole.
Il compromesso di GPT-Live è evidente: una sovrapposizione più naturale e la delega delle attività richiedono più stato, maggiore osservabilità e meno controllo basato su semplici confini tra i turni. I team disposti ad accettare questa complessità possono progettare fin da ora per il contratto full-duplex; chi ha bisogno di un endpoint di produzione documentato dovrebbe rilasciare su Realtime, mantenendo gli stessi punti di separazione guidati dagli eventi.