Aprendizaje por refuerzo para dictado por voz: GRPO, DPO y on-policy distillation en nuestro voice stack

Para un producto de voz, los errores dolorosos no son los errores promedio. Son esos pocos momentos en los que el modelo cambia el nombre de un paquete, escribe una respuesta tiesa en Slack o tarda demasiado antes de confirmar el texto. El aprendizaje por refuerzo para dictado por voz es nuestro término paraguas para el loop de post-entrenamiento que apunta a esos momentos.

Por qué la pérdida supervisada deja de rendir

El aprendizaje supervisado es necesario. Le enseña al modelo la tarea: audio de entrada, contexto de entrada, texto de salida. Pero llega un punto en el que la pérdida sigue mejorando en ejemplos fáciles mientras el producto deja de notarse mejor. Los problemas que quedan tienen forma de preferencia, no simplemente forma de etiqueta.

Considera el dictado técnico. Un par supervisado puede enseñar que "react query" a veces significa @tanstack/react-query. Pero la pregunta de producto es condicional: ¿debería el modelo preservar la frase hablada, reescribirla como un import path o dejarla como texto plano en inglés porque el cursor está en un correo a un cliente? La respuesta correcta depende del contexto y de la tolerancia del usuario a la corrección.

Un patrón concreto: nuestro benchmark interno de lectura en voz alta limpia mejoró menos de un punto porcentual en tres iteraciones supervisadas consecutivas, mientras que la tasa de edición en dogfood sobre flujos reales cambió más de cuatro puntos. Esa brecha es la firma del fallo con forma de preferencia: el modelo está técnicamente más cerca de la transcripción de referencia, pero menos alineado con lo que el usuario realmente quería dejar en el documento.

Ahí es donde el RL para reconocimiento de voz y renderizado de texto se vuelve útil. Podemos recompensar salidas que preservan entidades, llegan rápido y coinciden con el formato de destino, mientras penalizamos reescrituras demasiado seguras. La recompensa no es "más listo". La recompensa es "menos edición tras el dictado".

GRPO vs DPO vs PPO

Separamos tres familias de herramientas de post-entrenamiento. PPO es flexible e históricamente importante, con un linaje largo desde trabajos de policy-gradient como Proximal Policy Optimization. DPO es atractivo cuando tienes datos de preferencia por pares y quieres un objetivo más simple; mira el paper de Direct Preference Optimization para la formulación limpia.

El entrenamiento estilo GRPO es útil para candidatos agrupados: genera varias salidas para la misma frase y contexto, las ordena con una función de recompensa y luego actualiza hacia el comportamiento del mejor grupo. Para Loqua, la comparación agrupada encaja con muchos errores de voz. No solo preguntamos "¿es correcta esta transcripción?" Preguntamos cuál salida es la mejor para la app actual, el presupuesto de latencia y la intención de edición.

Cómo emparejamos métodos con capas

En la práctica, cada capa del stack recibe una herramienta de post-entrenamiento distinta. El renderizador de texto es la casa natural para DPO y la optimización agrupada porque sus decisiones son locales y fáciles de comparar lado a lado. El planificador de instrucciones usa actualizaciones por pares más ligeras para ajustar la clasificación de intención y la planificación de formato. El front-end acústico se mantiene en gran parte fuera del RL; las señales de preferencia están demasiado lejos del audio a nivel de frame para ser útiles, y allí obtenemos más de la curación de datos y del refinamiento supervisado. La elección práctica no es ideológica. Elegimos el loop más pequeño que expone el modo de fallo con claridad.

On-policy distillation para el renderizado de texto

On-policy distillation importa porque el renderizador de texto debe aprender de los estados que realmente visita. La destilación offline tradicional puede entrenar sobre salidas limpias del profesor a las que el estudiante más pequeño nunca llega en inferencia. En un producto de dictado en streaming, ese desajuste se nota: una vez que el estudiante toma un camino parcial ligeramente equivocado, los tokens posteriores quedan torpes.

Nuestro entrenamiento del renderizador de texto usa ideas de on-policy distillation: dejar que el estudiante produzca continuaciones candidatas, puntuar esas continuaciones con un evaluador más fuerte y una recompensa de tarea, y luego entrenar sobre la propia trayectoria del estudiante en lugar de sobre un camino dorado desconectado. La literatura reciente sobre on-policy distillation y los trabajos relacionados de memory-policy optimization dan vocabulario útil para este problema.

Concretamente, un paso de entrenamiento se ve así. Tomamos una frase real de dogfood y el contexto de pantalla. El estudiante produce tres a cinco continuaciones candidatas bajo restricciones de streaming. Un evaluador más grande puntúa cada candidato en términos de preservación de entidades, latencia, ajuste al destino y naturalidad. Luego se actualiza el estudiante para preferir la trayectoria con mejor puntuación, ponderada por cuán lejos está actualmente de la elección del evaluador. El estudiante nunca ve un camino dorado offline; solo ve su propio comportamiento, ordenado.

