Reinforcement learning em digitação por voz: GRPO, DPO e destilação on-policy na nossa stack de voz

Para um produto de voz, os erros dolorosos não são os erros médios. São os poucos momentos em que o modelo muda o nome de um pacote, escreve uma resposta rígida no Slack ou demora demais para confirmar o texto. Reinforcement learning em digitação por voz é nosso termo guarda-chuva para o loop de pós-treinamento que mira esses momentos.

Por que a loss supervisionada deixa de compensar

Aprendizado supervisionado é necessário. Ele ensina a tarefa ao modelo: áudio entra, contexto entra, texto sai. Mas em algum ponto a loss continua melhorando em exemplos fáceis enquanto o produto para de ficar perceptivelmente melhor. Os problemas restantes têm formato de preferência, não apenas de rótulo.

Considere ditado técnico. Um par supervisionado pode ensinar que "react query" às vezes significa @tanstack/react-query. Mas a pergunta de produto é condicional: o modelo deve preservar a frase falada, reescrevê-la como um import path ou deixá-la como inglês comum porque o cursor está em um email para cliente? A resposta certa depende do contexto e da tolerância do usuário à correção.

Um padrão concreto: nosso benchmark interno para fala limpa lida em voz alta melhorou menos de um ponto percentual em três iterações supervisionadas consecutivas, enquanto a taxa de edição em dogfood em fluxos reais mudou mais de quatro pontos. Essa lacuna é a assinatura de uma falha com formato de preferência: o modelo está tecnicamente mais perto da transcrição gold, mas menos alinhado com o que o usuário realmente queria confirmar no documento.

É aí que rl para reconhecimento de fala e renderização de texto fica útil. Podemos recompensar saídas que preservam entidades, chegam rápido e combinam com o formato de destino, ao mesmo tempo em que penalizamos reescritas confiantes demais. A recompensa não é "mais esperto". A recompensa é "menos edição depois do ditado".

GRPO vs DPO vs PPO

Separamos três famílias de ferramentas de pós-treinamento. PPO é flexível e historicamente importante, com uma linhagem longa a partir de trabalhos de policy gradient como Proximal Policy Optimization. DPO é atraente quando você tem dados de preferência em pares e quer um objetivo mais simples; veja o paper Direct Preference Optimization para a formulação limpa.

Treinamento no estilo GRPO é útil para candidatos agrupados: gerar várias saídas para a mesma fala e contexto, ranqueá-las com uma função de recompensa e então atualizar em direção ao melhor comportamento do grupo. Para o Loqua, comparação agrupada combina com muitos erros de voz. Não perguntamos apenas "esta transcrição está correta?". Perguntamos qual saída é melhor para o app atual, o orçamento de latência e a intenção de edição.

Como combinamos métodos com camadas

Na prática, cada camada da stack recebe uma ferramenta de pós-treinamento diferente. O renderizador de texto é o lugar natural para DPO e otimização agrupada porque suas decisões são locais e fáceis de comparar lado a lado. O planejador de instruções usa atualizações pareadas mais leves para ajustar classificação de intenção e planejamento de formato. O front-end acústico fica em grande parte fora de RL; sinais de preferência estão distantes demais do áudio em nível de frames para serem úteis, e ganhamos mais com curadoria de dados e refinamento supervisionado ali. A escolha prática não é ideológica. Escolhemos o menor loop que expõe claramente o modo de falha.

Destilação on-policy para renderização de texto

Destilação on-policy importa porque o renderizador de texto precisa aprender com estados que ele realmente visita. Destilação offline tradicional pode treinar com saídas limpas de professor que o estudante menor nunca alcança em inferência. Em um produto de ditado em streaming, esse desencontro fica visível: assim que o estudante toma um caminho parcial ligeiramente errado, tokens posteriores ficam estranhos.

Nosso treinamento de renderização de texto usa ideias de destilação on-policy: deixe o estudante produzir continuações candidatas, pontue essas continuações com um avaliador mais forte e uma recompensa da tarefa, então treine na própria trajetória do estudante em vez de um caminho gold desconectado. Literatura recente sobre destilação on-policy e trabalhos relacionados de otimização de política de memória oferece uma linguagem útil para esse problema.

Concretamente, um passo de treinamento se parece com isto. Pegamos uma fala real de dogfood e o contexto de tela. O estudante produz de três a cinco continuações candidatas sob restrições de streaming. Um avaliador maior pontua cada candidato em preservação de entidades, latência, ajuste ao destino e naturalidade. O estudante é então atualizado para preferir a trajetória de maior pontuação, ponderada pela distância atual em relação à escolha do avaliador. O estudante nunca vê um caminho gold offline; ele só vê seu próprio comportamento, ranqueado.

