Open Source Voice AI: Cómo Construimos la Infraestructura del Modo de Voz de ChatGPT

La voz, de eso se trata esta charla. Durante 40 años, hemos hablado con computadoras usando teclados y ratones. Durante los últimos dos años, hemos hablado con la IA escribiendo en ventanas de chat, entradas de texto, y CLIs. Bueno, eso está cambiando rápidamente. Los agentes de IA que vamos a usar en un año, no viven en ventanas de chat. Viven en nuestros teléfonos, en nuestros coches, nuestros auriculares, nuestros timbres, en robots. Y vamos a hablar con ellos de la manera en que los humanos siempre han hablado, en voz alta. Y no estoy hablando de transcripciones, sino de conversaciones reales.

La voz es la interfaz más natural que tenemos, y se está convirtiendo en la interfaz natural para la IA también. Pero hay un problema. Hay desafíos. Construir uno de estos para que realmente se sienta como una conversación es mucho más difícil de lo que parece. Prueba esto. Imagina tener una conversación telefónica con alguien donde cada respuesta tarda tres segundos. Ambos comienzan a hablar al mismo tiempo. Te disculpas. Esperas. Lo intentas de nuevo. Y en menos de un minuto, realmente quieres colgar. Y eso es lo que la mayoría de los agentes de IA de voz sienten la primera vez que un usuario real los saca del modo de demostración.

Y así, naturalmente respondemos entre nosotros en unos 500 milisegundos. Y ese es el contrato conversacional con el que compite tu software. Alrededor de un segundo o menos es el límite donde se siente como una conversación real. Pero la mayoría de las aplicaciones de voz en producción hoy en día se sitúan entre dos y cinco segundos. Lograr menos de un segundo en infraestructura real con los modelos que tenemos hoy es genuinamente difícil. La brecha entre donde estamos y donde necesita estar es todo el problema de ingeniería de la IA de voz. Así que esta es la brecha. 500 milisegundos es lo que hacen los humanos. Un segundo es donde comienza a sentirse como una conversación real. Y de dos a cinco segundos es donde la mayoría de las aplicaciones de voz que usamos hoy en día realmente se sitúan.

La buena noticia es que esta brecha se está cerrando rápidamente. Los modelos se están volviendo más pequeños, más rápidos, más baratos cada trimestre, cada semana, cada día. La barra de un segundo que es aspiracional hoy será un estándar dentro de un año. Así que mantén una pregunta en tu mente durante el resto de esta charla. ¿A dónde va mi presupuesto de latencia y cómo lo protejo?

Trabajo en una empresa llamada LiveKit. Creamos infraestructura de código abierto para voz, video y datos en tiempo real. Hemos observado de cerca lo que se rompe cuando un agente de voz pasa de la demostración a la producción. En diciembre de 2022, justo después del lanzamiento de ChatGPT, nuestro CEO construyó un prototipo de fin de semana. Quería hablar con él en lugar de escribir. Lo unió con cinta adhesiva usando el reconocimiento de voz del navegador, una llamada HTTP a ChatGPT ejecutándose en un navegador sin cabeza y un texto a voz del navegador para reproducirlo. Creo que "unido con cinta adhesiva" es realmente la mejor manera de decirlo. La latencia de ida y vuelta para eso era de unos ocho segundos. Era terrible, pero funcionó.

Ahora, unos meses después, el equipo lo construyó en WebRTC y liberó todo el código. Escribimos una publicación en el blog al respecto, pero ¿adivina qué? A internet no le importó. No estábamos en la cima de Hacker News. Pero unos meses después, un desarrollador de OpenAI creó silenciosamente una cuenta en LiveKit Cloud, tomó el SDK de código abierto y comenzó a prototipar una interfaz de voz para ChatGPT sobre él. No sabíamos lo que estaban haciendo, pero nos encontraron porque el código estaba en GitHub. Para septiembre de 2023, el modo de voz de ChatGPT se lanzó en esa pila. Dos años y medio después, aquí hay algunas empresas que han utilizado esta misma pila. WebRTC, Rock, SAP, alrededor de una cuarta parte de los centros de despacho de emergencias 911 en los EE. UU., y más de 100,000 desarrolladores construyendo sus propios productos de voz. Cada línea de esa pila es OpenSource, Apache 2.0 en GitHub. Puedes npm installarlo hoy. Esta es toda la razón por la que puedo dar esta charla.

