La conversación tiene un presupuesto de tiempo
Cuando una persona habla por teléfono no evalúa cada componente del sistema. Evalúa una sola cosa: si la conversación se siente natural. Entre el final de una frase y el comienzo de la respuesta se acumulan tiempos distintos: transporte de audio, detección de fin de turno, reconocimiento, decisión, generación de texto, síntesis y reproducción. Ninguno vive aislado. La latencia percibida es el resultado de la cadena completa.
Por eso un agente de voz no se vuelve rápido cambiando un prompt. Tampoco alcanza con elegir un modelo de lenguaje con mejor benchmark. Si el audio recorre una arquitectura innecesariamente larga, si el corte de turnos espera demasiado o si la síntesis no comienza hasta recibir una respuesta completa, el usuario escucha la demora aunque el modelo central sea excelente.
Separar la cadena permite medirla
Una arquitectura de voz defendible debería poder observar al menos estos tramos: entrada telefónica, normalización del audio, reconocimiento, endpointing o detección de turno, lógica del trámite, llamada eventual al modelo, síntesis y entrega de audio. La pregunta correcta deja de ser cuánto tarda la IA y pasa a ser dónde se consume el tiempo entre la última sílaba del usuario y el primer audio útil de la respuesta.
Ese cambio de unidad de análisis es importante. Permite descubrir que un componente relativamente pequeño puede dominar la experiencia completa. También evita atribuirle al modelo una demora que en realidad pertenece al transporte, al buffering, a una cola, a una integración o al sintetizador.
La distancia de red es una variable arquitectónica
Cuando reconocimiento y síntesis dependen de infraestructura remota, el audio agrega recorridos de red que no aportan inteligencia al trámite. Llevar esas etapas cerca de donde ocurre la llamada elimina una parte de ese recorrido. No garantiza por sí mismo una conversación rápida, pero reduce una fuente de demora y devuelve control sobre un tramo que de otro modo pertenece a terceros.
OSSA SVE parte de esa idea: el audio se diseña para procesarse en infraestructura dedicada al cliente. La arquitectura no promete una cifra universal de latencia porque sería técnicamente irresponsable hacerlo antes de medir telefonía, hardware, modelos, concurrencia y configuración reales. Lo que sí puede afirmarse es que sacar viajes remotos innecesarios del audio cambia la frontera del problema.
Streaming antes que bloques completos
La conversación también mejora cuando los componentes trabajan en flujo. El reconocimiento puede producir parciales, el orquestador puede preparar el siguiente paso mientras entra contexto suficiente y la síntesis puede comenzar por frase sin esperar a que todo el texto haya terminado. El objetivo no es hacer que cada etapa sea instantánea. Es evitar que todas esperen secuencialmente a la anterior cuando no existe una razón técnica para hacerlo.
Ese diseño exige cuidado. Anticipar demasiado puede producir interrupciones incorrectas, respuestas sobre una frase aún incompleta o una voz que comienza a hablar antes de que la intención esté clara. La optimización de latencia tiene que convivir con precisión y capacidad de corregir el turno.
El corte de turnos es parte del producto
Una persona puede interrumpir, dudar, corregirse o dejar silencios breves. Un sistema telefónico que trata cada silencio como final de turno se vuelve agresivo. Uno que espera demasiado parece torpe. Por eso la detección de turnos y el manejo de interrupciones no son detalles de interfaz: son parte central de la ingeniería conversacional.
La única validación útil ocurre sobre llamadas telefónicas reales. Un micrófono conectado directamente a una computadora elimina precisamente varias de las condiciones que el sistema necesita sobrevivir: códecs, jitter, central, troncal, ruido, eco, silencios y comportamiento humano.
El modelo no debe decidir el trámite
Hay otra fuente de demora y riesgo: pedirle al modelo que recuerde en qué paso está, qué acción corresponde y qué está permitido. Un diseño más controlable conserva el trámite en una máquina de estados y usa el modelo para interpretar lenguaje y redactar dentro del estado actual. Esto reduce el espacio de decisión del modelo y permite usar componentes reemplazables sin entregarles la lógica completa de la operación.
En ese esquema, velocidad y gobernanza dejan de competir tanto entre sí. El sistema puede resolver partes previsibles sin convocar razonamiento abierto y reservar el modelo para donde realmente aporta comprensión lingüística.
La métrica útil es conversacional
Evaluar una arquitectura de voz exige medir llamadas completas. Entre las métricas relevantes están el tiempo desde fin de turno hasta primer audio, percentiles de latencia y no sólo promedios, interrupciones correctamente manejadas, repreguntas por reconocimiento defectuoso, transferencias a humano, tareas completadas y fallos por integración. Una cifra aislada de milisegundos no describe la experiencia si el sistema corta al usuario o ejecuta una acción incorrecta.
Argentina como frontera de diseño
Diseñar específicamente para una operación argentina permite tomar decisiones que una plataforma global no necesariamente prioriza: español rioplatense, telefonía local, vocabulario propio del cliente, infraestructura instalada en el país y reglas operativas particulares. Eso no elimina la necesidad de validación. La vuelve más concreta.
La tesis es simple: la latencia de voz es un problema de sistemas. Se mejora diseñando y midiendo la cadena completa, no maquillando la demora desde el prompt.