強化学習による音声入力: GRPO、DPO、オンポリシー蒸留を Loqua の音声スタックで

音声製品にとって、痛いエラーは平均エラーではありません。モデルがパッケージ名を変えたり、硬い Slack 返信を書いたり、テキストをコミットする前に長く待ったりする数瞬間です。強化学習による音声入力は、その瞬間をターゲットにするポストトレーニングループの私たちの傘用語です。

なぜ教師あり損失が報われなくなるか

教師あり学習は必要です。タスクを教えます: 音声入力、コンテキスト入力、テキスト出力。しかし最終的に、損失は簡単な例で改善し続ける一方、製品は目に見えて良くならなくなります。残りの問題はプリファレンス形であってラベル形ではありません。

技術ディクテーションを考えてみてください。教師ありペアは、「react query」がときに @tanstack/react-query を意味することを教えられます。しかし製品の質問は条件的です: モデルは話されたフレーズを保持すべきか、import パスとして書き直すべきか、カーソルが顧客メールにあるので平易な英語のままにすべきか? 正しい答えはコンテキストと修正に対するユーザー許容度に依存します。

具体的なパターン: クリーン音読音声の社内ベンチマークは三回の連続教師ありイテレーションでパーセントポイント未満改善した一方、実ワークフローでのドッグフード編集率は 4 ポイント以上変化しました。そのギャップはプリファレンス形失敗の署名です: モデルは技術的にゴールド書き起こしに近いが、ユーザーが実際にドキュメントにコミットしたかったものと整合性が低くなっています。

そこで音声認識とテキストマテリアライゼーション向けの RL が有用になります。エンティティを保持し、素早く到着し、宛先フォーマットに合う出力を報酬し、自信過剰な書き直しを罰することができます。報酬は「より賢く」ではありません。報酬は「ディクテーション後の編集が少ない」です。

GRPO vs DPO vs PPO

三つのポストトレーニングツール族を分離します。PPO は柔軟で歴史的に重要で、Proximal Policy Optimization のようなポリシー勾配業務からの長い系譜があります。DPO はペアプリファレンスデータがあってよりシンプルな目的が欲しいときに魅力的です。クリーンな定式化は Direct Preference Optimization 論文を参照してください。

GRPO スタイル訓練はグループ化された候補に有用です: 同じ発話とコンテキストに対して複数の出力を生成し、報酬関数でランク付けし、より良いグループ動作に向けて更新します。Loqua にとって、グループ比較は多くの音声エラーに合います。「この書き起こしは正しいか?」だけを尋ねません。現在のアプリ、レイテンシ予算、編集意図に最適な出力はどれか、を尋ねます。

どう手法をレイヤーに合わせたか

実践では、スタックの各レイヤーは異なるポストトレーニングツールを得ます。テキストレンダリングレイヤーは DPO とグループ化最適化の自然な家です。決定がローカルで横に比較しやすいからです。意図分類とフォーマット計画を微調整するために、推論レイヤーはより軽量なペア更新を使います。音響フロントエンドはほぼ RL 外に留まります: プリファレンス信号がフレームレベル音響から遠すぎて有用にならず、そこではデータ curation と教師あり改良からより多く得られます。実践的選択はイデオロギー的ではありません。失敗モードを明確に露出する最小のループを選びます。

テキストレンダリング向けオンポリシー蒸留

オンポリシー蒸留が重要なのは、レンダリングレイヤーが実際に訪れる状態から学ばなければならないからです。伝統的なオフライン蒸留は、小さな生徒が推論時に決して到達しないクリーンな教師出力で訓練できます。ストリーミングディクテーション製品では、その不一致が可視です: 一度生徒がわずかに間違った部分的経路を取ると、後のトークンがぎこちなくなります。

私たちのテキストレンダリング訓練はオンポリシー蒸留のアイデアを使います: 生徒に候補継続を生成させ、より強い評価器とタスク報酬でそれらの継続を採点し、切断されたゴールド経路ではなく生徒自身の軌跡で訓練します。オンポリシー蒸留に関する最近の文献と関連メモリポリシー最適化業務が、この問題に有用な言語を与えます。

具体的に、訓練ステップはこう見えます。実際のドッグフード発話と画面コンテキストを取ります。生徒はストリーミング制約下で 3〜5 個の候補継続を生成します。より大きな評価器がエンティティ保持、レイテンシ、宛先適合、自然さに沿って各候補を採点します。生徒は次に、現在評価器の選択からどれだけ離れているかで重み付けされた、より高いスコアの軌跡を優先するよう更新されます。生徒はオフラインゴールド経路を決して見ません。自身の動作のみがランク付けされるのを見ます。

