6言語にまたがる字幕翻訳で、TranslateGemmaを他の5つのLLMとベンチマークしました。最初は数字がきれいな物語を語っていましたが、その後に人手によるQAが加わり、もう一つの章が生まれました。[D]

英語の字幕をスペイン語、日本語、韓国語、タイ語、中国語（簡体字）、中国語（繁体字）に翻訳する6つのモデルを評価しました。言語ペアごとに167セグメント、参照不要のQE指標を2つ用いてスコア化しています。

テストしたモデル：

• TranslateGemma-12b
• claude-sonnet-4-6
• deepseek-v3.2
• gemini-3.1-flash-lite-preview
• gpt-5.4-mini
• gpt-5.4-nano

スコアリング

MetricX-24（低いほど良い）とCOMETKiwi（高いほど良い）—どちらも参照不要のQE指標です。さらに、合成スコアも開発しました：

TQI = COMETKiwi × exp(−MetricX / 10)

指数減衰の項が、MetricXを乗法的な忠実度ペナルティに変換します。MetricXが0に近いときは、TQI ≈ COMETKiwi です。MetricXが大きくなるほど、ペナルティは指数関数的に増えます。TQIは私たち独自の指標で、業界標準ではありません。

上位結果（全6言語の平均TQI）

順位	モデル	平均TQI
#1	TranslateGemma-12b	0.6335
#2	gemini-3.1-flash-lite-preview	0.5981
#3	deepseek-v3.2	0.5946
#4	claude-sonnet-4-6	0.5811
#5	gpt-5.4-mini	0.5785
#6	gpt-5.4-nano	0.5562

すべてのモデルはCOMETKiwi（流暢性）で0.75〜0.79の範囲に収まっています。一方、MetricX-24の忠実度スコアではモデル間で大きく差が出ました。ここでTQIの分岐（差）が生まれます。

議論する価値があるいくつかの点：

1. メトリクスとモデルの相性の懸念 注意点として、MetricX-24はGoogleの指標であり、TranslateGemmaもGoogleのモデルです。UnbabelのCOMETKiwiでは、TranslateGemmaと他とのギャップが明確に小さくなっています。結果の方向性はどちらにしても同じですが、リードの大きさは、メトリクスとモデルの相性によって部分的に膨らんでいる可能性があります。

2. Claudeは日本語で崩壊 claude-sonnet-4-6は日本語で最下位（#6）でした—MetricX 3.90で、全言語中最悪の結果です。そのCOMETKiwi（0.79）は良好でした。典型的な「流暢性と忠実度のミスマッチ」：自然に聞こえる出力だが、元の意味からずれていく。

3. Gemini Flash Liteは、フルサイズの最先端モデルを上回る 「lite」モデルは一貫して#2〜#3にランクされ、ほとんどの言語でClaude Sonnetと両方のGPT-5.4バリアントを上回りました。

4. TranslateGemmaが#1—しかし人手のQAで、指標が完全に見落としていた何かが見つかった TranslateGemmaはすべての言語でトップでした。私たちの言語学者が繁体中国語（zh-TW）の出力を確認したところ、モデルはzh-CNとzh-TWの両方の言語コードに対して簡体中国語を出力していました。次に、繁体中国語の正しい明示タグはzh-Hantであるべきだというコミュニティ報告を調査し、そのタグで再テストしました。結果：76%のセグメントは依然として簡体、14%が繁体、10%が曖昧（セグメントが短すぎる、またはスクリプト非中立で判定できない）でした。

https://preview.redd.it/h6gfrd0ew4vg1.jpg?width=773&format=pjpg&auto=webp&s=fbe0afae3831528440b956167456e94004bcbe09

MetricX-24とCOMETKiwiは、両方の出力をまったく同じように、かつ非常に高くスコア付けしていました。どちらの指標からも問題の兆候はありませんでした。

結局のところ、これはトレーニングデータのバイアスによって引き起こされた、確認済みで公開されている問題です。TranslateGemmaのファインチューニング用コーパスは簡体中国語に大きく偏っています。ロケールタグはエラーなしで受け入れられますが、モデルの重み側で反映されません。これはすべてのモデルサイズ（4B、12B、27B）に影響します。容量を大きくしても修正にはなりません。根本原因が「能力（capacity）」ではなく、トレーニングデータ構成にあるためです。回避策は存在します（OpenCCのs2twp後処理）—ただし標準的なQE指標はずっと問題ないように見えます。これが、自動バリデーションに依存するあらゆるパイプラインにとってまさに問題になる点です。