Praxy Voice: Voice-Prompt Recovery + BUPS for Commercial-Class Indic TTS from a Frozen Non-Indic Base at Zero Commercial-Training-Data Cost

以下は、論文「Praxy Voice: Voice-Prompt Recovery + BUPS for Commercial-Class Indic TTS from a Frozen Non-Indic Base at Zero Commercial-Training-Data Cost.」の詳細な技術的サマリーです。

1. 問題定義

インド系言語（特にテルグ語、タミル語、ヒンディー語）向けの高品質な音声合成（TTS）システムを構築するには、通常、以下のいずれかが必要とされます：

1. ゼロからトレーニングする: 数百から数千の GPU 時間と、大規模なデータセット（例：Indic Parler-TTS、IndicF5）が必要。
2. クローズドな商用 API を使用する: 呼び出しごとのコストが発生し、データ制御が欠如している。

既存のオープンソースの多言語ベース（ResembleAI Chatterbox など）は 23 言語（ヒンディー語を含む）をサポートしていますが、テルグ語とタミル語をネイティブにサポートしていません。さらに、これらはブラフミー系文字（デーヴァナーガリー、テルグ、タミルなど）のトークナイズ機能を持っていないため、これらの言語を処理する際にトークナイズエラーや「バイト BPE ジャンク」が発生しがちです。著者らは問いかけます：「新しい音響デコーダーをトレーニングしたり、商用 TTS 学習データを使用したりすることなく、凍結された非インド系ネイティブの多言語ベースを、テルグ語、タミル語、ヒンディー語において商用レベルの性能に引き上げるために必要な最小限の介入とは何か？」

2. 手法

著者らは、3 つのエンジニアリングコンポーネントを単一のレシピとして組み合わせた3 分岐推論パイプラインを提案します。中核的な革新は、最小限のパラメータ更新と推論時のヒューリスティクスを通じて凍結モデルを適応させることにあります。

A. BUPS（ブラフミー統一音素空間）

• 課題: Chatterbox のトークナイザーは、生のテルグ語またはタミル語スクリプトを処理できません。
• 解決策: ブラフミー系文字（デーヴァナーガリー、テルグ、タミル、カンナダ、ベンガル、グジャラート、マラヤーラム）をトークナイズ時にISO-15919 によるローマ字化されたラテン文字列に変換する決定論的ルーティング層。
• メカニズム: 入力テキストをスクリプトごとにセグメントし、ブラフミー系スパンを音韻を保持するダイアクリティクスを用いてラテン文字へ転写し、非ブラフミー系スパンは変更せずに通過させます。これにより、モデルの既存のラテントークナイザー経路がモデル重みを変更することなくインド系テキストを処理できます。

B. LoRA 適応（テキストヘッドのみ）

• 対象: Chatterbox ベースのテキストトークン予測器（t3 トランスフォーマー）のみ。音響デコーダー（s3gen）と音声エンコーダー（ve）は凍結されたままです。
• 構成: 注意機構の投影（$q, k, v, o$）に適用される低ランク適応（LoRA）アダプター。
  • 学習可能パラメータ: 786 万（8 億 1000 万のベースモデルの 0.97%）。
  • 学習データ: 約 1,220 時間のライセンス付きインド系音声（IndicTTS、Rasa、FLEURS、Shrutilipi）。商用 TTS データはゼロ使用。
  • 言語条件付け: テルグ語とタミル語のテキストは、ヒンディー語プロキシ言語 ID（hi）で条件付けされます。これにより、ベースが既に保有する最も近いサポート済み音響多様体を通じて適応がルーティングされます。
• 結果: テキストヘッドはインド系音韻と整合する音声トークンを出力するように学習し、凍結されたデコーダーが音声を生成します。

C. 音声プロンプト復元と設定 B

• 問題: BUPS と LoRA を用いても、デフォルトの推論では、凍結されたデコーダーがネイティブなインド系音響事前分布を持たないため、「平坦な」または「外国語アクセントの」音声が生じます。
• 解決策: 推論時のレシピ：
  1. 音声プロンプト: 入力テキストと同じ対象言語の8〜11 秒の参照音声クリップを提供します。これにより、デコーダーをネイティブなプロソディと音色で条件付けます。
  2. 設定 B サンプリングオーバーライド: 生成を安定させるための 3 つの特定のパラメータ調整：
     • exaggeration: 0.7（プロソディ輪郭を増幅）。
     • temperature: 0.6（分布を緊密化）。
     • min_p: 0.1（音素のドリフトを引き起こす低確率トークンをフィルタリング）。

