5 Modos de Fallo de los Agentes de Voz que Encontrarás la Primera Semana — Venky B, Plivo

Transcript

00:00:00Hagamos un par de preguntas rápidas y luego nos metemos de lleno. ¿Cuántos de los presentes
00:00:19aquí han creado agentes de voz con IA? Bien, es un público bastante bueno. ¿Y cuántos de ustedes
00:00:28han creado agentes de IA que se hayan desplegado en producción? Nada mal. Vale, genial. Así que hablaremos
00:00:38de lo que suele pasar, ¿verdad? Como que todo el mundo habla de los agentes de voz con IA. La, ya sabes,
00:00:47la solución milagrosa para casi todo en el mundo hoy en día son los agentes de voz con IA. Así que todo el mundo
00:00:51está construyendo uno e intentando desplegarlo. Suenan genial cuando estás construyendo eso en tu
00:00:57entorno de desarrollo. Y luego, en el momento en que llevas esto de una prueba de concepto a producción,
00:01:03las cosas empiezan a fallar. Así que repasaremos estos cinco ángulos diferentes de cómo, o qué es lo que
00:01:09hemos visto en PLEVO con los agentes de voz con IA. Pero antes de eso, una rápida presentación de mi parte. Soy Venki,
00:01:19el fundador y director de agentes. Ella usó el título de gerente de ingeniería de agentes. Yo me llamo director de agentes
00:01:28desde el punto de vista del cargo. Muy bien, entonces, ¿qué es, qué es, ya sabes, por qué, por qué estamos calificados para esta
00:01:35discusión y qué es lo que estamos viendo que muchas empresas no llegan a ver? Así que,
00:01:42hablaré un poco de nuestro recorrido en cuanto a cómo hemos avanzado hasta ahora y luego entraremos de lleno.
00:01:48Ya sabes, llevamos unos 14 años. Nuestro recorrido ha sido el de una plataforma de API para desarrolladores.
00:01:54Y ahora, un negocio de agentes de IA. Empezamos con APIs de voz y SMS en el año 2011.
00:02:01Y ahora estamos enfocados principalmente en nuestra oferta de agentes de IA de pila completa.
00:02:08Toda la pila en nuestra plataforma. Vemos más de mil millones de llamadas de voz cada mes en todo el mundo.
00:02:16Y ahí es donde hemos visto surgir muchos de estos patrones en cuanto a cómo,
00:02:20cuando trabajamos con nuestros clientes, qué pasa con sus agentes de voz con IA en producción.
00:02:25Eh, somos un equipo de unos 90 miembros y, eh, tenemos 50 millones de financiación en el banco. Como dato curioso,
00:02:33esto no viene de inversores de capital de riesgo externos. Todo proviene de ser una empresa rentable,
00:02:38habiendo acumulado ese dinero en el banco a lo largo de estos años.
00:02:42Algunos de los clientes a los que damos servicio en todo el mundo. Hemos dejado algunos logotipos ahí,
00:02:49pero principalmente desde el punto de vista de la oferta, yo dividiría esto en tres categorías diferentes.
00:02:54Una es una oferta de agentes de IA programables. Lo llamamos, es una canalización
00:03:00de voz, todavía no es un producto verdadero de voz a voz, pero es una oferta programable.
00:03:05También tenemos un estudio de agentes de IA. Es un creador visual sin código. Y luego, como dije,
00:03:11empezamos con APIs de voz. Así que obviamente hemos desarrollado esto durante los últimos 14 años,
00:03:16la troncal SIP y la capa de transmisión de audio. Así que no dependemos de otros para la telefonía
00:03:22o la capa de operador. Ese es el negocio principal que hemos construido a lo largo de todos estos años.
00:03:26Y sobre eso es donde se asienta nuestra plataforma de agentes de IA.
00:03:32Bien. Dicho esto, metámonos en materia, ¿verdad? Estoy seguro de que, como todos ustedes han creado
00:03:39agentes de IA, todos han visto esto o lo han construido de una forma u otra. Y dedicaremos
00:03:44más tiempo a ver cómo se ve toda la tubería, ¿verdad? Lo que vemos con
00:03:51los clientes, y estoy seguro de que se sentirán identificados, es que cualquiera que piense en
00:03:56agentes de IA lo que hace es elegir un montón de estos marcos de orquestación y hacer un
00:04:01trabajo bastante bueno, como LiveKit o Pipecat, para construir su agente de IA sobre eso. Piensan
00:04:06que pueden simplemente orquestar estas cuatro capas diferentes: conversión de voz a texto, LLM y conversión de texto a voz
00:04:13con detección de turnos en medio, y ya estamos listos. Mi agente de IA funciona en una prueba de concepto
00:04:19y funcionará en producción. Típicamente eso es lo que pasa. Miden sus
00:04:24latencias y pueden ver algunas latencias indicativas en esta diapositiva en cada capa, y dicen:
00:04:30sí, esto me parece bien para lo que necesito, así que pasemos a producción. Y entonces
00:04:36la producción empieza a dar sorpresas y ves todo tipo de modos de fallo, en los cuales
00:04:41vamos a pasar la mayor parte del tiempo en esta charla, al menos. He dejado algo de tiempo
00:04:48al final para preguntas y respuestas si quieren hacer preguntas, pero vamos a entrar de lleno
00:04:53en los diferentes modos de fallo que vemos. Comencemos con el primero, del que todo el mundo habla.
00:05:01Este es el modo de fallo del que más se habla, que es la latencia. Creo que tenemos
00:05:07algunas charlas sobre agentes de IA o de voz hoy. Estoy seguro de que todo el mundo
00:05:12va a tocar este modo de fallo específico, por lo que lo menciono de inmediato
00:05:17en cuanto a cómo es toda esta experiencia para los usuarios, ¿verdad? Típicamente,
00:05:26la mayoría de la gente mide esto por el tiempo hasta el primer audio. Es decir, desde que los usuarios dejan de hablar
00:05:34hasta que su agente empieza a hablar, ¿verdad? Y creo que probablemente han visto esto si han
00:05:39creado agentes de voz sobre cómo se siente algo bueno o natural, cómo se siente
00:05:46algo un poco molesto o perceptible, y luego cómo se siente algo molesto, que son diferentes niveles.
00:05:52Notamos que la mayoría de la gente quiere estar por debajo de 550 ms porque es lo que anuncian
00:06:00las plataformas o soluciones, pero creo que la mayoría termina entre 750
00:06:07y 1.2 segundos. Ahí es donde termina la mayoría de la gente. Los de peor rendimiento terminan
00:06:13con más de 1.2 segundos, y es ahí cuando empiezas a ver que los usuarios cuelgan. Ahora, les compartiré
00:06:19lo que hemos visto prácticamente en producción con clientes que usan esto en diferentes capas,
00:06:26y luego soluciones para algunas de estas cosas. La forma en que queremos pensar
00:06:33sobre esta capa es como un equilibrio entre estos tres elementos: costo, inteligencia y latencia,
00:06:42¿verdad? ¿Y por qué menciono estos tres? Porque están interrelacionados. Creo que una
00:06:48de las cosas que hablaba con un par de personas afuera. Una de las cosas
00:06:51es que en el último año hemos visto muchas innovaciones y un gran aumento de inteligencia en el lado de los LLM,
00:06:58¿verdad? Y la mayor parte de la inteligencia ha llegado en forma de razonamiento,
00:07:05aprendizaje por refuerzo, etc. La ironía con los agentes de voz es que casi siempre
00:07:11el LLM o el agente que está hablando debe tener el razonamiento desactivado, ¿verdad? Así que todos los
00:07:19avances que hemos tenido en la capa de LLM en el último año, ninguno de ellos se aplica aquí ahora,
00:07:25¿verdad? Obviamente tienes mejores modelos que pueden hacer un mejor seguimiento de instrucciones
00:07:29o llamadas a herramientas, pero prácticamente toda la inteligencia integrada en la capa de razonamiento
00:07:34está desactivada por defecto si quieres que sea lo suficientemente rápido. Esa es una de las
00:07:39ironías con las que nos topamos. Entonces, ¿cómo balanceas la inteligencia, el costo y la latencia?
00:07:44Veamos algunas de estas opciones que existen en el mercado,
00:07:48¿verdad? Y estoy eligiendo específicamente los LLM porque, si miras el gráfico anterior, el LLM es
00:07:55básicamente el componente que más latencia añade, ¿verdad? Y si miras
00:08:02los modelos de frontera, con los que la mayoría de la gente empieza por defecto (OpenAI, Claude,
00:08:09Gemini), el tiempo hasta el primer token en el percentil 50 ronda los 450 o 500 ms en un buen día,
00:08:17pero puede tener picos, ¿verdad? El percentil 90 o 95 puede subir fácilmente por encima de 1.2 o 1.3 segundos,
00:08:25y eso no es bueno para la experiencia general del agente. Así que ese es tu modelo de frontera.
00:08:31Ahora bien, hay otra opción, que son Cerebras o Groq, que son famosos y
00:08:38populares por generar muchos tokens muy rápido, ¿verdad? Esto funciona, pero para obtener
00:08:45baja latencia o tiempo hasta el primer token en ellos, necesitas capacidad dedicada, y eso es realmente caro.
00:08:51De ahí que mencionara el costo como uno de los factores a equilibrar, ¿verdad? Es realmente
00:08:56caro. Y si hablas con alguien del equipo de Groq o Cerebras, te dirán
00:09:01que debes reservar con 12 meses de anticipación para tener capacidad dedicada. Están reservados para los próximos 12 meses.
00:09:05Así que esa es una opción bastante cara. Además, realmente necesitas estar seguro de que el modelo
00:09:11que despliegas en algunas de estas infraestructuras seguirá estando aquí de aquí a 12 meses. Es una
00:09:17gran inversión y una gran incógnita. Entonces, ¿cuál es una opción realista para producción
00:09:27de agentes de buena calidad que equilibren estos tres aspectos? Esto es lo que
00:09:34nos ha funcionado: los modelos de código abierto. Obviamente hay muchos en cuanto
00:09:41a la variedad y las variaciones que puedes elegir. Hablo específicamente de los dos con los que trabajamos:
00:09:47Qwen 3.5 y Gemma 4. Son modelos de código abierto de vanguardia en el mercado actual,
00:09:56disponibles en el mercado actualmente. Y hemos realizado muchas pruebas de rendimiento sobre cómo funcionan.
00:10:02Puede dar miedo pensar: “Vale, tengo los modelos, ahora tengo que alojarlos, ejecutarlos
00:10:10en mis propias GPUs, etc.”. Pero si apuntas sistemáticamente a menos de 300 ms,
00:10:17hemos visto que esta es una gran opción para equilibrar latencia, costo e inteligencia.
00:10:23Ahora bien, profundizando un poco más: si solo haces inglés, Qwen 3.5 o Gemma funcionan bien.
00:10:29Pero si haces multilingüe, públicos internacionales, diferentes idiomas, Gemma 4 es un
00:10:35modelo mucho mejor para eso. Hemos visto evaluaciones de fertilidad de tokens. Básicamente, lo que eso significa,
00:10:44si traduzco esto a un lenguaje sencillo, es: ¿cuántos tokens se necesitan para generar una palabra en
00:10:48ese idioma? Gemma es mucho, mucho mejor, al menos de 2.5 a 3 veces mejor que Qwen 3.5 desde esa
00:10:56perspectiva. Así que tu tiempo hasta las palabras es mucho más rápido en Gemma 4, todo lo demás constante, en
00:11:04multilingüe. Ahora bien, ¿qué tamaños elegir en la capa de LLM? Por lo general, los modelos de mezcla de expertos
00:11:12suelen funcionar bien, los de tres o cuatro mil millones de parámetros suelen ir bien. El problema con
00:11:17los modelos de mezcla de expertos es que si alguien decide adentrarse en la dirección del ajuste fino,
00:11:22eso puede ser un desafío, porque ajustar modelos de mezcla de expertos no es fácil; puedes terminar rompiendo
00:11:28el modelo muchas veces. Así que ese es un reto que vemos con la mezcla de expertos, pero normalmente de serie,
00:11:35te acerca un 90% a donde quieres estar, incluso sin realizar ningún ajuste fino o trabajo personalizado
00:11:42en el modelo. Esa es la ventaja de la mezcla de expertos. Ahora bien, si quieres hacer un ajuste fino
00:11:48y profundizar diciendo: «Mire, trabajo para un sector específico, atención médica,
00:11:53lo que sea», y quiero asegurarme de poder ajustar mi modelo, debes empezar al menos
00:11:58con los de 8 mil o 12 mil millones de parámetros, al menos desde donde estamos hoy; tal vez, dentro de seis meses,
00:12:04un modelo de 4 mil millones supere al de 8 mil millones sin duda, pero por hoy, lo que hemos
00:12:11visto es que necesitas como mínimo un modelo de 8 mil o 12 mil millones, porque buscas dos
00:12:16cosas en estos modelos: primero, obviamente, tokens rápidos, pero también que sigan bien las instrucciones, ¿de acuerdo? Y
00:12:23lo segundo es una proporción de éxito muy alta en la invocación de herramientas, porque si puedes hacer estas dos cosas
00:12:29bien, ya estás al 70 u 80% del camino sin necesidad de ajustar ningún modelo,
00:12:35los modelos funcionarán directamente, ¿verdad? Esa ha sido nuestra receta. De hecho,
00:12:42manejamos dos variantes: una de un modelo ajustado para industrias específicas y otra para,
00:12:50la mayoría de los casos de uso genéricos, un modelo MOE que funciona directamente. Hay algunos
00:12:56consejos y trucos más de los que hablaremos en las próximas diapositivas donde vemos modelos de fallo,
00:13:00pero ahí es donde nos situamos desde el punto de vista de la latencia en los LLM. Muy bien, voy mal
00:13:07de tiempo, así que voy a acelerar esto. Hay un par de variantes más en esto.
00:13:12La gente construye agentes con una mezcla de modelos. Lo que hacen es que, para la parte de conversación,
00:13:19tienen un modelo de conversación, que es un modelo mucho más pequeño, y luego,
00:13:24tal vez incluso un modelo de tres mil millones, y para la invocación de herramientas, tienen un modelo mucho más grande,
00:13:27de modo que consiguen una mayor proporción de éxito en la invocación de herramientas.
00:13:35perdón. Lo segundo es, uh, asumir que vuestras transcripciones van a ser frágiles. O sea, eso es,
00:13:42eso es, uh, algo con lo que debéis, por decirlo así, vivir al construir agentes de IA, incluso si tenéis
00:13:49el mejor motor de transcripción del mercado, y os, y os mostraré por qué, ¿verdad? O sea, los, los motores de
00:13:55transcripción más avanzados que hay, que hay en el mercado, eh, ya sabéis, consiguen una tasa de error de
00:14:02palabras del cuatro al seis por ciento, ¿verdad? Eh, y esto en conjuntos de evaluación conocidos. Eh, en llamadas
00:14:10reales y ruidosas con, ya sabéis, por así decirlo, eh acentos, como gente que tiene distintos tipos de acentos,
00:14:15vocabulario del dominio, etcétera. O sea, esas suelen terminar en los dos dígitos desde la perspectiva de
00:14:21la tasa de error por palabra, ¿verdad? Eh, ahora bien, obviamente podéis ajustar, ya sabéis, elegir un
00:14:25modelo de código abierto y ajustarlo, eh, pero normalmente vemos que, o sea, lo que suele fallar aquí,
00:14:31y hay patrones en cuanto a lo que falla. Así que nombres propios, la jerga, eh, números de teléfono, como
00:14:38dígitos aleatorios que faltan en los números de teléfono, eh, sustituciones erróneas. Os, os pondré algunos
00:14:43ejemplos de cómo resolver estas direcciones. Cuando intentáis recopilar una dirección larga, eh, ya sabéis,
00:14:48el motor de transcripción puede terminar perdiendo algunas partes. Cambio de código entre idiomas. Voy, voy a poner
00:14:55el ejemplo de un idioma que hablo, porque era fácil para mí ponerlo en la diapositiva, eh, donde, ya sabéis,
00:15:01si tomarais inglés, pero escrito en un alfabeto diferente, eh, eso es lo que se usa para el hindi,
00:15:06¿verdad? O sea, esto es inglés escrito en ese alfabeto, ¿verdad? Mientras que, como la versión en inglés
00:15:11real de esto es, hello, how are you? Entonces, si, si me dirijo a un público en otro país,
00:15:16donde tengo idiomas con cambio de código, y empiezo a recibir mi inglés en un, eh, tipo de alfabeto
00:15:21diferente, todo empieza a fallar, desde el motor de transcripción hasta la capa de LLM, y luego
00:15:26más allá, porque vuestro LLM empieza a producir resultados en ese tipo de alfabeto muchas veces, y entonces vuestro TTS
00:15:32falla. Bien, o sea, esto es, eh, muy importante tenerlo en cuenta, y si queréis construir vuestro
00:15:38agente independientemente del motor de transcripción, necesitáis construir una capa que normalice todo esto,
00:15:44¿verdad? Hablaremos de las soluciones en un momento. Y está el otro caso, que es, eh, el hindi,
00:15:48en solo, en solo latín o, o, o, ya sabéis, romano, ¿verdad? Es decir, esto es hindi, pero se lee
00:15:54en inglés, lo cual vuelve a estropear todo, eh, ya sabéis, en el procesamiento posterior. Esos solo son ejemplos. Esto se aplica a,
00:15:59ya sabéis, el árabe, el mandarín, el japonés, lo que sea, eh, prácticamente cualquier idioma. Así que,
00:16:04¿Qué es lo que realmente marca la diferencia en la capa de transcripción? Para los nombres propios,
00:16:11recomendamos no usar solo el refuerzo de palabras clave. Creo que muchos motores de transcripción
00:16:16ofrecen un refuerzo de palabras clave, donde puedes introducir palabras específicas en su motor,
00:16:21sino hacer un refuerzo dinámico de palabras clave. Lo que esto significa es: no mantengas la palabra clave durante toda la llamada.
00:16:26Añádela dinámicamente cuando creas que la necesitas como respuesta, para obtener la mayor
00:16:32precisión; es decir, en diferentes momentos de la llamada, el motor de transcripción tendrá diferentes
00:16:38palabras clave reforzadas durante distintas fases, ¿verdad? Y eso es lo que hemos visto que funciona mejor,
00:16:43porque si simplemente contaminas el contexto del motor de transcripción con toneladas de palabras clave, volverá a alucinar,
00:16:49¿verdad? Así que eso es lo que solemos ver que funciona mejor. Sí, haz un postprocesamiento de tus
00:16:55transcripciones con un LLM, porque tu LLM tiene contexto de dominio, pero tu motor de transcripción no.
00:17:02Así que muchas palabras que diría, te daré algunos ejemplos, pueden no tener sentido. Esto es
00:17:07una transcripción, como un número de teléfono de un motor de transcripción, ¿verdad? O sea, ¿qué crees que es esa E?
00:17:13¿Verdad? Si se lo das a un LLM, sabe que es un tres. De igual manera, ese uno es el dígito
00:17:18uno. Así que muchas veces tu motor de transcripción puede equivocarse en eso, pero al postprocesarlo
00:17:24con una capa de LLM, corregirá eso al instante desde el punto de vista de la corrección. O sea, y el último,
00:17:30como dije, la transliteración es que la salida de tu STT que es multilingüe también se normaliza
00:17:37usando un LLM con el que transliteras primero o usando algún tipo de motor de transliteración
00:17:46neuronal. Hay muchos de código abierto. Puedes simplemente elegir uno de ellos,
00:17:49¿verdad? Que hará todo ese trabajo por ti. Envía transcripciones limpias de forma constante,
00:17:55independientemente del motor de transcripción, a tu LLM.
00:18:00Muy bien. El tercero que solemos ver es la recopilación de datos. Aquí es donde creo que entre el 50 y el 60
00:18:05por ciento de los agentes de IA fallan estrepitosamente. Y nos gusta pensar en ello como un problema de UX,
00:18:14pero solo para voz. Así que piensa en modelos de datos, y no en una transcripción que llega a un LLM intentando
00:18:21descifrar qué decía la transcripción. Así que inspirémonos en, asumo que la mayoría de nosotros aquí somos
00:18:27desarrolladores. Inspírate en los modelos de datos de Python, Pydantic,
00:18:32Zod de TypeScript o en los campos de formulario de la interfaz de usuario, ¿verdad? Si empiezas a pensarlo desde ese planteamiento,
00:18:39hemos visto la precisión crecer del 30% al 95% desde el punto de vista de la recopilación de datos
00:18:46cuando empiezas a pensar de esa manera. Así que decide tu formato antes de preguntar, ¿no? En lugar de dejarlo abierto,
00:18:52¿puedes mantenerlo restringido? ¿Puede un número de teléfono ser un
00:18:58campo de tipo teléfono? En el momento en que haces eso, sabes cuántos dígitos necesita
00:19:03tener. Puedes aplicar validaciones sobre eso y definir qué valores permitidos puede haber.
00:19:10Así que en el ejemplo anterior vimos que si aparece una E en medio de un número de teléfono y sabes
00:19:15que es un número telefónico, sabes al instante que o bien adivinas inteligentemente que es un tres y lo confirmas con
00:19:20o sabes que es un error, lo validas y le pides al usuario que repita,
00:19:26¿verdad? Ese es uno de los patrones comunes que hemos visto aquí en cuanto a
00:19:31patrones de recopilación. El nombre creo que es el caso interesante. He elegido un nombre
00:19:36difícil de pronunciar. No hay forma de que un humano lo entienda a la primera, ni tampoco
00:19:43nuestro motor de transcripción, por más que lo intentes, ¿verdad? Así que en el momento
00:19:47en que empiezas a ver esto como campos y estableces reglas y mecanismos de confirmación para
00:19:53deletrearlo letra por letra, es la única manera de acertar. De lo contrario,
00:19:58fallará bastante en la forma en que recopilas esto en una llamada de voz. Y ese es solo
00:20:03un ejemplo de lo que menciono sobre la parte de recopilación de datos.
00:20:11Otro aspecto donde falla drásticamente son los valores relativos, siendo las fechas uno de los ejemplos.
00:20:18Si alguien dice el próximo miércoles a las ocho, podría significar las 8:00 a. m. o las 8:00 p. m., y averiguar
00:20:25cuál es la fecha exacta vuelve a ser un problema muy acotado. Si sabes que se trata de un
00:20:30campo de fecha y hora, tomas la fecha actual y calculas cuál sería este valor
00:20:35en función de eso, ¿verdad? Así es como te aseguras de
00:20:39hacer esto combinando el LLM con la invocación de herramientas, encargándose esta última
00:20:44de gran parte del trabajo pesado desde el punto de vista de los campos.
00:20:50Y luego ejecutas esto desde una perspectiva de pruebas unitarias. Por lo tanto, todas tus evaluaciones deben
00:20:58comenzar a tratar estos campos como pruebas unitarias. Y mientras tus pruebas unitarias se validen y pasen,
00:21:06ya sabes, tu agente será más o menos confiable y repetible. No tienes,
00:21:10ya sabes, que ejecutar cientos de casos de prueba de extremo a extremo solo para descubrir
00:21:15que la recopilación de un campo está rota. Haces tus evaluaciones a nivel de campo y de prueba unitaria.
00:21:24Y sí, como decía, creo que esta mentalidad hace que todo sea más estructurado,
00:21:30en lugar de esperar poner un montón de instrucciones y seguir cambiando el prompt por unos cuantos
00:21:36caracteres cada vez, esperando que de algún modo mi ingeniería de prompts haga que el LLM
00:21:41siga mejor las instrucciones y empiece a cumplir algunas de estas cosas como por arte de magia. De hecho,
00:21:47como decía, hemos visto que podemos alcanzar una precisión del 95 al 97% sin necesidad de ajustar un modelo.
00:21:53De acuerdo. Y el truco consiste básicamente en dividir el contexto de
00:21:57lo que está haciendo el agente en ese momento con estados específicos por los que atraviesa.
00:22:04Muy bien. Voy a pasar rápidamente por alto esto desde el punto
00:22:10de vista del tiempo. Veo que me quedan tres minutos. Espero que sea un error, pero lo dejaremos así.
00:22:16Bien. Esta es la cuarta área donde vemos que surgen problemas. La mayoría toma la salida del LLM
00:22:24y luego la envía a un sistema de texto a voz (TTS). Obviamente, hay muchos buenos sistemas de TTS en el mercado
00:22:30que se encargan de gran parte del trabajo pesado, pero muchas veces falla. Lo que recomendamos
00:22:37y hemos visto es que normalmente conviene tener una capa de normalización entre el LLM y lo que
00:22:43se le envía al TTS. No envíes la salida del LLM directamente al TTS, ¿verdad? Vamos a revisar
00:22:50algunos ejemplos. Lo básico: eliminar emojis y formato Markdown antes de realizar cualquier síntesis
00:22:58en el TTS. La mayoría de las tuberías de orquestación hacen esto, como LiveCAD o PipeCAD,
00:23:02que lo harían por ti con solo configurar algunas opciones. Pero asegúrate de que, si no los usas o
00:23:08estás construyendo desde cero, lo hayas configurado explícitamente, porque no querrás que aparezca un emoji
00:23:12en algo que se va a leer en voz alta, o que aparezca código Markdown.
00:23:17Bien. Otras opciones más comunes son los diccionarios personalizados. La mayoría de los motores de TTS ofrecen
00:23:23esta función para indicar cómo pronunciar palabras personalizadas, ya sean nombres propios, marcas,
00:23:30acrónimos, etc. Así que configúralos al pasar la salida del LLM al TTS,
00:23:36porque si no lo haces, saldrá mal. Y te mostraré un ejemplo de cómo probamos eso.
00:23:40Lo otro es que la mayoría de los motores también te permiten controlar la velocidad. Si sabes que vas a pronunciar
00:23:47una entidad, haz que el agente baje la velocidad a 0.8x o 0.7x, para que pueda
00:23:54enunciar esa entidad específica y no cometa errores al pronunciar un correo electrónico, un número de teléfono
00:24:00o un nombre letra por letra. Y sí, normaliza todo lo complejo: correos electrónicos,
00:24:09moneda, fechas. No dejes que el TTS se encargue de eso. La mayoría lo hace, pero no se lo dejes
00:24:15exclusivamente al TTS. Construye tu propia capa de normalización para que el día de mañana, si necesitas cambiar de TTS
00:24:21o por la razón que sea el primero no funciona y quieres usar otro,
00:24:25no tengas que depender de forma nativa del motor del TTS, sino que puedas gestionarlo internamente.
00:24:32Y bueno, creo que no tengo mi apellido aquí, no tengo mi apellido en eso. Mi primera prueba es si no puede pronunciar mi apellido
00:24:39o el nombre de mi empresa, ya está fallando. Así que mi apellido es Balasobramanian,
00:24:44y si un agente de voz con IA no puede pronunciar eso,
00:24:50para mí es una prueba clave. Ya sé que el agente va a fallar en muchas palabras que
00:24:56necesitan deletrearse constantemente. El segundo caso es el nombre de nuestra empresa, Pliwo. Muchos motores lo pronuncian
00:25:04día a día. La segunda es nuestra empresa llamada Pliwo. Así que muchos motores la pronuncian
00:25:09Pliwo o, eh, Pliwo y así sucesivamente. Pero, pero creo que poder controlar esto específicamente
00:25:16en tu flujo es súper crítico. Y luego, si estás construyendo, si estás construyendo un producto
00:25:21orientado al cliente, entonces, eh, ya sabes, como que le des esta opción a tus clientes. Muy bien,
00:25:26voy a repasar rápidamente las, las, las últimas dos diapositivas. Eh, voy, voy muy mal de tiempo.
00:25:32Eh, la detección de fin de turno, creo que este es un tema aparte, pero voy a
00:25:36mostrar rápidamente todos los puntos para que puedan echarles un vistazo. Y si, si necesitan charlar,
00:25:41eh, después de esto podemos, podemos hablar de esto. Bien, eh, lo voy a dejar así como unos cinco
00:25:49segundos y luego, y luego podemos charlar de esto fuera de línea. Voy, voy bastante mal de tiempo. Y luego,
00:25:53el, el, el último es, eh, la interrupción y, y el apoyo verbal. Creo que se habla mucho
00:25:58de los modelos de voz a voz que hacen algo de esto, pero hemos podido ver cómo podríamos hacer todo esto
00:26:03en flujos de voz a voz. Realmente no necesitas un modelo de voz a voz para hacer todo esto.
00:26:07Eh, de nuevo, solo lo, pondré esto en la diapositiva y, y con eso cerraré. Um,
00:26:15de acuerdo. No creo que tengamos tiempo para preguntas. Podemos atenderlas fuera de línea si tienen tiempo, pero,
00:26:19eh, espero que esto haya sido útil y les haya dado algunas perspectivas sobre, eh, lo que estamos viendo en producción,
00:26:24con miles de millones de llamadas a gran escala. Muy bien. Gracias.
00:26:29Nos vemos la próxima vez.

