RAGの精度を高める最も重要な準備は、モデル変更より先に社内データを整えることです。正本が不明、旧版が混在、見出しがない、権限情報がない状態では、検索で必要な文書を取得できず、回答も不安定になります。文書の棚卸し、クリーニング、分割、メタデータ、権限、評価、更新を一つの運用として設計します。
この記事では、PDF、Word、社内Wiki、FAQなどをRAGへ接続する前に行うデータ整備を解説します。技術担当だけでなく、文書を管理する業務部門が判断すべき項目も明確にします。
RAGの精度はデータで決まる
RAGは、質問に関連する文書を検索し、その内容をモデルへ渡して回答を生成します。したがって、必要な情報が検索対象にない、検索で取得できない、取得した文書が誤っている場合、モデルだけを変更しても根本的な改善にはなりません。
RAG品質は大きく次の3段階で決まります。
- データ品質：必要な文書が正確で、最新で、利用可能か
- 検索品質：質問に必要な部分を取得できるか
- 回答品質：取得内容に沿って、適切な形式で回答できるか
回答が間違ったときは、最終回答だけを見ず、どの文書が検索されたかを確認します。必要文書が取得されていなければデータと検索を、取得されているのに回答が違えば指示やモデルを改善します。
ステップ1：対象業務と質問を決める
最初からすべての社内文書を投入すると、不要情報と権限設計が増え、評価も難しくなります。対象業務を一つ選び、その業務で実際に聞かれる質問と、回答に必要な文書を整理します。
たとえば人事FAQなら、入社手続き、休暇、経費、福利厚生などの質問を集めます。質問ごとに「正しい回答」「参照すべき文書」「回答してはいけない条件」をセットで用意します。これが後の評価データになります。
最初に集める質問
- 頻度が高い通常質問
- 複数文書を参照しないと答えられない質問
- 条件によって回答が変わる質問
- 情報が存在せず「分からない」と答えるべき質問
- 個人情報や権限外情報を求める質問
- 表記揺れ、略語、話し言葉を含む質問
実際の問い合わせ履歴を使う場合は、個人情報や機密情報を除き、利用目的とアクセス権を確認します。
ステップ2：文書を棚卸しして正本を決める
同じ規程のPDF、Word、社内Wikiが存在すると、どれを参照すべきか判断できません。文書ごとに正本、所有者、版、更新日、有効期限を持たせ、古い版を検索対象から外します。
| 管理項目 | 内容 |
|---|---|
| 文書ID | 版が変わっても追跡できる識別子 |
| 文書名 | 利用者が理解できる正式名称 |
| 所有部署・責任者 | 内容を承認し更新する担当 |
| 正本URL | 最新版を管理する場所 |
| 版・更新日 | 新旧を判断する情報 |
| 有効期間 | いつからいつまで適用されるか |
| 機密区分 | 公開、社内、部門限定、個人情報 |
| 対象者 | 正社員、管理職、特定拠点など |
| 廃止状態 | 現行、改定予定、廃止 |
正本を決められない場合は、RAG導入より先に文書管理の責任を整理します。AIが矛盾を解決してくれると期待せず、人が正式な内容を確定してください。
ステップ3：文書をクリーニングする
検索対象へ入れる前に、本文以外のノイズを除き、構造を保ったテキストへ変換します。ヘッダー、フッター、ページ番号、メニュー、重複文が大量に残ると、検索結果に不要な断片が混ざります。
確認する項目
- OCRの文字化けや読み順がないか
- 表の行と列の関係が失われていないか
- 画像内だけに重要情報がないか
- 同じ注意書きが全ページに重複していないか
- 見出し階層と箇条書きが保たれているか
- URL、メールアドレス、日付が正しく抽出されているか
- パスワード、個人情報、不要な機密情報が混ざっていないか
PDFは見た目が整っていても、抽出したテキストの順序が崩れることがあります。投入前に代表ページをテキスト表示し、人が意味を読めるか確認します。
ステップ4：意味のまとまりで文書を分割する
長い文書は、検索しやすい小さな単位へ分割します。これをチャンク分割と呼びます。小さすぎると前提を失い、大きすぎると不要情報が混ざるため、文書の構造と質問に合わせて調整します。
MicrosoftのRAGデータパイプライン資料でも、チャンク方法は取得品質へ直接影響し、固定文字数だけの分割は意味の一貫性を失う場合があると説明されています。RAG向け非構造化データパイプラインを参照してください。
分割の基本方針
| 文書 | 分割単位の例 | 残す文脈 |
|---|---|---|
| 規程 | 章・条・項 | 規程名、対象者、施行日 |
| FAQ | 1つの質問と回答 | カテゴリ、更新日 |
| マニュアル | 作業・手順 | 前提条件、警告、次の手順 |
| 議事録 | 議題・決定事項 | 会議日、決定者、対象案件 |
| 製品資料 | 機能・仕様 | 製品名、版、対象プラン |
見出しを本文と一緒に保持すると、その断片が何についての説明か分かりやすくなります。表を分割する場合は列見出しを各行に持たせるなど、単体で読める形にします。
ステップ5：検索に使うメタデータを付ける
メタデータは、文書本文だけでは表せない属性です。部署、製品、地域、版、対象者、機密区分などを持たせると、検索対象を絞り、不要な文書が混ざるのを防げます。
有効なメタデータは、実際の質問や権限条件で使うものです。管理できないタグを大量に作ると更新漏れが増えるため、最初は5〜10項目に絞ります。
メタデータ例
- document_id：文書識別子
- title：文書名と見出し
- owner：所有部署
- version：版番号
- effective_from / effective_to：適用期間
- audience：対象者
- confidentiality：機密区分
- product / region：製品・地域
- source_url：正本へのリンク
- updated_at：更新日
回答画面では、文書名、該当箇所、更新日、正本URLを表示できるようにすると、利用者が根拠を確認しやすくなります。
ステップ6：アクセス権を検索時に適用する
文書を一つの検索基盤へ集めても、すべての利用者へ同じ結果を返してはいけません。利用者が元のシステムで閲覧できる範囲を越えないよう、検索時に部署、役職、案件、機密区分などで絞り込みます。
権限は回答生成後に文章を隠すのではなく、検索段階で適用します。権限外の断片がモデルへ渡った時点で、情報漏洩の可能性が生じるためです。
また、退職、異動、プロジェクト終了時に権限が更新される仕組みと、検索ログを確認できる状態を用意します。
ステップ7：評価セットで検索と回答を分けて測る
本番前に、実際の質問と期待する回答・根拠を組み合わせた評価セットを作ります。通常ケースだけでなく、答えがない質問、古い文書、矛盾、権限外、曖昧な質問を含めます。
検索評価
- 必要な文書が上位に取得されたか
- 不要な文書が多く混ざっていないか
- 最新版が旧版より優先されたか
- 権限外文書が除外されたか
- 略語や表記揺れでも取得できたか
回答評価
- 取得した根拠に沿っているか
- 根拠がない内容を追加していないか
- 条件や例外を正しく示しているか
- 出典を確認できるか
- 答えがないときに推測せず回答不能にできるか
Microsoftは、RAGの品質をデータパイプラインとRAGチェーンの両方で改善する考え方を示しています。RAGアプリケーション品質の改善も参考になります。
更新運用を設計する
公開時に精度が高くても、社内文書が更新されれば回答は古くなります。正本の更新から検索索引への反映までを業務フローにし、責任者と期限を決めます。
運用で必要な管理
- 文書の新規作成・改定を検知する
- 承認済みの正本だけ取り込む
- 旧版を検索対象から外す
- 変更された質問を再評価する
- 利用者から誤回答を報告できるようにする
- 原因をデータ、検索、回答へ分類する
- 改善履歴と再評価結果を残す
更新頻度は文書ごとに異なります。価格や在庫はAPIなどの構造化データから取得し、年次規程は改定時に反映するなど、情報特性に合わせます。
よくある失敗
すべての文書を最初に投入する
対象外や低品質な文書が増え、何を評価すべきか分からなくなります。一つの業務と質問群から始め、必要な文書だけ追加します。
ベクトル検索だけで解決しようとする
製品コード、型番、条文番号、固有名詞はキーワード検索が有効な場合があります。意味検索、キーワード、メタデータ絞り込み、再順位付けを質問特性に合わせて比較します。
回答だけを採点する
必要文書を取得できていないのか、取得後の生成に問題があるのか分かりません。検索結果と最終回答を別々に評価します。
文書責任者がいない
AI担当だけでは内容の正誤を確定できません。各文書の業務責任者が正本と更新を承認する体制が必要です。
よくある質問
文書は何件あればRAGを始められますか？
件数ではなく、対象質問へ答える文書がそろっているかで判断します。数十件でも業務範囲が明確なら検証でき、数万件あっても正本が不明なら精度は上がりません。
PDFをそのままアップロードしてもよいですか？
小規模な検証は可能ですが、OCR、表、見出し、重複、権限を確認してください。抽出後のテキストを人が読み、意味が保たれているかを確認します。
最適なチャンクサイズは何文字ですか？
一律の正解はありません。質問、文書構造、モデルの文脈長で変わります。章・条・FAQなど意味の単位から始め、評価セットで複数条件を比較します。
文書更新はどのくらいで反映すべきですか？
情報の変化速度と誤回答の影響で決めます。価格や障害情報は即時性が必要ですが、規程は承認済みの施行日に合わせるなど、文書ごとにSLAを設定します。
RAG導入後も人の確認は必要ですか？
必要です。特に法務、人事、契約、顧客への正式回答などは、根拠文書と回答を担当者が確認します。利用実績と評価に応じて確認範囲を見直します。
まとめ
RAGの精度改善は、文書の棚卸しと正本化、クリーニング、意味単位の分割、メタデータ、権限、検索・回答の分離評価、更新運用までを一続きで行います。モデル変更の前に、必要な情報が正しく検索できる状態を作ってください。
社内文書の整理からRAGのPoC・評価設計まで検討する場合は、お問い合わせからご相談ください。
関連記事
- RAGとは - 仕組みと導入手順の基礎
- RAG・ファインチューニング・AIエージェントの違い - 目的に合う方式の選び方
- AIエージェント導入の要件定義 - データ・権限を含むPoC要件
- 生成AIの情報漏洩リスクと対策 - 社内データを扱う際の安全対策
