Reinforcement learning per digitazione vocale: GRPO, DPO e distillazione on-policy nel nostro stack voce

Per un prodotto vocale, gli errori dolorosi non sono gli errori medi. Sono quei pochi momenti in cui il modello cambia il nome di un package, scrive una risposta Slack rigida o aspetta troppo prima di committare testo. Reinforcement learning voice typing e il nostro termine ombrello per il loop di post-training che mira a quei momenti.

Perche la loss supervisionata smette di rendere

Il supervised learning e necessario. Insegna al modello il task: audio in input, contesto in input, testo in output. Ma a un certo punto la loss continua a migliorare sugli esempi facili mentre il prodotto smette di migliorare in modo percepibile. I problemi rimasti sono plasmati dalle preferenze, non solo dalle label.

Considera la dettatura tecnica. Una coppia supervisionata può insegnare che "react query" a volte significa @tanstack/react-query. Ma la domanda di prodotto e condizionale: il modello deve preservare la frase pronunciata, riscriverla come import path o lasciarla in inglese naturale perché il cursore e in una email a un cliente? La risposta giusta dipende dal contesto e dalla tolleranza dell'utente verso la correzione.

Un pattern concreto: il nostro benchmark interno per parlato pulito letto ad alta voce e migliorato di meno di un punto percentuale in tre iterazioni supervisionate consecutive, mentre il tasso di edit dogfood sui workflow reali e cambiato di oltre quattro punti. Quel divario e la firma di un failure shaped by preference: il modello e tecnicamente più vicino alla trascrizione gold, ma meno allineato a ciò che l'utente voleva davvero committare nel documento.

E qui che RL per riconoscimento vocale e rendering testuale diventa utile. Possiamo premiare output che preservano entita, arrivano rapidamente e corrispondono al formato di destinazione, penalizzando riscritture troppo sicure. Il reward non è "essere più intelligente". Il reward e "meno editing dopo la dettatura".

GRPO vs DPO vs PPO

Separiamo tre famiglie di strumenti di post-training. PPO e flessibile e storicamente importante, con una lunga linea che parte da lavori policy-gradient come Proximal Policy Optimization. DPO e interessante quando hai dati di preferenza pairwise e vuoi un obiettivo più semplice; vedi il paper Direct Preference Optimization per la formulazione pulita.

Il training in stile GRPO e utile per candidati raggruppati: genera più output per lo stesso enunciato e contesto, ordinali con una funzione reward, poi aggiorna verso il comportamento migliore del gruppo. Per Loqua, il confronto raggruppato si adatta a molti errori vocali. Non chiediamo solo "questa trascrizione e corretta?". Chiediamo quale output e migliore per l'app corrente, il budget di latenza e l'intento di modifica.

Come abbiamo abbinato i metodi ai livelli

In pratica ogni livello dello stack riceve uno strumento di post-training diverso. Il renderer testuale e la casa naturale di DPO e ottimizzazione raggruppata perché le sue decisioni sono locali e facili da confrontare fianco a fianco. L'instruction planner usa aggiornamenti pairwise più leggeri per spingere classificazione dell'intento e pianificazione del formato. Il front end acustico resta quasi fuori dall'RL; i segnali di preferenza sono troppo lontani dall'audio frame-level per essere utili, e ricaviamo di più da data curation e rifinitura supervisionata. La scelta pratica non è ideologica. Scegliamo il loop più piccolo che espone chiaramente il failure mode.

Distillazione on-policy per il rendering testuale

La distillazione on-policy conta perché il renderer testuale deve imparare dagli stati che visita davvero. La distillazione offline tradizionale può addestrare su output puliti del teacher che lo student più piccolo non raggiunge mai in inferenza. In un prodotto di dettatura streaming, quel mismatch si vede: quando lo student prende un percorso parziale leggermente sbagliato, i token successivi diventano impacciati.

Il nostro training del text rendering usa idee di distillazione on-policy: lasciare che lo student produca continuazioni candidate, valutare quelle continuazioni con un evaluator più forte e un reward di task, poi addestrare sulla traiettoria dello student stesso invece che su un percorso gold disconnesso. La letteratura recente su on-policy distillation e su lavori correlati di memory-policy optimization offre un linguaggio utile per questo problema.

Concretamente, uno step di training e così. Prendiamo un enunciato dogfood reale e il contesto dello schermo. Lo student produce da tre a cinque continuazioni candidate sotto vincoli streaming. Un evaluator più grande assegna un punteggio a ogni candidato su preservazione delle entita, latenza, fit con la destinazione e naturalezza. Lo student viene poi aggiornato per preferire la traiettoria con punteggio più alto, pesata in base a quanto e lontano attualmente dalla scelta dell'evaluator. Lo student non vede mai un percorso gold offline; vede solo il proprio comportamento, classificato.

