Omni-modale Spracheingabe: multimodales Verständnis, MoE und streamende Textausgabe

Ich bin Shuran, Founder von Loqua.ai. Das ist die tiefere Engineering-Notiz hinter unserem omni-modalen Spracheingabe-Stack: warum wir akustische Erkennung von multimodalem Aufgabenverständnis und Text-Rendering trennen, wo bedingte Experten geholfen haben, wo nicht, und warum Streaming fast jede Architekturentscheidung diktiert hat.

Warum monolithische Audio-LMs am Mac an eine Wand stoßen

Ein monolithisches Audio-Sprachmodell ist auf dem Papier reizvoll: Audio, Bildschirmframes und Text in ein großes Modell füttern und es das fertige Diktat ausgeben lassen. Im täglichen Mac-Einsatz stößt dieses Design gleich an drei Wände. Erstens ist das Latenzbudget brutal. Wenn das erste nutzbare Token erst nach der Sprechpause ankommt, fühlt sich Spracheingabe eher wie Batch-Transkription an als wie Tippen.

Hier ist das Budget, an das wir uns halten. Vom Mikrofon bis zum ersten sichtbaren Zeichen haben wir etwa 200 Millisekunden. Davon sind rund 40ms Plattform-Overhead (Core-Audio-Buffering, Interprozess-Zustellung und finales Rendering), 60ms akustische Merkmalsextraktion und Frontend-Inferenz, 70ms Decodierung im Instruction Planner für das erste Partial, und 30ms bleiben dem Text-Renderer für ein sicheres frühes Commit. Ein einzelnes Audio-LM mit über 1 Mrd. Parametern, das in diesem Fenster jeden Schritt ausführt, ist auf einer Benchmark-Maschine plausibel, aber auf einem echten Laptop mit Browser, IDE und Zoom im Hintergrund unzuverlässig.

Zweitens ist die für Nutzer sichtbare Aufgabe nicht nur automatische Spracherkennung. Dieselbe Äußerung muss zu einem Slack-Absatz, einer Git-Commit-Zeile, einem Cursor-Prompt oder einem Python-Kommentar werden. Ein monolithisches Modell kann darauf trainiert werden, aber es muss die Formatkonventionen jeder App neu lernen und sie jedes Mal neu herleiten, wenn sich der Cursor bewegt. Drittens muss das Modell innerhalb des thermischen und Speicher-Budgets eines Laptops bleiben. Ein 7B-Audio-Vision-Text-Modell, das neben einem IDE-Index in den VRAM geladen wird, ist ein Rezept für thermisches Drosseln und einen lauten Lüfter. Öffentliche Arbeiten wie Whisper und jüngere Omni-Modell-Berichte haben dem Feld geholfen, robuste Audio- und multimodale Modellierung zu verstehen, aber ein lokales Produkt auszuliefern erzwingt engere, meinungsstärkere Entscheidungen.

Unsere Schlussfolgerung war einfach: Omni-modale Spracheingabe sollte eine Pipeline sein, kein einzelner Allzweckblock. Die Pipeline lässt jede Schicht ein kleines Ziel, einen messbaren Fehlermodus und begrenzte Laufzeitkosten behalten.

Die multimodale Instruktions-Pipeline

Loqua hat in diesem Produktpfad keine Sprachantwort- oder TTS-Schicht. Der Instruction Planner verarbeitet streamende Audiomerkmale, ausgewählten Bildschirmkontext, Metadaten der aktiven App, den jüngsten Text rund um den Cursor und den aktiven Instruction Prompt. Er erzeugt einen kompakten Textausgabe-Plan: Intent, Entitäten, Bearbeitungsmodus, Zielformat und Unsicherheit.

Der Text-Renderer wandelt diesen Plan in Text um. Er erzeugt kein Audio, keine gesprochenen Antworten und keine TTS-Ausgabe. Er entscheidet, ob aus dem Plan eine Markdown-Checkliste, ein Satz, ein Code-Kommentar oder eine strukturierte Anweisung wird. Diese Trennung hält teures cross-modales Reasoning aus dem Hot Path heraus, wenn der Nutzer einfach Prosa diktiert.

Was jede Schicht nicht tun darf