Aquí está el diagrama que quiero que lleves en tu cabeza. Cada agente de voz, sin importar el framework, sin importar el modelo, tiene aproximadamente la misma forma. El usuario habla, su micrófono captura el audio, se codifica, viaja a través de una red, tu backend. Un modelo de reconocimiento de voz a texto, STT, lo transcribe. El texto entra en un modelo de lenguaje grande. El LLM transmite tokens de vuelta. Un modelo de texto a voz, TTS, convierte esos tokens en audio. El audio viaja de regreso a través de la red, y el dispositivo del usuario lo decodifica y lo reproduce. Ocho etapas, y cada una cuesta latencia.

Tu trabajo, cada vez que tomas una decisión de diseño, es acercar la suma de esos costos lo más posible a un segundo. Este es el rango realista por etapa para un turno conversacional limpio hoy en día. STT rara vez es el cuello de botella, pero se acumula. El tiempo del LLM hasta el primer token suele ser la mayor parte y la más variable. El tiempo del TTS hasta el primer audio es el que la mayoría de las personas olvida medir. Suma todo y hasta un turno limpio ya consume la mayor parte de ese segundo. Esto es antes de las llamadas a funciones, antes de los reintentos, antes de cualquiera de las cosas del mundo real que te llevan a dos, tres, cinco segundos. Este es el piso.

Mira las filas de la red allí. Si tu usuario está en Sídney, y tu backend está en Virginia, eso es un piso de 120 milisegundos antes de que alguien siquiera procese algo. Ni siquiera has ejecutado un modelo todavía, y una parte significativa de tu presupuesto ya se ha ido. Por eso el enrutamiento en el borde no es un lujo. 100 milisegundos ahorrados en la red son exactamente tan valiosos como 100 milisegundos ahorrados en la inferencia.

tiempo de ingeniería en las etapas donde realmente puedes recuperar algo de ese tiempo. Los números de latencia publicados por los proveedores de modelos suelen ser tiempo hasta el primer token, TTFT. Eso es texto. Los agentes de voz necesitan tiempo hasta el primer audio, TTFA. Estos dos no son lo mismo. TTFA incluye el tiempo para que el LLM produzca suficientes tokens para que el TTS comience a sintetizar más el tiempo del TTS para comenzar a transmitir audio de vuelta.

Si estás midiendo TTFT y presupuestando contra TTFA, vas a enviar algo que se siente medio segundo más lento de lo que tu panel dice que realmente es. Siempre mide TTFA de extremo a extremo, instrumenta cada etapa y observa el P50 y el P99 por separado. La mayoría no alcanzará un segundo hoy. Probablemente aterrizarás más cerca de dos o tres segundos. Tu trabajo es pasar el próximo trimestre recuperando eso, cientos de milisegundos a la vez en cualquier etapa que sea más barata.

Los equipos que ganan en la IA de voz son los que tratan ese presupuesto como un estado de PNL. Una vez que tienes una canalización que devuelve audio lo suficientemente rápido, te enfrentas a un problema más difícil. ¿Cuándo ha terminado realmente de hablar el usuario? Eso suena trivial, pero no lo es. El enfoque ingenuo es la Detección de Actividad de Voz, o VAD. VAD escucha el silencio. En el momento en que ve un espacio de silencio, envía lo que tiene al LLM. Pero los humanos hacen pausas en medio de las oraciones todo el tiempo.

Si tu umbral de VAD es de 200 milisegundos, tu agente te interrumpirá constantemente. Si es de dos segundos, entonces tu agente se sentirá lento. No hay una buena respuesta estática. Cualquier respuesta que elijas estará equivocada en una dirección.

