Multimodale Spracherkennung: einen Listener bauen, der sieht, was du siehst

Reine Audio-Spracherkennung ist inzwischen gut genug, dass ihre verbleibenden Fehler leicht unterschätzt werden. Saubere Sprachbenchmarks verbergen das eigentliche Produktproblem: Nutzer diktieren in Apps, neben sichtbarem Code, in gemischten Sprachen und mit teilweisen Verweisen wie „diese Funktion" oder „der obige Stichpunkt".

Wo ASR weiterhin scheitert

Das klassische Beispiel sind Homophone. „From foo import bar" und from foo import bar klingen ähnlich, gehören aber in unterschiedliche Welten. Dasselbe gilt für „cache the auth client" und „cash the auth client", wenn das Modell nicht weiß, dass der Cursor in einer TypeScript-Datei steht. Audio allein kann das Ziel nicht zuverlässig ableiten.

Code-Bezeichner verschärfen das. Ein Nutzer sagt vielleicht „fetch profile", aber die sichtbare Funktion ist fetchProfile. Ein Transkriptionsmodell hört Wörter; ein Diktatmodell sollte den Bezeichner erhalten. Multimodale Spracherkennung behandelt den sichtbaren Text als Evidenz, nicht als Dekoration.

Deixis ist die dritte scharfe Kante. Wenn ein Nutzer „replace this with a guard clause" sagt, ist der gesprochene Text formal eine vollständige Anfrage, aber seine Bedeutung hängt vollständig davon ab, worauf „this" zeigt. Ohne Bewusstsein für die Auswahl oder eine stabile Cursorreferenz muss das System raten, und jede falsche Vermutung verschwendet mehr Zeit als Neutippen. Reine Audio-ASR kann Deixis überhaupt nicht auflösen; sie kann das Demonstrativpronomen nur transkribieren und hoffen, dass ein nachgelagertes Tool den Sinn herausfindet.

• Homophone: einfache Prosa vs. Code-Syntax.
• Entitäten: Paketnamen, Klassennamen, Dateipfade und Befehlsflags.
• Deixis: „dies", „das", „oben", „der ausgewählte Teil".
• Format: Prosa, Stichpunkt, Code-Kommentar, Commit-Nachricht oder Prompt.

Die Architektur des multimodalen Listeners

Loquas Listener hat drei lokale Eingaben: Streaming-Audiofeatures, aus dem Bildschirm abgeleiteten Kontext und App-Metadaten. Der Audiopfad schlägt vor, was gesagt wurde. Der Kontextpfad fasst zusammen, wo der Text landen wird: App, Feldtyp, ausgewählter Text, umliegende Tokens und sichtbare strukturelle Hinweise. Der App-Pfad fügt Einschränkungen hinzu, etwa ob Zeilenumbrüche, Markdown oder Code-Syntax angemessen sind.

Der Listener muss den gesamten Bildschirm nicht wie ein Mensch verstehen. Er braucht die minimal nützliche Evidenz für das Diktat. In VS Code können das sichtbare Bezeichner, Sprachmodus und ausgewählter Code sein. In Slack das Thread-Thema und der jüngste Ton. In Notes die Überschriftsebene und der Listenkontext.

Was wir bewusst nicht versuchen

Mehrere Fähigkeiten sind absichtlich außerhalb des Umfangs. Der Listener führt kein OCR auf Screenshots fremder Inhalte aus, fasst keine Fenster zusammen, in denen der Nutzer nicht aktiv tippt, und baut keine persistente visuelle Historie auf. Er versucht auch nicht, feingranulare Absichten aus Bildern abzuleiten: ein Graph, ein Videoframe oder eine Design-Leinwand werden nicht interpretiert, nur der umgebende Text. Jede Auslassung ist eine bewusste Produktentscheidung, die Fähigkeit gegen Vorhersagbarkeit und eine klarere Datenschutzgrenze eintauscht.

Deshalb sprechen wir nur im engen Produktsinn von audiovisuellem Diktat: Audio plus visueller Kontext zum Schreiben. Das Ziel ist keine allgemeine visuelle Schlussfolgerung. Das Ziel sind weniger falsche Wörter am Cursor.

Wie Bildschirmkontext Mehrdeutigkeit auflöst

Diktat mit Bildschirmkontext verändert die Ausgabe, indem es Möglichkeiten einschränkt. Steht der Cursor in einer Python-Datei und enthält die sichtbare Zeile bereits from fastapi import, ist das gesprochene Wort „router" eher ein Symbol als ein allgemeines Substantiv. Steht der Cursor in Gmail, sollte dieselbe Phrase ein Satz werden.

