Detección de eventos de audio en el dictado: sonidos con significado más allá de las palabras
Una nota en fase de prototipo sobre cómo el audio no verbal podría enriquecer el dictado sin romper la privacidad ni el flujo.
TL;DR
La detección de eventos de audio en el dictado sigue en fase de prototipo en Loqua. Loqua es una herramienta de dictado por voz nativa de Mac, y nuestro foco ya lanzado son las palabras, el contexto y la salida consciente de la app. Estamos investigando si el audio no verbal —como risas, pausas, timbres o suspiros— puede convertirse en contexto estructurado opcional sin hacer el dictado ruidoso o invasivo.
Este post es deliberadamente más tentativo que nuestras otras notas de ingeniería. Sonidos con significado no es una función ya lanzada. Es una dirección de investigación temprana: ¿puede la comprensión de sonidos para dictado por voz capturar señales útiles no verbales sin romper el flujo tranquilo del dictado?
El vacío del audio no verbal
Los sistemas de dictado por voz suelen descartar todo lo que no es una palabra. Eso es razonable para una transcripción limpia, pero pierde información. En una reunión, las risas pueden marcar acuerdo o tensión. En un diario, una pausa larga puede importar. En flujos de accesibilidad, un timbre, un temporizador o un bebé llorando pueden ser contexto útil.
Piensa cómo se ve una transcripción típica de dictado tras una reunión de una hora. Las palabras están, pero el ritmo queda aplanado: la pausa larga antes de que alguien discrepa, la risita que suavizó un feedback duro, el momento de silencio tras una pregunta difícil. Un humano que revisa la transcripción los rellena desde la memoria. Un compañero que no pudo asistir no tiene ninguna señal. La detección de eventos de audio en el dictado es una forma de devolver una pequeña parte de esa textura al registro escrito, sin pedirle al usuario que lo narre.
El riesgo es obvio: no todos los sonidos deberían convertirse en texto. La mayor parte del audio de fondo es irrelevante. Parte es privado. Parte es ambiguo. La detección de eventos de audio en el dictado solo tiene sentido si es opcional, local-first y conservadora sobre cuándo un sonido cambia la salida escrita.
AED vs audio captioning
La detección de eventos de audio (AED) responde a una pregunta compacta: ¿qué evento ocurrió, y cuándo aproximadamente? El audio captioning escribe una descripción en lenguaje natural de una escena sonora. Para el dictado, AED suele ser suficiente. Una etiqueta como "risas" o "timbre" puede ser un marcador; un caption completo puede ser demasiado verboso.
| Técnica | Salida | Encaje en dictado |
|---|---|---|
| AED | Etiqueta de evento + timestamp | Marcadores de reunión, recordatorios, señales de accesibilidad |
| Audio captioning | Frase que describe la escena | Journaling, notas de media, flujos de revisión |
| Señales de emoción/prosodia | Señal de afecto tentativa | Solo útil con control fuerte del usuario |
Por qué nos inclinamos primero por AED
Una etiqueta AED falla en silencio. Si el modelo etiqueta algo como "aplausos" y no lo era, el usuario ve un solo marcador entre corchetes fácil de eliminar. Un audio caption equivocado es más difícil de deshacer: da forma al párrafo que lo rodea, sesga al lector y permanece en los resúmenes. Para un producto de dictado donde la confianza se construye frase a frase, el coste de una etiqueta pequeña equivocada es mucho menor que el coste de una frase equivocada con confianza. Nuestro sesgo inicial es hacia marcadores estructurados pequeños, no hacia prosa automática. Un marcador es más fácil de revisar, eliminar o ignorar.
Qué podría significar esto para el dictado
En reuniones, el audio no verbal podría crear marcadores opcionales: "[risas]" tras un chiste, "[pausa larga]" antes de una decisión, o "[timbre]" cuando interrumpen al ponente. En journaling, podría ayudar a preservar la textura emocional sin obligar al usuario a narrarla. En flujos de accesibilidad, podría convertir el sonido ambiental en una nota corta o un recordatorio.
Un esbozo concreto. Imagina una nota de reunión donde el usuario ha aceptado marcadores de reunión. La transcripción se leería como prosa ordinaria con etiquetas raras y compactas: "Acordamos lanzar la migración esta semana. [risas] Luego repasamos el plan de rollback. [pausa larga] Alguien preguntó si deberíamos posponer los cambios de índice". El lector obtiene un sentido más rico de lo que pasó sin un párrafo de acotaciones.
Un esbozo de journaling es aún más estrecho. El usuario dicta una nota rápida de fin de día; una pausa larga audible podría aparecer como una etiqueta "[reflexión]" que el usuario puede conservar, editar o eliminar al revisar. Nada se confirma automáticamente en el cuerpo de la entrada del diario sin ocasión de mirarlo.
No intentamos hacer el dictado teatral. El objetivo no es escribir cada tos o click de teclado. El objetivo es detectar un conjunto estrecho de eventos de alta señal y dejar que el usuario decida si esos eventos se convierten en texto, etiquetas o nada.
Bases de investigación
Varias líneas de investigación públicas son relevantes. CLAP explora el preentrenamiento contrastivo lenguaje-audio. BEATs estudia preentrenamiento de audio para comprensión acústica. AudioSet es un dataset a gran escala para eventos de audio, y AudioCaps es una referencia para audio captioning.
Son bases de investigación, no una declaración de dependencias del producto. El trabajo de prototipo de Loqua se centra en la pregunta del dictado en Mac: qué señales sonoras son útiles en el cursor, cuáles deberían quedarse invisibles y cómo puede el usuario controlar la frontera.
Qué estamos prototipando
Estamos prototipando tres comportamientos estrechos. Primero, marcadores de reunión: etiquetas opcionales para risas, silencio, aplausos e interrupciones. Segundo, señales de journaling: etiquetas aprobadas por el usuario para pausas largas o exasperación audible. Tercero, alertas de accesibilidad: una señal sonora local que puede convertirse en un recordatorio o nota cuando el usuario lo pida.
La experiencia de usuario que esbozamos internamente es deliberadamente discreta. Los eventos detectados aparecen como chips en una pequeña superficie de revisión junto al texto dictado, no en el texto en sí. El usuario puede arrastrar un chip al documento, descartarlo, o convertirlo en una etiqueta específica para el destino. El comportamiento por defecto es "nunca insertar sin consentimiento". El modo por defecto está apagado hasta que el usuario opte por entrar en un flujo de trabajo dado.
El prototipo es local-first y opt-in. Nada en esta dirección debería anotar silenciosamente sonido privado de fondo. También estamos probando un modo "solo marcadores" donde los sonidos detectados nunca entran automáticamente en la prosa; aparecen como chips revisables antes de la inserción.
Problemas difíciles que aún no resolvimos
El problema más difícil es el significado. Las risas pueden significar acuerdo, incomodidad, sarcasmo o nada. Un suspiro puede significar fatiga, alivio o ruido del micrófono. No queremos un modelo inventando interpretación emocional a partir de evidencia débil. El segundo problema difícil es la privacidad: el sonido ambiental puede revelar más de lo que los usuarios esperan.
El tercer problema difícil son los espacios compartidos. Incluso con opt-in estricto, un micrófono en una sala de reuniones oye a personas que nunca aceptaron nada. Una función de audio no verbal que captura risas en esa sala sigue capturando información sobre personas que no son el usuario. No creemos que esto sea irresoluble, pero le da forma fuerte al conjunto de restricciones: el detector debería correr localmente en el dispositivo del usuario, los marcadores nunca deberían compartirse sin una acción explícita, y el comportamiento por defecto para clases ambientales debería inclinarse hacia el silencio antes que hacia la inferencia.
Así que el estándar actual es conservador. El audio captioning en dictado debería requerir control claro del usuario, marcadores visibles y eliminación fácil. La vara para mover la detección de eventos de audio en el dictado de prototipo a lanzamiento es concreta: un flujo opt-in que un usuario cuidadoso describiría como honesto, comportamiento off por defecto en cualquier entorno que no hayamos probado explícitamente, y una UX que haga de una etiqueta equivocada una sola tecla para descartar. Hasta que esas piezas se sientan bien, esto se queda como trabajo de frontera de investigación, no como una promesa central ya lanzada.
Preguntas frecuentes
Prueba Loqua hoy
Gratis para empezar. Nativo de Mac. Hecho por investigadores de algoritmos que lo usan cada día.
Download for Mac