El ejemplo canónico de algo como esto es el usuario dando su número de teléfono. Hacen una pausa entre el código de área y los siguientes tres dígitos. Pausan nuevamente antes de los últimos cuatro dígitos. VAD ve tres turnos separados. Tu agente responde tres veces. Al usuario le molesta eso. El mismo patrón rompe direcciones, números de tarjetas de crédito, números de pedido, cualquier cosa estructurada.

La solución es la Detección de Turnos Semánticos, un pequeño modelo que escucha el contenido de lo que el usuario está diciendo y decide, basado en el lenguaje, si parece que ha terminado. Este es uno de los pocos lugares donde no deberías crear el tuyo propio. Entrenamos y liberamos el nuestro como código abierto. Funciona en una CPU en menos de 50 milisegundos. Funciona con 14 idiomas. Detecta estos casos de uso de números de teléfono. También detecta cosas como un "y" al final. La detección de turnos es un equilibrio entre la tasa de verdaderos positivos y la tasa de verdaderos negativos. Quieres inclinarte hacia los verdaderos negativos. Los usuarios pueden tolerar un ligero retraso, pero no tolerarán ser interrumpidos.

Ahora, la imagen especular de la detección de turnos es el Manejo de Interrupciones. Cuando un agente está hablando y el usuario emite un sonido, ¿qué haces? Si el usuario está interrumpiendo, necesitamos detenernos en 100 milisegundos. Cualquier tiempo mayor y se siente como si estuvieras hablando sobre el agente. Si el usuario solo dice, oh, mientras estás explicando algo, no están interrumpiendo. Están retroalimentando. Te están diciendo que sigas adelante. Si tu agente se detiene cada vez que alguien respira, tose, estornuda en el micrófono, la conversación se desmorona.

El patrón aquí es un pequeño modelo que clasifica si el audio entrante es una interrupción real o solo un reconocimiento. Entonces, queremos detenernos rápidamente cuando lo es y seguir adelante cuando no lo es. Hasta ahora, hemos estado hablando de agentes que hablan. Eso es una demostración. Lo que convierte una demostración en un producto es la llamada a funciones. Cuando el agente puede buscar un pedido, programar una cita, registrar un ticket, transferir una llamada, cada llamada a función te cuesta aproximadamente dos llamadas de inferencia de LLM. Una para decidir qué herramienta llamar y otra para resumir el resultado al usuario. Ese rango de dos a cinco segundos del que acabamos de hablar, una llamada a herramienta te empuja al extremo superior de eso. Estás viendo cuatro o cinco segundos cuando el agente tiene que hacer algo realmente. Ahí es donde los usuarios comienzan a preguntarse si tu agente se rompió.

La llamada a funciones no es solo un problema de LLM. Es un problema de diseño de latencia. Así que, cuatro reglas que te devolverán aquí. La primera, las funciones deben tener nombres cortos y claros y la menor cantidad de parámetros posible. Los LLMs eligen mejor cuando hay menos de dónde elegir. Segundo, las llamadas de back end detrás de tu función deben regresar en menos de 500 milisegundos. Si tu CRM está tardando dos segundos, el agente está ahí sentado en silencio. La tercera cosa, los datos que tu función devuelve deben ser algo que el LLM pueda decir en voz alta. JSON funciona, pero tienta al modelo a filtrar estructura en el discurso. Así que, devuelve resúmenes concisos y hablables. Y cuarto, las matemáticas son implacables. 95% de precisión suena genial. Cuando un agente toma 300 conversaciones al día, eso son 15 fallos al día.

Así que, prueba las llamadas a funciones que más importan. Especialmente aquellas donde los fallos pueden costarte dinero. Ahora, cuando una función tarda más de un segundo, tienes que decir algo. En voz, el silencio suena como un fallo. Así que, el usuario va a pensar que está roto.

