Ottimizzazione della latenza degli agenti vocali: guida passo passo

La reattività di un agente vocale dipende dal ritardo totale tra il momento in cui un utente finisce di parlare e quello in cui l'agente inizia a rispondere. Raramente questo ritardo è causato da un singolo componente lento. Si accumula lungo diverse fasi indipendenti, ciascuna delle quali contribuisce con alcune decine o centinaia di millisecondi; per ridurlo, devi sapere quanto tempo richiede ogni fase.

L'ottimizzazione della latenza degli agenti vocali consiste nell'individuare dove si nasconde questo tempo e recuperarlo fase dopo fase.

Questo articolo è complementare alla panoramica concettuale sulla latenza. Mentre quella pagina spiega cos'è la latenza, questa tratta architettura e misurazione, così avrai un budget di latenza rispetto al quale effettuare misurazioni e una serie di azioni concrete da intraprendere.

Riepilogo

• Il tempo al primo audio rappresenta l'intera pipeline, non il tempo di inferenza di un singolo modello.
• Il tempo al primo token dell'LLM e l'endpointing sono le due voci più rilevanti.
• Sovrapporre le fasi, anziché eseguirle in serie, recupera gran parte del budget.
• Streaming, scelta del codec e regolazione del buffer del player riducono ciascuno millisecondi misurabili.
• Dovresti misurare per regione sulla base del tuo deployment e riportare P50 e P95.

Definire il budget di latenza dell'agente vocale

Un budget di latenza è un obiettivo totale di tempo al primo audio, definito per le fasi della pipeline, in cui a ogni fase viene assegnato un margine che deve mantenere il totale entro il tuo obiettivo. Definirlo è il primo passo ed è anche il punto in cui più spesso si commettono errori nel lavoro sulla latenza, perché gli sviluppatori possono confondere due valori simili ma con significati diversi.

Il primo è la latenza di inferenza del modello: il tempo che un modello impiega per generare l'output. Per i nostri modelli Flash è di circa 75 ms per input brevi tipici, escludendo l'overhead della rete e dell'applicazione. È un valore interno, utile per confrontare un modello con un altro. Non è il valore percepito dall'utente.

Dal punto di vista dell'utente, devi concentrarti sul tempo al primo audio (TTFA): il tempo trascorso da quando l'utente smette di parlare a quando sente il primo campione della risposta dell'agente. Il TTFA è sempre maggiore della latenza di inferenza di qualsiasi singolo modello, perché somma l'intera pipeline.

Un agente vocale a cascata è una catena di cinque fasi:

• acquisizione (microfono) -> STT -> LLM -> TTS -> riproduzione

L'audio viene acquisito dal microfono, trascritto in testo, inviato a un modello linguistico, il testo del modello viene sintetizzato di nuovo in parlato e questo viene bufferizzato e riprodotto. Ogni fase aggiunge latenza e, in diverse fasi, il costo maggiore non è quello che ti aspetteresti.

Ecco un esempio per un agente in lingua inglese con server ragionevolmente vicini all'utente. I numeri sono intervalli indicativi, non garanzie.

In genere, le due voci di latenza più rilevanti sono il tempo al primo token dell'LLM e il ritardo di endpointing all'inizio della catena. 

La tabella è utile per visualizzare la pipeline, ma implica che le fasi vengano eseguite rigorosamente in serie, cosa che non avviene. Diverse delle ottimizzazioni più importanti della latenza degli agenti vocali derivano dalla loro sovrapposizione, ed è lì che viene recuperata gran parte del budget riportato di seguito.

Speech to Text: ottimizzazione della latenza di trascrizione ed endpointing

La trascrizione è la seconda fase della pipeline e il suo costo reale non è la trascrizione stessa, ma decidere quando l'utente ha smesso di parlare. Questa sezione tratta entrambi gli aspetti per aiutarti a ottimizzare la latenza dell'agente vocale.

