RAGの試作は数日で動く。社内の規程を何十本か入れて、用意した質問を投げれば、それらしい答えが返ってくる。難しいのはその先で、本番の質問で答えが外れる、見せてはいけない文書の中身が出る、文書を更新しても答えが古いまま、という問題がここで出てくる。
RAGの仕組みそのものはRAGとはに書いた。ここでは、RAG構築を本番に出すまでの進め方を、評価、文書の分け方、検索、権限、運用の順に整理する。
RAG構築の全体の流れ
私が考える順番は次の表のとおりだ。ふつうは文書の取り込みから始めるが、私は評価の用意を最初に置く。
| 順番 | やること | 決めること |
|---|---|---|
| 1 | 評価の用意 | 質問、正解の文書、正解の答えの組。何点なら本番に出すか |
| 2 | 文書の整理と分け方 | 入れる文書と入れない文書、最新版の決め方、チャンクの切り方 |
| 3 | 検索の組み合わせ | ベクトル検索とキーワード検索の組み合わせ、並べ直し、渡す件数 |
| 4 | 権限 | 文書ごとに読める人、検索の段階での絞り込み、反映までの時間差 |
| 5 | 回答と運用 | 出典の示し方、答えがないときの返し方、更新と評価の回し方 |
評価を最初に置くのは、2から5のどれを変えても、良くなったのか悪くなったのかを数字で比べたいからだ。評価がないまま進めると、チャンクの大きさを変えた、検索の方式を変えた、という調整の良し悪しを、目で見た数件の答えで判断することになる。
精度は検索と回答に分けて測る
RAGの精度は、ひとつの数字で見ないほうがよい。正しい文書を拾えたかという検索の精度と、拾った文書から正しく答えたかという回答の精度は、原因も直し方も違う。
MicrosoftのRAG向けの評価の文書は、検索がRAGの上流にあるので検索の質が大事だと書き、検索の質が悪く、答えに社内固有の知識が要る場合は、モデルが満足な答えを返す見込みが下がると説明している。評価の指標も、検索を見るものと、答えを見るもの（根拠に沿っているか、質問に合っているか、漏れがないか）に分けている。
Amazon Bedrockも、ナレッジベースの評価を「検索だけ」と「検索と生成」の2種類に分けている。検索だけの評価では、拾った文章が質問にどれだけ関係するかを測る。検索と生成の評価には、検索した文章に対して事実と異なる答えを避けられているか（忠実さ）や、出典の示し方の正確さが入っている。
人手の正解なしで測る方法もある。2023年9月に公開された論文「Ragas: Automated Evaluation of Retrieval Augmented Generation」は、答えの主張が渡した文書から導けるか（忠実さ）、答えが質問に正面から答えているか、渡した文書に答えに要る情報だけが入っているか、という観点で、人手の正解に頼らずに測る指標を提案した。
私の見方では、最初は自動の指標より、業務を知る人が作った30〜50問の質問と正解の組のほうが役に立つ。件数は目安で、大事なのは、本番でよく来る質問と、間違えると困る質問が両方入っていることだ。自動の指標は、その組で測った結果と食い違わないかを確かめてから使う。
文書の分け方と検索の組み合わせ
チャンクの大きさは出発点を決めて測る
チャンクの大きさに決まった正解はない。各社の文書が示しているのは出発点だ。
- Azure AI Searchの文書は、512トークン（およそ2,000文字）、重なり25%から始めることを勧めている
- Amazon Bedrockのナレッジベースの既定の分け方は、文の区切りを守りながら、およそ300トークンずつに分ける
- Bedrockには、小さなチャンクで検索し、見つかったら親の大きなチャンクに差し替えてモデルに渡す階層型の分け方もある
規程やマニュアルのように見出しと条文の構造がはっきりした文書は、私の見方では、文字数より見出しの単位で切るほうを先に試す価値がある。Azure AI Searchの文書も、文書の途中のチャンクには文書のタイトルを付けて、文脈が抜け落ちないようにする工夫を挙げている。
キーワード検索と組み合わせる
意味の近さで探すベクトル検索は、言い換えに強い。一方で、Azure AI Searchの文書は、製品コード、専門用語、日付、人の名前のように完全一致が要る質問は、キーワード検索のほうがうまくいくと書いている。社内文書の質問には「規程の第何条」「型番の何番」が多いので、両方を組み合わせる前提で作るほうがよい。
Azure AI Searchのハイブリッド検索は、キーワード検索とベクトル検索を並行して走らせ、Reciprocal Rank Fusion（RRF）という方法で結果をまとめる。RRFは、各検索での順位から点数を出して足し合わせる方法で、2009年のSIGIRで発表された論文で示された。Azure AI Searchではこのあとに、上位50件を別のモデルで並べ直す処理（セマンティックランカー）を加えられる。
渡す件数と並べ方も精度に効く
検索で拾った文書は、多く渡せばよいわけでもない。2023年7月に公開された論文「Lost in the Middle」は、必要な情報が入力の最初か最後にあるときに精度が最も高く、長い入力の真ん中にあると大きく下がることが多いと報告した。拾った件数を増やすほど、必要な文書が真ん中に埋もれやすくなる。渡す件数も、評価の組で測って決める項目のひとつに入れるべきだと私は考える。
権限は検索の段階で絞る
RAG構築で後回しにされやすく、後から直すのが一番大変なのが権限だ。OWASPのLLMアプリのリスク一覧（2025年版）は、LLM08「Vector and Embedding Weaknesses」で、アクセス制御が不十分だと機密情報を含む埋め込みに権限のない人が触れられると指摘し、対策として権限を区別できるベクトルストアを挙げている。
考え方は単純で、質問した人が読めない文書は、モデルに渡す前の検索の段階で落とす。モデルに渡してから「この人には見せるな」と指示する作りは、指示の書き方ひとつで破れる。
主な検索サービスは、この絞り込みの仕組みを持っている。
| サービス | 権限の扱い | 確かめること |
|---|---|---|
| Azure AI Search | 文書ごとに読める人のIDを持たせ、検索時に絞る。SharePointのACLなどを取り込む方法もある（一部はプレビュー） | 元の権限の変更は、索引に同期されるまで検索結果に反映されない |
| Amazon Q Business | コネクタが文書のACLを取り込み、利用者が読める文書だけで答える | 権限の変更を拾うには定期的な再同期が要る。新規の受付は終了している |
| Google（Agent Search） | 利用者のIDプロバイダーで利用者を特定し、読める文書だけを結果に出す | 対応するデータソースと、文書ごとの読める人の上限 |
Amazon Bedrockのナレッジベースには、文書の属性で結果を絞るメタデータフィルタがある。ただしAWSの文書はこれを関連度を上げるための機能として説明していて、権限の仕組みとは書いていない。権限に使うなら、属性に誰が読めるかを入れ、質問した人の所属から絞り込みの条件を作る部分を、自分たちで正しく作ることになる。
私の見方では、どの仕組みを使うにしても、次の3つは本番前に確かめておきたい。読めない人の質問で、その文書の中身が答えに出ないこと。元の文書の権限を外してから、検索結果に反映されるまでの時間。退職者や異動者の権限が、どの経路で消えるか。
検索した文書に紛れた指示にモデルが従ってしまう問題は、権限とは別に対策が要る。仕組みと対策はプロンプトインジェクションとはにまとめた。
本番に出したあとの運用
RAGは出したあとに文書が変わり続ける。決めておくのは次のことだ。
- 文書の更新をいつ索引に反映するか。古い版の文書を索引から消す手順
- 評価の組をいつ回すか。文書の入れ替え、モデルの変更、検索の設定の変更のたびに回す
- 答えに出典を付け、文書に答えがなければ「わからない」と返す
- 利用者が答えを誤りと報告できる仕組みと、その報告を評価の組に足す流れ
もっともらしい誤りを減らす設計はハルシネーション対策に、モデルやプロンプトの変更を評価しながら本番で回し続ける仕組みはLLMOpsとはに書いた。
私の見方では、RAG構築の成否を分けるのは、どのベクトルデータベースを選ぶかより、どの文書が最新で誰が読めるのかを社内で決められるかどうかだ。そこは業務を知る人と一緒にしか決められない。業務の現場に入ってAIを実装する職種はFDEとは？Forward Deployed Engineerの意味と仕事内容で説明している。
社内文書に答えるAIを、評価と権限を含めて本番まで作る支援の中身は、私たちのサービスで紹介している。