Offline-Diktat nutzt Bildschirm-Textbäume zur Steigerung der Genauigkeit ohne LLMs

Ein Entwickler hat eine technische Analyse von Handy Context veröffentlicht, einem Offline-Diktatwerkzeug, das die Genauigkeit erhöht, indem es den aktuell auf dem Bildschirm des Benutzers sichtbaren Text liest. Das im November 2026 veröffentlichte Projekt demonstriert, wie man ein Sprachmodell unter Verwendung von Barrierefreiheits-Bäumen statt Screenshots oder großer Sprachmodelle (LLMs) beeinflusst. Der Ansatz läuft vollständig lokal und bietet eine datenschutzfreundliche Alternative zu cloudbasierten Transkriptionsdiensten.

Was passiert ist

Der Ersteller von Handy Context erläuterte eine Pipeline, die Bildschirminhalte in die Spracherkennung integriert, ohne das zugrunde liegende akustische Modell neu zu trainieren. Das System verwendet Parakeet-unified-en-0.6b, ein eingefrorenes Sprachmodell, und verbessert es durch Extraktion von Text aus dem Barrierefreiheits-Baum des aktiven Fensters. Diese Methode ermöglicht es der Diktatsoftware, Wörter zu priorisieren, die tatsächlich im aktuellen Arbeitsablauf des Benutzers vorkommen, wie Code-Variablen, Folientitel oder Dokumentenüberschriften.

Erste Experimente umfassten das Training zusätzlicher Schichten auf dem eingefrorenen Modell, um Listenwörter zu kopieren, ähnlich wie bei TCPGen-Techniken. Diese trainierten Versionen schnitten schlechter ab als die untrainierte Pipeline und führten oft zu Fehlern, wenn die bereitgestellte Wortliste nicht mit dem gesprochenen Audio übereinstimmte. Der Entwickler testete auch kleine Keyword-Spotter, um Bildschirmwörter auf wahrscheinliche Kandidaten zu filtern. Zwar reduzierten diese Spotter eine Liste von 1.000 Wörtern auf etwa drei Begriffe und behielten 98 % der korrekten Übereinstimmungen bei, aber die untrainierte Pipeline erzielte dennoch bessere Gesamtergebnisse, sodass die trainierten Komponenten nicht in die finale Version aufgenommen wurden.

Mehrere andere gängige Ansätze konnten die Leistung nicht verbessern. Die Verwendung eines Sprach-LLMs wie Qwen3-ASR-1.7B mit einem Kontext von 1.000 Wörtern reduzierte die Fehler im Vergleich zum vollständigen Verzicht auf eine Liste nicht, war jedoch zehnmal langsamer. Das Prompting von Whisper large-v3-turbo mit einem Vokabular erhöhte die Wortfehlerrate von 3,53 % auf zwischen 4,8 % und 5,6 %. Ebenso führte die Anwendung von VoiceInk-artigem Austausch die Fehlerrate bei echten Folien von 8,25 % auf 8,79 %, was hauptsächlich auf falsche Änderungen an Wortendungen zurückzuführen war.

Wie es funktioniert

Das System erfasst Kontextinformationen, indem es beim Drücken einer Tastenkombination den Barrierefreiheits-Baum des Vordergrundfensters durchläuft. Es sammelt Text aus Elementen wie statischen Textfeldern, Überschriften, Schaltflächen und Tabellenzellen und stoppt nach 4.000 Elementen oder 350 Millisekunden. Diese Daten werden mit dem Fenstertitel und den letzten 8.000 Zeichen des fokussierten Feldes kombiniert. Der extrahierte Text wird in Begriffe aufgeteilt, wobei häufig verwendete Wörter und kurze Strings herausgefiltert werden, während die Großschreibung für Akronyme beibehalten wird. Die Liste wird mit Flexionen aus dem LibriSpeech-Vokabular erweitert, um Pluralformen und Schreibvarianten abzudecken.

Audio wird einmal kodiert und bis zu neun Mal mit verschiedenen Biasing-Strategien dekodiert. Der Kernmechanismus nutzt NeMos Prefix-Tree Booster, um Scores für Tokens hinzuzufügen, die mit Begriffen aus dem Bildschirminhalt übereinstimmen. Das System generiert mehrere Kandidatentranskripte, einschließlich einfacher Dekodierungen und Zwei-Pass-Dekodierungen, die Begriffe basierend auf ihrer Ähnlichkeit zur initialen Transkription filtern. Die Ähnlichkeit wird unter Verwendung der Levenshtein-Distanz und Metaphone-Codes berechnet. Der finale Kandidat wird ausgewählt, indem seine exakte Log-Likelihood unter dem unbiasierten Modell berechnet und ein Bonus für jedes Wort vergeben wird, das in der erweiterten Begriffsliste erscheint.

