Show HN: Bot de voz con tiempo de respuesta de 500 ms
(fastvoiceagent.cerebrium.ai)- La IA de voz debe responder de inmediato, como en una conversación normal, para sentirse natural; por eso esta demo apunta a una respuesta de voz a voz de 500 ms
- El desafío central es reducir la latencia percibida por el usuario, influida tanto por la red como por el tiempo de procesamiento del modelo
- La demo muestra hasta dónde puede llegar la interacción de baja latencia con LLM mediante optimización y despliegue
- La implementación usa Pipecat, un framework open source para IA conversacional de voz y multimodal
- Para crear un bot de voz conversacional de nivel producto, no solo importa el rendimiento del modelo, sino también gestionar la latencia de toda la ruta de llamada
Demo orientada a respuestas de voz en 500 ms
- The World's Fastest Voice Bot Demo es una demo que muestra qué tan rápido puede responder un chatbot de IA basado en voz
- El objetivo es lograr un tiempo de respuesta voice-to-voice de 500 ms
- Como las personas esperan respuestas rápidas en una conversación normal, la velocidad se vuelve un factor clave de calidad en las interfaces de IA de voz
Enfoque de implementación para reducir la latencia
- La demo está construida en torno a la interacción de baja latencia con LLM
- Muestra el potencial de un chatbot de IA de voz optimizado y desplegado para minimizar la latencia de red y la latencia del modelo
- El bot fue creado con Pipecat
- Pipecat es un framework open source para IA conversacional de voz y multimodal
1 comentarios
Opiniones en Hacker News
Realmente rápido. Excelente y limpio. Da la sensación de que la velocidad le gana a todo lo demás. Recién después de leer los comentarios me di cuenta de la voz robótica.
Una vez creé una IA para atención al cliente, y el tiempo promedio de respuesta bajó de 24–48 horas a unos segundos.
A un cliente le llegó un mensaje como “Hello Bitch, your package will be picked up by USPS today...”, y el cliente respondió “thank you so much” y le dio la máxima puntuación de CSAT. Incluso con un error tan grave, la velocidad le gana a todo.
Pero el ingeniero de ventas más activo ya no pudo hacer demos para clientes potenciales. Había muchas llamadas incómodas en las que la IA simplemente no respondía, y su apellido era Dick.
Realmente, realmente bueno. Si entendí bien, parece una app teaser para mostrar Cerebrium, pero tiene mucho potencial de killer app. Cuando la probé en un iPad, la latencia reportada iba de 1400 ms a 400 ms, y en el extremo bajo se sentía muy fluida.
Con este nivel de velocidad, en algunos flujos de chat parece que un enfoque de varias etapas será necesario o posible. Primero se responde rápido mientras se ejecuta por separado una consulta más larga de datos/información/RAG, y luego toma el control una respuesta con la información.
Los humanos también funcionamos así. Empezamos a responder y usamos varias muletillas mientras ordenamos las ideas.
Hoy la mayoría lanza un prompt de una sola vez, o parsea → consulta → genera en segundo plano, pero si son posibles respuestas de baja latencia, creo que un mejor flujo sería algo como “[Llama 8B durante 3 segundos al oído] → consulta → [55 segundos de Llama 70B/GPT-4, etc., incorporando los resultados de la consulta]”.
Esta aplicación es fácil de ampliar o implementar, así que se puede modificar como quieras. Puedes cambiarla por otros LLM, modelos de reconocimiento de voz o síntesis de voz, cambiar el prompt e implementar cosas como RAG.
Junto con Daily, nos enfocamos en los ingenieros. Queríamos que la aplicación pudiera adaptarse con mucha flexibilidad a los casos de uso y preferencias, quitando de encima la configuración aburrida de infraestructura.
Puedes ver más sobre cómo ampliarla aquí: https://docs.cerebrium.ai/v4/examples/realtime-voice-agents
Si la complejidad se pudiera puntuar como un valor continuo, podríamos saber si conviene responder primero algo como “sí, un momento, voy a buscarlo”, en vez de esperar un ida y vuelta largo.
Como módulo de detección de actividad de voz para navegadores multiplataforma existe https://github.com/ricky0123/vad. Es un port a ONNX de la red VAD de Silero. Con multiplataforma quiero decir que también funciona en Firefox. Es más simple porque solo necesita acceso al micrófono, sin una sesión WebRTC. También me da curiosidad que el navegador ofrezca esta función como opción nativa.
También existen motores de texto a voz basados en el navegador, y cada vez son más rápidos y de mejor calidad. Sería bueno que los navegadores trajeran un gran TTS integrado por defecto.
GPT-4o puso el reconocimiento automático de voz, la comprensión y la generación de respuesta de voz en un solo modelo para lograr baja latencia, y parece una idea bastante buena. Si todavía no lo lanzaron, parece que hay problemas de escalabilidad o de calidad de algún tipo.
De forma similar, seguramente también haya gente creando modelos grandes de lenguaje multimodales integrados y abiertos, con entrada/salida de audio e incluso entrada visual.
Me pregunto hasta qué punto un modelo único acoplado es necesario y óptimo para optimizar latencia y costos.
El desglose provisto es interesante. Si es posible, parece mejor ejecutar más modelos en el dispositivo, como la generación de voz y quizá incluso la transcripción o comprensión de voz al inicio. ¿Quién quiere esperar a STUN?
Las apps básicamente lo ignorarían si no están escuchando, pero el transcriptor sería intercambiable y podría usarse en todas las apps.
Lógicamente, habría que pensar a nivel de fonemas. La salida del LLM tendría que alcanzar lo bastante rápido el último fonema para poder responder “de inmediato” en cuanto se detecte el punto final, y para eso toda la cadena debería tener una latencia de extremo a extremo de alrededor de 200 ms.
Para acercarse a eso, creo que haría falta otra arquitectura. Algo parecido al procesamiento de voz humano: adelantarse al stream de audio con fonemas predichos antes de que lleguen, y usar el audio recibido real solo como una señal ligera de verificación para decidir si vaciar el búfer de salida actual o reprocesar.
Con speculative decoding se puede avanzar en cierta medida, pero con una tubería mezclada de audio/texto parece difícil. En primer lugar, es mucho mejor no convertir el audio a texto y luego volver a convertirlo en audio.
https://github.com/charlesyu108/voiceai-js-starter
Lo probé directamente y fue divertido. A principios de esta semana probé june-va, pero sus tiempos de respuesta largos le restaban bastante utilidad. Las respuestas rápidas son una función excelente, y esto se siente mucho más como una conversación
Lo gracioso es que le pedí que me contara una historia y solo respondía una oración a la vez, así que para escuchar la siguiente línea tenía que decir “yes”, “aha”, “please continue”
Luego tuvimos esta conversación: “Ah, creo que descubrí tu secreto” “Por favor, dígalo” “Logras tiempos de respuesta cortos manteniendo un contexto breve” “Exactamente”
Muy impresionante. Es rapidísimo, quizá demasiado, pero parece que ese es el punto. Lo más impresionante es cómo están coordinados el VAD y el manejo de interrupciones. De lejos, es la conversación con un agente que más natural me ha sonado hasta ahora. Cuando se publique, definitivamente quiero probarlo
En marketing dice 500, pero el cálculo da 759
A mí también me entusiasma la inferencia por voz. Antes del lanzamiento de GPT-4o de OpenAI, hice mi propia implementación de Faster Whisper basada en WebSocket. Mis implementaciones del concepto de coach para entrevistas https://intervu.trueforma.ai y del coach de pitch de ventas https://sales.trueforma.ai quedaron opacadas por ellos
No pude hacer que el VAD funcionara de forma estable, así que dejé push-to-talk como opción predeterminada. Todo corre en una LattePanda. Quería conectarle el Whisper hospedado de Groq
Estoy harto de las conversaciones corporativas aburridas, así que me gusta la idea de usar como LLM el Llama3 sin censura de Groq. Quiero reducir la latencia y aprender de los ejemplos. También quiero probar la demo, pero parece demasiado saturada y no puedo entrar a hablar con el bot
Si apenas 3 personas intentaran hacer inferencia al mismo tiempo, creo que mi LattePanda se derretiría
Personalmente uso https://github.com/foges/whisper-dictation junto con llama-70b de Groq
Para cuando empiezo a hablar, voy al sitio web, termina de cargar y elijo llama-70b, ya terminé de hablar, así que la latencia adicional es 0. Como leer es mucho más rápido que escuchar, para mí encaja perfecto
Todavía uso Firefox
Necesitaba una forma de medir la latencia de voz a voz desde la perspectiva del usuario final, y me pareció que la detección de actividad de voz de Silero (https://github.com/snakers4/silero-vad) era la opción más confiable para detectar cuándo el usuario dejaba de hablar, iniciar un temporizador y detenerlo cuando llegara audio del bot
Silero se ejecuta con onnx-runtime y wasm. En Firefox funciona hasta cierto punto, pero el VAD falla con más frecuencia de lo esperado, así que las cifras de latencia salen bastante raras. Aun así, de verdad quiero hacerlo funcionar y sigo intentándolo
El código del VAD de la UI está aquí: https://github.com/pipecat-ai/web-client-ui/tree/main/src/va...
Realmente impresionante
Siri de Apple todavía solo permite conversaciones en las que se pisan las voces, se detiene, falla y al final te deja esperando obtener apenas una respuesta mínima