RAG（検索拡張生成）の精度を左右するメタデータフィルタとデータ前処理の実践ポイント：現場のRAG活用術第2回

なぜ「データのチューニング」が重要なのか

RAGは、

• データを検索する
• 検索結果をコンテキストとして生成AIに渡す
• その情報をもとに回答を生成する

という構造を持っています。

この構造を見ると分かる通り、RAGにおいて生成AIが扱える情報は、検索結果として渡されたデータに完全に依存しています。生成AIは自ら新たに情報を探索したり、検索結果を取り替えたりすることはできません。そのため、検索段階で「不適切なデータ」が混ざると、その後でどれだけプロンプトを工夫したとしても、もっともらしい誤答（ハルシネーション）が発生しやすくなります。

ここで重要なのは、生成AIは検索結果の正しさを自動的に検証してくれる存在ではない、という点です。生成AIは「与えられた情報をもっともらしく文章化する」ことには長けていますが、「その情報が本当に正しいか」「本来参照すべき文書を参照できているか」を判断する機構は持っていません。

言い換えると、生成AIは検索結果を前提条件として受け入れる存在です。検索結果に誤りやノイズが含まれていた場合に、それを疑うのではなく、「与えられた事実」として扱い、整合性のある文章を生成しようとします。

業務データ特有の難しさ

RAGを業務データに適用する際、一般的なWeb記事やFAQデータとは異なる、特有の難しさが存在します。

特に多くの現場で共通して見られるのが、次のような特徴です。

• 文書構造が似ている
• 表現や語彙、言い回しに定型的な記述が多い

これらは業務文書としては「正しく整理されている」状態でもありますが、RAGの検索という観点では、区別がつきにくい要因にもなります。

文書構造が似ているという問題

例えば、有価証券報告書や決算説明資料、統合報告書といった文書は、多くの場合、

• 会社概要
• 事業の状況
• 財務情報
• リスク情報

といった共通の構成を持っています。

このような文書を複数社分まとめてRAGの対象にすると、検索システムから見たときには、「構造が似ている上に、書いてあることも似ている文書群」として扱われてしまいます。

表現や語彙が定型的であるという問題

さらに、業務文書では使われる表現や語彙も非常に似通っています。

• 「当社グループは〜」
• 「売上高は前年同期比で〜」
• 「今後の事業環境としては〜」

といった定型表現は、企業や年度が違ってもほぼ同じ形で使われます。

これは人間が読む分には問題になりませんが、意味検索の観点では 「意味的に非常に近い文書」 と判断されやすくなります。

意味検索では区別がつきにくい理由

意味検索（ベクトル検索）は、文書の内容を「意味の近さ」で評価します。そのため、同じような構成・同じような語彙・同じような話題を持つ文書は、企業が異なっていても高い類似度を持つと判断されがちです。

人間であれば「これはA社の話で、あれはB社の話だ」と自然に区別できますが、意味検索は文書がさしている主体を必ずしも強く意識しません。

検索結果に何が起きるか

このような条件が重なると、検索結果には次のような文書が混ざりやすくなります。

• 本来参照すべき文書ではないもの
• 文脈的には近いが、対象が異なる文書

例えば、「ブレインパッドの財務状況」という質問に対して、他社の財務状況のセクションや、過年度の似た表現の文書が検索上位に並ぶ、といった現象が発生します。

業務データでは「意味が近い」だけでは不十分

このように、業務データでは「意味が近い」「文脈が似ている」という条件だけでは、本当に参照すべき文書を特定することができません。そのため、RAGを業務で活用する場合には、

• どの会社の文書か
• どの年度の文書か
• どの用途・セクションの文書か

といった、意味検索とは別の軸での制御が不可欠になります。

この制御を担うのが、次に紹介するメタデータフィルタです。

メタデータフィルタという基本的だが強力な手法

こうした問題に対して、まず検討すべきなのがメタデータフィルタです。

ここでいうメタデータとは、文書本文とは別に付与する、検索制御用の属性情報を指します。例えば以下の情報です。

• 会社名
• 年度
• ドキュメントの種別（有価証券報告書・決算説明資料　など）
• セクション（財務・事業・リスク　など）

重要なのは、これらを検索の前段で使う、という点です。

つまり、

• メタデータで検索対象となる文書群を限定し
• その中でベクトル検索や全文検索を行う

という二段構えの構造を取ります。

