Dictado por voz omni-modal: comprensión multimodal, MoE y salida de texto en streaming

Soy Shuran, fundador de Loqua.ai. Esta es la nota de ingeniería más profunda detrás de nuestro stack de dictado por voz omni-modal: por qué separamos el reconocimiento acústico de la comprensión multimodal de la tarea y del renderizado de texto, dónde ayudaron los expertos condicionales, dónde no, y por qué el streaming dictó casi cada decisión de arquitectura.

Por qué los LMs de audio monolíticos chocan con un muro en Mac

Un modelo monolítico de lenguaje sobre audio es atractivo en papel: alimentar audio, frames de pantalla y texto a un único modelo grande y pedirle que emita el dictado final. En el uso diario en Mac, ese diseño choca contra tres muros a la vez. Primero, el presupuesto de latencia es brutal. Si el primer token útil llega después de que el hablante pause, el dictado por voz se siente como transcripción batch en lugar de teclear.

Este es el presupuesto al que nos sujetamos. Desde el micrófono hasta el primer carácter visible, tenemos unos 200 milisegundos. De eso, aproximadamente 40 ms son overhead de plataforma (buffering de Core Audio, entrega inter-proceso y render final), 60 ms son extracción de características acústicas e inferencia del front-end, 70 ms son decodificación del planificador de instrucciones para la primera salida parcial, y quedan 30 ms para que el renderizador de texto emita un commit temprano seguro. Un único modelo de lenguaje sobre audio de 1B+ parámetros corriendo cada paso dentro de esa ventana es plausible en una máquina de benchmark pero poco fiable en un portátil real con un navegador, un IDE y Zoom ya corriendo.

Segundo, el trabajo visible para el usuario no es solo reconocimiento automático de voz. La misma frase debe convertirse en un párrafo de Slack, un asunto de commit de Git, un prompt de Cursor o un comentario de Python. Un modelo monolítico puede entrenarse para hacer todo eso, pero tiene que reaprender las convenciones de formato de cada app y volver a derivarlas cada vez que el cursor se mueve. Tercero, el modelo tiene que mantenerse dentro de la envolvente térmica y de memoria del portátil. Un modelo audio-visión-texto de 7B cargado en VRAM al lado del index de un IDE es una receta para thermal throttling y ventilador ruidoso. Trabajos públicos como Whisper y reportes recientes de modelos omni ayudaron al campo a entender el modelado robusto de audio y multimodal, pero enviar un producto local fuerza decisiones más estrechas y opinionadas.

Nuestra conclusión fue simple: el dictado por voz omni-modal debería ser un pipeline, no un único bloque para todo. El pipeline deja que cada capa mantenga un objetivo pequeño, un modo de fallo medible y un coste de runtime acotado.

El pipeline de instrucciones multimodal

Loqua no tiene una capa de respuesta hablada ni de TTS en este camino del producto. El planificador de instrucciones consume características de audio en streaming, contexto de pantalla seleccionado, metadatos de la app activa, el texto reciente alrededor del cursor y el prompt de instrucción activo. Produce un plan compacto de salida de texto: intención, entidades, modo de edición, formato objetivo e incertidumbre.

El renderizador de texto convierte ese plan en texto. No genera audio, respuestas habladas ni salida TTS. Decide si el plan se vuelve un checklist en Markdown, una frase, un comentario de código o una instrucción estructurada. Esta separación mantiene el razonamiento cross-modal caro fuera del camino caliente cuando el usuario simplemente está dictando prosa.

Lo que cada capa no debe hacer

La disciplina está en lo que quitamos. El front-end acústico no intenta ser listo sobre el formato de destino; expone tokens de audio con tiempos y confianza. El planificador de instrucciones no escribe prosa final; hace un plan estructurado lo bastante pequeño para revisarlo barato. El renderizador de texto no vuelve a leer el audio ni sintetiza voz; confía en el plan, el contexto de destino y el prompt de instrucción. Dejar que cualquier capa cruzara esas fronteras fue la causa más común de regresiones de latencia en nuestros primeros prototipos, porque los loops de feedback entre capas convierten el streaming en procesamiento batch sin que nadie se dé cuenta hasta que se lee el trace.

El beneficio es la depurabilidad. Cuando la salida está mal, podemos saber si el reconocedor oyó mal la palabra, el planificador de instrucciones eligió la intención equivocada o el renderizador de texto escribió en el registro equivocado. Eso es mucho más fácil que interpretar una trayectoria oculta larga. En nuestro triage interno, aproximadamente dos tercios de los arreglos de calidad post-lanzamiento se aislaron limpiamente a una sola capa; el resto requirió cambios entre capas, pero solo tras un diagnóstico claro.

MoE en el audio encoder

El audio encoder es donde rindió el cómputo condicional. No todas las frases necesitan el mismo tratamiento acústico. Habla silenciosa, inglés con acento, inglés y chino mezclados, identificadores de código y ruido de fondo de sala de reunión estresan partes distintas del modelo. Un router pequeño de mixture-of-experts deja que el encoder gaste más capacidad en regiones difíciles sin hacer caro cada frame.