Nachverarbeitungsschritte verfeinern die Ausgabe weiter. Das System schlägt Austausche vom gewonnenen Text zu Begriffen auf der erweiterten Liste vor, wenn sie einen Ähnlichkeits-Schwellenwert erfüllen. Es vermeidet Austausche, die nur Wortendungen ändern, eine häufige Fehlerquelle in früheren Versuchen. Die Großschreibung wird angepasst, um der auf dem Bildschirm angezeigten Schreibweise für Eigennamen und Akronyme zu entsprechen. Dieser gesamte Prozess läuft auf einem lokalen Server, sendet Audio und Kontext und erhält den Text in weniger als einer halben Sekunde für kurze Diktate zurück.

Wichtige Details

• Die Pipeline verwendet Parakeet-unified-en-0.6b in der Revision fe53cd8 ohne Fine-Tuning der Modellgewichte.
• Bildschirmtext wird über Barrierefreiheits-Bäume von Chromium- und Electron-Apps erfasst, was die Unterstützung derzeit auf diese Frameworks beschränkt.
• Der Speicherverbrauch von Handy Context beträgt ungefähr 7,1 GiB, deutlich höher als die 0,84 GiB des Basis-Handy-Modells aufgrund der PyTorch-Runtime.
• Das System führt neun parallele Dekodierungen mit variierenden Bias-Stärken und Zwei-Pass-Filter-Schwellenwerten durch, um die beste Übereinstimmung zu finden.
• Die Bewertung auf den Datensätzen SlideSpeech und LibriSpeech zeigte weniger Listenwortfehler als sowohl die reinen Parakeet- als auch die VoiceInk-Baselines.
• Das Werkzeug unterstützt derzeit nur Englisch und läuft auf einem einzelnen Desktop-Betriebssystem, ohne OCR-Fähigkeit für bildbasierten Text.

Warum das wichtig ist

Für Ingenieure, die Sprachschnittstellen entwickeln, hebt diese Arbeit die abnehmenden Renditen hervor, wenn man Modelle einfach skaliert oder LLMs zur Kontextbewusstseinserhöhung hinzufügt. Das Scheitern von Qwen3-ASR-1.7B, die Genauigkeit trotz seiner Größe zu verbessern, deutet darauf hin, dass architektonische Passgenauigkeit und effiziente Biasing-Mechanismen für spezifische Aufgaben wichtiger sind als die reine Parameteranzahl. Durch die Nutzung von Barrierefreiheits-Bäumen statt OCR oder Screenshots erreicht das System eine Latenzarme Kontextintegration ohne den Rechenaufwand visueller Verarbeitung.

Der Speicherbedarf bleibt eine erhebliche Hürde für die breite Adoption. Das Ausführen des Vollpräzisionsmodells in PyTorch verbraucht über 7 GiB RAM, was für viele Consumer-Laptops prohibitiv ist. Der Autor merkt jedoch an, dass die Portierung der Pipeline in eine eigene Engine diesen Bedarf auf unter 4 GiB reduzieren könnte. Dieser Kompromiss zwischen Genauigkeit und Ressourcennutzung ist eine kritische Überlegung für Entwickler, die Offline-KI-Funktionen auf Edge-Geräten bereitstellen möchten.

Der Erfolg der untrainierten Pipeline gegenüber trainierten Alternativen stellt zudem die Annahme infrage, dass Fine-Tuning für die Domänenanpassung immer notwendig ist. Durch die Nutzung robuster Dekodierungsstrategien und nachträglicher Scoring-Methoden können Entwickler hohe Genauigkeit mit eingefrorenen Modellen erreichen. Dieser Ansatz vereinfacht die Wartung und reduziert das Risiko des katastrophalen Vergessens, was ihn zu einem tragfähigen Muster für Anwendungen macht, bei denen sich der Kontext schnell ändert.

Was Sie tun können

• Extrahieren Sie Text aus Anwendungs-Barrierefreiheits-Bäumen, um dynamische Vokabulare für Spracherkennungsaufgaben zu erstellen.
• Verwenden Sie Prefix-Tree Boosting, um bestehende Sprachmodelle auf domänenspezifische Begriffe zu beeinflussen, ohne sie neu zu trainieren.
• Implementieren Sie Zwei-Pass-Dekodierung, um Kontextlisten basierend auf der Ähnlichkeit zu anfänglichen Transkriptions-Hypothesen zu filtern.
• Wenden Sie Nachverarbeitungsregeln an, um fehlerhafte Austausche zu verhindern, die nur Wortendungen oder Suffixe verändern.
• Überwachen Sie den Speicherverbrauch bei der Integration von PyTorch-Modellen in Desktop-Anwendungen und erwägen Sie eigene Engines zur Optimierung.
• Bewerten Sie kontextbewusste Systeme anhand von Listenwort-Fehlerraten neben standardmäßigen Wortfehlerraten, um spezifische Verbesserungen zu messen.