Reinforcement Learning für Spracheingabe: GRPO, DPO und On-Policy-Distillation in unserem Voice-Stack

Bei einem Voice-Produkt sind die schmerzhaften Fehler nicht die durchschnittlichen. Es sind die wenigen Momente, in denen das Modell einen Paketnamen ändert, eine steife Slack-Antwort schreibt oder zu lange wartet, bevor es Text committet. Reinforcement Learning für Spracheingabe ist unser Sammelbegriff für die Post-Training-Schleife, die genau auf diese Momente zielt.

Warum überwachter Loss nicht mehr zahlt

Überwachtes Lernen ist nötig. Es lehrt das Modell die Aufgabe: Audio rein, Kontext rein, Text raus. Aber irgendwann verbessert sich der Loss weiter auf einfachen Beispielen, während das Produkt merklich stagniert. Die verbleibenden Probleme sind präferenzförmig, nicht einfach label-förmig.

Nehmen wir technisches Diktat. Ein überwachtes Paar kann lehren, dass „react query" manchmal @tanstack/react-query bedeutet. Die Produktfrage ist aber bedingt: Soll das Modell die gesprochene Phrase erhalten, sie als Import-Pfad umschreiben oder sie als reines Englisch belassen, weil der Cursor in einer Kunden-E-Mail steht? Die richtige Antwort hängt von Kontext und Korrekturtoleranz des Nutzers ab.

Ein konkretes Muster: Unser interner Benchmark für sauberes Vorlesesprechen verbesserte sich über drei aufeinanderfolgende überwachte Iterationen um weniger als einen Prozentpunkt, während die Dogfood-Korrekturrate auf realen Workflows um mehr als vier Punkte schwankte. Diese Lücke ist die Signatur präferenzförmiger Fehler: Das Modell ist technisch näher am Gold-Transkript, aber weniger ausgerichtet auf das, was der Nutzer tatsächlich ins Dokument committen wollte.

Genau hier wird RL für Spracherkennung und Text-Rendering nützlich. Wir können Ausgaben belohnen, die Entitäten erhalten, schnell ankommen und das Zielformat treffen, und gleichzeitig zu selbstbewusste Umschreibungen bestrafen. Der Reward ist nicht „cleverer". Der Reward ist „weniger Nachbearbeitung nach dem Diktat".

GRPO vs. DPO vs. PPO

Wir trennen drei Familien von Post-Training-Werkzeugen. PPO ist flexibel und historisch wichtig, mit einer langen Linie aus Policy-Gradient-Arbeiten wie Proximal Policy Optimization. DPO ist attraktiv, wenn paarweise Präferenzdaten und ein einfacheres Ziel vorliegen; siehe das Direct Preference Optimization-Paper für die saubere Formulierung.

Training im GRPO-Stil ist nützlich für gruppierte Kandidaten: mehrere Ausgaben für dieselbe Äußerung und denselben Kontext erzeugen, sie mit einer Reward-Funktion rangieren und dann in Richtung des besseren Gruppenverhaltens aktualisieren. Für Loqua passt gruppierter Vergleich zu vielen Voice-Fehlern. Wir fragen nicht nur „ist dieses Transkript korrekt?". Wir fragen, welche Ausgabe am besten zur aktuellen App, zum Latenzbudget und zur Editierabsicht passt.

Wie wir Methoden den Schichten zugeordnet haben

In der Praxis bekommt jede Schicht des Stacks ein anderes Post-Training-Werkzeug. Der Text-Renderer ist die natürliche Heimat für DPO und gruppierte Optimierung, weil seine Entscheidungen lokal und leicht nebeneinander vergleichbar sind. Der Instruction Planner nutzt leichtere paarweise Updates, um Intent-Klassifikation und Format-Planung zu justieren. Das akustische Front-End bleibt überwiegend außerhalb von RL; Präferenzsignale sind für Audio auf Frame-Ebene zu weit weg, und wir gewinnen mehr aus Datenkuration und überwachter Verfeinerung. Die praktische Wahl ist nicht ideologisch. Wir wählen die kleinste Schleife, die den Failure-Mode klar zeigt.

On-Policy-Distillation für Text-Rendering

On-Policy-Distillation ist wichtig, weil der Text-Renderer aus Zuständen lernen muss, die er tatsächlich besucht. Klassische Offline-Distillation kann auf sauberen Teacher-Ausgaben trainieren, die der kleinere Student zur Inferenzzeit nie erreicht. In einem streamenden Diktatprodukt ist diese Diskrepanz sichtbar: Sobald der Student einen leicht falschen Teilpfad nimmt, werden spätere Tokens unbeholfen.

Unser Text-Rendering-Training nutzt Ideen der On-Policy-Distillation: Der Student erzeugt Kandidatenfortsetzungen, ein stärkerer Evaluator und der Task-Reward bewerten diese Fortsetzungen, dann wird auf der eigenen Trajektorie des Students trainiert statt auf einem losgelösten Gold-Pfad. Aktuelle Literatur zu On-Policy-Distillation und verwandter Memory-Policy-Optimierung liefert hierfür nützliche Begriffe.

Konkret sieht ein Trainingsschritt so aus. Wir nehmen eine reale Dogfood-Äußerung und Bildschirmkontext. Der Student erzeugt drei bis fünf Kandidatenfortsetzungen unter Streaming-Bedingungen. Ein größerer Evaluator bewertet jeden Kandidaten nach Entitätserhalt, Latenz, Ziel-Passung und Natürlichkeit. Der Student wird dann aktualisiert, die höher bewertete Trajektorie zu bevorzugen, gewichtet danach, wie weit er aktuell von der Wahl des Evaluators entfernt ist. Der Student sieht nie einen Offline-Gold-Pfad; er sieht ausschließlich sein eigenes Verhalten, rangiert.