Die Disziplin liegt in dem, was wir entfernt haben. Das akustische Frontend versucht nicht, schlau über das Zielformat zu sein; es liefert Audio-Tokens mit Timing und Konfidenz. Der Instruction Planner schreibt keine finale Prosa; er erstellt einen strukturierten Plan, der klein genug ist, um günstig revidiert zu werden. Der Text-Renderer liest das Audio nicht erneut und synthetisiert keine Sprache; er vertraut dem Plan, dem Zielkontext und dem Instruction Prompt. Eine Schicht über diese Grenzen hinweg arbeiten zu lassen, war in unseren frühen Prototypen die häufigste Einzelursache von Latenzregressionen, weil schichtenübergreifende Feedback-Schleifen Streaming in Batch-Verarbeitung verwandeln, ohne dass es jemand bemerkt, bis das Trace gelesen wird.

Der Vorteil ist Debuggbarkeit. Wenn die Ausgabe falsch ist, können wir sagen, ob der Recognizer das falsche Wort gehört hat, der Instruction Planner den falschen Intent gewählt hat oder der Text-Renderer im falschen Register geschrieben hat. Das ist viel einfacher, als eine lange verborgene Trajektorie zu interpretieren. In unserer internen Triage ließen sich etwa zwei Drittel der Qualitätsfixes nach Launch sauber auf eine einzige Schicht eingrenzen; der Rest erforderte schichtenübergreifende Änderungen, aber erst nach klarer Diagnose.

MoE auf dem Audio-Encoder

Der Audio-Encoder ist der Punkt, an dem bedingte Berechnung sich ausgezahlt hat. Nicht jede Äußerung braucht die gleiche akustische Behandlung. Leise Sprache, akzentuiertes Englisch, gemischtes Englisch und Chinesisch, Code-Bezeichner und Hintergrundgeräusche aus Meeting-Räumen belasten unterschiedliche Teile des Modells. Ein kleiner Mixture-of-Experts-Router lässt den Encoder mehr Kapazität auf schwierige Regionen verwenden, ohne jeden Frame teuer zu machen.

Wir haben das Routing konservativ gehalten. Der Router wird auf akustische Statistiken und flache lexikalische Hinweise konditioniert, nicht auf persönliche Nutzerprofile. Experten spezialisieren sich auf Muster wie leise Sprache, schnelles technisches Diktat und Code-Switching. Wir haben einen größeren Expert-Pool verworfen, weil Routing-Instabilität das Streaming-Verhalten verschlechterte: Ein Modell, das genau ist, aber mitten in der Äußerung den Stil wechselt, ist zum Tippen nicht brauchbar.

Was wir versucht und verworfen haben

Zwei Ideen sahen in der Forschung attraktiv aus und scheiterten im Produkt. Erstens, Per-User-Expert-Adaption: Training eines kleinen Adapters pro Vielnutzer. Es verbesserte die Cold-Start-Genauigkeit auf unserem internen Testset um wenige Punkte, verdoppelte aber den Speicherbedarf beim Cold-Launch und verwischte Datenschutzgrenzen. Zweitens ein Router, der den aktiven App-Bezeichner als starkes Signal nahm. Er überfittete auf eine Handvoll gängiger Apps und degradierte in neuen still. Wir haben ihn durch den aktuellen akustisch-lexikalischen Router ersetzt und app-bewusstes Verhalten hinauf zum Instruction Planner und Text-Renderer verlagert, wo es hingehört.

Praktisch hilft Audio-Encoder-MoE Loqua, den gemeinsamen Pfad schnell zu halten und das Tail weniger fragil zu machen. Das ist der Produktwert: kein Benchmark-Trick, sondern weniger Momente, in denen ein Bibliotheksname, eine leise Phrase oder ein zweisprachiges Fragment den Fluss bricht.

Streaming: Token für Token vs. Phrase für Phrase

Streaming war der härteste Tradeoff. Token-für-Token-Ausgabe wirkt reaktionsschnell, kann aber verfrühte Vermutungen offenlegen. Phrase-für-Phrase-Ausgabe ist sauberer, wirkt aber spät. Wir verwenden einen Hybrid: frühe Partials für risikoarme Spans, verzögerte Commits für Entitäten und Bearbeitungen, die Bildschirmkontext brauchen.