Key Takeaway

El paso de una prueba de concepto a producción en los agentes de voz de inteligencia artificial revela modos de fallo críticos en latencia, transcripción, recopilación de datos y síntesis, los cuales se mitigan mediante el uso de modelos de código abierto optimizados, normalización de datos y validación estructurada.

Highlights

  • La mayoría de las plataformas de agentes de voz experimentan latencias de 750 a 1.2 segundos en producción, lo que supera el umbral deseado de 550 ms e incrementa la tasa de llamadas abandonadas.

  • Los avances recientes en razonamiento para modelos de lenguaje extenso no se aplican en la capa de voz debido a la necesidad de mantener el razonamiento desactivado para asegurar respuestas rápidas.

  • Los modelos de código abierto como Qwen 3.5 y Gemma 4 equilibran de forma efectiva la latencia, el costo y la inteligencia en entornos de producción con una latencia objetivo menor a 300 ms.

  • Gemma 4 supera en eficiencia multilingüe a Qwen 3.5 con una fertilidad de tokens de 2.5 a 3 veces mayor para idiomas internacionales.

  • Los motores de transcripción presentan tasas de error de dos dígitos en llamadas reales con acentos diversos y vocabulario técnico, requiriendo normalización mediante modelos de lenguaje.

  • La precisión en la recopilación de datos se incrementa del 30% al 95% al adoptar modelos de datos estrictos inspirados en Pydantic o Zod en lugar de depender únicamente de la ingeniería de prompts.