La trascrizione avviene prima che il contenuto raggiunga l'LLM. Scribe v2 Realtime (scribe_v2_realtime) restituisce trascrizioni parziali in circa 150 ms e riceve l'audio in streaming a blocchi, quindi la trascrizione viene elaborata mentre l'utente sta ancora parlando. Supporta PCM da 8 kHz a 48 kHz e la codifica mu-law, aspetto rilevante per la sezione sui codec riportata sotto. Le trascrizioni parziali da 150 ms sono poco onerose.

Il costo di latenza maggiore è l'endpointing: il momento in cui il sistema decide che l'utente ha effettivamente concluso il proprio turno.

Il rilevamento dell'attività vocale (VAD) segmenta il parlato in base al silenzio, ed è qui che il tempo si accumula. Se aspetti, ad esempio, 700 ms di silenzio prima di dichiarare concluso il turno, aggiungi 700 ms a ogni turno, oltre al tempo della trascrizione stessa. Questo ritardo è invisibile in un benchmark di accuratezza della trascrizione, ma molto presente in una conversazione reale. Spesso è la latenza controllabile più elevata dell'intera pipeline e, proprio perché è controllabile, è un buon punto di partenza.

L'endpointing è un compromesso tra reattività e interruzioni. Una soglia di silenzio breve fa rispondere rapidamente l'agente, ma rischia di interrompere l'utente a metà frase durante una pausa naturale. Una soglia lunga è sicura, ma rallenta la risposta. In pratica, le tre modifiche che ottimizzano la latenza in Speech to Text sono:

1. Regola con precisione la soglia di silenzio: Riduci la soglia di silenzio al valore più basso che non tronchi le pause naturali degli utenti, quindi misura il tasso di interruzione in produzione anziché fare supposizioni.
2. Integra un evento di controllo fisico: Usa il controllo di commit manuale quando l'applicazione sa da un altro segnale che il turno è terminato, ad esempio il rilascio del push-to-talk o un evento dell'interfaccia utente, invece di aspettare il timer VAD.
3. Sovrapponi con i processi LLM: Invia tempestivamente a valle le trascrizioni parziali. Fornisci all'LLM quelle stabili e correggi se la trascrizione finale differisce: una forma di esecuzione speculativa che nasconde il ritardo di endpointing dietro l'elaborazione del prompt dell'LLM.

Per maggiori informazioni, Scribe v2 Realtime è descritto più nel dettaglio nella pagina sulle funzionalità di Speech to Text e nella pagina del prodotto Trascrizione vocale in tempo reale.

Il contributo dell'LLM alla latenza

Il modello linguistico è di solito il principale singolo fattore che contribuisce al TTFA, quindi è anche il punto in cui la sovrapposizione offre i maggiori vantaggi nell'ottimizzazione della latenza degli agenti vocali. L'idea chiave è che l'agente non ha bisogno dell'intera risposta prima di iniziare a parlare.

Il modello che recupera la maggior parte del budget di latenza consiste nello streaming dei token dall'LLM e nel loro invio al TTS man mano che arrivano, suddivisi ai confini di frasi o proposizioni. La logica è bufferizzare i token fino al confine di una frase, quindi sintetizzare quella frase mentre la successiva è ancora in generazione:

const SENTENCE_END = /(?<=[.!?])\s+/;

async function* speakLlmStream(tokens: AsyncIterable<string>) {
  let buffer = "";
  for await (const token of tokens) {
    buffer += token;
    const parts = buffer.split(SENTENCE_END);
    buffer = parts.pop() ?? ""; // keep the incomplete fragment
    for (const sentence of parts) {
      if (sentence.trim()) yield* synthesize(sentence.trim());
    }
  }
  if (buffer.trim()) yield* synthesize(buffer.trim());
}

async function* synthesize(text: string) {
  const stream = await elevenlabs.textToSpeech.stream("JBFqnCBsd6RMkjVDRZzb", {
    text,
    modelId: "eleven_flash_v2_5",
    outputFormat: "mp3_44100_128",
  });
  yield* stream;
}

Per le conversazioni di lunga durata, preferisci il WebSocket TTS affinché una connessione aperta possa ricevere testo in modo incrementale senza dover sostenere di nuovo la configurazione della connessione per ogni frase. Solo il tempo in cui il modello genera attivamente audio conta ai fini del limite di concorrenza, quindi un WebSocket aperto ma inattivo è quasi gratuito.

