Reconnaissance vocale multimodale : construire un listener qui voit ce que tu vois

La reconnaissance vocale audio uniquement est devenue suffisamment bonne pour que ses échecs résiduels soient faciles à sous-estimer. Les benchmarks de parole propre cachent le vrai problème produit : les utilisateurs dictent à l'intérieur d'applications, autour de code visible, dans des langues mélangées, et avec des références partielles comme « cette fonction » ou « la puce ci-dessus ».

Là où l'ASR échoue encore

L'exemple classique, ce sont les homophones. « From foo import bar » et from foo import bar sonnent pareil mais appartiennent à des mondes différents. Idem pour « cache the auth client » et « cash the auth client » si le modèle ne sait pas que le curseur est dans un fichier TypeScript. L'audio seul ne peut pas inférer la destination de manière fiable.

Les identifiants de code rendent ça plus net. Un utilisateur peut dire « fetch profile », mais la fonction visible est fetchProfile. Un modèle de transcription entend des mots ; un modèle de dictée devrait préserver l'identifiant. La reconnaissance vocale multimodale traite le texte visible comme une preuve, pas une décoration.

La deixis est la troisième arête tranchante. Quand un utilisateur dit « replace this with a guard clause », le texte prononcé est techniquement une requête complète, mais son sens dépend entièrement de ce que « this » désigne. Sans conscience de la sélection ni référence stable au curseur, le système doit deviner, et toute mauvaise supposition gaspille plus de temps que retaper. L'ASR audio uniquement ne peut pas résoudre la deixis du tout ; il ne peut que transcrire le démonstratif et espérer qu'un outil en aval s'en sortira.

• Homophones : anglais courant vs syntaxe de code.
• Entités : noms de packages, noms de classes, chemins de fichiers et flags de commande.
• Deixis : « this », « that », « above », « the selected part ».
• Format : prose, puce, commentaire de code, message de commit ou prompt.

L'architecture du listener multimodal

Le listener de Loqua a trois entrées locales : les features audio en streaming, le contexte dérivé de l'écran et les métadonnées d'application. Le chemin audio propose ce qui a été dit. Le chemin de contexte résume où le texte va atterrir : application, type de champ, texte sélectionné, tokens à proximité et indices structurels visibles. Le chemin d'application ajoute des contraintes comme la pertinence des sauts de ligne, du Markdown ou de la syntaxe de code.

Le listener n'a pas besoin de comprendre l'écran entier comme le ferait un humain. Il a besoin du minimum de preuves utiles pour la dictée. Dans VS Code, cela peut être les identifiants visibles, le mode de langue et le code sélectionné. Dans Slack, cela peut être le sujet du fil et le ton récent. Dans Notes, cela peut être le niveau de titre et le contexte de liste.

Ce que nous nous interdisons délibérément

Plusieurs capacités sont hors périmètre exprès. Le listener n'effectue pas d'OCR sur des captures d'écran de contenu distant, ne résume pas les fenêtres dans lesquelles l'utilisateur ne tape pas activement, et ne construit pas d'historique visuel persistant. Il n'essaie pas non plus d'inférer une intention fine à partir d'images : un graphique, une image vidéo ou une toile de design n'est pas interprété, seul le texte environnant l'est. Chaque suppression est un choix produit délibéré qui échange de la capacité contre de la prévisibilité et une limite de confidentialité plus claire.

C'est pour ça que nous l'appelons dictée audio-visuelle uniquement au sens produit étroit : audio plus contexte visuel pour l'écriture. L'objectif n'est pas le raisonnement visuel général. L'objectif est moins de mauvais mots au curseur.

Comment le contexte d'écran résout l'ambiguïté

La dictée à contexte d'écran change la sortie en restreignant les possibilités. Si le curseur est dans un fichier Python et que la ligne visible contient déjà from fastapi import, le mot prononcé « router » est plus susceptible d'être un symbole qu'un nom générique. Si le curseur est dans Gmail, la même phrase devrait devenir une phrase complète.