La lezione che ci interessa e semplice: addestra il modello dove vivra. Per la digitazione vocale, vive in enunciati parziali, contesto visibile, identificatori incerti e modifiche utente. Una bellissima trascrizione offline non basta.

Reward shaping: latenza, accuratezza, naturalezza

Il reward ha quattro parti. L'accuratezza premia preservazione delle entita, basso WER nelle condizioni supportate e intento di edit corretto. La latenza premia testo utile precoce, non solo token precoci. La naturalezza premia testo che suona come l'utente, incluse risposte Slack concise e prosa tecnica pulita. La safety premia comportamento conservativo quando l'incertezza e alta.

Fare reward shaping nei sistemi voce e facile da sbagliare. Se sovrappesi la latenza, il modello committa troppo presto. Se sovrappesi la formattazione, trasforma note casuali in template. Se sovrappesi la preservazione delle entita, può mantenere frammenti dettati grezzi che andrebbero ripuliti. Taramo i pesi del reward confrontando gli edit reali di dogfooding prima e dopo ogni training run.

• Reward latenza: tempo al primo testo utilizzabile e tempo al commit stabile.
• Reward entita: nomi tecnici, file path, comandi e span mistilingue.
• Reward destinazione: forma corretta per Slack, GitHub, Cursor, VS Code, email o note.
• Reward correzione: meno backspace utente e meno riscritture manuali dopo l'inserimento.

Le coppie controfattuali sono i dati di preferenza più utili che raccogliamo. Per ogni edit accettato che un utente fa dopo la dettatura, possiamo costruire una coppia in cui il testo dettato e il candidato respinto e il testo editato e quello preferito. Quel dato e denso, naturalmente allineato all'uso reale e privo di artefatti da preferenza sintetica. Lo trattiamo come un loop di feedback lento e ad alto segnale, non come un segnale RL online in tempo reale.

Come appare in produzione

In produzione, RL non appare come funzione visibile. Si manifesta come meno momenti irritanti. Un messaggio di commit Git prende una forma imperativa concisa. Una email a un cliente mantiene un tono più caldo. Un commento Python preserva l'identificatore esatto visibile vicino al cursore. Un enunciato lungo inizia a fare streaming rapidamente ma ritarda gli span di entita rischiosi finche il contesto non è disponibile.

Un piccolo esempio concreto: dettare "fix the bug where retry exhausts the queue" in una finestra terminale con un git diff recente visibile produce fix: drain retry queue before exhausting backoff window come subject del commit. Lo stesso enunciato con il cursore in un thread Slack produce "Fixing the bug where retry exhausts the queue — should land this afternoon." Stesso parlato, stesso speaker, due output diversi e adatti alla destinazione. L'instruction planner ha scelto il piano di destinazione; il renderer testuale, post-addestrato con reward di destinazione, ha prodotto la forma giusta.

Manteniamo anche stretto il confine del post-training. Il recognizer core, l'instruction planner e il renderer testuale sono addestrati in-house per la superficie di dettatura di Loqua. La ricerca pubblica su RLHF, DPO, grouping simile a GRPO e distillazione on-policy informa il nostro vocabolario di valutazione, ma lo stack di produzione e tarato sui nostri dati, vincoli runtime e confine privacy.

Failure mode e debugging

RL rende più evidenti le cattive funzioni reward. I failure mode comuni sono bias verso la verbosita, commit prematuro, deriva di stile e reward hacking intorno a cue di formattazione facili. Li debugghiamo con ablation: rimuovere il reward di latenza, congelare il reward entita, confrontare candidati senza contesto schermo e rieseguire enunciati reali di dogfooding su checkpoint vecchi e nuovi.

La nostra checklist pre-merge per un run RL e breve e deliberata. Il correction rate e sceso sui dati dogfood reali, non solo su un preference set held-out? Il p95 del tempo al primo testo utilizzabile e rimasto dentro il budget? La preservazione delle entita ha tenuto o migliorato su slice inglese, cinese e identificatori di codice? Il renderer testuale ha smesso di aggiungere bullet point non richiesti o cortesie finali? Se una risposta e no, il checkpoint torna al tuning invece di essere rilasciato.

La disciplina più importante e preservare una tassonomia di errore leggibile dagli esseri umani. Un output sbagliato dovrebbe essere etichettato come errore di ascolto, entita, intento, destinazione, tono, latenza o confine privacy. Senza quella tassonomia, il reinforcement learning per digitazione vocale diventa un mucchio di numeri che possono migliorare mentre il prodotto peggiora.