A lição que nos interessa é simples: treine o modelo onde ele vai viver. Para digitação por voz, ele vive em falas parciais, contexto visível, identificadores incertos e edições de usuário. Uma bela transcrição offline não basta.

Reward shaping: latência, precisão, naturalidade

A recompensa tem quatro partes. Precisão recompensa preservação de entidades, WER baixo em condições suportadas e intenção de edição correta. Latência recompensa texto útil cedo, não apenas tokens cedo. Naturalidade recompensa texto que soa como o usuário, incluindo respostas concisas no Slack e prosa técnica limpa. Segurança recompensa comportamento conservador quando a incerteza é alta.

Reward shaping em sistemas de voz é fácil de errar. Se você pesa latência demais, o modelo confirma cedo demais. Se pesa formatação demais, ele transforma notas casuais em templates. Se pesa preservação de entidades demais, pode manter fragmentos ditados crus que deveriam ter sido limpos. Ajustamos pesos de recompensa comparando edições reais de dogfooding antes e depois de cada rodada de treinamento.

• Recompensa de latência: tempo até o primeiro texto utilizável e tempo até commit estável.
• Recompensa de entidade: nomes técnicos, caminhos de arquivo, comandos e trechos em idiomas mistos.
• Recompensa de destino: formato correto para Slack, GitHub, Cursor, VS Code, email ou notas.
• Recompensa de correção: menos backspaces do usuário e menos reescritas manuais depois da inserção.

Pares contrafactuais são os dados de preferência mais úteis que coletamos. Para cada edição aceita que um usuário faz depois do ditado, podemos construir um par em que o texto ditado é o candidato rejeitado e o texto editado é o preferido. Esse dado é denso, naturalmente alinhado ao uso real e livre de artefatos de preferência sintética. Tratamos isso como um loop de feedback lento e de alto sinal, não como um sinal de RL online em tempo real.

Como aparece em produção

Em produção, RL não aparece como um recurso visível. Ele aparece como menos momentos irritantes. Uma mensagem de commit ganha forma imperativa e concisa. Um email para cliente mantém tom mais caloroso. Um comentário Python preserva o identificador exato visível perto do cursor. Uma fala longa começa a transmitir rapidamente, mas adia trechos arriscados de entidade até o contexto estar disponível.

Um exemplo pequeno e concreto: ditar "corrigir o bug em que retry esgota a fila" em uma janela de terminal com um git diff recente visível produz fix: drain retry queue before exhausting backoff window como subject do commit. A mesma fala com o cursor em uma thread do Slack produz "Corrigindo o bug em que retry esgota a fila — deve entrar hoje à tarde." Mesma fala, mesma pessoa, duas saídas diferentes adequadas ao destino. O planejador de instruções escolheu o plano de destino; o renderizador de texto, pós-treinado com recompensa de destino, produziu o formato certo.

Também mantemos estreita a fronteira de pós-treinamento. O reconhecedor central, o planejador de instruções e o renderizador de texto são treinados internamente para a superfície de ditado do Loqua. Pesquisas públicas em RLHF, DPO, agrupamento tipo GRPO e destilação on-policy informam nosso vocabulário de avaliação, mas a stack de produção é ajustada contra nossos próprios dados, restrições de runtime e fronteira de privacidade.

Modos de falha e debugging

RL torna funções de recompensa ruins mais óbvias. Os modos de falha comuns são viés de verbosidade, confirmação prematura, drift de estilo e reward hacking em torno de pistas fáceis de formatação. Depuramos com ablations: remover recompensa de latência, congelar recompensa de entidade, comparar candidatos sem contexto de tela e repetir falas reais de dogfooding em checkpoints antigos e novos.

Nosso checklist pré-merge para uma rodada de RL é curto e deliberado. A taxa de correção caiu em dados reais de dogfood, não apenas em um conjunto de preferência retido? O p95 de tempo até o primeiro texto utilizável ficou dentro do orçamento? A preservação de entidades se manteve ou melhorou em fatias de inglês, chinês e identificadores de código? O renderizador de texto parou de adicionar bullets não solicitados ou polidez no fim? Se qualquer resposta for não, o checkpoint volta para tuning em vez de ir para produção.

A disciplina mais importante é preservar uma taxonomia de erros legível por humanos. Uma saída ruim deve ser rotulada como falha de audição, entidade, intenção, destino, tom, latência ou fronteira de privacidade. Sem essa taxonomia, reinforcement learning em digitação por voz vira uma pilha de números que pode melhorar enquanto o produto parece pior.