Le listener gère aussi l'édition consciente de la sélection. Si du texte est sélectionné, la dictée est interprétée comme une instruction sur ce texte sauf si l'utilisateur demande explicitement d'insérer une nouvelle prose. Cette seule distinction supprime toute une classe de textes dupliqués par accident.

Les conflits de contexte sont gérés en faisant confiance d'abord à la preuve la plus forte. L'application active est le signal le plus fiable car elle est structurellement garantie par le système d'exploitation. Le texte sélectionné vient ensuite. Les tokens visibles à proximité sont le signal le plus mou car ils peuvent être obsolètes ou accidentels. Quand deux signaux divergent, le listener préfère le plus dur et baisse la confiance plutôt que d'en choisir un et de s'engager.

Confidentialité : le contexte d'écran reste local

La reconnaissance vocale consciente du contexte a un coût en confidentialité si elle est implémentée à la légère. La règle de Loqua, c'est que le contexte d'écran dont le listener a besoin reste local par défaut. Le résumé de contexte est calculé sur l'appareil ; il sert à façonner l'énoncé courant ; il n'est pas conservé comme un journal général d'écran.

Concrètement, ce qui atteint le listener sur l'appareil est un bundle de contexte court et éphémère : identifiant d'application active, langue et type de champ, plage de sélection, et quelques centaines de caractères de texte visible à proximité. Ce qui ne quitte jamais l'appareil par défaut, c'est le contenu plus large de la fenêtre, les autres onglets, les autres applications ou tout historique persistant de l'un des éléments ci-dessus. Les fonctionnalités cloud optionnelles, quand elles sont activées par l'utilisateur, reçoivent l'audio ou le texte dicté selon les limites déjà décrites dans notre note sur la confidentialité hybride ; elles ne reçoivent jamais le bundle de contexte brut.

Cette limite compte car un listener qui voit ce que tu vois peut observer du code, des messages ou des brouillons. Nous traitons cela comme des données sensibles. L'architecture de confidentialité est couverte plus en détail dans notre note sur la confidentialité hybride, mais la version courte est claire : le chemin de contexte d'écran est local-first, et les fonctionnalités cloud optionnelles ne reçoivent pas le contenu brut de l'écran environnant.

Contexte de la recherche ouverte

Le contexte de recherche inclut le modèle audio-langage, la projection visuel-langage et le multimodal instruction tuning. Des points de départ utiles incluent Whisper pour l'ASR robuste, LLaVA pour les patterns de visual instruction tuning, et ImageBind pour l'alignement entre modalités.

Ces articles sont du contexte de littérature. Le stack de reconnaissance vocale multimodale de Loqua est un travail original ajusté pour la surface de dictée Mac : contexte local, streaming à faible latence et sortie consciente de l'application. Nous empruntons le vocabulaire du domaine, pas une chaîne de dépendances.

Feuille de route

L'étape suivante est un meilleur reporting de l'incertitude. Si le contexte suggère deux identifiants possibles, le système devrait préserver l'ambiguïté au lieu d'inventer une confiance. Nous voulons aussi des adaptateurs d'application plus fins pour les terminaux, tableurs, panneaux de chat d'IDE et outils de design, où la forme de sortie utile diffère radicalement.

L'adaptateur de terminal est le travail à court terme le plus concret. Un terminal est structurellement une seule ligne au curseur, mais contextuellement c'est un long historique de commandes et sorties précédentes qui devrait informer ce que l'utilisateur s'apprête à taper. Un adaptateur de tableur est la forme opposée : une toute petite fenêtre de contexte visible avec un sens de colonne rigide. Les deux adaptateurs réutilisent la même architecture de listener ; la différence est dans ce qui compte comme preuve et où le renderer de texte puise ses indices de formatage.

La direction à long terme n'est pas « le modèle voit tout ». Elle est plus étroite et plus sûre : le listener voit suffisamment de contexte local pour écrire ce que tu voulais dire, là où tu voulais le dire, avec moins de nettoyage. C'est la promesse produit de la reconnaissance vocale multimodale.