検索拡張ローカライゼーションでLLMの用語エラーを17〜45%削減

本番ローカライゼーションでは、段落や文字列が切り出された状態で翻訳されます。CI/CDパイプラインは前回バージョンとの差分を取り、変更があった箇所だけを再翻訳します。たとえば、UI文字列、ツールチップ、書き換えられた段落などです。各リクエストは、ページ全体も、ドキュメント全体の文脈も、このテキストがEUの法令文なのかマーケティングコピーなのかを示す手がかりもないまま、LLMに単独で渡されます。推論時にドメイン文脈を注入しなければ、こうした孤立したリクエストの一つひとつが、用語ドリフトを生む新たな起点になります。

**検索拡張ローカライゼーション（RAL）**は、各翻訳リクエストに対し、推論時にグロッサリー用語、ブランドボイスのルール、ロケール固有の指示を付与することで、このギャップを埋めます。これは検索拡張生成（RAG）と同じ retrieve-inject パターンです。5つのLLMプロバイダーと5つのヨーロッパ言語を対象にした統制評価では、RALによって用語エラーが16.6〜44.6%減少しました。

主な調査結果：

• RALは、検証した5つのLLMプロバイダーすべてで用語エラーを16.6〜44.6%削減した
• 総合品質スコア（GEMBA-DA）では、こうした差を検出できなかった。差分は0.0007〜0.0178にすぎない一方、MQMではエラーが数千件少なく数えられた
• ベースラインの用語スコアが低いモデルほど改善幅が大きかった。Mistral（-44.6%）とDeepseek（-42.1%）に対し、Anthropic（-24.4%）とGoogle（-16.6%）は小幅だった
• ロケール別ではポルトガル語が最大の改善幅を示し、フランス語が最小だった。ドメイン用語が学習データから離れるほど、RALの効果は大きい

孤立の問題#

本番ローカライゼーションの単位は小さいものです。段落、文字列、差分。200語を超えることはまれで、50語未満のことも珍しくありません。JSONのロケールファイルには個別のキーが並び、それぞれに語句や文が入っています。CMSのページもブロック単位で構成され、各ブロックが独立して翻訳されます。

モデルが孤立した英語の段落で "provider" に出会うと、判断を迫られます。ポルトガル語では "fornecedor"（一般的な語）なのか、それとも "prestador"（EU法令上の正式用語）なのか。ドメイン文脈がなければ、一般的なほうを選びます。これが各ロケールのあらゆるドメイン固有用語で繰り返されれば、用語ドリフトがデフォルトになります。

私たちは、このギャップが実際にどれほど大きいのか、そして推論時にグロッサリー文脈を注入することで本当に埋められるのかを測定しました。

最初の試みでは何も見えなかった#

初回の実験では、各ロケールペアにつき37個のグロッサリー用語を使い、記事レベルで翻訳を採点しました。つまり、各記事（200〜700語）を1つの単位として評価したのです。結果はこうでした。GEMBA-DA――WMT23で優勝した総合品質プロンプト――は、素の出力でも設定済みの出力でも0.952でした。MQMのエラー注釈でも、すべての翻訳が0.985〜0.999というスコアになりました。シグナルはなし。差もなし。どの指標で見ても、素の出力とグロッサリー拡張後の出力は同じに見えたのです。

私たちは危うく、差がないという結果をそのまま公開するところでした。そこで、その理由を掘り下げました。

問題は2つありました。第一に、37個のグロッサリー用語では少なすぎました。多くのテスト段落にはグロッサリー該当語が1つもなく、設定済みエンジンに優位性がありませんでした。第二に、記事レベルの採点では、品質差が数学的にノイズへと圧縮されてしまいます。MQMスコアは1 - penalty / wordCountとして計算されます。500語の記事に重大な用語エラーが1件ある場合は1 - 5/500 = 0.99。同じエラーが50語の段落にある場合は1 - 5/50 = 0.90。エラー自体は同じでも、スコアは同じではありません。記事レベルでは、実際の品質差は0.98を超えた領域で見えなくなってしまいます。

これは私たちの研究だけの測定上の問題ではありません。ページや記事レベルで評価するあらゆる翻訳ベンチマークに当てはまります。エラーは確かにあるのに、指標のほうがそれを見つけられないのです。

見方を変えた#

2回目の試行では、4つの変更を加えました。

第一に、グロッサリーを各ロケールペアあたり37語から72語へ拡張しました。抽出元は、評価に使ったテストセットとは別の、記事の訓練セットです。第二に、実際の本番翻訳の単位に合わせて、段落レベル（50〜200語）で採点しました。第三に、審査者が用語を直接比較できるよう、MQM採点プロンプトに人手の参考訳を追加しました。第四に、審査者を6人から4人に減らしました。DeepseekとQWENは段落あたり1〜3件しかエラーを指摘せず、より厳格な審査者の5〜15件に比べて甘すぎ、シグナルを増やせなかったためです。

シグナルはすぐに現れました。

調査設計#

