ローカライゼーションパイプラインが、用語集用語をモデルのコンテキストウィンドウに注入するために検索拡張生成を使っているなら、そこにはこれまで一度も測定されてこなかった検索リコールの問題があります。
パターンはどこも同じです。入力テキストを埋め込み、用語バンクをコサイン類似度で検索し、上位k件をプロンプトに注入する。出力は文法的には正しい。用語は間違っている。このエラーは、両方の言語がわかり、なおかつ用語集も把握している人でないと見抜けません。
私たちも最初はこの素朴な実装から始めました。ところが、本番用語集に対して検索リコールを測ってみると、実際のペイロードでは適用可能な用語の大半をシステムが取りこぼしていることがわかりました。
| 手法 | 検索拡張ローカライゼーション（RAL）— 推論時のコンテキスト拡張 |
| 中核となる修正 | 埋め込み前にNグラム分解を行う。文レベル埋め込みではない |
| 検索モード | 3種類（skip / preload / vector search）。用語集のカーディナリティに応じて、リクエストごとに選択 |
| しきい値キャリブレーション | ロケールペアごとの品質スコアに対して、継続的に毎週実施 |
| 用語エラーの削減 | 5つのLLMプロバイダー全体で17〜45%（統制研究、42,000件超の品質評価） |
| スコアリング | 独立したクロスモデル評価、非同期、リクエスト単位 |
なぜ文埋め込みでは用語集用語を見逃すのか？#
用語集用語は1〜3語です。"Localization engine"。"Access token"。"Deployment pipeline"。
入力テキストはJSONオブジェクトで、値は2語のもの（ボタンラベル）から200語のもの（製品説明）までさまざまです。文字列全体 "Configure the localization engine for production deployment" を埋め込むと、得られるベクトルは文全体の意味、つまり設定や本番システムに関する情報を表現します。用語集にとって重要なフレーズである "localization engine" は、その文レベル表現の中に溶けてしまいます。
その文ベクトルと用語集エントリ "localization engine" のコサイン類似度は0.6〜0.7程度に収まります。検索しきい値を下回る水準です。用語は入力内に存在しているのに、検索システムは見逃してしまいます。
問題は粒度です。文レベルの表現で、フレーズレベルの対象を検索しているのです。埋め込みモデルは文全体の意味を忠実に表現します。構成要素である用語には、ベクトル空間内で独立した領域が与えられません。
私たちはこれを痛い形で学びました。本番ペイロード、つまり20〜50個のキーを持つネストされたJSONオブジェクトで、値の長さもさまざまなデータを対象にすると、文レベル検索では適用可能な用語集用語の大半を取りこぼしていました。ローカライゼーションリクエスト自体は問題なく完了します。出力も自然に読めます。ですが、"localization engine" が "translation tool" になってしまう。文法的には正しく、意味的にも近い。それでも用語としては誤りです。そしてパイプラインは成功として報告されるのです。
Nグラム分解は、どうやって用語集検索を改善するのか？#
解決策は、埋め込みの前に入力をフレーズレベルの単位へ分解することでした。各文字列値は、重なり合うNグラムウィンドウの集合になります。
Input: "Configure the localization engine for production"
1-grams: [configure, the, localization, engine, for, production]
2-grams: [configure the, the localization, localization engine,
engine for, for production]
3-grams: [configure the localization, the localization engine,
localization engine for, engine for production]各Nグラムは独立した検索クエリになります。"Localization engine" は単独のフレーズとして用語集を検索し、高い類似度で一致項目を見つけます。
分解パイプラインは次のとおりです。
- ネストされたJSON構造から、すべての文字列値を再帰的に抽出する
- 文に分割し、HTMLとマークアップ注釈を取り除く
- 空白を正規化し、外側の引用符を除去し、書式エスケープを解除する
- 各文から、重なり合う1-gram、2-gram、3-gramのフレーズを生成する
50語の段落からは、およそ150個のNグラムが生成されます。20個のキーを持つ典型的なAPIペイロードでは、検索可能なフレーズが1,000〜3,000個になります。各フレーズは独立して埋め込まれ、それぞれの埋め込みが用語集のベクトルインデックスに対して最近傍検索を実行します。
私たちは、もともとの問題をあぶり出したのと同じ本番ペイロードで差分を測定しました。すると用語集用語は、その前後の文脈に左右されず一致するようになりました。200語の製品説明に埋もれた2語の用語でも、単独のラベルと同じリコールで取得できます。
適応的検索は、用語集サイズの違いにどう対応するのか？#
大規模な用語集には、Nグラム分解とバッチ埋め込みが正しいアプローチです。一方で、小規模な用語集に対しては計算コストの無駄になることがわかりました。
8個の用語集用語で構成されたローカライゼーションエンジンなら、直接注入のほうが高速です。データベースクエリは1回、決定的で、サブミリ秒で完了します。2,000件の用語を持つローカライゼーションエンジンでは、ベクトル検索が必要になります。コンテキストウィンドウの制約と関連性の希薄化により、全件注入は不可能だからです。
検索モードは3つあり、ロケールペアに対する用語集のカーディナリティに応じて、リクエストごとに選択されます。
| モード | 条件 | 動作 |
|---|---|---|
| Skip | 一致項目が0件 | 埋め込みなし、検索なし、注入なし |
| Preload | カーディナリティしきい値未満 | 単一のデータベースクエリですべての一致項目を読み込み、直接注入 |
| Search | カーディナリティしきい値超過 | 完全なNグラム分解 → バッチ埋め込み → ベクトル最近傍検索 |
preloadとsearchを分けるカーディナリティしきい値は、本番トラフィック全体のレイテンシープロファイリングから導き出され、埋め込みモデルの性能、用語集サイズの分布、インフラ特性の変化に応じて調整されます。最初にリリースした値は、テレメトリが見直しを示すまでおよそ3週間しか持ちませんでした。それ以降も何度も調整しています。エンジンに用語集用語が蓄積され、プロバイダー更新に伴って埋め込みモデルの特性が変わるにつれて、最適なしきい値もずれていくことがわかったからです。
検索レイテンシーは、ペイロードサイズではなく用語集の複雑さに応じてスケールします。10個の用語を持つローカライゼーションエンジンなら、入力長に関係なく1桁ミリ秒で完了します。500個の用語を持つローカライゼーションエンジンでは完全な分解パイプラインを使いますが、それでも耐久性のあるバックグラウンドワークフローステップのレイテンシー予算内に収まります。
用語集検索の類似度しきい値は、どうキャリブレーションするのか？#
各Nグラム埋め込みは、類似度しきい値を超える最近傍をベクトルインデックスに問い合わせます。しきい値未満の一致はノイズとして破棄されます。
このしきい値は、検索精度とリコールを同時に左右します。
- 緩すぎる場合: 無関係な用語がプロンプトに入り込みます。モデルは入力に当てはまらない用語集コンテキストを見て、ときにそれに従ってしまい、無関係なドメインの用語を使った出力を生成します。
- 厳しすぎる場合: 妥当な言い換えや形態変化が除外されます。"Deploying" が用語集エントリ "deploy" と一致しなくなる。リコールは下がります。
適切なしきい値はロケールペアごとに異なることがわかりました。英語→ドイツ語の検索では、英語→日本語とは異なる類似度分布になります。後者では、ソースNグラムと用語集エントリのあいだの形態的距離が構造的に異なるからです。単一のグローバルしきい値では、測定したロケールペア間でリコールにばらつきが出ていました。
現在、このしきい値は独立したスコアリングパイプラインから得られるロケールペアごとの品質スコアに対して継続的にキャリブレーションされています。スコアリングシステムが、用語集非準拠（入力にはあるのに出力にはない用語）の増加を検出した場合、検索リコールが劣化しているため、しきい値は緩められます。モデルが無関係な用語を適用していることを検出した場合は、偽陽性の注入が増えているため、しきい値は厳しくされます。
このキャリブレーションは毎週実行されます。そうせざるを得ません。埋め込みモデルの挙動はプロバイダー更新のたびに変化し、チームが用語を追加することで用語集の分布も変わり、製品の成長に伴って入力テキストの特性も変化していくからです。
取得した用語集用語は、どうローカライゼーションモデルに注入されるのか？#
取得した用語集項目は、モデルのシステムプロンプト内で異なる強制挙動を持つ2つの制約クラスに分かれます。
非翻訳語 — ターゲット出力にそのまま現れなければならないソース言語の文字列。ブランド名、技術識別子、製品名。モデルはこれらを一字一句そのまま保持します。
カスタム翻訳 — モデル自身の判断を上書きするソース→ターゲットの対応。"Localization engine" は必ず "moteur de localisation" にならなければならない。モデルはこれを交渉の余地がない語彙制約として扱います。
どちらのクラスも、モデルのデフォルト挙動より明示的に優先されるルールとしてシステムプロンプトに注入されます。このプロンプト階層によって、モデルの言語的な好みよりも用語集準拠が優先されます。
この区別はスコアリング時に重要です。独立したスコアリングモデルは、非翻訳語が変更されず保持されたか、カスタム翻訳が正確に適用されたかを確認します。制約タイプが2つある以上、検証基準も2つ必要です。私たちは早い段階で、これらを単一の「用語集」カテゴリにまとめるとスコアリングが信頼できなくなることを発見しました。翻訳されるべき用語がそのまま保持されていた場合（またはその逆）でも、統一されたチェックでは正しいと判定されてしまうからです。
話せない言語のローカライゼーション品質を、どう検証するのか？#
検索とローカライゼーションのパイプライン全体は、エラーなく実行され、それでいて用語的には誤った出力を生成し得ます。見逃された用語集用語は、何のエラーシグナルも出しません。誤って適用されたカスタム翻訳でも200が返ります。パイプラインは成功する。出力は間違っている。
これが、多くのチームが最後まで埋められないローカライゼーションの可観測性ギャップです。
検索は、独立した非同期スコアリングと組み合わされています。ローカライゼーションリクエストが完了した後、別個のスコアリングモデルがローカライゼーションエンジンの設定に照らして出力を評価します。
- 用語集準拠 — 非翻訳語は保持されたか。カスタム翻訳は正確に適用されたか。
- 指示準拠 — ロケール固有のルールは守られたか。
- カスタムスコアリング基準 — ローカライゼーションチームがローカライゼーションエンジンごとに定義する品質指標
スコアリングモデルは、ローカライズモデルとは別のインフラで動作します。処理はバックグラウンドのワークフローで非同期に実行され、スコアリングを有効にしたローカライゼーションエンジンを通るすべてのリクエストの後に起動されます。ローカライズするモデルと、スコアを付けるモデルは別です。こうしたクロスモデル評価によって、自己採点の問題を回避できます。
スコアリング結果は、検索キャリブレーションの改善にフィードバックされます。
- スコアリングによって、あるロケールペアで用語集への準拠率が下がりつつあることが検知される
- 調査の結果、検索の再現率が低下していることが判明。しきい値が現在の用語集分布に対してずれていた
- しきい値を調整すると、再現率が回復し、準拠スコアも安定する
このループこそが、システムを自己修正型にします。スコアリングは、検索だけでは得られない可観測性をもたらします。これがなければ、チームは自分たちが話せない言語向けのローカライズ済みコンテンツを出荷しながら、自分たちで整備した用語集が本当に適用されているのかを知る手がかりを持てません。
なぜ検索の再現率は時間とともに効いてくるのか？#
用語集の用語が正しく適用されたローカライズリクエストは、そのたびにプロダクト全体の用語の一貫性を強化します。逆に、用語を取りこぼしたリクエストはドリフトを生みます。ある画面では「ローカライゼーションエンジン」、別の画面では「localization tool」、さらに別の画面では「localization module」といった具合です。これが30のロケール、毎週のリリースという環境で積み重なると、不整合は複利的に増えていきます。
検索の再現率が高いか低いかの違いは、1リクエストごとの品質差にとどまりません。これは一貫性を積み上げていく仕組みそのものです。再現率が高ければ、用語集はあらゆる画面、あらゆるロケール、あらゆるリリースで均一に効きます。再現率が低ければ、用語集はたまにしか効かず、構造的には用語集がないのとほぼ同じです。違うのは、劣化が少し遅いという点だけです。
ローカライゼーションエンジニアリングにとっての意味#
ここで説明している検索の問題は、特定の実装だけに当てはまるものではありません。埋め込みベースの検索で用語集を意識したローカライズを行おうとする、あらゆるシステムに共通する構造的な課題です。文レベルの入力表現とフレーズレベルの用語集ターゲットの粒度のズレは、どの埋め込みモデルを使うか、どのベクトルデータベースを使うか、どのLLMが出力を生成するかに関係なく発生します。
ローカライゼーション自動化を構築するチームには、2つの選択肢があります。見えない再現率ギャップを抱えたまま文レベル検索を受け入れるか、そのギャップを埋めるための分解とキャリブレーションの基盤を作るかです。後者には、3つのシステムが必要です。n-gram分解、適応型検索、そしてしきい値管理にフィードバックするスコアリングループです。それぞれに固有の運用サイクルがあります。分解ロジックは入力形式の変化に合わせて進化し、検索しきい値は用語集の拡大に応じて変動し、スコアリング基準はローカライゼーションチームが自分たちのコンテンツで何を重視すべきかを学ぶにつれて洗練されていきます。
本番品質の検索拡張ローカライズは、一度作って終わりの仕組みではありません。継続的に構築し、計測し、観測し、調整していくエンジニアリング実践です。この領域で立ち上がりつつあるローカライゼーションエンジニアリングという分野は、その運用上の現実を反映しています。ローカライゼーションインフラには、バックエンドサービスやCI/CDパイプライン、可観測性スタックと同じように、継続的な注意が必要です。
次のステップ#
FAQ#
検索拡張ローカライズ（RAL）とは何ですか？ 検索拡張ローカライズは、推論時に各ローカライズリクエストへ用語集の用語、ブランドボイスのルール、ロケール固有の指示を付与する手法です。つまり、RAGで使われる retrieve-inject パターンをローカライズに応用したものです。5つのLLMプロバイダーと5つの欧州言語を対象にした統制実験では、RALはコンテキスト拡張なしの同一モデルと比べて、用語エラーを17〜45%削減しました。
なぜ文レベルの埋め込みでは用語集の用語を取りこぼすのですか？ 用語集の用語は通常1〜3語です。これを文全体の一部として埋め込むと、文レベルの意味ベクトルの中に埋もれてしまいます。埋め込みが捉えるのは、あくまで文全体の意味です。たとえば「Configure the localization engine for production」という文の中にある「ローカライゼーションエンジン」は、それ単体では認識されません。その結果、文ベクトルと用語集エントリのコサイン類似度が検索しきい値を下回ります。
n-gram分解はどのように検索の再現率を改善するのですか？ 入力文字列全体をそのまま埋め込むのではなく、システムは埋め込み前にテキストを重なり合う1-gram、2-gram、3-gramのフレーズへ分解します。各フレーズは独立した検索クエリになります。200語の段落に埋もれた2語の用語集用語でも、単独のラベルと同じ再現率でマッチします。周囲のコンテキストとは切り離して検索されるからです。
システムは何種類の検索モードを使いますか？ 3種類です。スキップ（用語集項目がゼロで検索不要）、プリロード（基数しきい値未満なら全項目を直接読み込む）、ベクトル検索（しきい値を超えた場合は完全なn-gram分解と埋め込みを実行）です。モードは、対象のロケールペアにおける用語集の基数に基づいて、リクエストごとに選択されます。
類似度しきい値はどのように維持されますか？ しきい値は、独立したスコアリングパイプラインから得られるロケールペアごとの品質スコアに対して、毎週キャリブレーションされます。用語集への非準拠が増加傾向にある場合は、再現率を改善するためにしきい値を緩めます。逆に、無関係な用語がプロンプトに入り込む場合は、しきい値を厳しくします。必要なしきい値は、形態的な距離の違いによりロケールペアごとに異なります。
ローカライズ品質におけるクロスモデルスコアリングはどのように機能しますか？ 各ローカライズリクエストの完了後、別のインフラで動作する別モデルが、用語集の用語が正しく適用されたか、ロケール固有の指示に従っているか、カスタム品質基準を満たしているかを評価します。ローカライズするモデルと、スコアを付けるモデルは別です。これにより自己採点バイアスを排除し、検索だけでは得られない可観測性を実現します。
用語集検索の再現率が低いと何が起こりますか？ 検索の再現率が低いと、用語集の適用にムラが出ます。ある画面では正しい用語が使われ、別の画面では使われません。これが30超のロケールと毎週のリリースをまたいで積み重なると、用語のドリフトへとつながります。用語集は存在していても、実際には効いていません。数か月たてば、構造的には用語集がないのと同じ状態になります。
ローカライゼーションの可観測性ギャップとは何ですか？ ローカライゼーションパイプラインは、エラーなく実行されていても、用語的には誤った出力を返すことがあります。用語集の取りこぼしは、エラーシグナルを生みません。APIは200を返し、翻訳としても文法的には成立しています。可観測性ギャップとは、「パイプラインは成功した」と「用語は正しい」のあいだにある空白です。独立したスコアリングは、すべてのリクエストで用語集準拠を測定することで、このギャップを埋めます。
