La dictée hors ligne utilise les arbres de texte d'écran pour améliorer la précision sans LLM

Un développeur a publié une analyse technique de Handy Context, un outil de dictée hors ligne qui améliore la précision en lisant le texte actuellement visible sur l'écran de l'utilisateur. Publié en novembre 2026, le projet démontre comment biaiser un modèle de parole en utilisant des arbres d'accessibilité plutôt que des captures d'écran ou des grands modèles de langage (LLM). Cette approche s'exécute entièrement en local, offrant une alternative respectueuse de la vie privée aux services de transcription basés sur le cloud.

Ce qu'il s'est passé

Le créateur de Handy Context a détaillé un pipeline qui intègre le contexte de l'écran dans la reconnaissance vocale sans réentraîner le modèle acoustique sous-jacent. Le système utilise Parakeet-unified-en-0.6b, un modèle de parole figé, et l'améliore en extrayant du texte depuis l'arbre d'accessibilité de la fenêtre active. Cette méthode permet au logiciel de dictée de prioriser les mots réellement présents dans le flux de travail actuel de l'utilisateur, tels que les variables de code, les titres de diapositives ou les en-têtes de documents.

Les premières expériences impliquaient l'entraînement de couches supplémentaires par-dessus le modèle figé pour copier les mots de la liste, similaire aux techniques TCPGen. Ces versions entraînées ont obtenu des résultats inférieurs à ceux du pipeline non entraîné, introduisant souvent des erreurs lorsque la liste de mots fournie était sans rapport avec l'audio parlé. Le développeur a également testé de petits détecteurs de mots-clés pour filtrer les mots de l'écran afin de ne conserver que les candidats probables. Bien que ces détecteurs aient réduit une liste de 1 000 mots à environ trois termes tout en conservant 98 % des correspondances correctes, le pipeline non entraîné a toujours obtenu de meilleurs scores globaux ; les composants entraînés n'ont donc pas été inclus dans la version finale.

Plusieurs autres approches courantes n'ont pas permis d'améliorer les performances. L'utilisation d'un LLM de parole comme Qwen3-ASR-1.7B avec un contexte de 1 000 mots n'a pas réduit les erreurs par rapport à l'absence totale de liste, tout en étant dix fois plus lent. La sollicitation de Whisper large-v3-turbo avec un vocabulaire a augmenté son taux d'erreur sur les mots de 3,53 % à entre 4,8 % et 5,6 %. De même, l'application d'un remplacement de type VoiceInk a fait passer le taux d'erreur sur de vraies diapositives de 8,25 % à 8,79 %, principalement en raison de modifications incorrectes des terminaisons de mots.

Comment cela fonctionne

Le système capture le contexte en parcourant l'arbre d'accessibilité de la fenêtre au premier plan lorsqu'un raccourci est pressé. Il collecte le texte d'éléments tels que les champs de texte statiques, les titres, les boutons et les cellules de tableaux, s'arrêtant après 4 000 éléments ou 350 millisecondes. Ces données sont combinées au titre de la fenêtre et aux 8 000 derniers caractères du champ actif. Le texte extrait est divisé en termes, en éliminant les mots courants et les chaînes courtes, tout en préservant les majuscules pour les acronymes. La liste est enrichie avec les flexions trouvées dans le vocabulaire LibriSpeech pour couvrir les formes plurielles et les variantes orthographiques.

L'audio est encodé une seule fois et décodé jusqu'à neuf fois en utilisant différentes stratégies de biaisage. Le mécanisme central utilise le booster d'arbre de préfixes de NeMo pour ajouter des scores aux tokens correspondant aux termes du contexte de l'écran. Le système génère plusieurs transcriptions candidates, y compris des décodages simples et des décodages en deux passes qui filtrent les termes en fonction de leur similarité avec la transcription initiale. La similarité est calculée à l'aide de la distance de Levenshtein et des codes Metaphone. Le candidat final est choisi en calculant sa log-vraisemblance exacte sous le modèle non biaisé et en ajoutant un bonus pour chaque mot apparaissant dans la liste de termes étendue.