Text to Speech: streaming e scelta della voce

Text to Speech è la fase in cui puoi determinare la latenza con maggiore precisione. Hai due leve principali: come trasmetti l'audio in streaming e quale voce scegli.

Flash v2.5 (eleven_flash_v2_5) è il modello da usare in un agente. Offre circa 75 ms di inferenza del modello per input brevi, supporta 32 lingue e accetta fino a 40.000 caratteri per richiesta.

Il valore di 75 ms si riferisce esclusivamente all'inferenza. La voce TTFA del TTS nel budget sopra è maggiore perché, oltre all'inferenza, include il round trip di rete e lo scheduling del server.

La leva più importante qui è lo streaming. Se richiedi l'audio completo e lo aspetti, l'utente deve attendere che l'intera clip venga sintetizzata prima di sentire qualcosa. Se usi lo streaming, l'utente sente il primo chunk non appena viene generato e il resto arriva mentre sta già ascoltando. Lo streaming non rende il modello più veloce: inizia semplicemente a inviare l'output all'utente mentre la generazione è ancora in corso.

La guida pratica sullo streaming tratta lo streaming HTTP, mentre la guida al WebSocket in tempo reale descrive il percorso WebSocket che ti servirà quando invii token da un LLM.

Inizializza il client una volta e riutilizzalo per ogni chiamata seguente:

import { ElevenLabsClient } from "@elevenlabs/elevenlabs-js";

const elevenlabs = new ElevenLabsClient({ apiKey: process.env.ELEVENLABS_API_KEY });

Quindi configura uno stream e inoltralo man mano che arriva:

const stream = await elevenlabs.textToSpeech.stream("JBFqnCBsd6RMkjVDRZzb", {
  text: "Your call is connected. How can I help today?",
  modelId: "eleven_flash_v2_5",
  outputFormat: "mp3_44100_128",
});

for await (const chunk of stream) {
  // forward each chunk to your audio sink as it arrives
}

L'altra leva è la scelta della voce, che ha anch'essa un costo di latenza. Le voci predefinite, le voci sintetiche e le Instant Voice Clone (IVC) sintetizzano più rapidamente delle Professional Voice Clone (PVC), perché le PVC comportano una complessità aggiuntiva del modello che aumenta l'overhead per ogni generazione. Per un agente con requisiti di latenza rigorosi, la combinazione di Flash e una IVC o una voce predefinita è l'opzione a minore latenza.

Scelta della dimensione dei chunk in streaming

Con i token che fluiscono nel TTS e l'audio che ritorna, la decisione successiva riguarda la dimensione dei segmenti e quanto il player debba bufferizzare prima di iniziare.

I chunk più piccoli raggiungono prima il player, riducendo la latenza al primo byte, a fronte di più messaggi e di un overhead per chunk leggermente maggiore. I chunk più grandi sono più efficienti da trasportare, ma fanno attendere più a lungo l'utente per il primo. Per gli agenti interattivi, privilegia chunk più piccoli all'inizio dell'enunciato, perché il primo chunk è quello che l'utente sta aspettando; quelli successivi arrivano mentre l'audio è già in riproduzione e la loro dimensione conta meno.

Il player rappresenta una parte significativa della latenza residua. La maggior parte dei player audio non avvia la riproduzione al primo byte. Bufferizzano una piccola quantità di dati per evitare interruzioni se lo stream rallenta brevemente. Un buffer predefinito di 500 ms è comune e si aggiunge direttamente alla latenza percepita. Ridurlo comporta un lieve aumento del rischio di interruzioni in cambio di un TTFA inferiore; il valore giusto dipende dal jitter di rete tra il server e il client:

• Su una connessione stabile, come la riproduzione lato server o un client co-localizzato, un buffer da 50 a 150 ms è generalmente sicuro e riduce sensibilmente il TTFA.
• Su una connessione mobile instabile o tra regioni diverse, un buffer più grande evita interruzioni udibili, peggiori della latenza che comportano.