Timeline

Introducción y panorama de la plataforma

  • Plivo gestiona más de mil millones de llamadas de voz mensuales a nivel global.
  • La arquitectura combina canalizaciones de voz programables, un estudio visual sin código y una capa troncal SIP propia.

Se analiza la transición de las pruebas de desarrollo hacia entornos de producción, donde la infraestructura telefónica propia se integra con marcos de orquestación como LiveKit o Pipecat.

Modo de fallo uno: La latencia

  • El tiempo hasta el primer audio se sitúa entre 750 y 1.2 segundos para la mayoría de las implementaciones estándar.
  • Los modelos de frontera generan picos de latencia en el percentil 90 que superan 1.2 segundos.
  • Los modelos de código abierto como Qwen 3.5 y Gemma 4 permiten alcanzar una latencia menor a 300 ms sin incurrir en los costos prohibitivos de infraestructura dedicada.

Se examina el equilibrio entre costo, inteligencia y latencia, destacando que los modelos de mezcla de expertos de 3 a 4 mil millones de parámetros ofrecen un rendimiento óptimo de serie.

Modo de fallo dos: La fragilidad de la transcripción

  • La tasa de error por palabra alcanza los dos dígitos en llamadas con acentos variados o jergas técnicas.
  • El refuerzo dinámico de palabras clave evita las alucinaciones provocadas por la saturación de contexto.
  • El postprocesamiento con modelos de lenguaje corrige errores en números de teléfono y normaliza la transliteración multilingüe.