Les étapes de post-traitement affinent davantage la sortie. Le système propose des remplacements depuis le texte gagnant vers des termes de la liste étendue s'ils atteignent un seuil de similarité. Il évite les remplacements qui modifient uniquement les terminaisons de mots, une source fréquente d'erreurs dans les tentatives précédentes. La capitalisation est ajustée pour correspondre à l'orthographe à l'écran pour les noms propres et les acronymes. L'ensemble de ce processus s'exécute sur un serveur local, envoyant l'audio et le contexte pour recevoir le texte en moins d'une demi-seconde pour les dictées courtes.

Détails clés

• Le pipeline utilise Parakeet-unified-en-0.6b à la révision fe53cd8 sans fine-tuning des poids du modèle.
• Le texte de l'écran est capturé via les arbres d'accessibilité des applications Chromium et Electron, limitant pour l'instant le support à ces frameworks.
• L'utilisation mémoire de Handy Context est d'environ 7,1 GiB, nettement supérieure aux 0,84 GiB du modèle Handy de base en raison du runtime PyTorch.
• Le système effectue neuf décodages parallèles avec des forces de biaisage variées et des seuils de filtrage en deux passes pour trouver la meilleure correspondance.
• L'évaluation sur les jeux de données SlideSpeech et LibriSpeech a montré moins d'erreurs sur les mots de la liste que les références Parakeet simple et VoiceInk.
• L'outil ne prend actuellement en charge que l'anglais et fonctionne sur un seul système d'exploitation de bureau, sans capacité OCR pour le texte basé sur des images.

Pourquoi c'est important

Pour les ingénieurs développant des interfaces vocales, ce travail met en évidence les rendements décroissants liés au simple agrandissement des modèles ou à l'ajout de LLM pour la conscience contextuelle. L'échec de Qwen3-ASR-1.7B à améliorer la précision malgré sa taille suggère que l'adéquation architecturale et les mécanismes de biaisage efficaces comptent plus que le nombre brut de paramètres pour des tâches spécifiques. En s'appuyant sur des arbres d'accessibilité plutôt que sur de l'OCR ou des captures d'écran, le système atteint une intégration de contexte à faible latence sans la surcharge computationnelle du traitement visuel.

L'empreinte mémoire reste un obstacle significatif à l'adoption généralisée. L'exécution du modèle en pleine précision dans PyTorch consomme plus de 7 GiB de RAM, ce qui est prohibitif pour de nombreux ordinateurs portables grand public. Cependant, l'auteur note que le portage du pipeline dans un moteur personnalisé pourrait réduire cette consommation à moins de 4 GiB. Cet arbitrage entre précision et utilisation des ressources est une considération critique pour les développeurs visant à déployer des fonctionnalités IA hors ligne sur des périphériques edge.

Le succès du pipeline non entraîné par rapport aux alternatives entraînées remet également en question l'hypothèse selon laquelle le fine-tuning est toujours nécessaire pour l'adaptation au domaine. En tirant parti de stratégies de décodage robustes et de scoring a posteriori, les développeurs peuvent atteindre une haute précision avec des modèles figés. Cette approche simplifie la maintenance et réduit le risque d'oubli catastrophique, ce qui en fait un modèle viable pour les applications où le contexte change rapidement.

Ce que vous pouvez faire

• Extraire le texte des arbres d'accessibilité des applications pour construire des vocabulaires dynamiques pour les tâches de reconnaissance vocale.
• Utiliser le boosting d'arbre de préfixes pour biaiser les modèles de parole existants vers des termes spécifiques au domaine sans réentraînement.
• Implémenter un décodage en deux passes pour filtrer les listes de contexte en fonction de la similarité avec les hypothèses de transcription initiales.
• Appliquer des règles de post-traitement pour empêcher les remplacements erronés qui modifient uniquement les terminaisons ou suffixes de mots.
• Surveiller l'utilisation mémoire lors de l'intégration de modèles PyTorch dans des applications de bureau et envisager des moteurs personnalisés pour l'optimisation.
• Évaluer les systèmes conscients du contexte en utilisant les taux d'erreur sur les mots de la liste parallèlement aux taux d'erreur standards sur les mots pour mesurer les améliorations spécifiques.