Interfaces de voz con LLMs: latencia, turnos y errores
Una interfaz de voz con LLM falla por el silencio, no por la respuesta. Principios para diseñar turnos, latencia percibida, interrupciones y errores.
¿Por qué la voz es distinta a una pantalla?
En una pantalla, un retraso de un segundo se tolera. En una conversación, el silencio tiene un significado: el usuario piensa que no lo escucharon, que se cortó la línea o que tiene que repetir. Picovoice describe la referencia humana: la pausa mediana entre hablantes ronda los 200 milisegundos en diez idiomas (Stivers et al., 2009), y contra ese ritmo se juzga a un agente.
Un agente de voz encadena varias etapas (de dónde sale el tiempo de un modelo se explica en latencia y tokens por segundo): captura del audio, detección de fin de turno, transcripción, razonamiento del modelo y síntesis de voz. Cada etapa consume tiempo, y el usuario solo percibe la suma. Por eso la latencia se presupuesta por etapa, no se resuelve con un único cambio.
¿Cómo se diseñan los turnos?
Los silencios fijos fallan en las dos direcciones: cortan al usuario que hizo una pausa para pensar, o añaden un silencio muerto cuando ya terminó. La alternativa que describe Picovoice combina tres señales: acústica (detección de actividad de voz), lingüística (si la transcripción parcial suena a frase completa) y de comportamiento (una política por niveles de confianza). Con confianza media el agente empieza a razonar de forma especulativa, pero no habla; con confianza alta, responde. Si el usuario retoma la palabra, el trabajo especulativo se descarta sin ruido.
Salesforce recomienda terminar cada turno del agente con la pregunta al final, sin añadir frases después, y ceder el turno de inmediato cuando alguien interrumpe, tratando lo que dice como el nuevo turno. Para la interrupción (barge-in), Picovoice pide dos capas: detener o silenciar el audio saliente y vaciar el búfer de reproducción, y cancelar todo lo que está en curso (generación pendiente y síntesis en cola), para que no aparezca una respuesta vieja después de que el usuario cambió de tema.
¿Cómo se maneja la latencia percibida?
Hay dos tipos de latencia: la medida (en milisegundos) y la percibida (lo que el usuario siente). Se pueden gestionar por separado:
- Solapar etapas: empezar a razonar con transcripciones parciales y sintetizar la voz desde los primeros tokens.
- Hablar pronto: un acuse breve y veraz, como “Lo reviso”, mientras llega el dato, hace que la espera parezca conversación.
- Nunca hablar encima del usuario: si el usuario empieza a hablar, el agente se calla y espera.
El acuse debe ser verdadero. Decir “Lo reviso” cuando el sistema no está buscando nada rompe la confianza en el siguiente turno.
¿Cómo se recuperan los errores?
Salesforce propone recuperar por grados, con la señal más débil que localice el problema. Primero, una señal general que pida repetir ("¿Perdón?"). Luego, una pregunta que nombre el punto de fallo (“No entendí la fecha”). Después, ofrecer una opción concreta para que la persona la confirme ("¿Te refieres al martes 14?"). No conviene repetir el mismo prompt sin cambios, ni culpar a la persona por el error. Para nombres y números largos, pasa a deletrear o a dictar dígito por dígito. Y si los fallos se acumulan a lo largo de la llamada, ofrece proactivamente una transferencia a una persona, con la transcripción para que no tenga que repetirse.
Esto conecta con el manejo de errores de IA y recuperación en cualquier interfaz: el sistema debe decir qué falló y qué puede hacer la persona. Ese orden importa porque el usuario tiene memoria de trabajo limitada en voz: no puede volver atrás ni ver una lista. Por eso conviene limitar las listas a unas tres opciones (Salesforce propone dar titulares primero y detalles si los piden) y reservar la confirmación explícita para acciones difíciles de revertir, como una reserva o un pago; para datos ordinarios basta repetir el dato dentro de la siguiente pregunta.
Para decidir cuánto debe confirmar el agente antes de actuar, revisa calibración de confianza y aprobación de acciones.
¿Qué ajustes ofrecen las APIs de voz en tiempo real?
Las plataformas de modelos ya exponen como parámetros las decisiones de turnos e interrupciones. Dos ejemplos de su documentación oficial, consultada en noviembre de 2026:
- OpenAI Realtime API. La detección de actividad de voz (VAD) viene activada por defecto y se configura con
turn_detection, por ejemplo consemantic_vad. Cuando el usuario habla, la API cancela la respuesta en curso y empieza una nueva. Con WebRTC o SIP el servidor recorta el audio que no llegó a reproducirse; con WebSocket, tu cliente debe detener la reproducción y enviarconversation.item.truncateindicando cuántos milisegundos escuchó la persona. Para push-to-talk se poneturn_detectionennully el turno se controla a mano. - Gemini Live API. La VAD automática se configura en
realtimeInputConfig.automaticActivityDetection, con sensibilidad de inicio y fin de habla ysilence_duration_ms; la guía recomienda 500 a 800 ms, porque valores menores parten las frases y mayores añaden latencia. También puede desactivarse para marcar los turnos conactivityStartyactivityEnd. Al detectar una interrupción, el servidor cancela la generación y envía un mensajeinterruptedpara que el cliente detenga y vacíe el audio.
La lección de diseño es que el recorte no es un detalle técnico: si el cliente sigue reproduciendo audio viejo, o el historial conserva frases que la persona nunca oyó, el agente “recuerda” cosas que el usuario no escuchó. Revisa también los nombres y parámetros en la documentación vigente, porque cambian entre versiones.
¿Cómo hacerla accesible?
Un tiempo de escucha corto perjudica a quien habla despacio, busca las palabras o tiene una discapacidad del habla. La pauta WCAG 2.2.1 (Timing Adjustable, nivel A) pide, para los límites de tiempo que fija el contenido, que la persona pueda desactivarlos, ajustarlos a al menos diez veces el valor por defecto, o extenderlos tras un aviso con al menos 20 segundos para hacerlo. WCAG no menciona las interfaces de voz y se aplica a contenido web, pero su idea sirve como criterio: deja que el usuario alargue el tiempo de espera, avisa antes de cortar la escucha y ofrece siempre una alternativa por texto.
Ejemplo
Ejemplo ilustrativo: un asistente de voz para reservar una mesa tarda casi dos segundos en consultar disponibilidad. Sin diseño, hay un silencio y el usuario vuelve a hablar, lo que cancela la consulta. Con diseño, el agente responde “Busco mesas para las ocho” en menos de 300 milisegundos, mantiene el turno mientras consulta, y si el usuario interrumpe para cambiar la hora, detiene la consulta anterior y responde a la nueva. Antes de confirmar la reserva, repite la fecha, la hora y el número de personas, porque es una acción de alto riesgo.
Este artículo cubre los principios de interacción; para el agente completo que ejecuta tareas por voz, consulta Agentes de voz.
Errores comunes
- Medir solo la latencia del modelo y olvidar la detección de fin de turno y la síntesis.
- Usar un silencio fijo de la misma duración para todas las frases.
- Hablar encima del usuario o ignorar las interrupciones.
- Leer listas largas de opciones en voz.
- Repetir el mismo mensaje de error sin cambiar la pregunta.
- Confirmar todo de forma explícita, lo que vuelve lenta la conversación.
- No dar salida a una persona cuando el agente falla varias veces.
Cuándo NO conviene
Cuando la información es larga, visual o de comparación compleja, como un contrato o una tabla de precios. También cuando hay datos sensibles que el entorno no permite decir en voz alta. En esos casos, combina la voz con una pantalla, un enlace de texto o entrada por teclado, como recomienda Salesforce para comparar tres o más opciones y para datos que exigen exactitud de caracteres. Pide el acuerdo de la persona antes de cambiar de canal y llega con los campos ya rellenados.