この設計により、意味検索の「拾いすぎ」という弱点を補うことができます。ベクトル検索は非常に強力な手法ですが、検索対象が広すぎるとノイズを拾いやすいためです。

メタデータフィルタがない場合に起きること

例えば、複数社の有価証券報告書をRAGの対象にしたとします。会社名をメタデータとして扱っていない場合、「有価証券報告書」という文脈に強く引っ張られます。その結果、他社の財務セクションが検索結果の上位にヒットする可能性があります。

結果として生成AIは、別会社の数値や説明を自然につなぎ合わせ、一見正しそうな回答を生成してしまいます。こういった現象は、生成AIの能力不足ではなく、検索設計の問題としてとらえるべきです。

実際に、富士通の有価証券報告書・ブレインパッドの有価証券報告書をナレッジとして登録し、「ブレインパッドの本店の所在の場所は、東京都何区ですか」と問い合わせてみました。

しかし、このとき生成AIは両方のドキュメントから情報を参照しようとしてしまい、整合性のある回答を返すことができませんでした。

ここで注目すべきなのは、ドキュメント単位ではなくチャンク単位で検索が行われているという点です。RAGにおけるベクトル検索は、PDF全体ではなく分割されたテキストチャンクを対象に類似度計算を行います。

今回のように複数企業の有価証券報告書を同時に登録した場合、

• 「本店所在地」
• 「東京都〇〇区」
• 「会社情報」

といった記述は、企業を問わず似た文脈・語彙で記載されていることが多く、チャンクレベルでは企業固有の識別子（社名など）を含まない断片的なテキストとして埋め込まれてしまいます。

その結果、「ブレインパッド」に関する質問であっても、

• 富士通の「本店所在地」に関するチャンク
• ブレインパッドの「本店所在地」に関するチャンク

といった、異なる企業に由来するチャンクが同時にTopK検索でヒットする可能性があります。

生成AIは、これらを同一のコンテキストとして扱って回答を構築しようとするため、結果として企業情報が混在した不整合な回答、あるいは回答不能な状態に陥ります。

メタデータフィルタを入れると何が変わるか

同じ例でも、以下のようなメタデータが文書に付与されていれば状況は大きく変わります。

• company = ブレインパッド
• company = 富士通

検索時にまずこの条件でフィルタリングを行うことで、検索対象は「ブレインパッドの資料」のみに限定され、その中で意味検索が行われるという構造になります。これにより、他社情報の混入・回答内容のブレ・ハルシネーションの発生を大きく抑えることができます。実務においては、このメタデータフィルタだけでRAGの安定性が大きく向上するケースも珍しくありません。

さきほどの例においても、メタデータでcompany=ブレインパッドの文書のみ参照するように設定を変更すると、今度は東京都港区にある旨を正しく回答できるようになりました。

PDFの扱いとデータ前処理

ここまで見てきたように、メタデータフィルタを適切に設計することで、RAGにおける検索対象は大きく制御できるようになります。

どの会社の、どの年度の、どの種類の情報を参照するのかを明示できるようになることで、検索結果のブレや不要な文書の混入を大幅に抑えることが可能になります。

しかし、ここで注意したいのは、メタデータ設計がどれだけ適切であっても、検索対象となるデータそのものの品質が低ければ、期待した効果は得られないという点です。

検索空間を正しく絞り込んでいたとしても、肝心の文書が「検索に適した形」で扱われていなければ、意味検索は正しく機能しません。

特に業務データでは、PDF形式の資料や、スキャンされた画像データが多く含まれるケースが一般的です。

これらの資料の多くは、あくまで人が読むために作成されたものであり、機械的に処理・検索されることを前提として設計されたものではありません。

そのため、人が目で見て内容を理解する分には何の問題もない「文書」であっても、RAGで取り扱うという観点では課題を抱えている場合があります。

すなわち、一見すると同じ「文書」に見えても、

• 機械的に文字情報として扱えるもの
• 画像として埋め込まれており、そのままでは検索できないもの

が混在しています。

この状態でRAGに投入すると、「メタデータで正しく絞り込んでいるはずなのに、なぜか期待通りの検索結果が返ってこない」といった問題に直面することがあります。

つまり、メタデータによる“どの文書を使うか”という制御と同時に、“その文書をどのような状態で検索に渡すか”という前処理の設計が不可欠なのです。

次に、RAGで頻繁に問題になりやすいPDF・画像データを例に、前処理の重要性について見ていきます。

PDF・画像データにおける前処理の重要性