El patrón aquí es reconocer antes de actuar. Así que, déjame buscar eso para ti. Un segundo. Eso te compra otro segundo o dos de paciencia percibida. Para cualquier cosa que dure más de cinco segundos, añade actualizaciones de progreso en streaming. Así que, este único patrón es la diferencia entre un agente que se siente receptivo y uno que se siente roto, aunque la latencia real sea idéntica.

Ahora, el siguiente problema, escribes un prompt del sistema que dice, primero, pide al usuario su correo electrónico. Luego pide su dirección. Luego confirma el pedido. Luego ofréceles una venta adicional. Eso funciona por un par de días, tal vez, pero luego un usuario te da su correo electrónico y su dirección en la misma frase. O un usuario hace una pregunta en el medio, o alguien interrumpe y quiere empezar de nuevo. De repente, tu máquina de estados con forma de prompt está en siete estados diferentes a la vez, y tu agente está alucinando números de pedido. Así que, los LLMs, son malos para ejecutar lógica de negocio rígida de los pros.

Son excelentes manejando el lenguaje. Son malos siendo motores de flujo de trabajo. Así que, divide responsabilidades. Tu código posee el flujo de trabajo, el estado, transiciones, validación, lo que está permitido cuándo. El LLM posee la comprensión del lenguaje dentro de cada paso. Puedes pedir al usuario un correo electrónico en cualquier fraseo que deseen, pero cuando el correo electrónico resulta inválido, el código dice que pregunte de nuevo, no el prompt. Este es uno de los pocos lugares donde el framework que elijas realmente importa.

Tareas, conversaciones estructuradas, como sea que tu herramienta las llame. Estas piezas que de otro modo reconstruirías, como recopilar correos electrónicos, direcciones, capturar tonos DTMF, los tonos de toque en un teclado para un árbol telefónico, hacer una transferencia cálida a un humano. Si construyes esos a mano, pasarás un mes para hacerlos bien. Así que elige un framework que los envíe y los haga de manera confiable. Los agentes de voz en producción son su propio animal. Lo más importante para internalizar es que la voz AI no es sin servidor.

En una aplicación web normal, un inicio en frío de un segundo en una primera solicitud, está bien. El usuario espera, la página carga, continúan. En un agente de voz, la primera solicitud es el usuario diciendo hola. Así que, si inicias en frío tu contenedor, ya estás 400 milisegundos en el agujero antes de que alguien haya hecho algo. Así que el patrón es siempre cálido, grupos inactivos, pre-gira suficientes procesos de agente para absorber tu carga normal, más espacio para picos. Trata la capacidad como asientos en un centro de llamadas, no como lambdas.

Aquí hay dos realidades más de producción. La primera es el costo. El LLM va a ser del 50 al 70% de tu factura por minuto. Y luego el costo crece de manera superlineal porque el LLM relee todo el historial en cada turno. Así que una llamada de 30 turnos procesa bien más de 100,000 tokens, aunque el usuario solo haya hablado tal vez 2,000 palabras. El almacenamiento en caché de tokens es lo único que realmente hace esto asequible. Así que hazlo un requisito indispensable para tu proveedor de modelos.

La segunda cosa es saber cuándo no ser el que maneja la llamada. Aquí hay algunas señales. La frustración repetida, solicitudes fuera de alcance, escalada emocional, límites de tiempo. Así que estas son señales para transferir la llamada, una transferencia cálida donde un humano retoma la conversación con el contexto ya resumido, y eso es una experiencia completamente diferente de una transferencia en frío que hace que el usuario tenga que empezar de nuevo. Así que construye la transferencia antes de lanzar, vas a necesitar eso desde el primer día.