Der Listener beherrscht auch auswahlbewusstes Bearbeiten. Ist Text ausgewählt, wird Diktat als Anweisung über diesen Text interpretiert, sofern der Nutzer nicht ausdrücklich darum bittet, neue Prosa einzufügen. Diese eine Unterscheidung beseitigt eine ganze Klasse versehentlich duplizierter Texte.

Kontextkonflikte werden gelöst, indem zuerst der stärksten Evidenz vertraut wird. Die aktive App ist das verlässlichste Signal, weil sie strukturell vom Betriebssystem garantiert wird. Ausgewählter Text kommt als Nächstes. Sichtbare umliegende Tokens sind das weichste Signal, weil sie veraltet oder zufällig sein können. Stehen zwei Signale in Widerspruch, bevorzugt der Listener das härtere und senkt die Konfidenz, statt eines auszuwählen und sich darauf festzulegen.

Datenschutz: Bildschirmkontext bleibt lokal

Kontextbewusste Spracherkennung hat einen Datenschutzpreis, wenn sie unbedacht umgesetzt wird. Loquas Regel lautet: Der vom Listener benötigte Bildschirmkontext bleibt standardmäßig lokal. Die Kontextzusammenfassung wird auf dem Gerät berechnet; sie wird genutzt, um die aktuelle Äußerung zu formen; sie wird nicht als allgemeines Bildschirmprotokoll behalten.

Konkret erreicht den lokalen Listener ein kurzes, flüchtiges Kontextpaket: aktive App-Kennung, Sprach- und Feldtyp, Auswahlbereich und einige hundert Zeichen nahegelegenen sichtbaren Texts. Standardmäßig verlässt das Gerät nichts vom übrigen Fensterinhalt, von anderen Tabs, anderen Apps oder einer persistenten Historie davon. Optionale Cloud-Funktionen erhalten, wenn vom Nutzer aktiviert, das diktierte Audio oder den Text unter den bereits in unserem Hinweis zum hybriden Datenschutz beschriebenen Grenzen; sie erhalten nie das rohe Kontextpaket.

Diese Grenze ist wichtig, denn ein Listener, der sieht, was du siehst, kann Code, Nachrichten oder Entwürfe beobachten. Wir behandeln das als sensible Daten. Die Datenschutzarchitektur ist ausführlicher in unserem Hinweis zum hybriden Datenschutz beschrieben, die Kurzfassung ist aber klar: Der Pfad für Bildschirmkontext ist local-first, und optionale Cloud-Funktionen erhalten keine rohen umliegenden Bildschirminhalte.

Offener Forschungskontext

Der Forschungshintergrund umfasst Audio-Sprach-Modellierung, Vision-Language-Projektion und multimodales Instruction-Tuning. Nützliche Ausgangspunkte sind Whisper für robuste ASR, LLaVA für Muster des visuellen Instruction-Tuning und ImageBind für die Ausrichtung über Modalitäten hinweg.

Diese Arbeiten sind Literaturkontext. Loquas Stack für multimodale Spracherkennung ist Eigenarbeit, abgestimmt auf die Mac-Diktatoberfläche: lokaler Kontext, latenzarmes Streaming und app-bewusste Ausgabe. Wir übernehmen das Vokabular des Feldes, nicht eine Abhängigkeitskette.

Roadmap

Der nächste Schritt ist bessere Unsicherheitsmeldung. Wenn der Kontext zwei mögliche Bezeichner nahelegt, soll das System die Mehrdeutigkeit erhalten, statt Konfidenz zu erfinden. Wir wollen außerdem feinere App-Adapter für Terminals, Tabellen, IDE-Chat-Panels und Design-Tools, in denen die Form nützlicher Ausgaben stark unterschiedlich ist.

Der Terminal-Adapter ist die konkreteste Arbeit in naher Zukunft. Ein Terminal ist strukturell eine einzelne Zeile am Cursor, kontextuell aber eine lange Historie früherer Befehle und Ausgaben, die informieren sollte, was der Nutzer als Nächstes tippen will. Ein Tabellen-Adapter hat die umgekehrte Form: ein winziges sichtbares Kontextfenster mit starrer Spaltenbedeutung. Beide Adapter nutzen dieselbe Listener-Architektur weiter; der Unterschied liegt darin, was als Evidenz zählt und woraus der Textrenderer seine Formatierungssignale zieht.

Die langfristige Richtung ist nicht „das Modell sieht alles". Sie ist enger und sicherer: Der Listener sieht genug lokalen Kontext, um zu schreiben, was du meintest, dort, wo du es meintest, mit weniger Nacharbeit. Das ist das Produktversprechen multimodaler Spracherkennung.