Spracheingabe-Architektur: Einblick in Loquas Drei-Modell-Stack

Ich bin Shuran. Ich leite ein kleines Team aus Algorithmus-Forschern, die Spracheingabe jeden Tag nutzen. Wir haben Loqua gebaut, weil die Diktier-Werkzeuge, die wir evaluiert haben — die meisten gut entwickelt, die meisten wirklich nützlich — alle gegen dieselbe Decke stießen, sobald wir sie auf Code, mehrsprachiges Mischen und app-bewusste Formatierung drängten. Diese Decke ist strukturell, kein Tuning-Problem. Das ist die Architektur, bei der wir gelandet sind, nachdem wir entschieden hatten, dass sich die Struktur ändern muss.

Das ist kein Paper. Es ist ein Walkthrough auf Blog-Ebene — die Intuition hinter jeder Schicht, die Zahlen, die dabei herauskamen, und wofür wir den Stack tatsächlich nutzen. Wenn du den tieferen akademischen Kontext willst, verweist der Abschnitt mit weiterführender Literatur am Ende auf die Papers, aus denen wir geschöpft haben.

Die Wrap-Whisper-Falle

OpenAIs Whisper hat verändert, was bei englischer Spracherkennung möglich ist. Es ist ein bemerkenswertes Modell. Das Whisper-Paper hat gezeigt, dass das Skalieren von schwach überwachtem Audio-Training robuste allgemeine ASR liefert — über Akzente, Bedingungen und 99 Sprachen hinweg — ohne domänenspezifisches Fine-Tuning. Das ist ein struktureller Gewinn für das Feld.

Aber Whisper ist ein ASR-Modell, kein Diktier-Produkt. Die Lücke zwischen „transkribiert Sprache präzise" und „erzeugt Text, den ich ohne Bearbeitung in eine E-Mail einfügen kann" ist groß. Der Wrap-Whisper-Ansatz — nimm Whispers Ausgabe und schicke sie durch eine Formatier-Schicht — schließt einen Teil dieser Lücke. Er versagt an drei Stellen, die uns wichtig waren:

• Technisches Vokabular. Whisper hört „react query" und gibt dir „react query". Es weiß nicht, dass das in deiner Codebase @tanstack/react-query ist und du den Package-Import wolltest. NER auf technischem Vokabular braucht ein Modell, das den umgebenden Kontext sieht, nicht eines, das Phoneme hört.
• App-bewusste Formatierung. Whisper transkribiert; es weiß nicht, ob du in Slack oder in einer Python-Datei bist. Einen Formatierer obendrauf zu schrauben braucht entweder eine Heuristik — die brüchig ist — oder einen schweren LLM-Aufruf pro Äußerung, was langsam und Cloud-abhängig ist.
• Streaming unter knappen Latenz-Budgets. Whisper ist hervorragend für Batch-Transkription. Streamendes, latenzarmes, lokales Whisper erfordert entweder Kompromisse (kleineres Modell, geringere Genauigkeit) oder aggressives Engineering, das gegen die Struktur des Modells arbeitet.

Wir haben den Wrap-Whisper-Pfad für einen Forschungsprototyp ausprobiert. Er war gut genug, um Ideen zu testen. Er war nicht gut genug, um als unser tägliches Werkzeug zu dienen.

Die Drei-Modell-Intuition: eine andere Art von Spracherkennungs-Stack

Die Intuition ist, dass Spracheingabe drei Aufgaben sind — und dasselbe Modell ist in allen dreien schlecht. Die drei Aufgaben:

1. Die Wörter hören. Akustik zu Token. Darin ist ASR gut.
2. Die Absicht verstehen. Füllwörter und Fehlstarts bereinigen, mitten im Satz korrigieren. Technische Entitäten erkennen. Entscheiden, was der Nutzer tatsächlich tippen wollte.
3. Es korrekt platzieren. Die Ausgabe für die Ziel-App formatieren. Dieselbe Absicht als Code in VS Code, als Slack-Nachricht in Slack, als strukturierten Prompt in Cursor erscheinen lassen.

Ein einzelnes End-to-End-Modell, das versucht, alle drei zu erledigen, hat ein hartes strukturelles Problem: Die Loss-Oberfläche für „Phoneme transkribieren" und die Loss-Oberfläche für „für Slack formatieren" zeigen in verschiedene Richtungen. Gemeinsames Training kompromittiert beide. Wir können das mit unseren eigenen Ablationen bestätigen — wir haben versucht, die Schichten 2 und 3 in einem Transformer zu vereinen, der auf Multi-Task-Daten trainiert wurde, und die Genauigkeit fiel bei beiden.