Y luego probar agentes de voz es más como ejecutar un control de calidad para un equipo de servicio al cliente que probar una función de software. Los modos de falla son muy diferentes. ¿Interrumpió el agente al usuario? ¿Sonó robótico cuando debería haber sonado cálido? ¿Reconoció antes de una búsqueda lenta? ¿Perdió el contexto después de 15 turnos? Estas no son afirmaciones que puedas escribir en una prueba unitaria. Así que necesitamos clasificar estos fallos en tres capas. Primero es la percepción, ¿el audio y STT captaron las palabras correctamente? Y luego el razonamiento, ¿el LLM tomó la decisión correcta? Y luego la integración, ¿la llamada a la función funcionó? ¿Y regresó lo suficientemente rápido? Así que cuando una sesión sale mal, revisa esas tres capas en orden. No busques el prompt primero, busca la transcripción.

Y para evaluaciones automatizadas, el patrón que ha surgido es LLM como juez, eso es bueno. Escribes una plantilla de conversación, tal vez un cliente quiera reprogramar una cita. La evaluación ejecuta el agente a través de esa plantilla usando un usuario simulado. Otro LLM califica la transcripción resultante contra criterios, como si el agente confirmó la nueva hora. ¿Manejó la política de cancelación? El problema es que el juez, sin embargo, puede estar equivocado. Así que querrás calibrarlo contra sesiones etiquetadas por humanos primero, y luego confiar en él. Y luego ejecuta estos en cada PR.

Construye activos de datos a partir de sesiones de producción reales, anonimízalos, y luego incorpora los interesantes de nuevo en tu suite de regresión. Ahora, cuando algo se rompe en producción, la observabilidad es tu único amigo. Hay dos aspectos no negociables. El primero, spans de latencia para cada etapa del turno. Necesitamos saber de dónde vino la latencia. ¿Fue el final de la expresión, STT, el tiempo de LLM al primer token, finalización de LLM, tiempo de TTS al primer audio, respuesta total. Míralos todos en P50, P90 y P99. Un modo de falla común es que P50 se ve bien, y luego P99 son dos segundos.

Así que el 1% de tus usuarios están teniendo una experiencia terrible, y no puedes verlo en tu panel. Y la segunda cosa es poder reproducir el audio real de cualquier sesión, no solo la transcripción, el audio real. Más de una vez, la transcripción se veía bien, pero el audio era terrible, ha costado a los equipos una semana de depuración. Ya sea que uses el nuestro o desarrolles el tuyo propio, asegúrate de que puedes observar lo que realmente se dijo y cómo sonó. Ahora, un agente de voz mínimo viable es solo unas diez líneas de Typescript. Este es un agente real en funcionamiento. Puedes hablar con él, te responde, maneja interrupciones, usa WebRTC.

Está conectado al mismo pipeline que acabo de pasar 15 minutos describiendo. Así que no intentes construir un asistente que lo haga todo el primer día. Elige una cosa específica, programa un tipo de cita, responde preguntas frecuentes para una línea de productos. Omite la versión más pequeña útil, aprende de ella, luego expande. Mantente en un cronograma. Tal vez en la primera semana, logres que el bucle básico funcione. En la segunda semana, agregas la funcionalidad para tu caso de uso.

La tercera semana, construyes tu marco de evaluación, y la cuarta semana, lo fortaleces para la producción. Si omites cualquiera de estos pasos, lo lamentarás. Ahora, todo lo que acabo de explicarte está en un marco de código abierto que puedes usar hoy. No tienes que pedir permiso. No tienes que estar a la escala de chat GPT para beneficiarte de la ingeniería que nos llevó a la escala de chat GPT.

Ya sea que construyas sobre nuestra pila o la de alguien más, las restricciones son las restricciones. Presupuesto de latencia, toma de turnos, costos de llamadas a funciones, flujo de trabajo en código, lenguaje en el modelo, inicios en frío que afectan el primer saludo, almacenamiento en caché, evaluaciones, observabilidad, los modelos seguirán haciéndose más rápidos. Esa barra de un segundo se sentirá lenta antes de mucho tiempo. Los equipos que ganan son los que diseñan para ello ahora en una infraestructura que realmente poseen. Hazlo bien y tus usuarios no pensarán en tu agente en absoluto. Simplemente tendrán una conversación. Espero que esto haya sido útil. Ve y construye un agente de voz AI hoy.