Azure AI Search、language analyzer選定をRAG品質の設計論点として解説

Microsoft Foundry Blog は 2026年5月29日、Azure AI Search で language analyzer をどう選ぶべきかを解説しました。Language analyzer は、対象言語のルールに基づいて lexical analysis を行う text analyzer であり、検索品質や RAG の retrieval 品質に直結する設定です。

要点

• language analyzer は、単語分割、正規化、語形変化の扱いなど、検索一致の前処理を左右する
• Azure AI Search や RAG では、モデルやプロンプト以前に retrieval の品質が重要になる
• 多言語コンテンツや日本語・英語混在の社内文書では、analyzer 選定の影響が大きい
• field ごとに analyzer を設計し、評価クエリで比較する必要がある

今回のブログ記事で語られていること

この記事は、Azure AI Search の地味だが重要な設定である language analyzer を扱っています。RAG や enterprise search では、LLM の回答品質が注目されがちですが、そもそも検索で適切な文書が取れていなければ、モデルは正しい回答を作れません。Analyzer はその検索結果の土台です。

Language analyzer は、言語ごとの形態や語彙のルールに合わせて、テキストを検索しやすい単位に分解します。英語、フランス語、日本語、中国語などでは、単語境界、語形変化、複合語、記号、数字、固有名詞の扱いが違います。標準 analyzer のままで十分な場合もありますが、言語特性が強いデータや専門用語の多いデータでは、検索漏れや過剰一致の原因になります。

実務では、ひとつの index 全体に同じ考え方を当てるのではなく、field ごとに設計する必要があります。製品名、ドキュメント本文、タイトル、タグ、コード片、ID、型番では、検索したい振る舞いが異なります。たとえば本文には言語 analyzer が有効でも、ID や product code には余計な分割を避けたい場合があります。

RAG の観点では、analyzer は embedding や reranking とも切り離せません。Keyword search、semantic search、hybrid retrieval を組み合わせるとき、どの field がどの analyzer で処理されるかによって、候補文書の集まり方が変わります。回答生成の前段で retrieval recall が落ちている場合、prompt を直すだけでは改善しません。

実務で確認したいポイント

まず、検索対象の言語構成を把握してください。日本語だけなのか、英語だけなのか、日本語・英語・コード・製品名が混在するのかで analyzer の選び方は変わります。

次に、実際の問い合わせログや想定質問を使って、analyzer 別に上位検索結果を比較します。RAG の評価では、回答文だけでなく、取得された chunks が正しいか、取りこぼしがないかを見ることが重要です。

結局、このブログ記事をどう読むべきか

Azure AI Search の language analyzer は、設定項目としては小さく見えますが、RAG 品質の土台です。検索精度に課題があるチームは、モデルや prompt の前に、index 設計、field 設計、analyzer 選定を見直す価値があります。