第11章 社内文書を検索して根拠付きで回答する
本章は初稿です。
11.1 この章で学ぶこと
第10章で、検索関数の結果を返す仕組みを学びました。次は、どの資料を取得し、どのように回答へ使うかを考えます。
本章では RAG(Retrieval-Augmented Generation、検索拡張生成)を学びます。資料の準備、検索、回答を分け、必要な根拠を取得できない問題と、根拠を正しく使えない問題を切り分けることが目標です。
11.2 RAG の二つの流れ
RAG は、必要な情報を検索し、その情報をモデルへの入力に加え、根拠に沿った回答を生成する考え方です。モデルを学習し直して社内規程を永久に覚えさせる仕組みではありません。[^rag]
図11-1 文書を準備する流れと、質問に答える流れを分ける。 上段の矢印は取り込み、下段は質問時の情報の流れです。権限の確認は、文書がモデルへ届く前に置きます。特定の検索製品の内部構成ではなく、RAG の基本的な分解です。
基本課題では、第10章のローカル資料と検索関数で「取得 → 根拠を渡す → 回答」を学びます。専用の索引や Azure AI Search の配備は必要ありません。図の取り込みと索引は、資料を増やして検索基盤へ発展させるときの概念です。
| 流れ | 開発者が用意すること |
|---|---|
| 文書の準備 | 対象、版、適用条件、閲覧範囲を整理する |
| 検索の準備 | 必要なまとまりへ分割し、探せるようにする |
| 質問時の取得 | 質問と権限に対応する根拠を取り出す |
| 回答 | 根拠にあることと、ないことを区別して説明する |
11.3 小さな資料から始める
第10章の三つの架空資料を、そのまま最初の教材データにします。一般社員向けの Windows と macOS の手順、管理者専用の資料です。最初から大量の文書を入れると、検索の失敗を調べにくくなります。
実際の資料を扱う際には、本文だけでなく次の情報を残します。
| 情報 | 必要な理由 |
|---|---|
| 文書 ID と断片の ID | 取得した根拠を特定する |
| タイトルと参照先 | 利用者が元の資料へ戻る |
| 文書の版・更新日 | 古い資料との混同を調べる |
| 適用する OS や製品 | 別の対象の手順を除外する |
| 閲覧範囲 | 許可された情報だけを取得する |
長い資料を分割した単位を、チャンクと呼びます。短すぎると手順の前提や注意事項が欠け、長すぎると必要でない情報が増えます。まず見出しや手順のまとまりを保って分け、質問に必要な前提と本文が一緒に取れるかを見ます。すべての文書に通用する固定の分割サイズは置きません。
11.4 キーワード検索とベクトル検索
第10章の実装は、全キーワードが含まれる文書を探すだけでした。本格的な検索基盤へ進むと、キーワード検索、ベクトル検索、両者を組み合わせるハイブリッド検索などが選択肢になります。Foundry は Azure AI Search などと組み合わせた取得を扱えます。[^rag]
| 方法 | 捉えやすいもの | 注意すること |
|---|---|---|
| キーワード検索 | 製品名、エラー番号、明示された単語 | 言い換えや表記ゆれを拾えない場合がある |
| ベクトル検索 | 数値表現の近さに基づく関連内容 | 近さは正しさ、最新性、閲覧許可の保証ではない |
| ハイブリッド検索 | 単語の一致と意味的な近さの組み合わせ | 構成を複雑にする前に、同じ質問で効果を確かめる |
ベクトル検索で使う文章などの数値表現を、埋め込み、または embedding と呼びます。埋め込みの作成と検索にも処理や費用が増えます。入門段階では、検索方法を増やす前に「期待する資料が取れたか」を確認します。
サービス側の検索ツールへ置き換える場合、認証、索引、対応リージョン、引用の形式、ネットワーク経路も確認し直します。ローカルの関数を Azure AI Search に替えるだけで、権限や図の経路がそのまま成立するとは考えません。
11.5 検索結果を根拠として渡す
第10章の検索結果は、たとえば次のような情報を持ちます。これは教材独自の形式であり、Foundry の固定の検索結果スキーマではありません。
{
"document_id": "vpn-windows",
"title": "Windows の VPN 確認手順",
"passage": "学習用手順: Windows では接続先とエラー表示を確認します。",
"source": "https://kb.example.invalid/vpn-windows"
}
モデルには「取得した根拠にある手順だけを説明する」「資料の適用条件を明示する」「根拠が不足する場合は不足を伝える」という方針を与えます。回答例は、次のように根拠へ戻れる形です。
Windows の相談として、接続先と表示されたエラーを確認してください。根拠は学習用資料「Windows の VPN 確認手順」(文書 ID:
vpn-windows)です。
元の資料にない「再インストールすれば必ず直る」を足したら、検索が成功していても回答は不適切です。また、参照先が表示されたことだけで、本文が根拠に沿っていると判断してはいけません。
11.6 権限と失敗を先に扱う
権限外の資料を回答から消すだけでは不十分です。モデルへ渡す前に除外します。取得した資料も信頼できる命令ではなく、回答の材料として扱います。資料内に「以前の指示を無視せよ」と書かれていても、権限を変更する命令として実行しません。[^rag]
| 条件 | 区別すること |
|---|---|
| 正常に検索したが該当がない | 許可された検索範囲では根拠を得られなかった |
| 検索の通信や処理が失敗した | 根拠の有無をまだ確認できていない |
| 権限外の文書がある | その文書を取得・表示してよいわけではない |
| 古い資料しか得られない | 最新の手順として断定しない |
「検索できなかった」を「社内に手順が存在しない」へ置き換えないことが大切です。
11.7 小さな実習と確認課題
同じ質問を使って、次の三つを別々に記録してください。Azure に接続しない場合は、第10章の検索関数と手書きの回答例で練習できます。
VPN Windowsで取得した文書 ID と、期待する文書 ID を比較する。- 取得した抜粋の中に、回答で述べる手順の根拠があるかを確かめる。
- 一般社員の条件では、管理者専用資料がモデルへの入力に含まれないことを確かめる。
次に、質問を「当社の VPN サーバー名は」に変えます。資料に名前がなければ、関連資料を取得できても答えを断定できません。「関連する資料がある」と「必要な答えがある」の違いを説明してください。
11.8 まとめ
RAG の品質は、文書、検索、回答のすべてに依存します。まず小さな資料で、必要な根拠、根拠に沿う回答、適切な閲覧範囲を別々に確かめます。次章では、その確認を繰り返せる評価ケースにします。
11.9 参考情報
- Retrieval augmented generation (RAG) and indexes in Microsoft Foundry — 文書準備、索引、取得、回答、安全性の基本
[^rag]: Retrieval augmented generation (RAG) and indexes in Microsoft Foundry — Microsoft
前章:第10章 Function calling で外部の処理を呼び出す · 教材の目次へ戻る · 次章:第12章 評価とトレースで振る舞いを確かめる