Dictée vocale et apprentissage par renforcement : GRPO, DPO et on-policy distillation dans notre voice stack

Pour un produit vocal, les erreurs douloureuses ne sont pas les erreurs moyennes. Ce sont les rares moments où le modèle change le nom d'un package, écrit une réponse Slack guindée, ou attend trop longtemps avant de valider le texte. « Reinforcement learning voice typing » est notre terme générique pour la boucle de post-entraînement qui cible ces moments-là.

Pourquoi la loss supervisée cesse de payer

L'apprentissage supervisé est nécessaire. Il apprend au modèle la tâche : audio en entrée, contexte en entrée, texte en sortie. Mais à terme, la loss continue de s'améliorer sur les exemples faciles tandis que le produit cesse de progresser de façon perceptible. Les problèmes qui restent ont une forme de préférence, pas simplement de label.

Prenons la dictée technique. Une paire supervisée peut apprendre que « react query » désigne parfois @tanstack/react-query. Mais la vraie question produit est conditionnelle : le modèle doit-il préserver la phrase parlée, la réécrire en chemin d'import, ou la laisser en anglais courant parce que le curseur est dans un email client ? La bonne réponse dépend du contexte et de la tolérance de l'utilisateur à la correction.

Un motif concret : notre benchmark interne sur de la parole lue propre s'est amélioré de moins d'un point sur trois itérations supervisées consécutives, alors que le taux d'édition en dogfood sur les workflows réels bougeait de plus de quatre points. Cet écart est la signature d'une défaillance en forme de préférence : le modèle se rapproche techniquement de la transcription de référence mais s'éloigne de ce que l'utilisateur voulait réellement valider dans le document.

C'est là que le RL appliqué à la reconnaissance vocale et au rendu texte devient utile. On peut récompenser les sorties qui préservent les entités, arrivent vite et collent au format de destination, tout en pénalisant les réécritures trop sûres d'elles. La récompense, ce n'est pas « plus malin ». La récompense, c'est « moins d'édition après la dictée ».

GRPO vs DPO vs PPO

On sépare trois familles d'outils de post-entraînement. PPO est flexible et historiquement important, avec une longue filiation depuis les travaux sur les policy gradients comme Proximal Policy Optimization. DPO est intéressant quand on a des données de préférence par paires et qu'on veut un objectif plus simple ; voir le papier Direct Preference Optimization pour la formulation propre.

L'entraînement de type GRPO est utile pour des candidats groupés : on génère plusieurs sorties pour la même énonciation et le même contexte, on les classe avec une fonction de récompense, puis on met à jour vers le meilleur comportement du groupe. Pour Loqua, la comparaison groupée colle à beaucoup d'erreurs vocales. On ne demande pas seulement « cette transcription est-elle correcte ? ». On demande quelle sortie est la meilleure pour l'application courante, le budget de latence, et l'intention d'édition.

Comment on a aligné les méthodes sur les couches

En pratique, chaque couche du stack reçoit un outil de post-entraînement différent. Le text renderer est le terrain naturel pour DPO et l'optimisation groupée parce que ses décisions sont locales et faciles à comparer côte à côte. Le planificateur d'instructions utilise des mises à jour par paires plus légères pour orienter la classification d'intention et la planification de format. Le front end acoustique reste essentiellement à l'écart du RL ; les signaux de préférence sont trop éloignés de l'audio au niveau frame pour être utiles, et on gagne plus avec de la curation de données et du raffinage supervisé à ce niveau. Le choix pratique n'est pas idéologique. On prend la plus petite boucle qui expose clairement le mode de défaillance.

On-policy distillation pour le rendu texte

L'on-policy distillation compte parce que le text renderer doit apprendre depuis les états qu'il visite réellement. La distillation offline classique peut entraîner sur des sorties propres du professeur que l'élève, plus petit, n'atteint jamais à l'inférence. Dans un produit de dictée en streaming, ce décalage se voit : dès que l'élève prend un chemin partiel un peu de travers, les tokens suivants deviennent maladroits.

Notre entraînement du rendu texte s'appuie sur les idées d'on-policy distillation : on laisse l'élève produire des continuations candidates, on les note avec un évaluateur plus fort et une récompense liée à la tâche, puis on entraîne sur la trajectoire de l'élève lui-même plutôt que sur un chemin de référence déconnecté. La littérature récente sur l'on-policy distillation et les travaux apparentés sur la memory-policy optimization fournissent un vocabulaire utile pour ce problème.

Concrètement, une étape d'entraînement ressemble à ça. On prend une vraie énonciation issue du dogfood, avec son contexte d'écran. L'élève produit trois à cinq continuations candidates sous contraintes de streaming. Un évaluateur plus large note chaque candidat sur la préservation des entités, la latence, l'adéquation à la destination et le naturel. L'élève est ensuite mis à jour pour préférer la trajectoire la mieux notée, pondérée par sa distance actuelle au choix de l'évaluateur. L'élève ne voit jamais un chemin de référence offline ; il ne voit que son propre comportement, classé.

