语音输入中的强化学习：Loqua 语音栈里的 GRPO、DPO 与 on-policy distillation

对语音产品来说，真正痛的错误不是平均错误，而是少数几个时刻：模型改掉了 package name，写出僵硬的 Slack 回复，或者在提交文本前等太久。Reinforcement learning voice typing 是我们对 post-training loop 的总称，用来瞄准这些时刻。

为什么 supervised loss 的收益会停止

监督学习是必要的。它教会模型任务本身：audio in、context in、text out。但到了某个阶段，loss 会继续在简单样本上变好，而产品体验不再明显变好。剩下的问题是 preference-shaped，不只是 label-shaped。

以技术听写为例。一个监督样本可以教模型，"react query" 有时意味着 @tanstack/react-query。但真正的产品问题是有条件的：模型应该保留口头短语，把它改写成 import path，还是因为光标在客户邮件里就保留成普通英文？正确答案取决于上下文，也取决于用户对纠正的容忍度。

一个具体模式是：我们的内部 benchmark 在干净朗读语音上，连续三轮监督迭代只提升不到一个百分点；但真实工作流里的 dogfood edit rate 变化超过四个点。这个差距就是 preference-shaped failure 的信号：模型在技术上更接近 gold transcript，却更不符合用户真正想提交到文档里的内容。

这就是 rl for speech recognition 和 text rendering 有用的地方。我们可以奖励保留实体、快速到达、匹配目标格式的输出，同时惩罚过度自信的改写。reward 不是“更聪明”，而是“听写后更少编辑”。

GRPO vs DPO vs PPO

我们把 post-training 工具分成三类。PPO 灵活、历史重要，来自 Proximal Policy Optimization 这类 policy-gradient 工作的长谱系。DPO 在你有 pairwise preference data 并且想要更简单目标函数时很有吸引力；清晰表述可以看 Direct Preference Optimization 论文。

GRPO-style training 适合 grouped candidates：对同一个 utterance 和 context 生成多个输出，用 reward function 排序，再朝更好的 group behavior 更新。对 Loqua 来说，分组比较很适合很多语音错误。我们不只问“这个 transcript 对不对？”我们会问：在当前 app、延迟预算和编辑意图下，哪个输出最好？

我们如何把方法匹配到各层

实践中，stack 的每一层会使用不同的 post-training 工具。Text renderer 是 DPO 和 grouped optimization 最自然的归宿，因为它的决策局部、容易并排比较。Instruction planner 使用更轻的 pairwise updates，推动 intent classification 和 format planning。Acoustic front end 基本不进入 RL；preference signals 离 frame-level audio 太远，不够有用，我们在那里从 data curation 和 supervised refinement 得到更多收益。实际选择不是意识形态问题。我们会选能清楚暴露失败模式的最小 loop。

文本渲染的 on-policy distillation

On-policy distillation 重要，是因为 text renderer 必须从自己实际会访问的状态中学习。传统 offline distillation 可能用干净 teacher outputs 训练，而这些状态小 student 在 inference 时根本到不了。在流式听写产品里，这种不匹配很明显：一旦 student 走上稍微错误的 partial path，后续 token 就会变得别扭。

我们的 text-rendering training 使用 on-policy distillation 思路：让 student 生成 candidate continuations，用更强的 evaluator 和 task reward 给这些 continuation 打分，然后在 student 自己的 trajectory 上训练，而不是在断开的 gold path 上训练。近期关于 on-policy distillation 和相关 memory-policy optimization 的文献，为这个问题提供了有用的语言。

具体来说，一步训练是这样的。我们取一个真实 dogfood utterance 和 screen context。Student 在 streaming constraints 下生成三到五个 candidate continuations。更大的 evaluator 从 entity preservation、latency、destination fit 和 naturalness 几个维度给候选打分。然后 student 会被更新为更偏好高分 trajectory，权重取决于它当前离 evaluator 选择有多远。Student 永远看不到离线 gold path；它只看到自己的行为，以及这些行为的排序。

