Reconocimiento de voz multimodal: construyendo un listener que ve lo que tú ves

El reconocimiento de voz solo con audio ha llegado a ser lo bastante bueno como para que sus fallos restantes sean fáciles de subestimar. Los benchmarks de habla limpia esconden el problema real del producto: los usuarios dictan dentro de apps, alrededor de código visible, en idiomas mezclados y con referencias parciales como "this function" o "the above bullet".

Dónde sigue fallando el reconocimiento de voz

El ejemplo clásico son los homófonos. "From foo import bar" y from foo import bar suenan parecido pero pertenecen a mundos distintos. También "cache the auth client" y "cash the auth client" si el modelo no sabe que el cursor está en un archivo TypeScript. El audio solo no puede inferir el destino de forma fiable.

Los identificadores de código lo hacen más agudo. Un usuario puede decir "fetch profile", pero la función visible es fetchProfile. Un modelo de transcripción oye palabras; un modelo de dictado debería preservar el identificador. El reconocimiento de voz multimodal trata el texto visible como evidencia, no como decoración.

La deixis es el tercer borde afilado. Cuando un usuario dice "replace this with a guard clause", el texto hablado es técnicamente una petición completa, pero su significado depende enteramente de a qué apunta "this". Sin conciencia de selección o una referencia estable del cursor, el sistema tiene que adivinar, y cualquier suposición equivocada cuesta más tiempo que volver a teclear. El reconocimiento de voz solo con audio no puede resolver la deixis en absoluto; solo puede transcribir el demostrativo y esperar que una herramienta posterior lo entienda.

• Homófonos: inglés llano frente a sintaxis de código.
• Entidades: nombres de paquete, nombres de clase, rutas de archivo y flags de comando.
• Deixis: "this", "that", "above", "the selected part".
• Formato: prosa, bullet, comentario de código, mensaje de commit o prompt.

La arquitectura del listener multimodal

El listener de Loqua tiene tres entradas locales: features de audio en streaming, contexto derivado de la pantalla y metadatos de la app. La ruta de audio propone lo que se dijo. La ruta de contexto resume dónde aterrizará el texto: app, tipo de campo, texto seleccionado, tokens cercanos y pistas estructurales visibles. La ruta de la app añade restricciones, como si los saltos de línea, el Markdown o la sintaxis de código son apropiados.

El listener no necesita entender toda la pantalla como lo haría un humano. Necesita la evidencia mínima útil para el dictado. En VS Code, eso pueden ser los identificadores visibles, el modo de lenguaje y el código seleccionado. En Slack, puede ser el tema del hilo y el tono reciente. En Apple Notes, puede ser el nivel de encabezado y el contexto de la lista.

Lo que deliberadamente no intentamos hacer

Varias capacidades están fuera de alcance a propósito. El listener no hace OCR sobre capturas de pantalla de contenido remoto, no resume ventanas en las que el usuario no está tecleando activamente y no construye un historial visual persistente. Tampoco intenta inferir intención de grano fino desde imágenes: un gráfico, un fotograma de vídeo o un canvas de diseño no se interpretan, solo se interpreta el texto que los rodea. Cada omisión es una decisión deliberada de producto que cambia capacidad por previsibilidad y por un límite de privacidad más limpio.

Por eso lo llamamos audio visual dictation solo en el sentido estrecho de producto: audio más contexto visual para escribir. El objetivo no es el razonamiento visual general. El objetivo son menos palabras incorrectas en el cursor.

Cómo el contexto de pantalla resuelve la ambigüedad

El dictado con contexto de pantalla cambia la salida restringiendo posibilidades. Si el cursor está dentro de un archivo Python y la línea visible ya contiene from fastapi import, la palabra hablada "router" es más probable que sea un símbolo que un sustantivo genérico. Si el cursor está en Gmail, la misma frase debería convertirse en una oración.

El listener también gestiona la edición consciente de la selección. Si hay texto seleccionado, el dictado se interpreta como una instrucción sobre ese texto a menos que el usuario pida explícitamente insertar prosa nueva. Esa única distinción elimina toda una clase de texto duplicado por accidente.

Los conflictos de contexto se resuelven confiando primero en la evidencia más fuerte. La app activa es la señal más fiable porque el sistema operativo la garantiza estructuralmente. El texto seleccionado viene a continuación. Los tokens visibles cercanos son la señal más blanda porque pueden estar desactualizados o ser accidentales. Cuando dos señales no concuerdan, el listener prefiere la más dura y baja la confianza en lugar de elegir una y comprometerse.

Privacidad: el contexto de pantalla se queda local

El reconocimiento de voz consciente del contexto tiene un coste de privacidad si se implementa con descuido. La regla de Loqua es que el contexto de pantalla que necesita el listener se queda local por defecto. El resumen de contexto se computa en el dispositivo; se usa para dar forma al enunciado actual; no se retiene como un registro general de pantalla.

En concreto, lo que llega al listener en el dispositivo es un paquete de contexto breve y efímero: identificador de app activa, lenguaje y tipo de campo, rango de selección y unos cientos de caracteres de texto visible cercano. Lo que nunca sale del dispositivo por defecto es el contenido más amplio de la ventana, otras pestañas, otras apps o cualquier historial persistente de cualquiera de los anteriores. Las funciones opcionales en la nube, cuando el usuario las habilita, reciben el audio o el texto dictado bajo los límites ya descritos en nuestra nota de privacidad híbrida; nunca reciben el paquete de contexto en bruto.

Este límite importa porque un listener que ve lo que tú ves puede observar código, mensajes o borradores. Lo tratamos como datos sensibles. La arquitectura de privacidad se cubre con más detalle en nuestra nota de privacidad híbrida, pero la versión corta es clara: la ruta de contexto de pantalla es local-first, y las funciones opcionales en la nube no reciben contenido bruto de la pantalla circundante.

Contexto de investigación abierta

El trasfondo de investigación incluye el modelado de audio-lenguaje, la proyección visual-lenguaje y el ajuste de instrucciones multimodal. Puntos de partida útiles son Whisper para reconocimiento de voz robusto, LLaVA para patrones de visual instruction tuning, e ImageBind para alineación entre modalidades.

Esos papers son contexto de literatura. El stack de reconocimiento de voz multimodal de Loqua es trabajo original ajustado para la superficie de dictado en Mac: contexto local, streaming de baja latencia y salida consciente de la app. Tomamos prestado el vocabulario del campo, no una cadena de dependencias.

Roadmap

El siguiente paso es reportar mejor la incertidumbre. Si el contexto sugiere dos identificadores posibles, el sistema debería preservar la ambigüedad en lugar de inventar confianza. También queremos adaptadores más finos para apps de terminal, hojas de cálculo, paneles de chat del IDE y herramientas de diseño, donde la forma de salida útil difiere drásticamente.

El adaptador de terminal es el trabajo más concreto a corto plazo. Una terminal es estructuralmente una sola línea en el cursor, pero contextualmente es un largo historial de comandos y salidas anteriores que debería informar lo que el usuario está a punto de teclear. Un adaptador de hoja de cálculo es la forma opuesta: una ventana de contexto visible diminuta con un significado de columna rígido. Ambos adaptadores reutilizan la misma arquitectura del listener; la diferencia está en qué cuenta como evidencia y de dónde saca el renderizador de texto sus pistas de formato.

La dirección a largo plazo no es "el modelo lo ve todo". Es más estrecha y más segura: el listener ve suficiente contexto local para escribir lo que quisiste decir, donde lo quisiste decir, con menos limpieza después. Esa es la promesa de producto del reconocimiento de voz multimodal.