私たちが気にする教訓はシンプルです: モデルを住む場所で訓練する。音声入力の場合、それは部分発話、可視コンテキスト、不確実な接頭辞、ユーザー編集に住みます。美しいオフライン書き起こしでは十分ではありません。

報酬形成: レイテンシ、精度、自然さ

報酬には四つの部分があります。精度はエンティティ保持、サポート条件での低い WER、正しい編集意図を報酬します。レイテンシは早期の有用なテキストを報酬し、早期トークンだけではありません。自然さは、簡潔な Slack 返信とクリーンな技術散文を含む、ユーザーらしく読まれるテキストを報酬します。安全性は、不確実性が高いときの保守的動作を報酬します。

音声システムの報酬形成は間違えやすいです。レイテンシを過剰重み付けすると、モデルは早すぎてコミットします。フォーマットを過剰重み付けすると、カジュアルなノートをテンプレートにします。エンティティ保持を過剰重み付けすると、クリーンアップされるべきだった生のディクテーションされた断片を保持するかもしれません。各訓練ランの前後で実際のドッグフード編集を比較することで報酬重みをチューニングします。

• レイテンシ報酬: 最初の有用なテキストまでの時間と安定したコミットまでの時間。
• エンティティ報酬: 技術名、ファイルパス、コマンド、混合言語スパン。
• 宛先報酬: Slack、GitHub、Cursor、VS Code、メール、ノートの正しい形。
• 修正報酬: 挿入後のユーザーバックスペースと手動書き直しを少なく。

反実仮想ペアが私たちが集める最も有用なプリファレンスデータです。ユーザーがディクテーション後に行う各受け入れられた編集に対して、ディクテーションされたテキストが拒否候補、編集されたテキストが優先のペアを構築できます。そのデータは密で、自然に実際の使用と整合し、合成プリファレンスアーティファクトから自由です。リアルタイムのオンライン RL 信号ではなく、遅い高信号フィードバックループとして扱います。

本番ではどう見えるか

本番では、RL は可視機能として現れません。煩わしい瞬間が少なくなるという形で現れます。Git コミットメッセージが簡潔な命令形になります。顧客メールがより暖かいトーンを保ちます。Python コメントがカーソル付近で可視の正確な識別子を保持します。長い発話が素早くストリーミングを始めますが、コンテキストが利用可能になるまでリスクのあるエンティティスパンを遅らせます。

小さな具体例: 最近の git diff が可視なターミナルウィンドウで「retry が queue を使い果たすバグを修正」とディクテーションすると、fix: drain retry queue before exhausting backoff window がコミット件名として生成されます。同じ発話をカーソルが Slack スレッドにあるときにすると、「retry が queue を使い果たすバグを修正中 — 今日午後に着地予定」になります。同じ音声、同じ話者、二つの異なる宛先適切な出力。推論レイヤーが宛先計画を選び、宛先報酬でポストトレーニングされたテキストレンダリングレイヤーが正しい形を生成しました。

ポストトレーニング境界も狭く保ちます。コアの認識器、推論、テキストレンダリングは Loqua のディクテーション表面のために社内で訓練されています。RLHF、DPO、GRPO ライクグルーピング、オンポリシー蒸留に関する公開研究は私たちの評価語彙に情報を与えますが、本番スタックは自身のデータ、ランタイム制約、プライバシー境界に対してチューニングされています。

失敗モードとデバッグ

RL は悪い報酬関数をより明白にします。一般的な失敗モードは冗長性バイアス、早すぎるコミット、スタイルドリフト、簡単なフォーマット手がかり周辺の報酬ハッキングです。アブレーションでデバッグします: レイテンシ報酬を取り除く、エンティティ報酬を凍結する、画面コンテキストなし候補を比較する、古いと新しいチェックポイントを通じて実際のドッグフード発話を再生する。

RL ラン用のプリマージチェックリストは短く意図的です。修正率は保持されたプリファレンスセットだけでなく実ドッグフードデータで下がったか? p95 最初の有用なテキストまでの時間は予算内に留まったか? エンティティ保持は英語、中国語、コード識別子スライスにわたって保持または改善したか? テキストレンダリングは求められていないブレットポイントや末尾礼儀の追加を止めたか? いずれかの答えが no なら、チェックポイントは出荷ではなくチューニングのために戻ります。

最も重要な規律は、人間可読なエラー分類を保つことです。悪い出力は聴覚、エンティティ、意図、宛先、トーン、レイテンシ、またはプライバシー境界失敗としてラベル付けされるべきです。その分類なしには、強化学習による音声入力は、製品が悪く感じる間に改善できる数値の山になります。