我们真正关心的经验很简单：在模型将要生活的地方训练它。对语音输入来说，它生活在 partial utterances、可见上下文、不确定标识符和用户编辑里。漂亮的离线 transcript 不够。

Reward shaping：延迟、准确率、自然度

Reward 有四个部分。Accuracy 奖励实体保留、支持条件下的低 WER，以及正确的编辑意图。Latency 奖励早期可用文本，而不只是更早吐 token。Naturalness 奖励读起来像用户自己的文字，包括简洁的 Slack 回复和干净的技术 prose。Safety 奖励在不确定性高时保守输出。

Reward shaping voice systems 很容易做错。如果 latency 权重过高，模型会过早 commit。如果 formatting 权重过高，它会把随手 note 变成模板。如果 entity preservation 权重过高，它可能会保留本该清理掉的口语碎片。我们通过比较每次训练前后的真实 dogfooding edits 来调 reward weights。

• Latency reward：time to first usable text 和 time to stable commit。
• Entity reward：技术名称、文件路径、命令和混合语言片段。
• Destination reward：Slack、GitHub、Cursor、VS Code、email 或 notes 中的正确形态。
• Correction reward：插入后更少 backspace，更少手动重写。

Counterfactual pairs 是我们收集到的最有用 preference data。用户每次在听写后接受某个编辑，我们都能构造一个 pair：原始听写文本是 rejected candidate，用户编辑后保留下来的文本是 preferred one。这种数据密集、自然贴近真实使用，而且没有 synthetic-preference artifacts。我们把它当作一个慢速、高信号反馈 loop，而不是实时 online RL 信号。

生产环境里是什么样

在生产环境里，RL 不会以一个可见功能出现。它体现为更少恼人的瞬间。Git commit message 会得到简洁的祈使句形式。客户邮件会保持更温暖的语气。Python 注释会保留光标附近可见的精确标识符。较长 utterance 会很快开始 streaming，但会在上下文可用前延迟提交有风险的 entity spans。

一个很小的具体例子：在终端窗口里，旁边可见最近的 git diff 时，说 "fix the bug where retry exhausts the queue"，会生成 fix: drain retry queue before exhausting backoff window 作为 commit subject。同一句话，如果光标在 Slack thread 里，会生成 "Fixing the bug where retry exhausts the queue — should land this afternoon." 同一段语音、同一个说话人，两个适合不同目标位置的输出。Instruction planner 选择了 destination plan；经过 destination reward post-trained 的 text renderer 生成了正确形态。

我们也把 post-training 边界保持得很窄。Core recognizer、instruction planner 和 text renderer 都是为 Loqua 的听写表面在内部训练的。RLHF、DPO、GRPO-like grouping 和 on-policy distillation 的公开研究会影响我们的评估词汇，但生产 stack 是围绕我们自己的数据、运行时约束和隐私边界调出来的。

失败模式与调试

RL 会让糟糕的 reward functions 更明显。常见失败模式包括 verbosity bias、premature commitment、style drift，以及围绕简单格式线索的 reward hacking。我们用 ablations 调试：移除 latency reward，冻结 entity reward，比较 no-screen-context candidates，并把真实 dogfooding utterances 在旧 checkpoint 和新 checkpoint 上 replay。

我们每次 RL run 的 pre-merge checklist 很短，但刻意严格：真实 dogfood data 上的 correction rate 是否下降，而不只是 held-out preference set 变好？p95 time to first usable text 是否仍在预算内？English、Chinese 和 code-identifier slices 上的 entity preservation 是否保持或提升？Text renderer 是否停止添加不请自来的 bullet points 或结尾客套？任何一个答案是否定的，这个 checkpoint 就回去继续调，而不是发布。

最重要的纪律，是保留人能读懂的错误分类。一个坏输出应该被标成 hearing、entity、intent、destination、tone、latency 或 privacy-boundary failure。没有这套 taxonomy，reinforcement learning voice typing 就会变成一堆数字：数字可能变好，但产品感觉更差。