La configurazione esatta che scegli dipende dal caso d'uso attivo e dalle tue priorità.

Scelta dei codec

La destinazione dell'audio dovrebbe determinare il codec da richiedere. Restituiamo formati come mp3_44100_128, mp3_22050_32, pcm_16000, pcm_24000 e ulaw_8000. Abbinare il formato nativo del trasporto elimina una fase di transcodifica, contribuendo all'ottimizzazione della latenza degli agenti vocali.

Per la telefonia, come Twilio e provider simili, usa ulaw_8000. La rete telefonica utilizza mu-law a 8 kHz end-to-end, quindi richiederlo direttamente evita una fase di transcodifica nella pipeline e corrisponde a ciò che il gestore si aspetta. Non c'è alcun vantaggio nel sintetizzare audio a maggiore fedeltà che la rete telefonica ricampionerà immediatamente verso il basso: aggiungeresti soltanto latenza senza alcuna perdita udibile.

Per WebRTC e la riproduzione nel browser, usa PCM (pcm_24000 o pcm_16000) oppure un formato MP3. Il PCM non è compresso, quindi non richiede una fase di decodifica sul client: questo elimina una piccola quantità di latenza per chunk ed è pratico quando alimenti direttamente una pipeline Web Audio. L'MP3 è più compatto nella trasmissione, il che aiuta sulle connessioni limitate, a fronte di una leggera decodifica lato client.

Geografia e distanze di rete

Ogni ottimizzazione precedente presuppone che i byte debbano percorrere una breve distanza. La geografia stabilisce il limite minimo del budget di latenza, quindi vale la pena esaminarla prima di ottimizzare qualsiasi altra cosa.

Forniamo le richieste da cluster in Nord America, Europa e Sud-est asiatico e instradiamo automaticamente ogni richiesta al cluster più vicino. Il round trip di rete su Internet pubblico è in genere compreso tra 20 e 200 ms, a seconda della vicinanza geografica, e non può essere ridotto senza cambiare dove viene eseguita la tua infrastruttura.

Un agente che sembra istantaneo a San Francisco, a poca distanza da un cluster nordamericano, può apparire lento a un utente nell'Asia meridionale, il cui traffico attraversa un oceano due volte per turno.

La soluzione è co-localizzare i server dell'applicazione con gli utenti, non soltanto con noi. Se i tuoi utenti sono in Europa, esegui il backend dell'agente in Europa affinché il tratto tra utente e server sia breve; il nostro routing gestirà poi il tratto tra il tuo server e il modello da un cluster vicino.

Misurare autonomamente la latenza degli agenti vocali

I numeri nella tabella del budget di latenza sopra sono intervalli indicativi su cui pianificare. I numeri su cui basare il deployment dovrebbero provenire da uno script come questo, eseguito sul tuo deployment.

La strumentazione seguente misura il TTFA della fase TTS in isolamento, ovvero il tempo dalla richiesta al primo chunk audio, su molte prove e riporta i percentili. Eseguila dalla stessa regione in cui sono eseguiti i server, non dal computer di sviluppo. Presuppone il client ElevenLabs mostrato in precedenza:

const VOICE_ID = "JBFqnCBsd6RMkjVDRZzb";
const TEXT = "Thanks for waiting. I have pulled up your account and I can help with that now.";
const TRIALS = 50;

async function measureTtfa(): Promise<number | null> {
  const start = performance.now();
  const stream = await elevenlabs.textToSpeech.stream(VOICE_ID, {
    text: TEXT,
    modelId: "eleven_flash_v2_5",
    outputFormat: "mp3_44100_128",
  });
  for await (const _chunk of stream) {
    return performance.now() - start; // first chunk -> stop the clock
  }
  return null;
}

function percentile(values: number[], p: number): number {
  const v = [...values].sort((a, b) => a - b);
  const k = (v.length - 1) * (p / 100);
  const lo = Math.floor(k);
  const hi = Math.min(lo + 1, v.length - 1);
  return v[lo] + (v[hi] - v[lo]) * (k - lo);
}