Mantuvimos el routing conservador. El router se condiciona en estadísticas acústicas y pistas léxicas superficiales, no en perfiles personales de usuario. Los expertos se especializan en patrones como habla de baja amplitud, dictado técnico rápido y code-switching. Rechazamos un pool de expertos más grande porque la inestabilidad del routing empeoraba el comportamiento de streaming: un modelo que es preciso pero cambia de estilo a mitad de frase no sirve para teclear.

Lo que probamos y descartamos

Dos ideas se veían atractivas en investigación y fallaron en producto. Primero, adaptación de expertos por usuario: entrenar un pequeño adapter por usuario intensivo. Mejoró la precisión de cold-start unos pocos puntos en nuestro set de test interno, pero duplicó la huella de memoria al lanzar y enturbió las fronteras de privacidad. Segundo, un router que tomara el identificador de la app activa como señal fuerte. Sobreajustó a un puñado de apps comunes y se degradó silenciosamente en las nuevas. Lo reemplazamos con el router acústico-y-léxico actual y movimos el comportamiento consciente de la app hacia arriba, al planificador de instrucciones y al renderizador de texto, donde corresponde.

En términos prácticos, el MoE del audio encoder ayuda a Loqua a mantener rápido el camino común mientras hace la cola menos frágil. Ese es el valor de producto: no un truco de benchmark, sino menos momentos en los que el nombre de una biblioteca, una frase silenciosa o un fragmento bilingüe rompen el flujo.

Streaming: token a token vs frase a frase

El streaming fue el tradeoff más difícil. La salida token a token se siente responsiva, pero puede exponer suposiciones prematuras. La salida frase a frase es más limpia, pero se siente tarde. Usamos un híbrido: parciales tempranos para tramos de bajo riesgo, commits retrasados para entidades y ediciones que necesitan contexto de pantalla.

Por ejemplo, cuando dices "change the fetch profile function to return early if the auth client is missing", el sistema puede transmitir las palabras ordinarias rápido. Pero los tokens alrededor de fetchProfile y authClient esperan a que la capa de contexto confirme los identificadores visibles. Por eso el renderizado de texto está separado del reconocimiento: puede revisar un pequeño tramo antes de confirmar el texto, sin reiniciar la frase entera.

La entrada bilingüe a mitad de frase es un caso relacionado. Cuando dices "把这个 retry 函数改成指数退避", el planificador de instrucciones produce un plan de salida de texto que intercala tramos en chino con un token de código en inglés. El renderizador de texto emite los caracteres chinos en cuanto pasan un umbral interno de confianza y espera unos milisegundos extra en el identificador en inglés para confirmarlo contra el buffer visible del IDE. El usuario ve primero el flujo en chino, luego el identificador, luego el resto. Reordenar la salida habría sido más rápido pero se sentía mal; el ojo espera escritura de izquierda a derecha.

Las commit boundaries son la otra perilla. Una commit boundary es el momento en que el renderizador de texto promete no revisar. Las anclamos a pausas naturales, terminadores de oración y transiciones estructurales como párrafo, item de lista o bloque de código. Dentro de una commit boundary el renderizador de texto es libre de revisar; una vez confirmado, el texto es final desde el punto de vista del usuario. Ese contrato es lo que hace que el streaming se sienta honesto en lugar de tembloroso.

El resultado es un voice stack en streaming que se siente inmediato pero no trata cada suposición acústica temprana como final. Para el dictado por voz, ese compromiso importa más que la pura velocidad de transcripción.

Contexto de investigación abierta

Seguimos la investigación abierta de cerca porque afina nuestro vocabulario para los problemas que vemos en producto. Papers y reportes sobre modelado audio-lenguaje, encoders multimodales y optimización por preferencias muestran al campo convergiendo en responsabilidades separadas, restricciones de streaming y alineación cross-modal. Como base, empieza con Whisper, el reporte técnico de Qwen2, y la visión general pública de Qwen2.5-Omni.

La frontera importante de producto: estas referencias son contexto de literatura. El stack de producción de Loqua es investigación original entrenada y optimizada internamente para dictado en Mac. Citamos trabajos abiertos para explicar el campo, no para sugerir procedencia.

Lo que construimos y lo que viene

Lo que salió de esta dirección es un sistema estrecho: dictado por voz en Mac que escucha, lee el contexto local de pantalla y escribe texto consciente de la app. El siguiente trabajo es una evaluación más rigurosa. Necesitamos metodología pública para latencia, NER técnico, WER multilingüe y desambiguación por contexto de pantalla, para que las afirmaciones sean revisables fuera de nuestro loop de dogfooding.

La segunda dirección es mejor calibración. Cuando el modelo está incierto sobre un identificador visible, debería pedir menos al usuario eligiendo una forma de salida segura o preservando la frase cruda. También estamos explorando marcadores ligeros de incertidumbre en el renderizador de texto para que la UI downstream pueda resaltar tramos de baja confianza para una corrección rápida con teclado sin romper el ritmo del dictado.

La tercera dirección es el audio no-palabra. Ese trabajo sigue en fase de prototipo y lo cubrimos por separado en Sonidos con significado. Junto con nuestro trabajo en aprendizaje por refuerzo y el oyente multimodal, conforma la agenda del próximo año para nuestro stack de dictado por voz omni-modal.