D. ルーティングアーキテクチャ

システムは、純粋なスクリプト入力に対して2 分岐アーキテクチャを、コード混合入力に対して第 3 の分岐を配備します：

1. テルグ語/タミル語（純粋スクリプト）: **BUPS + LoRA（ヒンディー語プロキシ）**を介してルーティング。
2. ヒンディー語（純粋スクリプト）: バニラ Chatterbox（LoRA なし、BUPS なし）を介してルーティング。重要なのは、ヒンディー語に LoRA を適用すると意味的精度が低下するため、ネガティブコントロール分岐を使用することです。
3. コード混合（例：ヒンディー語 + 英語）: IndicF5（ネイティブなインド系フローマッチングモデル）へルーティングされ、その前にHaiku 駆動の転写前処理が英語単語をネイティブスクリプトの音綴スペリングに変換します（例："WhatsApp" $\to$ "व्हाट्सऐप"）。

3. 主要な貢献

1. BUPS: ラテントークナイズされた TTS ベースにおいてインド系サポートを可能にするルーティング機構として、ISO-15919 ローマ字化を初めて適用。
2. 最小介入 LoRA: プロキシ言語 ID を使用して凍結された多言語モデルのテキストヘッドのみを適応させる戦略。音響デコーダーのトレーニングなしで商用品質を達成。
3. 音声プロンプト復元レシピ: 特定のサンプリングオーバーライド（設定 B）と同一言語の音声プロンプトを組み合わせることで、凍結デコーダーから商用レベルの音響を回復できることを実証。
4. 2 分岐展開: 言語に基づいて LoRA 適応モデルとバニラモデルを動的に切り替える新規アーキテクチャ。LoRA がヒンディー語のパフォーマンスを低下させることを示すネガティブコントロールによって検証済み。
5. コード混合ソリューション: 英語スパンをネイティブスクリプトへ転写する前処理パイプラインにより、コード混合入力における LLM-WER を約 0.80 から約 0.14〜0.27 に削減。
6. オープンリリース: R6 LoRA 重み（Apache-2.0）と推論コード（MIT）が公開利用可能。

4. 結果

**PSP（音素置換プロファイル）**ベンチマークと知性度指標で評価：

• テルグ語:
  • 後舌音の崩壊: 26.7%（Praxy）対 33.3%（Sarvam Bulbul）および 50%（Cartesia）。Praxy が一位。
  • FAD（フレシェ音響距離）: 291.3（商用ベースラインと同等）。
• タミル語:
  • Zha の崩壊: 71%（Praxy）対 86%（商用トリオ）。これは最も明確な次元別改善です。
  • PSD（プロソディ署名発散）: 71.2（Sarvam Bulbul と一致）。
• ヒンディー語:
  • LLM-WER: 0.025（Praxy バニラ）は Cartesia Sonic-3 と同率。
  • 注記: LoRA 分岐はヒンディー語のパフォーマンスを著しく低下させました（LLM-WER 0.334）。これは 2 分岐ルーティングの必要性を検証するものです。
• コード混合:
  • 転写前処理により、LLM-WER は 0.80〜0.85（生 IndicF5）から0.14〜0.27に低下しました。

5. 意義

• コスト効率: 商用学習データゼロおよび最小限の計算資源（単一 A100、約 11 時間、約 45 ドル）を使用して、主要なインド系言語向けの商用グレード TTS を達成。
• アクセシビリティ: ゼロからモデルをトレーニングするために必要な計算資源やデータを負担できない開発者に対して、高品質なインド系 TTS へのアクセスを民主化。
• 方法論的洞察: 多言語ベースにおいて、テキストヘッドの適応と推論時の音響条件付け（音声プロンプト）の組み合わせが、ベースが「十分に近い」音響多様体（例：テルグ語/タミル語に対するヒンディー語）を保有している限り、サポートされていない言語のギャップを埋めるのに十分であることを証明。
• ネガティブコントロール: 本論文は厳密に、「より多くの適応」が常に良いわけではないことを実証しました。LoRA アダプターは、ベースが既にサポートしている言語（ヒンディー語）のパフォーマンスを積極的に損なうため、条件付きルーティング戦略が必要となります。

著者らは、この「最小介入」アプローチが、純粋スクリプトのインド系入力においてオープンソースと商用 TTS の間のギャップを効果的に埋め、コード混合シナリオには別途低コストの解決策を提供すると結論付けています。