RAGで扱う業務資料がPDFであり、そのままでは文字情報として正しく扱えないケースは少なくありません。スキャンされた画像PDFの場合、テキストとして検索できる状態にするために次のような前処理が必要です。

• OCR（光学文字認識）によるテキスト化
• 不要な改行の除去
• ヘッダー・フッターの除去
• 段組み崩れの補正

これらの処理を行わないと、検索精度が大きく低下します。

OCRによるテキスト化は”前提条件”

スキャンされた画像PDFをRAGの対象にするためには、まずOCRによるテキスト化が不可欠です。OCRを行わない場合、検索システムから見ればその文書は「文字情報を持たないデータ」であり、どれだけ適切なメタデータを付与していても、検索にはヒットしません。

一方で、OCRを適用した場合でも、

• 認識精度が低い
• 数値や記号が誤認識される

といった問題が発生することがあります。

このため、OCRは「かければ終わり」ではなく、検索用途に耐える品質でテキスト化できているかどうかを意識する必要があります。

不要な改行が検索精度に与える影響

OCR後のテキストでは、不要な改行が大量に含まれることがよくあります。

• 1行ごとに改行が入る
• 単語の途中で改行が挿入される

といった状態のままインデックス化すると、意味検索において文脈が分断され、本来ひとまとまりとして扱うべき情報がバラバラに解釈される可能性があります。

その結果、

• クエリとの意味的な類似度が下がる
• 意図しないかたまり（チャンク）が検索上位に来る

といった現象が起こりやすくなります。

ヘッダー・フッターがノイズになる理由

業務資料では、ページごとに同じヘッダーやフッターが繰り返し含まれることが多くあります。

• 会社名
• ページ番号
• 注意書き

これらは人間が読む際には無意識に無視できますが、検索システムにとっては頻出する重要な語句として扱われてしまいます。

その結果、

• 本文よりもヘッダー由来の語句が強調される
• 本来関係のない文書同士が似ていると判断される

といった副作用が生じ、検索精度の低下につながります。

段組み崩れは意味検索に致命的

PDF資料では、段組みレイアウトが使われていることも多くあります。

OCR後のテキストでは、

• 左列と右列の文章が交互に混ざる
• 本来つながっていない文が連結される

といった形で、意味的に不自然な文章が生成されることがあります。

この状態でインデックス化すると、検索システムは意味の通らない文書を前提に検索を行うことになり、結果として検索精度が大きく損なわれます。

前処理をしないと何が起きるのか

これらの前処理を行わずにRAGを構築すると、次のような問題が表面化します。

• メタデータで正しく絞り込んでいるはずなのに、期待した文書が出てこない
• 回答や参照している文書が断片的になる

こうした問題は、モデルやプロンプトを調整しても解消されないことが多く、原因がデータ前処理にあると気づくまでに時間がかかる点も厄介です。

前処理は「検索のためのデータ設計」

RAGにおける前処理は、単なるデータクレンジングではありません。検索と生成の両方を前提にした「データ設計」と捉える必要があります。

• どのような粒度で文脈を保つのか
• どの情報を残し、どの情報を削るのか
• 検索システムが意味を理解しやすい形になっているか

これらを意識して前処理を設計することで、初めてメタデータフィルタや検索ロジックの効果が最大化されます。どのようなデータを、どのような状態で検索に渡すか。この設計こそが、RAGを業務で安定して活用するための重要な前提条件であると言えるでしょう。

データ側チューニングは「地味」だが効果がある

データ側のチューニングは、RAGの中でも最も地味な作業に見えるかもしれません。しかしその一方で、RAGの品質を最も確実に底上げしてくれるのも、この領域です。

• 検索結果が安定し
• 回答の根拠を示せるようになり
• 「なぜこの答えになったのか」を説明できる

こうした状態は、生成AIの振る舞いを調整するだけでは実現できません。

データ設計という土台が整って初めて得られる性質だと言えるでしょう。

おわりに

本記事では、RAGにおける「データ側」のチューニングとして、

• メタデータフィルタによる検索空間の制御
• PDF・画像データの前処理

を中心に整理しました。

RAGの精度改善というと生成AIやプロンプトに注目が集まりがちですが、検索に渡る前のデータ設計が結果を左右するという点は、現場でRAGを活用する上で避けて通れない観点です。

次回はさらに踏み込み、より高度な検索構造（GraphRAG） といった「検索そのもののチューニング」について解説していく予定です。