Die Aufteilung in drei lässt jedes Modell eine Aufgabe gut erledigen. Der Preis ist ein geringer Latenzaufwand für die Übergabe zwischen den Schichten, den wir wettmachen, indem wir alles in einer einzigen Pipeline auf der Neural Engine laufen lassen. Das ist der Kern von Loquas Spracheingabe-Architektur: kein monolithischer Transkriptor, sondern ein kleiner Diktier-Modell-Stack, in dem jede Schicht zweckgerichtet für ihren Teil des Problems trainiert ist.

Schicht 1: Spracherkennung

Akustische Eingabe → Token-Sequenz. Das ist ein aufgabenspezifischer Spracherkenner statt eines direkten Whisper-Wrappers. Die Architektur-Entscheidungen wurden von drei Einschränkungen getrieben, bei denen wir keine Kompromisse machen wollten:

• Streaming-first. Die Ausgabe beginnt, bevor der Sprecher die Äußerung beendet. Das schließt non-kausale Aufmerksamkeit über die gesamte Audio-Sequenz als Standard aus — wir verwenden eine streamingfreundliche Variante.
• Kompatibilität mit der Neural Engine on-device. Modellgröße und Operator-Auswahl sind durch das eingeschränkt, was effizient auf Apples Core ML über die Neural Engine läuft. Das ist eine echte Einschränkung — Operatoren, die in einem Paper gut aussehen, können vom Neural-Engine-Pfad fallen und CPU-gebunden werden.
• Robustheit bei niedriger Lautstärke. Unsere Trainingsdaten enthalten bewusst flüsterlaute Eingaben (Leute, die leise in Cafés diktieren, spät nachts). Die meisten allgemeinen ASR-Trainingsdaten sind in normaler Lautstärke; Flüsterlautstärke erfordert explizite Abdeckung.

Die Ausgabe dieser Schicht ist eine Token-Sequenz mit Timing und Konfidenzwerten. Es ist nicht dein finaler Text — es ist die Roh-Erkennung, die die nächste Schicht bereinigt.

Schicht 2: Sprachintelligenz

Token-Sequenz → bereinigter, absichtsaufgelöster Text. Hier investieren wir am meisten in die Forschung, weil hier der größte Teil der nutzersichtbaren Qualität entsteht.

Aufgabe dieser Schicht: nimm, was das Sprachmodell gehört hat, und erzeuge, was der Nutzer gemeint hat. Drei Dinge passieren parallel:

• Entfernung von Füllwörtern und Fehlstarts. „Ähm, also, im Grunde, wir sollten — eigentlich warte, lass mich von vorn anfangen — wir sollten das cachen" wird zu „Wir sollten das cachen". Die Korrektur mitten im Satz wird respektiert; das Räuspern ist weg.
• NER für technisches Vokabular. Die Schicht lernt die Namen gängiger Libraries, Frameworks, Modellfamilien, Dateiendungen, Terminal-Befehle und idiomatischer API-Oberflächen. „React query" wird zu @tanstack/react-query, wenn der umgebende Kontext eine JavaScript-Datei ist. Unser internes Ziel ist eine Erkennung im hohen 90er-Bereich für kuratiertes domänenspezifisches technisches Vokabular, sodass Bezeichner korrekt herauskommen, ohne für jeden gängigen Begriff ein persönliches Wörterbuch zu erzwingen.
• Strukturelle Formung. Ob die Ausgabe ein Satz, eine Aufzählung, eine Markdown-Tabelle oder ein Code-Kommentar ist, wird hier entschieden — basierend darauf, was die nächste Schicht (multimodaler Kontext) über das Ziel sagt.

Diese Schicht ist nach Parameterzahl das kleinste Modell im Stack, aber das mit der größten Wirkung auf die Nutzererfahrung. Wir haben hier mehr Team-Stunden investiert als in die anderen beiden zusammen.

Schicht 3: Multimodaler Kontext

App-Zustand + Bildschirm + Cursor → Format-Direktive. Das ist die omni-modale Schicht — und der Grund, warum wir das nicht einfach „eine Diktier-App" nennen. Loquas Aufgabe ist nicht zu transkribieren; sie ist, das zu schreiben, was du gemeint hast, dort, wo du es gemeint hast.

Die Kontext-Schicht liest die aktive App über die macOS Accessibility API, den ausgewählten Text (falls vorhanden), den sichtbaren angrenzenden Text und die strukturellen Hinweise des Ziels (Gmail-Compose vs. Slack-Thread vs. VS Code Python-Datei vs. Cursor-Chat-Panel). Sie gibt eine Format-Direktive aus, die die Sprachschicht nutzt, um den finalen Text zu formen.

