Curso exprés · No. 35
La voz lo cambia todo en un producto de IA. En lugar de leer y escribir, tiene que escuchar, entender, pensar y hablar — lo bastante rápido para que parezca una conversación, no un walkie-talkie. Hay un pipeline de tres piezas, más la parte genuinamente difícil: hacerlo todo en tiempo real. Aprende las etapas, por qué la latency es el reto central y qué hace que un agente de voz se sienta natural en lugar de robótico.
Solo lo esencial · Una imagen por idea · La latencia lo es todo
Una IA de voz no es una sola cosa — es una cadena de tres trabajos funcionando juntos. Ver primero el pipeline hace que todo lo demás en este curso encaje en su sitio.
Oído, cerebro, boca
Una persona en una conversación: oye lo que dices, lo piensa y responde hablando — tres actos distintos que parecen una sola cosa sin costuras.
Una IA de voz hace tres cosas en secuencia: escucha (convierte tu habla en texto), piensa (un modelo razona sobre ese texto y produce una respuesta) y habla (convierte la respuesta de nuevo en audio). Oído, cerebro, boca. El paso intermedio es el modelo de lenguaje que ya conoces; las partes nuevas son el oído y la boca a cada lado. Entender la IA de voz empieza por verla como esta cadena de tres etapas, no como una única caja mágica.
Speech-to-text, modelo, text-to-speech
Una línea de montaje con tres estaciones: una transcribe, una decide, una pone voz — el trabajo fluye de cada una a la siguiente.
Las tres etapas tienen nombre. Speech-to-text (STT) transcribe las palabras habladas del usuario a texto. El modelo toma ese texto y genera una respuesta, exactamente el texto-entra-texto-sale que has aprendido a lo largo del curso. Text-to-speech (TTS) convierte la respuesta de texto del modelo en audio hablado. Voz entra, transcripción, razonamiento, síntesis, voz sale. La mayoría de la IA de voz es este pipeline clásico, y nombrar las tres etapas es casi todo lo que hay que entender de cómo funciona.
El modelo es el mismo; los bordes son nuevos
Ya sabes pensar y responder con palabras — aprender a conversar por voz solo añade escuchar y hablar alrededor de ese mismo núcleo.
El núcleo de razonamiento es el mismo modelo de lenguaje de todos los demás cursos — contexto, prompting, herramientas, salida estructurada, todo sigue aplicándose al texto del medio. Lo nuevo es el audio en ambos extremos: convertir sonido en texto, y texto en sonido, de forma fiable y rápida. Así que no reaprendes el cerebro; añades el oído y la boca, y aprendes lo único que hace que la voz sea genuinamente difícil — hacer las tres cosas dentro del ritmo ajustado que exige una conversación.
Una IA de voz es un pipeline: speech-to-text (el oído), el modelo (el cerebro) y text-to-speech (la boca). El núcleo de razonamiento es el modelo que ya conoces; las partes nuevas son los bordes de audio, y el ritmo entre ellos.
La primera etapa convierte sonido en palabras. Ahora es notablemente buena, pero sus imperfecciones moldean todo lo que viene después, así que vale la pena entender qué puede y qué no puede hacer.
Transcription: el sonido se vuelve texto
Una taquígrafa judicial tecleando cada palabra según se pronuncia — convirtiendo el flujo del habla en un registro escrito que el resto del sistema puede leer.
Speech-to-text (también llamado transcription o reconocimiento automático del habla) convierte el audio hablado en texto escrito. Es el oído del sistema: el usuario habla, y STT produce las palabras sobre las que razonará el modelo. El STT moderno es impresionantemente preciso y maneja el habla natural y desordenada muchísimo mejor que el torpe reconocimiento de voz de hace años. Este es el paso que permite a una persona simplemente hablar en lugar de teclear — la puerta de entrada a toda la experiencia de voz.
Acentos, ruido y errores fluyen hacia abajo
Si la taquígrafa oye mal una palabra, todo lector posterior hereda el error — el fallo queda grabado desde el principio.
El STT no es perfecto: acentos, ruido de fondo, voces solapadas, términos técnicos y nombres pueden causar transcripciones erróneas. Y como es la primera etapa, sus errores se propagan — el modelo razona sobre el texto que se le dio, así que una palabra mal oída puede descarrilar silenciosamente toda la respuesta. Un sistema de voz es solo tan bueno como su transcription. Por eso diseñas para una entrada imperfecta: el modelo debería manejar con elegancia un texto algo distorsionado, y vigilas las condiciones (ruido, acentos) donde más le cuesta al oído.
Transcription en streaming mientras el usuario habla
Una taquígrafa que teclea continuamente mientras hablas, no una que espera a que termines todo el discurso antes de empezar — el texto aparece al compás de las palabras.
Para una sensación de respuesta ágil, el STT puede ser streaming — transcribiendo continuamente mientras el usuario habla, en lugar de esperar a que termine y procesar luego todo el fragmento. Esto importa para la velocidad: el streaming deja que el sistema empiece a trabajar antes y reaccione en cuanto el usuario para, en vez de añadir una pausa larga. La elección entre transcribir-al-final y transcribir-sobre-la-marcha es una de las primeras decisiones de latency en un sistema de voz, y el streaming es normalmente lo que hace que se sienta en vivo.
Speech-to-text es el oído: transcribe el habla en texto para el modelo. Sus errores fluyen hacia abajo, así que diseña para una entrada imperfecta — y haz la transcription en streaming para que el sistema reaccione según el usuario habla.
La última etapa convierte la respuesta de texto del modelo de nuevo en una voz. Es la parte que el usuario realmente oye, así que su calidad moldea cómo se siente todo el producto.
Síntesis: el texto se vuelve una voz
Un narrador leyendo un guion en voz alta — convirtiendo palabras escritas en un habla natural y expresiva que el oyente vive como una voz, no como un recitado.
Text-to-speech (TTS) convierte la respuesta de texto del modelo en audio hablado — la boca del sistema. El TTS moderno produce voces notablemente naturales, con entonación y ritmo realistas, mucho más allá del habla plana y robótica de antaño. Esto es lo que el usuario oye, así que carga buena parte de la personalidad y el carácter del producto. Un gran pipeline con una voz robótica aún se siente barato; una voz natural hace que toda la interacción se sienta humana, lo cual es buena parte de por qué los productos de voz se han vuelto viables.
La voz carga la experiencia
Las mismas palabras dichas con calidez o con frialdad llegan de forma completamente distinta — la entrega, no solo el contenido, es a lo que responde el oyente.
En un producto de voz, cómo se dice algo importa tanto como lo que se dice. La voz elegida, su tono, su cadencia — son decisiones de producto que moldean la confianza y la comodidad, igual que el diseño visual lo hace en un producto de pantalla. Una voz demasiado rápida, demasiado plana o con una inflexión rara socava una respuesta por lo demás buena. Así que el TTS no es algo añadido a última hora; la voz es una parte central de la experiencia, y merece elegirse y ajustarse con tanta deliberación como cualquier otro elemento de la interfaz.
Transmite el habla a medida que se genera
Alguien que empieza a decir su respuesta según se le ocurre, en lugar de componerla entera en silencio y luego soltarla de un bloque.
Igual que el STT puede transmitir hacia dentro, el TTS puede transmitir hacia fuera — empezando a decir el inicio de la respuesta mientras el resto todavía se está generando, en lugar de esperar al texto completo y al audio completo antes de emitir un sonido. Esto es crucial para la sensación de respuesta: transmitir la voz significa que el usuario oye una respuesta empezar casi de inmediato, en vez de quedarse sentado en silencio. Combinado con el modelo transmitiendo su texto, así es como un agente de voz responde sin un hueco incómodo — el habla arranca en cuanto hay algo que decir.
Text-to-speech es la boca: pone voz a la respuesta del modelo, y las voces modernas suenan lo bastante naturales para cargar toda la experiencia. Transmite el habla a medida que se genera para que la respuesta empiece al instante, no tras un silencio.
Aquí está lo que hace que la voz sea genuinamente difícil. Una conversación tiene un ritmo, y todo el pipeline de tres etapas tiene que completarse dentro de él — o la magia se rompe.
Una conversación tiene un presupuesto de tiempo ajustado
En una charla real, una respuesta que llega un instante tarde se siente incómoda; una que llega tras varios segundos se siente rota. La ventana para lo «natural» es pequeña.
La gente espera que una respuesta conversacional llegue en una fracción de segundo. Un retraso que sería invisible en una app de chat resulta evidente en el habla — un par de segundos de silencio después de que terminas de hablar se sienten como si el sistema se hubiera congelado. Este ajustado latency budget es la restricción que define la IA de voz: todo el ida y vuelta — oír, transcribir, pensar, sintetizar, hablar — tiene que caber dentro de la pequeña ventana que permite una conversación humana. Si fallas, hasta una respuesta perfecta se siente rota.
Los retrasos de las tres etapas se suman
Una carrera de relevos donde el tiempo total es la suma de la posta de cada corredor — un relevo lento en cualquier punto hace que todo el equipo llegue tarde.
La parte cruel es que la latency se acumula a lo largo del pipeline: el tiempo de transcribir, más el tiempo de que el modelo piense, más el tiempo de sintetizar el habla, todo se apila en el retraso total que siente el usuario. Que cada etapa sea «lo bastante rápida» por sí sola no basta si su suma revienta el presupuesto. Por esto la voz es más difícil que el texto: un chat de texto solo espera al modelo, pero la voz espera a tres etapas en serie, y la ventana de tiempo conversacional es mucho más ajustada.
Transmitir todo es como cumples el presupuesto
Un intérprete que traduce mientras hablas y empieza a poner voz a la respuesta a media idea — solapando las etapas en vez de hacerlas estrictamente una tras otra.
La técnica clave es transmitir y solapar las etapas en lugar de ejecutarlas estrictamente en secuencia: transcribir mientras el usuario habla, dejar que el modelo empiece a generar antes de que la pregunta esté del todo procesada, empezar a decir la respuesta antes de que esté del todo escrita. Solapar las tres etapas, en vez de esperar a que cada una termine por completo, es como un sistema de voz colapsa el retraso total en algo conversacional. Todo el arte de la voz de baja latency es mantener el pipeline fluyendo continuamente en lugar de parar y arrancar en cada etapa.
Una conversación tiene un latency budget ajustado, y los retrasos de las tres etapas se suman. Transmítelas y solápalas — transcribir, pensar y hablar en paralelo en vez de en secuencia — para encajar la respuesta dentro de la ventana conversacional.
Más allá de la velocidad, la conversación natural tiene una coreografía de quién habla y cuándo. Acertar con ese flujo es lo que separa a un agente de voz que se siente real de uno torpe.
Saber cuándo ha terminado el usuario
Un buen oyente distingue entre una pausa para respirar y el final de una frase — no salta cada vez que te tomas un momento.
Un sistema de voz tiene que detectar cuándo el usuario realmente ha terminado de hablar frente a cuándo solo ha pausado a media idea — el problema de saber cuándo es el turno del sistema. Si saltas demasiado pronto cortas al usuario; si esperas demasiado la conversación se arrastra. Este juicio de turn-taking es sorprendentemente difícil y central para sentirse natural: los humanos lo hacen sin esfuerzo con señales sutiles, y un agente de voz tiene que aproximarlo lo bastante bien como para que el ida y vuelta fluya en vez de trastabillar.
Manejar interrupciones: barge-in
Cuando empiezas a hablar por encima de alguien, esa persona se detiene y escucha — no sigue empujando su frase como si no hubieras dicho nada.
La conversación real incluye la interrupción. Si el usuario empieza a hablar mientras la IA está hablando — barge-in — un sistema natural se detiene, escucha y responde a la nueva entrada, en lugar de terminar su respuesta guionizada por encima de él. Soportar la interrupción es el sello de un buen agente de voz y notoriamente está ausente en uno malo, que te habla por encima sin enterarse. Manejar el barge-in significa que el sistema siempre está escuchando incluso mientras habla, listo para ceder la palabra en el instante en que el usuario la toma.
El flujo es parte del producto
Un buen compañero de conversación y uno incómodo dicen palabras parecidas — la diferencia es el ritmo, el escuchar y el ceder. El flujo es la experiencia.
Buena parte de si un agente de voz se siente natural o robótico se reduce a esta coreografía — captar los turnos, manejar las interrupciones, no dejar aire muerto ni hablar por encima del usuario. Estos detalles de flujo son tan importantes como la precisión de la respuesta, porque una respuesta correcta entregada con un ritmo torpe aún se siente rota. Así que diseñar un producto de voz significa diseñar la conversación, no solo las respuestas: el ritmo de quién habla y cuándo es una parte de primera clase de la experiencia, no un paso de pulido.
La voz natural necesita turn-taking — saber cuándo el usuario terminó — y barge-in — detenerse al ser interrumpido. El flujo de quién habla y cuándo es tanto el producto como las respuestas mismas.
Al clásico pipeline de tres etapas se le une un enfoque más nuevo: modelos que manejan la voz directamente, de extremo a extremo, colapsando las etapas para recortar la latency. Vale la pena saber hacia dónde se dirige el campo.
Modelos que toman y producen voz directamente
En lugar de un traductor que anota tus palabras, pasa la nota a un pensador y entrega su respuesta a un orador — una sola persona que oye, piensa y responde todo a la vez.
Una clase más nueva de modelos realtime (o speech-to-speech) maneja el audio directamente: toman voz de entrada y producen voz de salida, sin los pasos separados de transcribir-luego-razonar-luego-sintetizar. En lugar de tres modelos en cadena, un modelo hace todo el trabajo. Al colapsar el pipeline, este enfoque puede recortar drásticamente la latency que crea apilar tres etapas, y puede preservar el tono y la emoción que se pierden cuando el habla se aplana a texto plano y vuelta.
Menos etapas, menos latency
Un vuelo directo en lugar de dos conexiones — menos relevos, mucho menos tiempo total y nada se pierde en los transbordos.
La gran victoria de los modelos realtime end-to-end es la latency: eliminar las fronteras entre etapas elimina los retrasos de pasar datos entre ellas, acercándose mucho más al ida y vuelta instantáneo de la conversación humana. También evita perder información en cada conversión — el modelo puede oír cómo se dijo algo, no solo las palabras, y responder con una expresión a juego. Para las interacciones de voz más exigentes y de sensación más natural, este pipeline colapsado es cada vez más el enfoque.
Pipeline o end-to-end: una elección real
Puedes viajar con una serie de trenes en los que controlas cada tramo, o con un único servicio directo que es más rápido pero te da menos voz sobre la ruta — distintos compromisos, ambos válidos.
El clásico pipeline y el modelo end-to-end son ambos opciones reales con sus compromisos. El pipeline te da control y flexibilidad en cada etapa — cambiar el STT, inspeccionar la transcription, usar cualquier modelo — a costa de latency y complejidad. El modelo end-to-end da velocidad y naturalidad pero menos visibilidad y control sobre el medio. Saber que ambos existen te permite elegir con deliberación: el pipeline transparente y flexible, o el enfoque end-to-end rápido y fluido, según lo que tu producto necesite más.
Los modelos realtime end-to-end toman voz de entrada y de salida directamente, colapsando el pipeline para recortar la latency y preservar el tono. Pipeline frente a end-to-end es un compromiso real: control y flexibilidad, o velocidad y naturalidad.
Usar bien la voz significa elegirla para las situaciones adecuadas y respetar que la latency, más que nada, decide si se siente mágica o rota.
Recurre a la voz cuando de verdad encaja
Preferirías decir las indicaciones mientras conduces y teclear un formulario largo en tu escritorio — la entrada adecuada depende por completo de la situación.
La voz es potente donde encaja — uso con las manos libres, accesibilidad, conversación natural, situaciones en las que hablar es más rápido o más seguro que teclear — y encaja mal donde el texto es mejor, como cualquier cosa que necesite una entrada precisa, privacidad en público o una revisión cuidadosa. La habilidad está en emparejar la modalidad con el momento, no en añadir voz porque impresiona. Una interfaz de voz usada donde el texto serviría mejor es un retroceso; usada donde hablar es el acto natural, es transformadora. Elígela por la situación, no por la novedad.
Presupuesta la latency desde el principio
Un chef que planea toda la comida en torno al plato que más tarda — diseñando alrededor de la restricción que limita, no descubriéndola al final.
Como la latency es la restricción que lo decide todo, diseña para ella desde el principio: elige streaming en cada etapa, considera un modelo end-to-end donde la velocidad sea crítica, y ten un plan para cuando una etapa sea lenta. Las funciones de voz que ignoran la latency hasta tarde tienden a sentirse lentas y rotas por buenas que sean las respuestas. Trata el presupuesto de tiempo de respuesta como la restricción central de diseño de un producto de voz — el único número que, si se falla, arruina todo lo demás — y construye todo alrededor de cumplirlo.
- ¿De verdad encaja la voz en la situación — o el texto serviría mejor al usuario? - ¿Está cada etapa en streaming — transcribir, pensar y hablar solapándose, no en secuencia estricta? - ¿La latency total se siente conversacional, o hay un hueco incómodo? - ¿Maneja el turn-taking — saber cuándo el usuario terminó — y el barge-in? - ¿Es la voz lo bastante natural para cargar la experiencia? - ¿Pipeline o end-to-end — he elegido la arquitectura según mis necesidades de latency y control?
- speech-to-text (STT) / transcription — el oído: convertir el habla en texto. - text-to-speech (TTS) / síntesis — la boca: convertir la respuesta en una voz. - el pipeline de voz — STT, modelo, TTS en secuencia. - streaming — procesar cada etapa de forma continua en vez de esperar a que termine. - latency budget — la ajustada ventana de tiempo de respuesta que permite una conversación. - turn-taking / barge-in — saber cuándo el usuario terminó, y detenerse al ser interrumpido. - modelo realtime / end-to-end (speech-to-speech) — manejar la voz directamente, colapsando el pipeline.
- Eliges la voz para situaciones donde hablar de verdad encaja, no por novedad. - Cada etapa transmite y se solapa, así que la respuesta empieza casi al instante. - La latency total se siente conversacional, sin silencios incómodos. - El agente maneja el turn-taking y el barge-in, así que el flujo se siente natural. - Elegiste pipeline o end-to-end con deliberación, diseñando alrededor del latency budget.
La voz significa escuchar, pensar y hablar lo bastante rápido para que parezca una conversación. Transmite y solapa el pipeline, maneja el turn-taking y las interrupciones, elige pipeline o end-to-end con deliberación — y trata la latency como la restricción a la que todo lo demás se pliega.