RAGの検索精度を高める設計術:質問の正規化とドキュメントマッチングとは|LLM入門 6.2

6.2 質問の正規化とドキュメントマッチング
RAG(Retrieval-Augmented Generation)の品質を決定づける要素のひとつが、Retriever の性能です。
Retriever の役割は、ユーザーの質問に対して意味的に近い情報を文書群から探し出すことですが、その成功は「検索対象」だけでなく「検索に用いられるクエリ」の質にも大きく依存します。
このセクションでは、ユーザーからの自然文の質問を検索に適した形式へと整える「質問の正規化」と、それを元により適切な文書チャンクを選び出す「ドキュメントマッチング」の実践的な設計について解説します。
なぜ「質問の正規化」が必要なのか?
ユーザーからの質問文は、そのままでは曖昧だったり、口語的だったり、文脈依存の表現が含まれていることがよくあります。
例:
-
「これって退職後も保険って続くんですか?」
-
「3ヶ月前の制度改定、反映されてる?」
-
「結局どれが対象になるの?」
こうした質問をそのままベクトル化して検索すると、埋め込みモデルが意味を誤って解釈し、的外れなチャンクがヒットすることがあります。
そこで、「誰が、何を、どのように、なぜ尋ねているか」という観点から、質問を意味的に整理・変換してからRetrieverに渡す、というステップが効果的です。これが「質問の正規化(Query Normalization)」です。
正規化の例とテクニック
以下は、よくある質問の「正規化」前後の例です:
元の質問 | 正規化後の検索クエリ |
---|---|
「これって保険まだ使えます?」 | 「退職後に健康保険を継続利用できるかどうか」 |
「前の制度いつ終わったの?」 | 「旧制度の終了時期と新制度の開始時期」 |
「アルバイトでも対象?」 | 「雇用形態がアルバイトの場合の制度適用条件」 |
テクニック:
-
曖昧語の除去:「これ」「それ」「あれ」など指示語を具体化する
-
主語と動詞の明確化:「誰が何をするか」を明確にする文に変換
-
意図の補完:質問文に含まれた目的(何を知りたいのか)を表出させる
-
社内用語の変換:略語・部内俗語を正式な制度名に変換(例:「インセン」→「インセンティブ制度」)
この処理は、RuleベースでもLLMベースでも実装可能で、特にLLMによるリライティングは自然で柔軟な正規化に有効です。
マッチング戦略:検索対象との適合性を高める
質問が正規化されたあとは、それにマッチする文書チャンクをどう選ぶかが問題になります。
RAGのRetrieverでは一般的にベクトル検索(意味検索)が使われますが、より精度を高めるためには、以下のようなマッチング強化戦略が有効です。
- スコアリングとフィルタリング
-
ベクトル類似度に加え、文書のカテゴリ・作成日・タグを条件に絞り込み
-
類似度の閾値を設定し、過剰なマッチを除外
- 質問の分類とドキュメントのスコープ調整
-
質問を「制度」「手続き」「FAQ」などのカテゴリに分類し、対象の文書範囲を限定
-
LangChain などでは
MultiQueryRetriever
やSelfQueryRetriever
がこうした調整を支援
- メタデータ付きチャンク設計
-
文書の内容だけでなく、発行元や適用対象などの情報をチャンク単位で保持
-
質問の条件に合うチャンクを意味+メタで選定
Retrieverの前段に設計の知恵を込める
質問の正規化とドキュメントマッチングは、検索精度を左右する「最初の分岐点」です。Retrieverの性能だけに頼るのではなく、入力と対象の双方を丁寧に整える設計によって、RAG全体の精度と安定性が向上します。
RAGシステムにおいては、「検索」が生成の入口です。だからこそ、「検索にかける質問」そのものをデザインするという視点が重要なのです。
Retriever後のプロンプト合成パターン
次のセクション「6.3 Retrieval後のプロンプト合成パターン」では、Retrieverで得られたチャンクをどのようにLLMに渡すか、つまりプロンプトとしての合成方法やテンプレート設計について解説します。いよいよRAGの中心である「生成の質」を高める構造へと踏み込んでいきます。

下田 昌平
開発と設計を担当。1994年からプログラミングを始め、今もなお最新技術への探究心を持ち続けています。カテゴリー
検索履歴
チーム

任 弘毅
株式会社レシートローラーにて開発とサポートを担当。POSレジやShopifyアプリ開発の経験を活かし、業務のデジタル化を促進。

下田 昌平
開発と設計を担当。1994年からプログラミングを始め、今もなお最新技術への探究心を持ち続けています。