Die tiefere Intuition — warum omni-modale Architekturen Spracheingabe verändern, nicht nur verbessern — ist ein eigenes Stück. Siehe Voice trifft Vision: wie omni-modale Modelle kontextbewusstes Diktat ermöglichen, wenn du diesem Faden folgen willst.

Die Zahlen, die wir verfolgen

Das sind interne Benchmark- und Dogfooding-Zahlen, keine Drittpartei-Benchmark-Suite. Die Testsets umfassen unser eigenes technisches Vokabular, Code-Switching-Beispiele, Samples mit akzentuiertem Englisch und laute Alltagsumgebungen. Der nächste inhaltliche Schritt sollte eine öffentliche Methodik-Seite sein, damit diese Zahlen ohne Handwedeln zitiert werden können.

Wofür wir es selbst nutzen

Das Wichtigste, was ich über diesen Stack sagen kann, ist, dass wir ihn geschrieben haben, weil wir ihn nutzen. Jedes Teammitglied diktiert täglich — für Commits, PRs, internes Slack, längeres technisches Schreiben und (in meinem Fall) den Großteil der Prosa für Blogposts wie diesen. Die Entscheidungen, die die Architektur geprägt haben, kamen aus echter Nutzung, nicht aus einer Produktspezifikation.

Drei Stellen, an denen die Unterscheidung Architektur vs. Feature im täglichen Gebrauch sichtbar wird:

• Code-Diktat. Die NER-Qualität ist der Unterschied zwischen Stimme als realistischer Schnittstelle für Code und Stimme als Spielzeug. Siehe den Leitfaden zum Code-Diktat dafür, was das ermöglicht.
• Mehrsprachiges Code-Switching. Die Hälfte unseres internen Slack ist gemischtes Mandarin und Englisch. Die Sprachschicht ist auf Code-Switching-Daten trainiert, nicht um sie herum; Wechsel mitten im Satz funktionieren ohne Modus-Umschalter.
• App-bewusste Formatierung. Dieselbe Sprachphrase, die in VS Code zu einem Code-Kommentar und auf GitHub zu einer strukturierten PR-Beschreibung wird, ist der Unterschied zwischen Spracheingabe und einem nützlichen Produkt.

Wir sind ein kleines Team. Die ehrliche Version dieser Geschichte ist, dass wir nicht die Ressourcen haben, ein Wrapped-Whisper-Produkt UND einen Drei-Modell-Forschungs-Stack zu pflegen. Wir haben auf den strukturellen Pfad gesetzt, weil wir die Qualität für uns selbst brauchten — und wir bringen lieber etwas Schmaleres mit Qualität raus als etwas Breiteres ohne.

Wie jede Schicht 2026 neu gebaut wurde

Schicht 1 — Spracherkennung. Der Erkenner wurde rund um Streaming, leise Sprache und technisches Vokabular verfeinert; der tiefere Walkthrough steht in Einblick in unseren omni-modalen Voice-Stack und die Post-Training-Details in RL in unserem Voice-Stack.

Schicht 2 — Sprachintelligenz. Die Sprachschicht behandelt Bereinigung, Entitätserhalt und app-bewusste Struktur jetzt als einen Diktier-Modell-Stack statt als separate Post-Processoren. Genau hier hilft Reinforcement Learning am meisten: die Ausgabe zu wählen, die Nutzer am wenigsten bearbeiten.

Schicht 3 — multimodaler Kontext. Die Kontext-Schicht wurde rund um lokale Bildschirmevidenz neu gebaut: aktive App, ausgewählter Text, sichtbare Bezeichner und Cursor-Umgebung. Siehe einen Listener bauen, der sieht, was du siehst für die Architektur.

Die nächste Front sind nicht-wörtliche Audios: AED und Audio-Captioning als optionaler, lokal-zuerst-Kontext. Wir beschreiben diese Arbeit im Prototyp-Stadium in Geräusche mit Bedeutung.

Weiterführende Literatur

Wenn du tiefer einsteigen willst als in diese Blog-Behandlung:

• Das Whisper-Paper (Radford et al., 2022) — für das schwach überwachte Audio-Trainingsparadigma, aus dem wir für Schicht 1 geschöpft haben.
• Apple Core ML-Dokumentation — wie Neural-Engine-Deployment in der Praxis aussieht.
• Unsere Begleitnotiz zu Voice trifft Vision: omni-modale Spracheingabe für die Logik hinter Schicht 3.
• Unsere Notiz zu Datenschutz by Design mit Hybrid-Architektur dazu, was die Leitung überquert und was nicht.

Wenn du Fragen zur Architektur hast oder eine dieser Schichten tiefer ausleuchten willst, schreib uns. Wir sind ein kleines Team und lesen jede E-Mail.