Die Lektion, die uns wichtig ist, ist einfach: Trainiere das Modell dort, wo es leben wird. Für Spracheingabe lebt es in Teiläußerungen, sichtbarem Kontext, unsicheren Bezeichnern und Nutzerkorrekturen. Ein schönes Offline-Transkript reicht nicht.

Reward Shaping: Latenz, Genauigkeit, Natürlichkeit

Der Reward hat vier Teile. Genauigkeit belohnt Entitätserhalt, niedrige WER unter unterstützten Bedingungen und korrekte Editierabsicht. Latenz belohnt früh nutzbaren Text, nicht nur frühe Tokens. Natürlichkeit belohnt Text, der wie der Nutzer klingt, einschließlich knapper Slack-Antworten und sauberer technischer Prosa. Safety belohnt konservatives Verhalten bei hoher Unsicherheit.

Reward Shaping in Voice-Systemen ist leicht falsch zu machen. Übergewichtest du Latenz, committet das Modell zu früh. Übergewichtest du Formatierung, macht es aus lockeren Notizen Vorlagen. Übergewichtest du Entitätserhalt, behält es vielleicht rohe diktierte Fragmente, die bereinigt gehört hätten. Wir justieren Reward-Gewichte, indem wir reale Dogfooding-Korrekturen vor und nach jedem Trainingslauf vergleichen.

• Latenz-Reward: Zeit bis zum ersten nutzbaren Text und Zeit bis zum stabilen Commit.
• Entitäts-Reward: technische Namen, Dateipfade, Befehle und gemischtsprachige Spans.
• Ziel-Reward: korrekte Form für Slack, GitHub, Cursor, VS Code, E-Mail oder Notizen.
• Korrektur-Reward: weniger Backspaces und weniger manuelle Umschreibungen nach dem Einfügen.

Kontrafaktische Paare sind die nützlichsten Präferenzdaten, die wir sammeln. Für jede akzeptierte Korrektur, die ein Nutzer nach dem Diktat vornimmt, können wir ein Paar konstruieren, bei dem der diktierte Text der abgelehnte Kandidat und der bearbeitete Text der bevorzugte ist. Diese Daten sind dicht, natürlich an reale Nutzung angepasst und frei von Synthetik-Artefakten. Wir behandeln sie als langsame, signalstarke Feedback-Schleife, nicht als Echtzeit-Online-RL-Signal.

Wie es in der Produktion aussieht

In der Produktion erscheint RL nicht als sichtbares Feature. Es zeigt sich als weniger nervige Momente. Eine Git-Commit-Nachricht bekommt eine knappe, imperativische Form. Eine Kunden-E-Mail behält einen wärmeren Ton. Ein Python-Kommentar erhält genau den Bezeichner, der nahe am Cursor sichtbar ist. Eine lange Äußerung beginnt schnell zu streamen, verzögert aber riskante Entitäts-Spans, bis Kontext verfügbar ist.

Ein kleines konkretes Beispiel: Diktiert man „fix the bug where retry exhausts the queue" in einem Terminalfenster mit sichtbarem git diff, ergibt sich fix: drain retry queue before exhausting backoff window als Commit-Betreff. Dieselbe Äußerung mit dem Cursor in einem Slack-Thread ergibt „Fixing the bug where retry exhausts the queue — should land this afternoon." Gleiche Sprache, gleicher Sprecher, zwei verschiedene ziel-angemessene Ausgaben. Der Instruction Planner wählte den Zielplan; der Text-Renderer, post-trainiert mit Ziel-Reward, erzeugte die richtige Form.

Wir halten die Post-Training-Grenze außerdem eng. Der Kern-Recognizer, der Instruction Planner und der Text-Renderer werden in-house für Loquas Diktat-Oberfläche trainiert. Öffentliche Forschung zu RLHF, DPO, GRPO-artiger Gruppierung und On-Policy-Distillation prägt unser Evaluationsvokabular, aber der Produktions-Stack ist gegen unsere eigenen Daten, Laufzeitbeschränkungen und Datenschutzgrenze getuned.

Failure-Modes und Debugging

RL macht schlechte Reward-Funktionen sichtbarer. Häufige Failure-Modes sind Verbosity-Bias, vorzeitiges Committen, Stil-Drift und Reward-Hacking um leichte Formatierungshinweise herum. Wir debuggen sie mit Ablationen: Latenz-Reward entfernen, Entitäts-Reward einfrieren, Kandidaten ohne Bildschirmkontext vergleichen und reale Dogfooding-Äußerungen durch alte und neue Checkpoints abspielen.

Unsere Pre-Merge-Checkliste für einen RL-Lauf ist kurz und gezielt. Ist die Korrekturrate auf realen Dogfood-Daten gesunken, nicht nur auf einem ausgehaltenen Präferenz-Set? Blieb p95-Zeit bis zum ersten nutzbaren Text im Budget? Hielt oder verbesserte sich Entitätserhalt über EN-, ZH- und Code-Bezeichner-Slices? Hörte der Text-Renderer auf, unaufgeforderte Aufzählungspunkte oder nachgestellte Höflichkeiten hinzuzufügen? Lautet eine dieser Antworten nein, geht der Checkpoint zurück ins Tuning statt ins Release.

Die wichtigste Disziplin ist, eine menschlich lesbare Fehler-Taxonomie zu bewahren. Eine schlechte Ausgabe sollte als Hör-, Entitäts-, Intent-, Ziel-, Ton-, Latenz- oder Datenschutz-Grenz-Fehler etikettiert werden. Ohne diese Taxonomie wird Reinforcement Learning für Spracheingabe zu einem Haufen Zahlen, der sich verbessern kann, während sich das Produkt schlechter anfühlt.