Arquitectura de dictado por voz: dentro del stack de tres modelos de Loqua

Soy Shuran. Lidero un pequeño equipo de investigadores en algoritmos que usan dictado por voz a diario. Construimos Loqua porque las herramientas de dictado que evaluamos — la mayoría bien diseñadas, la mayoría genuinamente útiles — se aplastaban contra el mismo techo cuando las empujábamos con código, mezcla multilingüe y formato consciente de la app. El techo es estructural, no un problema de tuning. Esta es la arquitectura a la que llegamos tras decidir que la estructura tenía que cambiar.

Esto no es un paper. Es un recorrido a nivel blog — la intuición detrás de cada capa, los números que salieron y para qué usamos el stack de verdad. Si quieres el contexto académico más profundo, la sección de lecturas adicionales al final apunta a los papers de los que tomamos ideas.

La trampa de envolver Whisper

Whisper de OpenAI cambió lo que es posible para reconocimiento de voz en inglés. Es un modelo notable. El paper de Whisper mostró que escalar entrenamiento de audio débilmente supervisado produce ASR general robusto — a través de acentos, condiciones y 99 idiomas — sin fine-tuning por dominio. Es una victoria estructural para el campo.

Pero Whisper es un modelo de ASR, no un producto de dictado. La brecha entre "transcribe el habla con precisión" y "produce texto que puedo pegar en un correo sin editar" es grande. El enfoque de envolver Whisper — tomar la salida de Whisper y pasarla por una capa de formato — cierra parte de esa brecha. Falla en tres lugares que nos importaban:

• Vocabulario técnico. Whisper oye "react query" y te da "react query". No sabe que en tu codebase eso es @tanstack/react-query y que el import del paquete era lo que querías. NER sobre vocabulario técnico requiere un modelo que vea el contexto circundante, no uno que oiga fonemas.
• Formato consciente de la app. Whisper transcribe; no sabe si estás en Slack o en un archivo Python. Atornillar un formateador encima requiere una heurística — que es frágil — o una llamada pesada a un LLM por frase, que es lenta y depende de la nube.
• Streaming con presupuestos de latencia ajustados. Whisper es excelente para transcripción batch. Streaming on-device de baja latencia con Whisper requiere o compromiso (modelo más pequeño, menor precisión) o ingeniería agresiva que pelea contra la estructura del modelo.

Intentamos el camino de envolver Whisper para un prototipo de investigación. Fue suficientemente bueno para probar ideas. No fue suficientemente bueno para usarlo como nuestra herramienta diaria.

La intuición de los tres modelos: un tipo distinto de stack de reconocimiento de voz

La intuición es que el dictado por voz son tres tareas, y el mismo modelo es malo en las tres. Las tres tareas:

1. Oír las palabras. Acústico a token. Esto es en lo que el ASR es bueno.
2. Entender la intención. Limpiar muletillas, falsos arranques, correcciones a mitad de frase. Reconocer entidades técnicas. Decidir qué quería realmente teclear el usuario.
3. Colocarlo correctamente. Formatear la salida para la app de destino. Hacer que la misma intención salga como código en VS Code, como mensaje de Slack en Slack, como prompt estructurado en Cursor.

Un solo modelo end-to-end intentando hacer las tres tiene un problema estructural duro: la superficie de pérdida para "transcribir fonemas" y la superficie de pérdida para "formatear para Slack" apuntan en direcciones distintas. El entrenamiento conjunto compromete ambas. Podemos confirmarlo con nuestras propias ablaciones — intentamos unificar las capas 2 y 3 en un transformer entrenado con datos multitarea, y la precisión bajó en las dos.

Dividir en tres deja que cada modelo haga bien una tarea. El coste es una pequeña cantidad de latencia para el hand-off entre capas, que recuperamos corriendo todo en el Neural Engine dentro de un único pipeline. Ese es el corazón de la arquitectura de dictado por voz de Loqua: no un transcriptor monolítico, sino un pequeño stack de modelos de dictado donde cada capa está entrenada con propósito para su parte del problema.

Capa 1: reconocimiento de voz

Entrada acústica → secuencia de tokens. Este es un reconocedor de voz específico de tarea, en lugar de un wrapper directo de Whisper. Las decisiones de arquitectura las marcaron tres restricciones que no íbamos a comprometer:

• Streaming-first. La salida empieza antes de que el hablante termine la frase. Esto descarta la atención no causal sobre toda la secuencia de audio como opción por defecto — usamos una variante apta para streaming.
• Compatibilidad con el Neural Engine on-device. El tamaño del modelo y la selección de operadores están restringidos por lo que corre eficientemente sobre Core ML de Apple vía el Neural Engine. Es una restricción real — operadores que parecen bien en un paper pueden caerse del camino del Neural Engine y volverse CPU-bound.
• Robustez a baja amplitud. Nuestros datos de entrenamiento incluyen deliberadamente entrada en volumen susurrado (gente dictando bajo en cafeterías, tarde por la noche). La mayoría de datos de entrenamiento de ASR general son a volumen normal; el volumen susurrado requiere cobertura explícita.

La salida de esta capa es una secuencia de tokens con tiempos y puntuaciones de confianza. No es tu texto final — es el reconocimiento crudo que la siguiente capa limpia.

Capa 2: inteligencia lingüística

Secuencia de tokens → texto limpio con intención resuelta. Aquí es donde hacemos la mayor inversión en investigación, porque aquí vive la mayor parte de la calidad visible para el usuario.

El trabajo de esta capa: tomar lo que oyó el modelo de voz y producir lo que el usuario quiso decir. Tres cosas pasan en paralelo:

• Eliminación de muletillas y falsos arranques. "Um, so, basically, we should — actually wait, let me start over — we should cache this" se convierte en "We should cache this". La corrección a mitad de frase se respeta; el carraspeo se va.
• NER para vocabulario técnico. La capa aprende los nombres de bibliotecas comunes, frameworks, familias de modelos, extensiones de archivo, comandos de terminal y superficies de API idiomáticas. "React query" se convierte en @tanstack/react-query cuando el contexto circundante es un archivo JavaScript. Nuestro objetivo interno es reconocimiento en los altos 90s sobre vocabulario técnico in-domain curado, para que los identificadores salgan bien sin forzar un diccionario personal para cada término común.
• Moldeado estructural. Si la salida es una frase, una lista con bullets, una tabla markdown o un comentario de código se decide aquí en función de lo que la siguiente capa (contexto multimodal) diga sobre el destino.

Esta capa es el modelo más pequeño del stack por número de parámetros, pero el de mayor impacto en la experiencia de usuario. Pasamos más horas de equipo aquí que en las otras dos juntas.

Capa 3: contexto multimodal

Estado de la app + pantalla + cursor → directiva de formato. Esta es la capa omni-modal — y es la razón por la que no llamamos a esto solo "una app de dictado". El trabajo de Loqua no es transcribir; es escribir lo que querías decir donde querías decirlo.

La capa de contexto lee la app activa vía macOS Accessibility, el texto seleccionado (si lo hay), el texto adyacente visible y las pistas estructurales del destino (compose de Gmail vs hilo de Slack vs archivo Python de VS Code vs panel de chat de Cursor). Emite una directiva de formato que la capa de lenguaje usa para moldear el texto final.

La intuición más profunda — por qué las arquitecturas omni-modales cambian el dictado por voz, no solo lo mejoran — es su propia pieza. Mira voz se encuentra con visión: cómo los modelos omni-modales desbloquean el dictado consciente del contexto si quieres ese hilo.

Los números que seguimos

Estos son números de benchmark interno y de dogfooding, no de una suite de benchmark de terceros. Los sets de prueba incluyen nuestro propio vocabulario técnico, ejemplos de code-switching, muestras de inglés con acento y entornos cotidianos ruidosos. El siguiente paso de contenido debería ser una página pública de metodología para que estos números puedan citarse sin hand-waving.

Para qué la usamos nosotros mismos

Lo más importante que puedo decir sobre este stack es que lo escribimos porque lo usamos. Cada miembro del equipo dicta a diario — para commits, PRs, Slack interno, escritura técnica más larga y (en mi caso) la mayor parte de la prosa de posts de blog como este. Las decisiones que moldearon la arquitectura vinieron de uso real, no de una spec de producto.

Tres lugares donde la distinción arquitectura-vs-feature aparece en el uso diario:

• Dictado de código. La calidad del NER es la diferencia entre voz como interfaz viable para código y voz como juguete. Mira la guía de dictado de código para lo que esto habilita.
• Code-switching multilingüe. La mitad de nuestro Slack interno es mandarín e inglés mezclados. La capa de lenguaje se entrena con datos code-switched en vez de evitarlos; los cambios a mitad de frase funcionan sin un toggle de modo.
• Formato consciente de la app. Que la misma frase hablada se vuelva un comentario de código en VS Code y una descripción de PR estructurada en GitHub es la diferencia entre dictado por voz y un producto útil.

Somos un equipo pequeño. La versión honesta de esta historia es que no tenemos los recursos para mantener un producto envolviendo Whisper Y un stack de investigación de tres modelos. Apostamos por el camino estructural porque necesitábamos la calidad para nosotros mismos, y preferimos enviar algo más estrecho con calidad que algo más amplio sin ella.

Cómo se reconstruyó cada capa en 2026

Capa 1 — reconocimiento de voz. El reconocedor se ajustó alrededor de streaming, habla de baja amplitud y vocabulario técnico; el recorrido más profundo está en dentro de nuestro voice stack omni-modal y los detalles de post-entrenamiento están en RL en nuestro voice stack.

Capa 2 — inteligencia lingüística. La capa de lenguaje ahora trata limpieza, preservación de entidades y estructura consciente de la app como un único stack de modelos de dictado en lugar de post-procesadores separados. Ahí es donde más ayuda el aprendizaje por refuerzo: eligiendo la salida que los usuarios editan menos.

Capa 3 — contexto multimodal. La capa de contexto se reconstruyó alrededor de la evidencia local de pantalla: app activa, texto seleccionado, identificadores visibles y entorno del cursor. Mira construyendo un oyente que ve lo que tú ves para la arquitectura.

La siguiente frontera es el audio no-palabra: AED y audio captioning como contexto opcional y local-first. Cubrimos ese trabajo en fase de prototipo en sonidos con significado.

Lecturas adicionales

Si quieres ir más profundo que este tratamiento a nivel blog:

• El paper de Whisper (Radford et al., 2022) — para el paradigma de entrenamiento de audio débilmente supervisado del que tomamos ideas para la capa 1.
• La documentación de Apple Core ML — para cómo es desplegar en el Neural Engine en la práctica.
• Nuestra nota acompañante sobre voz se encuentra con visión: dictado omni-modal para el razonamiento de la capa 3.
• Nuestra nota sobre privacy by design con una arquitectura híbrida para qué cruza el cable y qué no.

Si tienes preguntas sobre la arquitectura o quieres profundizar más en alguna de estas capas, escríbenos. Somos un equipo pequeño y leemos cada correo.