Wenn du zum Beispiel sagst „change the fetch profile function to return early if the auth client is missing", kann das System gewöhnliche Wörter schnell streamen. Aber die Tokens rund um fetchProfile und authClient warten darauf, dass die Kontextschicht sichtbare Bezeichner bestätigt. Deshalb ist Text-Rendering von Erkennung getrennt: Es kann einen kleinen Span vor dem Committen revidieren, ohne die ganze Äußerung neu zu starten.

Zweisprachige Eingabe mitten im Satz ist ein verwandter Fall. Wenn du sagst „把这个 retry 函数改成指数退避", erzeugt der Instruction Planner einen Textausgabe-Plan, der chinesische Spans mit einem englischen Code-Token verschachtelt. Der Text-Renderer gibt die chinesischen Zeichen aus, sobald sie eine interne Konfidenzschwelle überschreiten, und wartet ein paar zusätzliche Millisekunden auf den englischen Bezeichner, um ihn gegen den sichtbaren IDE-Puffer zu bestätigen. Der Nutzer sieht zuerst den chinesischen Fluss, dann den Bezeichner, dann den Rest. Die Ausgabe umzuordnen wäre schneller gewesen, fühlte sich aber falsch an; das Auge erwartet Tippen von links nach rechts.

Commit-Grenzen sind das andere Stellrad. Eine Commit-Grenze ist der Moment, in dem der Text-Renderer verspricht, nicht mehr zu revidieren. Wir setzen sie an natürliche Pausen, Satzendezeichen und strukturelle Übergänge wie Absatz, Listenelement oder Codeblock. Innerhalb einer Commit-Grenze kann der Text-Renderer frei revidieren; einmal committet, ist der Text aus Sicht des Nutzers endgültig. Dieser Vertrag lässt Streaming ehrlich wirken statt zappelig.

Das Ergebnis ist ein streamender Voice-Stack, der sich unmittelbar anfühlt, aber nicht jede frühe akustische Vermutung als final behandelt. Für Spracheingabe zählt dieser Kompromiss mehr als rohe Transkriptgeschwindigkeit.

Kontext aus offener Forschung

Wir verfolgen offene Forschung genau, weil sie unser Vokabular für die Probleme schärft, die wir im Produkt sehen. Veröffentlichungen und Berichte zu Audio-Sprachmodellen, multimodalen Encodern und Präferenzoptimierung zeigen, dass das Feld sich auf geteilte Verantwortlichkeiten, Streaming-Anforderungen und cross-modale Ausrichtung zubewegt. Als Hintergrund beginne mit Whisper, dem technischen Bericht zu Qwen2 und der öffentlichen Qwen2.5-Omni-Übersicht.

Die wichtige Produktgrenze: Diese Referenzen sind Literaturkontext. Loquas Produktions-Stack ist eigene Forschung, intern für Mac-Diktat trainiert und optimiert. Wir zitieren offene Arbeiten, um das Feld zu erklären, nicht um Herkunft zu suggerieren.

Was wir gebaut haben und was als Nächstes kommt

Was aus dieser Richtung ausgeliefert wurde, ist ein eng umrissenes System: Mac-Spracheingabe, die zuhört, lokalen Bildschirmkontext liest und app-bewussten Text schreibt. Die nächste Arbeit ist rigorosere Evaluation. Wir brauchen eine öffentliche Methodologie für Latenz, technische NER, mehrsprachige WER und Bildschirmkontext-Disambiguierung, damit die Aussagen auch außerhalb unserer Dogfooding-Schleife überprüfbar sind.

Die zweite Richtung ist bessere Kalibrierung. Wenn das Modell bei einem sichtbaren Bezeichner unsicher ist, sollte es weniger vom Nutzer verlangen, indem es eine sichere Ausgabeform wählt oder die Rohphrase bewahrt. Wir erkunden außerdem leichtgewichtige Unsicherheitsmarker im Text-Renderer, sodass nachgelagerte UI Spans mit niedriger Konfidenz für eine schnelle Tastatur-Korrektur hervorheben kann, ohne den Diktatrhythmus zu brechen.

Die dritte Richtung ist nicht-wörtliches Audio. Diese Arbeit ist noch im Prototypenstadium, und wir behandeln sie separat in Geräusche mit Bedeutung. Zusammen mit unserer Arbeit zu Reinforcement Learning und dem multimodalen Listener bildet sie die Agenda für das nächste Jahr unseres omni-modalen Spracheingabe-Stacks.