目次
社内FAQや製品マニュアルをAIに読ませたのに、別の製品の説明が混ざる。該当するページがあるはずなのに、回答が曖昧になる。このようなRAGの問題は、指示文を強くしたり、大きいモデルへ変更したりするだけでは解決しないことがあります。
RAGは、質問に関連する資料を検索し、その結果を使って回答する構成です。必要な根拠が検索結果に入っていなければ、生成側だけを調整しても改善に限界があります。本記事ではアクセス権限を扱った既存記事とは観点を変え、資料を正しく見つけ、必要な文脈を渡すための品質管理を深掘りします。
2026年10月20日に確認したMicrosoftの公式資料を参照した実装解説です。特定の製品の導入を前提とせず、以下のFAQ例と改善手順、評価方法は本サイトからの提案です。実際の比較実験の成績や、すべてのデータに共通する最適値を示すものではありません。
スポンサーリンク
最初に検索と回答の失敗を分ける
例えば「法人プランを途中解約した場合の返金は？」という質問に、個人向けの月額プランの説明が返ったとします。ここで見るべき記録は、最終回答だけではありません。検索に渡した質問、候補の文書ID、採用した断片、生成へ渡した本文を順に確認します。
正しい法人向け規約が候補にもないなら、取り込み漏れ、検索方法、用語の不一致などを疑います。候補にはあるが採用されないなら、順位や絞り込みが問題です。正しい規約が入力にあるのに誤るなら、文脈の配置、回答指示、生成処理を調べます。
この三つを同じ「AIの精度」で集計すると、原因に合わない対策を続けがちです。本サイトでは、検索結果だけを見る点検と、渡された資料から回答できるかを見る点検を分けることを勧めます。回答文をきれいにする前に、正しい根拠へ到達できているかを確かめましょう。
チャンクは文字数だけで決めない
長い文書を検索しやすい断片へ分けたものをチャンクと呼びます。分割の単位が小さすぎると、条件や例外が落ちます。逆に多くの話題をまとめると、目的の一節に無関係な説明が付き、検索や回答の焦点がぼやけます。
Microsoftの資料は、固定長、文の境界、見出しや意味上のまとまりを利用する方法を説明しています。文書の構造や質問の性質に応じて分割を選び、必要なら重なりを設ける考え方です。文字数とモデルのトークン数は同一ではない点にも注意が必要です。
スポンサーリンク
見出しと条件を残して分割する
FAQなら、質問と回答を一緒に保つのが比較の出発点になります。規約なら条項とその適用条件、手順書なら前提条件と作業手順を関連づけます。表を扱うときは、行の値だけが残り、列名や単位が消えていないかを点検してください。
「返金しません」という一文だけでは、どの契約や期間の話か分かりません。各断片には文書名、見出しの階層、対象製品、適用開始日などを必要に応じて添えます。ただし、同じ説明を大量に複製すると入力が膨らむため、検索に使う情報と回答へ渡す情報を区別します。
本サイトが提案する試し方は、まず現行の固定長分割を基準として残し、次に見出し単位の分割を比較する方法です。さらに長すぎる節だけを再分割します。分割、埋め込みモデル、検索方式を同時に変えると、どの変更が効いたか判別しにくくなります。
キーワードと意味検索の得意分野を組み合わせる
意味が近い文章を探すベクトル検索は、利用者の言い換えに対応する選択肢です。一方、型番、エラーコード、固有の名称などは、文字列として一致することが重要な場合があります。
Azure AI Searchのハイブリッド検索は全文検索とベクトル検索を並行して実行し、RRFという順位の統合方法で結果をまとめます。同資料は、製品コードや専門用語などでキーワード検索が有効になる場面も説明しています。これを、どのサイトでもハイブリッドが必ず勝つという保証として受け取るべきではありません。
スポンサーリンク
候補の数を増やすだけで解決しない理由
検索候補を増やすと、正しい資料を拾える可能性は広がります。ただし、似た旧版が増えたり、同じページの断片が上位を埋めたりすると、回答へ渡す根拠の多様性は増えません。候補数と生成へ渡す件数を、同じ設定として扱わないことが大切です。
本サイトでは、まず少し広めに候補を取り、その後に対象製品や適用条件を点検し、重複を減らして必要な根拠を選ぶ構成を提案します。候補を質問との関連性で再評価する再順位付けも、ここで比較できる選択肢です。処理が一段増えるため、品質だけでなく待ち時間と費用を確認します。
例えば、返金の原則と例外を別の断片に持つ規約なら、上位の一断片だけでは判断できません。関連する節を補って渡す方法も検討します。ただし、前後の全文を毎回追加する設計では、無関係な情報が増えやすくなります。補完する範囲を決めて評価しましょう。
出典は回答の文章と対応させる
最後に資料一覧を付けるだけでは、どの主張が何に基づくのかが分かりません。「途中解約は可能」と「返金はない」が別の条項に基づくなら、その対応を読者が確認できる形にすることを提案します。
検索時には、元のURL、文書の版、節の識別子、断片IDを保管します。生成側には採用した断片の識別子を渡し、回答が示した識別子が実際の入力に存在するかをアプリ側で確認します。実在しない番号を出典として表示しないための仕組みです。
識別子が正しくても、文章が根拠に支えられているとは限りません。引用した箇所に返金条件が本当に書かれているか、例外を落としていないかも確認します。出典付きという表示だけで、内容の正しさを保証しない運用が必要です。
見つからない質問に無理に答えない
FAQには対象外の質問も届きます。「来月始まる予定のキャンペーンは？」と聞かれても、資料に予定がなければ回答できません。意味が似た過去キャンペーンを検索できたことと、今の質問へ答えられることは別です。
本サイトでは、資料不足、質問の曖昧さ、資料同士の矛盾を区別して扱うことを勧めます。資料不足なら確認先を案内し、対象プランが不明なら質問を返し、版が食い違うなら確定的な結論を保留します。「分かりません」だけを連発するのではなく、不足している条件を示します。
検索スコアに万能の閾値を一つ置く方法には限界があります。検索方式や対象資料が変われば、値の意味も変わり得ます。実際の質問で、答えてよいケースと保留すべきケースを比較し、回答を止める条件を決めてください。
小さな質問集で改善を測る
比較用の質問集には、よくある質問だけでなく、略称、型番、表の値、複数条件、旧版との違い、資料に答えがない質問を含めます。各質問には、答えの文例だけでなく、必要な根拠の箇所と満たすべき条件を付けると原因を追いやすくなります。
例えば「必要な根拠が上位候補に含まれたか」「採用した断片で条件がそろうか」「回答の主張が根拠と一致するか」を別々に記録します。数値にするときは、何件のどの種類の質問を測ったのかも残してください。一つの成功率だけでは、型番検索の改善と例外条件の悪化が相殺されることがあります。
比較時には文書の版と質問集を固定し、設定を一つずつ変更します。失敗例を見て調整した質問と、最終確認用に残した質問は分けます。同じ問題だけに合わせ込んで、初めて見る問い合わせに弱くなるのを避けるためです。
スポンサーリンク
FAQサイトで検証するなら何を残すか
説明用の例として、製品Aと製品Bのマニュアルを検索する問い合わせサイトを考えます。まず「製品AのエラーE12」を質問し、製品Aの該当節が取れることを確かめます。次に、似た表現で別の対処法が書かれた製品Bのページを追加し、回答が混ざらないかを見ます。
次は、質問の製品名を省略します。ここで無理に製品Aと決めつけるなら、検索精度だけでなく確認質問の設計にも課題があります。さらに、同じ製品の旧版マニュアルを追加し、利用者が版を指定した場合と指定しない場合を分けて確認します。これらは公開前に試せる仮想の検証条件です。
記録する項目は、質問ID、文書の版、検索設定、候補ID、採用した根拠、回答、判定理由です。機密の本文をそのまま全件ログへ残す必要があるとは限りません。再現に必要な情報と保存期間を決め、原文へのアクセス権も管理します。
埋め込みの変更は索引の変更として扱う
埋め込みモデルを変える場合は、新しい質問ベクトルだけを作って旧索引へ投げればよいとは考えないでください。検索エンジンや埋め込みモデルの仕様を確認し、文書側と質問側で対応する表現を使う必要があります。移行中に旧データと新データを混在させる設計は、比較も復旧も難しくします。
本サイトからの提案は、新しい索引を別に作り、固定した質問集で品質と応答時間を比較し、切り替え後も旧構成へ戻せる期間を設けることです。改善が小さいのに取り込み費用や運用負担が大きくなるなら、モデルの更新よりも文書の整理を優先する判断もできます。
スポンサーリンク
更新と削除まで品質管理に含める
一度うまく回答できても、規約や製品仕様が変われば古くなります。文書の更新と検索用データの更新が別工程なら、その間に旧情報を答える時間が発生します。更新日時だけでなく、どの版から生成した断片なのかを追えるようにしておきます。
本サイトでは、文書IDと版を使って更新対象を特定し、旧断片の削除まで検査する運用を提案します。削除したページが検索に残らないか、出典のリンク先が見つからなくなっていないかも確認します。生成モデルを更新していなくても、取り込みや検索設定の変更で回答は変わります。
導入の順序としては、質問と根拠を記録することから始め、取り込み漏れと分割の欠損を直し、検索方式を比較し、最後に回答の表現を調整すると整理しやすくなります。権限制御や個人情報の保護は別途必要ですが、検索品質の検証でも実データの保存範囲を決めてください。