La lección que nos importa es simple: entrena al modelo donde va a vivir. Para el dictado por voz, vive en frases parciales, contexto visible, identificadores inciertos y ediciones del usuario. Una transcripción offline bonita no basta.

Reward shaping: latencia, precisión, naturalidad

La recompensa tiene cuatro partes. La precisión recompensa la preservación de entidades, WER bajo en condiciones soportadas y la intención de edición correcta. La latencia recompensa texto útil temprano, no solo tokens tempranos. La naturalidad recompensa texto que se lee como el usuario, incluyendo respuestas concisas en Slack y prosa técnica limpia. La seguridad recompensa comportamiento conservador cuando la incertidumbre es alta.

El reward shaping para sistemas de voz es fácil de hacer mal. Si pesas demasiado la latencia, el modelo confirma demasiado pronto. Si pesas demasiado el formato, convierte notas casuales en plantillas. Si pesas demasiado la preservación de entidades, puede conservar fragmentos crudos dictados que debían haberse limpiado. Ajustamos los pesos de recompensa comparando ediciones reales de dogfooding antes y después de cada corrida de entrenamiento.

• Recompensa de latencia: tiempo hasta el primer texto útil y tiempo hasta un commit estable.
• Recompensa de entidad: nombres técnicos, rutas de archivo, comandos y tramos en idiomas mixtos.
• Recompensa de destino: forma correcta para Slack, GitHub, Cursor, VS Code, correo o notas.
• Recompensa de corrección: menos backspaces del usuario y menos reescrituras manuales tras la inserción.

Los pares contrafactuales son los datos de preferencia más útiles que recolectamos. Para cada edición aceptada que un usuario hace tras dictar, podemos construir un par donde el texto dictado es el candidato rechazado y el texto editado es el preferido. Esos datos son densos, naturalmente alineados con el uso real y libres de artefactos de preferencias sintéticas. Los tratamos como un loop de feedback lento y de alta señal, no como una señal de RL online en tiempo real.

Cómo se ve en producción

En producción, el RL no aparece como una característica visible. Aparece como menos momentos molestos. Un mensaje de commit de Git toma una forma imperativa concisa. Un correo a un cliente conserva un tono más cálido. Un comentario de Python preserva el identificador exacto que está visible cerca del cursor. Una frase larga empieza a transmitirse rápido, pero retrasa los tramos de entidad arriesgados hasta que el contexto esté disponible.

Un pequeño ejemplo concreto: dictar "fix the bug where retry exhausts the queue" en una ventana de terminal con un git diff reciente visible produce fix: drain retry queue before exhausting backoff window como asunto del commit. La misma frase con el cursor en un hilo de Slack produce "Fixing the bug where retry exhausts the queue — should land this afternoon." Misma voz, mismo hablante, dos salidas distintas apropiadas al destino. El planificador de instrucciones eligió el plan de destino; el renderizador de texto, post-entrenado con recompensa de destino, produjo la forma correcta.

También mantenemos estrecho el límite del post-entrenamiento. El reconocedor central, el planificador de instrucciones y el renderizador de texto se entrenan internamente para la superficie de dictado de Loqua. La investigación pública sobre RLHF, DPO, agrupamiento tipo GRPO y on-policy distillation informa nuestro vocabulario de evaluación, pero el stack de producción está afinado contra nuestros propios datos, restricciones de runtime y frontera de privacidad.

Modos de fallo y depuración

El RL hace más obvias las funciones de recompensa malas. Los modos de fallo comunes son el sesgo de verbosidad, el compromiso prematuro, la deriva de estilo y el reward hacking sobre pistas de formato fáciles. Los depuramos con ablaciones: quitar la recompensa de latencia, congelar la recompensa de entidad, comparar candidatos sin contexto de pantalla y re-reproducir frases reales de dogfooding a través de checkpoints viejos y nuevos.

Nuestro checklist pre-merge para una corrida de RL es corto y deliberado. ¿Bajó la tasa de corrección en datos reales de dogfood, no solo en un set de preferencia retenido? ¿El p95 del tiempo hasta el primer texto útil se mantuvo dentro del presupuesto? ¿La preservación de entidades se mantuvo o mejoró en cortes de inglés, chino y de identificadores de código? ¿El renderizador de texto dejó de añadir bullets no solicitados o cortesías al final? Si alguna de esas respuestas es no, el checkpoint vuelve a tuning en lugar de salir a producción.

La disciplina más importante es preservar una taxonomía de error legible para humanos. Una salida mala debería etiquetarse como fallo de oído, entidad, intención, destino, tono, latencia o frontera de privacidad. Sin esa taxonomía, el aprendizaje por refuerzo para dictado por voz se vuelve un montón de números que pueden mejorar mientras el producto se siente peor.