データセット。 私たちは、厳しい条件下でのグロッサリー注入をストレステストするため、利用可能な中で最も用語密度の高いテキスト種別を選びました。EU AI Act（規則2024/1689）はまさにそれに適していました。形式張った規制文書であり、各段落に特定の公式訳が定義された用語が含まれているからです。EUR-Lexは5つの対象言語すべてについて公式の人手翻訳を公開しており、正解データに照らした段落ごとの採点が可能です。対象は15記事、英語からドイツ語、フランス語、スペイン語、ポルトガル語、イタリア語への翻訳です。

エンジン。 各プロバイダーは2つのローカライゼーションエンジン構成でテストしました。raw エンジン（LLM単体。グロッサリーなし、検索なし、学習済み知識だけで翻訳）と、RAL-augmented エンジン（同じモデルに、ドメイングロッサリー、ブランドボイスのプロファイル、ロケール固有の指示を推論時に適用）です。合計10個のエンジンで、すべての RAL-augmented エンジンは同一の構成を共有しました。

QWENは当初含めていましたが、最終セットからは外しました。翻訳が遅く不安定で、審査者から外したのと同じ理由で除外しました。

RAL構成。 各拡張エンジンには、ロケールペアごとに72個のグロッサリー用語（カスタム翻訳70件と非翻訳項目2件）、ブランドボイスのプロファイル（EU規制文書向けのフォーマルな文体）、および13個のロケール固有の指示を設定しました。グロッサリー用語は、評価に使ったテストセットとは別の訓練用記事セットから抽出しています。例：EN "provider" → PT "prestador"（"fornecedor" ではない）、EN "high-risk AI system" → PT "sistema de IA de risco elevado"（"sistema de IA de alto risco" ではない）。推論時には、現在の段落に一致する用語だけを取得してモデルに渡すため、グロッサリーが大きくてもコンテキストウィンドウは膨らみません。エンジンはLingo.dev上で、すべてのリクエストに永続的なコンテキストを適用するステートフルなローカライゼーションエンジンとして構成しました。

採点。 翻訳された各段落は4人のLLM審査者が採点し、個々の審査者バイアスをならすために平均を取りました。各審査者は自分の出力だけでなく、全プロバイダーの出力を採点します。

GEMBA-MQM。 MQM（Multidimensional Quality Metrics）は、翻訳品質評価の標準的なフレームワークで、通常は訓練を受けた人手アノテーターが実施します。GEMBA-MQMは、WMT23で優勝した評価手法で、人手アノテーターをLLMに置き換えつつ、同じMQMプロトコルに従います。つまり、審査者は翻訳を読み、すべてのエラーを指摘し、それぞれにカテゴリと重大度を割り当てます。

エラーカテゴリは、正確性、流暢さ、スタイル、用語です。重大度の重みは公式MQM標準に従い、minor = 1、major = 5、critical = 25です。

段落ごとのMQMスコア：max(0, 1 - weighted penalty / word count)。50語の段落に重大な用語エラーが1件ある場合、スコアは1 - 5/50 = 0.90です。完璧な段落は1.0です。結果表のエラー件数は、特定のプロバイダーとロケールについて、4人の審査者と全段落にわたる合計です。

標準のGEMBA-MQMプロンプトから1点だけ変更しました。人手の参考訳を追加したのです。GEMBA-MQMは設計上、参照訳なしです。つまり、審査者は「正しい」答えを見ずに品質を評価します。今回参照訳を追加したのは、EUR-LexがEU AI Actの公式翻訳を5つの対象言語すべてについて公開しており、審査者が用語を正解データと直接比較できるようにするためです。

GEMBA-DA。 GEMBA-DAプロンプト（これもWMT23優勝）を用いた、0〜1の総合品質スコアです。MQMと異なり、エラー注釈なしで単一のスコアを出力します。結果が示す通り、これを妥当性確認として含めていますが、用語レベルの差は検出できません。

Deepseekは採点が甘すぎたため、審査者パネルから除外しました（段落あたり1〜3件のエラーに対し、より厳格な審査者は5〜15件）。4人の審査者で平均を取ることで個々のバイアスをならし、raw と RAL の相対的な改善は各審査者内でも一貫していました。

サンプルサイズ。 プロバイダーごとに535件のペア段落観測（107段落 × 5ロケール）。個別の品質判定は合計42,000件超（535段落 × 5プロバイダー × 2構成 × 各8スコア）です。

用語エラーは16.6〜44.6%減少#

15記事・5ロケール・4人の審査者にまたがるMQMの用語エラー件数。

改善幅はベースラインスコアに反比例していました。raw のエラー件数が最も多かったMistralとDeepseekでは、42.1〜44.6%の削減が見られました。一方、学習時点ですでにEU法令用語をより多く取り込んでいたAnthropicとGoogleでは、改善幅は小さめでした。このパターンが示しているのは、RALがモデルに不足している知識を補うということです。

