Herramientas · Voz · 09

Encuentra dónde se consume la latencia antes de que el agente empiece a hablar.

Descompón el intervalo desde el final acústico del turno del usuario hasta el primer audio que vuelve al oyente. Cambia la arquitectura, mide cada tramo y comprueba si el objetivo es viable antes de culpar al modelo. El barge-in se calcula por separado porque detener audio ya en reproducción es otro camino crítico.

Respuestafin del habla → primer audio del agente
Interrupcióninicio de habla → audio del agente detenido
Comparacióncascada, half-cascade y speech-to-speech

Arquitectura y objetivo

Los presets son escenarios didácticos editables, no mediciones de proveedores.

Camino hasta primer audio

Último audio del usuario hasta tu punto de procesamiento.
Espera residual tras recibir el final acústico.
Usa 0 si la arquitectura no tiene STT externo en este camino.
TTFB/primer chunk audible, no duración total de síntesis.

Barge-in

Primer audio
Presupuesto restante para el modelo
Barge-in hasta detener audio

. Cada cifra representa contribución residual al camino crítico después del final acústico del turno; si dos etapas se solapan en tu sistema, no sumes dos veces el mismo tiempo de pared.

Entrada de audio
Fin de turno
STT residual
Primera salida del modelo
Primer audio TTS
Salida de audio
Buffer de reproducción
Mayor contribución
Camino de interrupción

Método

Mide un borde claro y suma solo el camino crítico.

Frontera de medida. Esta herramienta define la latencia de respuesta como el tiempo desde el final acústico del turno en el borde de captura hasta el primer audio del agente en el borde de escucha. Si tu telemetría usa otra frontera, cambia los componentes para que todos compartan la misma referencia.

first_audio = ingress + turn_detection + residual_STT + model_first_output + TTS_first_audio + egress + playback_buffer

Arquitectura. En una cascada completa aparece STT y TTS externos. En el preset half-cascade, la comprensión de audio está dentro del modelo y se mantiene TTS externo. En speech-to-speech, STT y TTS externos quedan a cero. Son presets didácticos: no implican que una arquitectura sea siempre más rápida.

Fin de turno. Deepgram documenta endpointing por VAD con un tiempo de silencio configurable. OpenAI Realtime distingue server_vad y semantic_vad; la detección semántica puede esperar más cuando estima que el usuario no ha terminado. Reducir este tramo sin medir falsos cortes puede empeorar la conversación.

TTS. ElevenLabs separa el tiempo de inferencia del tiempo extremo a extremo y recomienda streaming/WebSocket para reducir tiempo hasta primer byte/audio. El buffering de texto puede añadir espera antes de iniciar síntesis. Por eso aquí se usa “primer audio TTS”, no duración total de generación.

Barge-in. El camino de interrupción no es la latencia de respuesta al revés. Incluye recibir nueva voz, detectarla, cancelar la generación/reproducción y vaciar audio ya en cola. En Media Streams bidireccional, Twilio documenta clear para vaciar el buffer y mark para seguir qué audio terminó o fue limpiado.

barge_in_stop = ingress + speech_start_detection + cancel/control + output_buffer_clear

No son benchmarks. Los números iniciales son deliberadamente redondos para que exista un escenario manipulable. Sustitúyelos por percentiles de tus trazas. Una media puede ocultar colas largas; para gates de producción conviene mirar al menos distribución por región, proveedor, idioma, tipo de turno y arquitectura.

La investigación sobre turn-taking humano muestra una tendencia transversal a minimizar silencios y solapamientos, pero no define un SLA universal para agentes de voz. El objetivo de 750/800/900 ms de los presets es una hipótesis editable, no una recomendación científica.

Fuentes: OpenAI Realtime API, Deepgram Endpointing, ElevenLabs Latency Optimization, Twilio Media Streams y Stivers et al. (PNAS, 2009).