const samples: number[] = [];
for (let i = 0; i < TRIALS; i++) {
  const ttfa = await measureTtfa();
  if (ttfa !== null) samples.push(ttfa);
  await new Promise((r) => setTimeout(r, 300)); // space requests, don't measure your own queueing
}

console.log(`trials: ${samples.length}`);
console.log(`P50:    ${percentile(samples, 50).toFixed(0)} ms`);
console.log(`P95:    ${percentile(samples, 95).toFixed(0)} ms`);

Alcuni aspetti da ricordare:

• Riporta P50 e P95: Concentrati su questi, anziché sulla media. La media nasconde la coda, ed è la coda a far sembrare un agente inaffidabile. P95 rappresenta l'esperienza di un turno su venti. 
• Test basati sulla posizione: Esegui lo stesso script da ogni regione che servi e tieni separati i risultati.
• Scagliona le richieste per una maggiore precisione: Distanza le richieste (con il setTimeout sopra). Se le invii tutte insieme, misuri l'accodamento interno anziché il servizio. Quando il limite di concorrenza viene superato, le richieste vengono accodate per priorità, aggiungendo in genere circa 50 ms; oltre la capacità, ricevi HTTP 429.
• Misura l'intera catena di latenza: Estendi lo stesso schema di timing alle altre fasi. Inserisci la finalizzazione STT, il primo token dell'LLM e l'avvio del player tra le stesse chiamate performance.now(); potrai così compilare la tabella del budget completa con i tuoi numeri e capire quale fase affrontare per prima.

Seguendo questi suggerimenti, potrai misurare autonomamente la latenza degli agenti vocali. Da lì, avrai un percorso chiaro delle priorità da affrontare per prime.

Cosa riduce maggiormente la latenza degli agenti vocali?

Se cerchi alcune azioni rapide su cui concentrarti, queste sono le modifiche con il maggiore impatto.

Indicativamente in ordine di impatto, puoi usare i seguenti metodi per ridurre la latenza dell'agente:

• Avvia il lavoro dell'LLM sulle trascrizioni parziali STT stabili per nascondere il ritardo di endpointing.
• Trasmetti in streaming i token dell'LLM al TTS ai confini delle frasi, in modo che la sintesi della prima frase si sovrapponga alla generazione della seconda.
• Trasmetti in streaming l'audio TTS al player e riduci il buffer del player al valore minimo tollerato dal jitter di rete.
• Usa Flash con una voce predefinita o una IVC per il TTS a minore latenza e abbina il codec al trasporto (ulaw_8000 per la telefonia, PCM o MP3 per browser/WebRTC).
• Co-localizza i server con gli utenti e misura per regione, perché i tratti di rete sono reali e non equivalenti.

Per tecniche specifiche più approfondite, consulta la guida pratica per sviluppatori sull'ottimizzazione della latenza. Per un punto di partenza completo ed eseguibile, il quickstart API e la guida pratica sullo streaming includono esempi completi. 

Vuoi accedere più rapidamente a cascate di agenti ottimizzate? ElevenAgents implementa questa pipeline con ottimizzazioni di sovrapposizione già integrate.

Crea agenti vocali a bassa latenza con ElevenAgents

L'ottimizzazione della latenza degli agenti vocali richiede di misurare ogni fase e poi sovrapporre le fasi, affinché quelle più lente vengano eseguite mentre è già in corso altro lavoro. Puoi creare e ottimizzare manualmente questa cascata attraverso diverse iterazioni, usando gli schemi riportati sopra, oppure iniziare da una pipeline che dispone già di ottimizzazioni della latenza.

ElevenAgents implementa questa cascata completa, dallo STT in streaming al passaggio token per token all'LLM fino al TTS Flash, con tecniche di sovrapposizione già integrate. Invece di partire da zero, regolerai le soglie in base alle prestazioni che per te contano di più.

Inizia usando ElevenAgents per creare un agente oggi oppure contattare il team commerciale per maggiori informazioni.

Domande frequenti sull'ottimizzazione della latenza degli agenti vocali