あなたはドイツチームのためにチャットボットを出荷します。UIはドイツ語です。ソースドキュメントの一部はドイツ語、一部は英語です。アシスタントの背後にあるツールは、英語の列挙値、英語の関数説明、英語の製品名、すべてを期待しています。
そして、誰かがドイツ語でごく普通の質問をすると、モデルは適切なツールを選択し、英語の代わりにドイツ語で1つの引数を渡します。
私はこのようなバージョンを何度も見てきたので、もはや翻訳の問題だとは思っていません。**実行の問題です。
私の現在のデフォルトはシンプルで、ユーザーに好きな言語を話させ、LLMに検索、推論、ツール作業を英語で行わせるというものです。そして、そのループの外側で答えをローカライズします。
最初は少し異端に聞こえるかもしれません。私の意見では、今できる最も実用的なことです。
研究は声高にこう言い始めています
数字はもう微妙ではありません。
MASSIVE-Agentsベンチマーク](https://aclanthology.org/2025.findings-emnlp.1099/)では、52言語、47,020サンプル、21モデルで多言語関数呼び出しを評価しました。全言語の平均スコアの最高はわずか34.05%でした。英語は57.37%でした。アムハラ語は6.81%に落ちました。
これは小さな品質のぐらつきではありません。信頼性の崖です。
次に、Lost in Executionがあります。これは実際のシステムの問題にさらに近づいたものです。この論文は、多言語ツール呼び出しの失敗の多くが、モデルがすでに意図を理解し、正しいツールを選択した後に起こることを示しています。支配的な問題は、パラメータ値の言語の不一致でした。平たく言えば、モデルは何をすべきかを知っていたが、実行可能なビットをインターフェース言語ではなくユーザーの言語で表現したため、呼び出しに失敗したということです。
これはツール呼び出しに限ったことではありません。Etxanizたちは、Do Multilingual Language Models Think Better in English?で、5つのタスクにおいて、英語への自己翻訳が英語以外の直接推論よりも一貫して優れていることを発見しました。彼らの言い回しは、「英語以外の言語でプロンプトが出された場合、モデルは多言語の可能性をフルに活用することができない」というもの。
そう、多言語モデルは素晴らしい。しかし、「かなり良さそうだ」ではなく、「本番で正しく動作する必要がある」という基準であれば、英語がより安全な動作言語であることが非常に多いのです。
同じ場所でRAGが壊れる理由
この議論を聞いた人は、まずエージェントを思い浮かべるでしょう。関数の呼び出し、構造化された出力、APIの実行、そういったものです。
RAGにも同じ弱点があります。
検索レイヤが、一貫性のない用語、翻訳された商品名、中途半端にローカライズされたタクソノミーラベルなど、様々な言語で書かれたコンテンツに対して、ユーザのローカルな言い回しをマッチングさせなければならない場合、生成が始まる前にシステムがドリフトする可能性が高まります。正直なところ、「モデルが信頼できない」という不満の多くはここから来ています。モデルは問題ないかもしれません。コンテンツ・インターフェースはそうではありません。
私はむしろ早期に正規化することを望みます。
質問を英語に翻訳。英語の正規コーパスに対して検索。1つの安定した専門用語レイヤーをモデルに推論させます。必要であれば、英語の回答ドラフトを生成します。その後、ユーザーのために最終的な回答を翻訳またはローカライズします。
これで、ネーミングが安定した1つの場所になります：
- 正規の文書タイトル
- 正規の製品語彙
- 正規のツール・スキーマ
- 検索ラベルの正規セット
外部ですべてのユーザー言語をサポートすることはできます。コアとなる実行パスに、すべてのステップで完全に多言語であることを求めるのをやめるだけです。
これは反ローカリゼーションではありません
正反対です。
悪質な多言語AIアーキテクチャは通常、ローカルユーザーを最初に傷つけます。素敵なローカライズされたインターフェイスを手に入れた後、その下に隠された英語中心のシステムが矛盾した振る舞いをし、その代償を払わされるのです。
適切なローカライゼーションとは、言語が柔軟になるべきところとそうでないところについて、正直であることを意味します。
私の場合、その分かれ目は次のようなものです：
- UI、プロンプト、ヘルプテキスト、オンボーディング、最終的な回答をローカライズします。
- 市場で存在する必要があるコンテンツは、人々が直接読むソースコンテンツをローカライズします。
- 内部ツールの定義、正規識別子、検索ラベル、推論ピボットは、それが最も安定したレイヤーであれば、英語のままにしておきます。
- ローカライズされた出力が法的、規制的、または契約上の重みを持つ場合は、明示的な後処理または人間によるレビューを追加します。
この最後のポイントは、チームが認めたがっている以上に重要です。モデルが人間と会話している場合、ローカライゼーションはユーザーエクスペリエンスの決定です。モデルが他のシステムと会話する場合、言語はインターフェイス契約です。
これらは同じものではありません。
私が今最も信頼しているアーキテクチャ
これは、多言語AI製品のために今日私が賭けるバージョンです：
1.1.ユーザーは自分の言語で質問します。 2.システムはそのリクエストを英語に翻訳または正規化します。 3.検索、推論、ランキング、ツール呼び出しは、英語の正規データに対して発生します。 4.最終的な回答はユーザーの言語にローカライズされます。 5.高リスクの出力は、システムを離れる前に余分な検証ステップを取得します。
それは哲学的に純粋ではありません。運用上はまともです。
素晴らしいことに、最近の研究も同じ方向を示しています。Lost in Executionは、ユーザークエリを事前に翻訳することで、英語レベルのパフォーマンスを完全に回復させることはできなかったとしても、一般的に、その場限りの修正よりも言語のミスマッチエラーを減らすことができることを発見しました。これは、すでに多くのビルダーが実際に疑っていることと一致します。多言語の不一致を解消するのを最後まで待つと、たいていは手遅れになります。
そして、例外もあります。低リソース言語、ドメイン特有の言語、文化に依存した言い回しのために構築する場合、すべてを英語に翻訳するとドリフトが発生する可能性があります。上記の論文では、その点について明確に警告しています。ですから、これをドグマにしてはいけません。
しかし、企業のコパイロット、社内アシスタント、多言語RAG、ツールを使用するエージェントのデフォルトとして、このルールは驚くほどうまく機能すると思います。
これがラセピにとって意味すること
これこそが、私が正規化されたコンテンツ構造にこだわる理由です。
もし、知識ベースが1つのクリーンなソースレイヤー、安定した用語集、管理されたローカライゼーションの上にあれば、AIは信頼しやすくなります。すべての言語バージョンが実行パスの中で独立して漂うなら、システムが正確であるべきところで、モデルに即興を求めることになります。
ラセピのアプローチ全体は、これらの懸念をきれいに分離することに基づいて構築されています。標準的なコアを維持します。意図的にローカライズします。バリアントが存在する場所を追跡します。UIが多言語だからといって、スタックのすべてのレイヤーが同じように多言語であるかのように装わないでください。
私は以前、最高の多言語AIエクスペリエンスとは、"ユーザーの言語ですべてを行う "ことだと思っていました。しかし、今はそうは思いません。正しい段落を取得し、正しいツールを選択し、信頼できるものを返さなければならないシステムのためではありません。
しかし、LLMの実行パスは安定していなければなりません。今現在、それは通常、真ん中では英語、端ではローカライズを意味します。
それは時間とともに変わっていくでしょう。早く変わることを願っています。しかし、もしあなたが今日出荷していて、美しさよりも信頼性の方が重要なのであれば、私はモデルに英語で考えさせ、製品にユーザーの言語をしゃべらせます。