一方、総合スコアであるGEMBA-DAでは、全プロバイダーで raw と RAL の差分は0.0007〜0.0178と報告されました。MQMが16.6〜44.6%多い用語エラーを指摘した同じ翻訳が、総合スコアではほぼ同一と判定されたのです。これが測定ギャップです。どの粒度で見ても、総合評価では用語レベルの品質差を検出できません。

総エラー数（MQMの全カテゴリ）でも、5つのプロバイダーすべてで一貫して減少が見られました。ただし、削減幅は用語エラーほど大きくはありませんでした。

用語エラーの削減率（16.6〜44.6%）と全体の削減率（3.1〜13.5%）の差は、主にスタイルで説明できます。LLMの評価者は、たとえ公式リファレンスに近づく方向への違いであっても、学習データ上の好みから外れるとテキストを「不自然」と判定しがちです。これは自己選好バイアスと呼ばれる、よく知られた限界です。用語と正確性はリファレンスを基準に評価できますが、スタイルには評価者自身の「自然に聞こえるか」以外の拠りどころがありません。

統計的有意性#

用語エラーの削減は、各プロバイダーごとに対応のあるWilcoxon符号付順位検定で検証しました（片側検定、5プロバイダー間の比較にはHolm-Bonferroni補正を適用）。段落ごとの用語エラー数は4人の評価者分を合算し、そのうえで段落単位で対応付けています（同一ソース、同一評価者、Raw vs RAL）。

5つのプロバイダーすべてで、用語エラーの削減は統計的に有意でした（多重比較に対するHolm-Bonferroni補正後も p < 0.001）。95%信頼区間はいずれも0を含んでいません。効果量は中〜大（Mistral、d = 0.60）から小（Google、d = 0.20）まで幅があり、ベースラインの用語カバレッジが低いモデルほどRALの恩恵を大きく受けるという傾向とも一致しています。

RALが最も効果を発揮する領域#

ポルトガル語は、すべてのプロバイダーで最も大きな用語改善を示しました。ポルトガル語の法務用語は日常的なポルトガル語との隔たりが大きく、EUの法務用語もポルトガル語ではLLMの学習データに十分含まれていません。一方、最も改善幅が小さかったのはフランス語でした。フランス語の法務用語は、学習コーパス内で十分に表現されているためです。

この傾向は一般化できます。ドメイン用語がLLMの学習分布から離れているロケールほど、RALの効果は大きくなります。

仕組み#

仕組みはシンプルです。推論時、エンジンは入力テキストをn-gramのフレーズに分解し、それを埋め込みベクトル化します。次に、用語集のベクトルインデックスに対してコサイン類似度検索を行い、一致する用語を見つけます。見つかった用語は、ソーステキストと一緒にLLMのコンテキストウィンドウへ注入されます。モデルは「fornecedor」か「prestador」かを推測しているのではありません。文脈の中で正しい対応関係を見たうえで、それを使っているのです。構造はRAGとまったく同じです。埋め込み、検索、注入、生成。

Raw品質によるプロバイダー順位#

RALなし — Rawモデル出力のみ：

AnthropicとDeepseekの0.072ポイント差は、100語の段落あたりおよそ3〜4件の追加エラーに相当します。RALはこの差を縮めました。RALを適用したMistral（平均0.940）は、GoogleのRaw品質（0.938）に迫っています。1トークンあたりのコストがその数分の一のモデルでも、72語の用語集で拡張すれば、より高価なモデルを用語集なしで使った場合と同等の用語精度に到達できました。

これが本番運用で意味すること#

RawのLLM出力と、本番投入できるローカライズ品質とのギャップはコンテキストの問題です。そしてその問題は、時間とともに積み上がっていきます。RALなしで10回リリースすれば、「provider」の誤訳が3種類、同じプロダクト内に共存することになります。

RALはこのパターンを断ち切ります。用語集は永続的に機能し、何が変わったかに関係なく、すべてのリクエストに適用されます。今回の調査でエラーを16.6〜44.6%削減した72語の用語集は、一度きりの改善ではありません。プロダクトのライフタイム全体を通じて、あらゆる翻訳リクエストに一貫性をもたらすレイヤーです。

LLM翻訳を本番で運用するチームにとって、重要な発見は2つあります。第一に、総合的な品質スコアでは用語レベルの問題を検出できないということです。WMT23で優勝した手法であるGEMBA-DAでは、Raw翻訳とRALで拡張した翻訳のスコア差は0.0007〜0.0178にとどまりました。一方、MQMでは用語エラーが16.6〜44.6%少なくカウントされました。ページ単位を単一スコアで評価しているなら、見えていないものがまだあります。

第二に、解決策は問題の見た目ほど複雑ではありません。推論時に注入するドメイン用語集だけで、私たちがテストしたすべてのプロバイダーにおいて用語エラーは減少しました。最も翻訳品質が高いモデル（Anthropic、MQM 0.955）でも改善し、ベースラインのエラー率が最も高いモデル（Deepseek、MQM 0.883）が最も大きく改善しました。

RALは、ローカライゼーションにおけるRAGです。生成におけるRAGと同じく、モデルと本番運用の間をつなぐエンジニアリングレイヤーです。

次のステップ#