Se detallan las fallas comunes en nombres propios, números y códigos de idiomas mixtos, proponiendo capas intermedias de normalización para asegurar datos limpios hacia el modelo de lenguaje.

Modo de fallo tres: La recopilación de datos

  • Entre el 50 y el 60 por ciento de los agentes fallan en la captura de información estructurada.
  • La aplicación de modelos inspirados en Pydantic o Zod eleva la precisión de recopilación hasta el 95%.
  • Las evaluaciones unitarias por campo sustituyen con mayor eficiencia a las pruebas de extremo a extremo.

Se demuestra que restringir los tipos de datos, validar formatos de fecha y aplicar mecanismos de confirmación iterativa resuelven los problemas de ambigüedad en nombres y fechas relativas.

Modo de fallo cuatro: La síntesis de texto a voz (TTS)

  • La eliminación previa de emojis y etiquetas Markdown previene errores sintácticos en la síntesis.
  • Los diccionarios personalizados y el control de velocidad en entidades complejas garantizan una pronunciación precisa.
  • Una capa de normalización independiente evita la dependencia nativa de motores específicos de TTS.

Se abordan los desafíos de pronunciación en nombres propios y marcas comerciales, cerrando con una revisión general sobre la detección de fin de turno y la gestión de interrupciones.

Community Posts

No posts yet. Be the first to write about this video!

Write about this video