社内ナレッジを活用するRAG（検索拡張生成）システムの構築

LLM（大規模言語モデル）は、インターネット上の一般的な知識は持っていますが、自社の就業規則や先月の売上データは知りません。これらを質問のたびに検索し、回答の根拠としてモデルに渡す仕組みがRAG（Retrieval-Augmented Generation）です。

• できること：社内の資料に基づく回答、根拠（参照元）の提示、更新した資料の反映（取り込みの仕組みによる）。
• できないこと：資料にないことへの正確な回答（推測で補ってしまう場合がある）、整理されていない資料からの正確な抽出。RAGを使っても、回答が正しいことは保証されません。

RAGとファインチューニングの違い

RAGは、回答のたびに参照する情報を検索してモデルに渡す方式です。ファインチューニングは、追加のデータでモデル自体を調整する方式で、文体や出力の形式をそろえたい場合などに使われます。社内規程やマニュアルのように内容が更新され、根拠を示したい情報には、RAGが合う場合が多くあります。費用、更新の手間、どちらが適するかは、データの量と更新の頻度、使うサービス、求める品質によって変わり、一律には決まりません。

なお、RAGという方式を使うことと、入力したデータがサービス側で学習に使われるか・保存されるかは別の問題です。構成に使うサービスごとに、学習への利用、保存、ログ、検索と生成の権限を確認します。

RAGを導入しても成果が出ない場合、原因は製品の選び方よりも、検索対象にした資料の管理にあることが多くあります。

• 資料の品質：古いマニュアルや未確定の議事録などが検索対象に含まれていると、回答の精度が下がりやすくなります。
• アクセス権限の不備：機密情報が検索対象に含まれていると、権限のない利用者がAIを通じて閲覧できてしまうおそれがあります。
• 情報の不整合：元の資料を更新してもRAG側へ反映されず、古い内容のまま回答が続くことがあります。

このうち気付きにくいのが情報の不整合です。元の資料を改訂しても、RAGが参照する索引（検索用に取り込んだデータ）が更新されていなければ、AIは旧版の内容で回答を続けます。回答に根拠が示されていても、その資料が旧版なら業務上は誤りです。資料ごとに有効な版と管理者を決め、更新や削除が索引へ反映されたことを確認する手順を運用に組み込みます。RAGは、資料の管理者と更新の手順を決めて、構築した後も運用を続けることが前提になります。

最初に、検索対象を絞ります。ファイルサーバー全体を対象にせず、AIに参照させてよく、内容を管理できているフォルダを決め、そこだけを検索させます。

RAGの精度が上がらない場合は、次のどちらに問題があるかを切り分けます。

1. 検索の失敗：必要な資料が検索結果に出てこない。
   → キーワードの類義語の登録、チャンク（分割）サイズの調整、ハイブリッド検索（キーワード+ベクトル）の導入を試します。
2. 生成の失敗：資料は渡せているが、回答の内容が資料と合わない。
   → プロンプトの改善（「以下の情報を元に答えて」という指示を明確にする）や、新しい世代のモデルへの変更を試します。

このほか、回答が資料に沿っていても、根拠の資料自体が旧版や対象外なら業務上は誤りです。権限・更新・削除の問題は、平均の正答率に混ぜずに個別に確認します。改善の前後で同じ評価質問を使い、どこが変わったかを比べます。

評価では、次の4つを分けて記録します。

1. 検索：必要で有効な資料を、利用者に許可された範囲で取り出せたか。資料にない質問では、回答できないことを検索の失敗と決めつけず、適切に保留できたかを確認します。
2. 生成：取り出した資料に沿って、期待する回答を作れたか。資料にない条件を付け加えた場合は、生成の誤りとして記録します。
3. 根拠の有効性：根拠にした資料が、業務の責任者が定めた有効な版か。資料に忠実でも、旧版や対象外の資料なら業務上は誤りです。
4. 権限・更新・削除：平均の正答率に混ぜず、個別の受入条件として確認します。検索結果に加えて、引用・リンク・キャッシュなど、実際の構成で情報が残る箇所を確認します。

次の7件は、評価質問の作り方を示すための説明用の例です。顧客の資料や実際の実行結果ではありません。実際の評価では対象の業務に合わせて件数を増やし、期待する結果を先に決めます。

権限の確認（R04・R06）は、検索の段階で利用者の権限に応じて結果を絞り込む設計になっているかを確かめるものです。生成した後に回答を隠すだけ、または指示文で「見せないで」と書くだけでは、制御したことになりません。MicrosoftのマルチテナントRAGの設計ガイドも、取り出しのたびに権限による絞り込みを適用することを挙げています。更新・削除（R05）も、元の資料を削除しただけで索引から消えるとは限りません。たとえばAzure AI Searchでは、削除を検知する設定によっては索引に文書が残り、手動での削除が必要になると説明されています。使う構成で、反映の条件と確認の方法を決めます。

評価用の質問は、プロンプトや検索設定の調整に使うものと、最終確認に使うものを分けます。自動の評価（LLMによる採点など）は補助として使えますが、期待する結果、有効な資料、権限外の情報の扱いは人が確認し、同じモデルによる自己採点だけで重要な項目を通さないようにします。Microsoftの評価機能の説明でも、検索の評価と、回答の評価（根拠との整合、関連性、網羅性）を分けています。

評価の結果から、本番へ進むか、範囲を限って運用するか、追加の検証や見送りにするかの判断は、PoCから本番へ進む条件と、止める条件で扱っています。7件すべてに合格しても、本番全体の安全性や性能を保証するものではありません。

資料は日々増え、古くなります。マニュアルを更新したのに、AIが古い内容で回答し続けることのないよう、構築した後の運用の仕組みを決めておきます。

更新の反映には、資料の更新をきっかけに検索用の索引を更新するフローを組む方法と、担当者が定期的に資料を入れ替える方法があります。どちらの場合も、取り込み、索引、キャッシュ、引用・リンクのどこまでに反映されたかを確認します。

• 更新の手順：資料の更新・削除を索引へ反映する方法と、反映を確認する担当・時期を決めます。索引の更新はモデルの再学習ではありません。
• 記録：回答に参照元のリンクを表示することは、利用者が根拠を確かめる助けになりますが、それだけで監査のための記録にはなりません。何を（質問・回答・参照した資料・操作）、どの期間残し、誰が閲覧できるかを別に決めます。
• 責任分界：画面に「AIの回答は参考情報です」と表示するだけでは、責任の分担は決まりません。資料の管理者、回答の確認者、更新と停止の担当を決めます。

全社へ一度に広げず、次の順で進めます。

1. PoC（概念実証）：IT部門や特定のプロジェクトチーム（10名程度）に利用者を限り、特定の資料（例：社内PCのセットアップ手順）だけで試す。
2. 資料の整備：PoCで答えにくかった資料（画像の多いPDF、スキャンしたPDF、複雑な表など）を確認し、テキストの抽出や形式の変換などの処理が必要かを、実際に試して判断する。
3. 本番展開：評価質問の結果と、更新・削除・権限変更の確認を終えてから、部署単位で権限を設定しながら対象範囲を広げる。

RAGを構築する前に確かめる項目です。