La leçon qui nous tient à cœur est simple : entraîne le modèle là où il vivra. Pour la dictée vocale, il vit dans des énonciations partielles, du contexte visible, des identifiants incertains et des éditions utilisateur. Une magnifique transcription offline ne suffit pas.

Reward shaping : latence, précision, naturel

La récompense a quatre composantes. La précision récompense la préservation des entités, un WER bas dans les conditions supportées et la justesse de l'intention d'édition. La latence récompense le texte utile précoce, pas seulement les tokens précoces. Le naturel récompense un texte qui se lit comme l'utilisateur, y compris des réponses Slack concises et une prose technique propre. La sûreté récompense un comportement conservateur quand l'incertitude est élevée.

Le reward shaping d'un système vocal est facile à rater. Si tu surpondères la latence, le modèle s'engage trop tôt. Si tu surpondères le formatage, il transforme des notes décontractées en modèles. Si tu surpondères la préservation des entités, il peut conserver des fragments dictés bruts qui auraient dû être nettoyés. On ajuste les poids de récompense en comparant les éditions réelles en dogfooding avant et après chaque run d'entraînement.

• Récompense de latence : temps jusqu'au premier texte utilisable et temps jusqu'au commit stable.
• Récompense d'entités : noms techniques, chemins de fichiers, commandes et passages multilingues.
• Récompense de destination : forme correcte pour Slack, GitHub, Cursor, VS Code, email ou notes.
• Récompense de correction : moins de retours arrière utilisateur et moins de réécritures manuelles après insertion.

Les paires contrefactuelles sont les données de préférence les plus utiles qu'on collecte. Pour chaque édition acceptée par un utilisateur après dictée, on peut construire une paire où le texte dicté est le candidat rejeté et le texte édité est le candidat préféré. Ces données sont denses, naturellement alignées avec l'usage réel, et exemptes d'artefacts de préférence synthétique. On les traite comme une boucle de feedback lente et à fort signal, pas comme un signal de RL en ligne en temps réel.

À quoi ça ressemble en production

En production, le RL n'apparaît pas comme une fonctionnalité visible. Il se manifeste par moins de moments agaçants. Un message de commit Git prend une forme impérative concise. Un email client garde un ton plus chaleureux. Un commentaire Python préserve l'identifiant exact visible près du curseur. Une énonciation longue commence à streamer rapidement mais retarde les passages d'entités risqués jusqu'à ce que le contexte soit disponible.

Un petit exemple concret : dicter "fix the bug where retry exhausts the queue" dans une fenêtre terminal avec un git diff récent visible produit fix: drain retry queue before exhausting backoff window comme sujet de commit. La même énonciation avec le curseur dans un fil Slack produit "Fixing the bug where retry exhausts the queue — should land this afternoon." Même parole, même locuteur, deux sorties différentes adaptées à la destination. Le planificateur d'instructions a choisi le plan de destination ; le text renderer, post-entraîné avec une récompense de destination, a produit la forme correcte.

On garde aussi un périmètre de post-entraînement étroit. Le recognizer principal, le planificateur d'instructions et le text renderer sont entraînés en interne pour la surface de dictée de Loqua. La recherche publique sur RLHF, DPO, les regroupements à la GRPO et l'on-policy distillation nourrit notre vocabulaire d'évaluation, mais le stack de production est calibré sur nos propres données, contraintes runtime et frontière de confidentialité.

Modes de défaillance et débogage

Le RL rend les mauvaises fonctions de récompense plus visibles. Les modes de défaillance courants sont le biais de verbosité, l'engagement prématuré, la dérive de style et le reward hacking autour de signaux de formatage faciles. On les débogue par ablations : retirer la récompense de latence, geler la récompense d'entités, comparer des candidats sans contexte d'écran, et rejouer de vraies énonciations dogfood à travers les anciens et nouveaux checkpoints.

Notre checklist pré-merge pour un run RL est courte et délibérée. Le taux de correction a-t-il baissé sur les vraies données de dogfood, pas seulement sur un set de préférences mis de côté ? Le p95 du temps jusqu'au premier texte utilisable est-il resté dans le budget ? La préservation des entités a-t-elle tenu ou progressé sur les tranches anglais, chinois et identifiants de code ? Le text renderer a-t-il cessé d'ajouter des puces non sollicitées ou de la politesse en fin de phrase ? Si l'une de ces réponses est « non », le checkpoint repart en tuning au lieu d'être expédié.

La discipline la plus importante, c'est de préserver une taxonomie d'erreurs lisible par un humain. Une mauvaise sortie devrait être étiquetée comme une défaillance d'écoute, d'entité, d'intention, de destination, de ton, de latence ou de frontière de confidentialité. Sans cette taxonomie, le reinforcement learning voice typing devient un tas de chiffres qui peuvent s'améliorer pendant que le produit se dégrade au ressenti.