RAGの実装において、「検索精度の頭打ち」と「情報の鮮度・権限管理」は大きな課題です。
単一のベクトル検索だけでは、文脈が不足したチャンクを取り違えたり、権限外のドキュメントを参照したりするリスクがあります。
本記事では、この課題を解決するためのデータ構造設計(メタデータ設計)を解説します。

なぜメタデータ設計が必要なのか

RAGはドキュメントをチャンク分割して、ベクトル検索することが基本ですが、そもそも検索対象のドキュメントに新版と旧版が混ざっていたり、似たようなドキュメントがあると、ベクトル検索で意味の近いチャンクをとってきたときに、正しい検索結果にならないケースがあります。そのため、メタデータを利用して、検索前に事前に検索対象のドキュメントを絞り込んでしまいたいというモチベーションがあります。

そこで、メタデータ設計です。文書本文とは別に付与する、検索制御用の属性情報を指します。具体的には、会社名、年月、ドキュメント種別などです。メタデータで検索対象となる文書群を限定することで、検索精度を高める狙いです。

処理的には、以下の流れです。
①ユーザーの質問文から、メタデータに対応する構造化条件を抽出する
②抽出した条件をメタデータフィルタとして検索クエリに付与する
③その条件で限定された範囲に対して、ベクトル検索/キーワード検索/ハイブリッド検索を行う

①の構造化条件への変換は、LLMで行う場合もあれば、事前に用意した辞書を使って、質問文中に含まれる会社名、年度、文書種別などの表現を照合することで行う場合もあります(表記ゆれを吸収して正規化することが必要)。

メタデータは上記のフィルタリング利用が基本ですが、ほかにも様々な活用が考えられます。その内容を整理します。

メタデータの「2つの扱い方」

メタデータ設計の最大の論点は、「メタデータを本文(ベクトル化対象)に含めるべきか否か」です。情報の性質によって以下の「レベル1」と「レベル2」を使い分けるのが良いでしょう。

レベル1:属性情報の「分離」(ノイズ対策)

・原則: 管理的な属性は、本文には入れず、DBのメタデータフィールドに隔離する。
・理由: 「作成日: 2025年」「種別: マニュアル」といった情報を本文に混ぜると、本来の意味ベクトルに対してノイズとなり、検索精度を下げるため。
・対象: 作成日時 / 年度:リランキングでの活用推奨
     カテゴリ / 部署ID:「0か1か」のフィルタリングでの活用推奨

関係ない部署や古いデータの混在を防ぐことで、Precision(適合率)向上が期待できる。

レベル2:属性情報の「本文注入」(文脈補完)

・原則: 本文に属性情報を入れるとノイズになって検索精度が下がる。そのため、タイトルや見出しなど本文のテーマや主語を補完する情報に限り、本文の先頭に文字列として注入する。
・理由: 文書をチャンクに分割すると、指示語の指す内容が失われやすい。タイトルや見出しを補うことで、ベクトルに正しい「主語」を持たせる。
・対象: 文書名、章・見出し

チャンク化で主語が消えた情報を補完することで、Recall(再現率)向上が期待できる。

3つのメタデータ活用方法

設計したメタデータは、RAGシステムの「検索」「出力」「運用」の3フェーズで活用します。

① 検索時活用(精度向上)

分離したメタデータを、検索エンジンの機能で活用。

・条件フィルター(Pre-Filtering):
 ベクトル検索を行う前に、条件で絞り込む。使いすぎると検索結果が0件になるので、権限管理など対象範囲を限定する。
 - 権限管理: ユーザーIDや所属部署で、閲覧可能なドキュメントのみを検索対象とする。
 - 鮮度維持: 「最終更新日が1年以内」などの条件で、古い情報を除外する。

・リランキング(Post-Ranking):
 ベクトル検索でヒットした上位候補に対し、メタデータを考慮してリランキングする。リランキングはLLMの利用を推奨。
 - 鮮度調整: 更新日付が新しいドキュメントを上位表示。
 - 重要度調整: 「公式マニュアル」を「個人の日報」より上位表示。

② 出力時活用(ユーザビリティ)

LLMが回答を生成する際、根拠としてメタデータを提示する。

・出典情報の明示: 回答の末尾や脚注に、参照したドキュメントのタイトル、URLを表示する。ハルシネーション対策。
・回答生成用のLLMのプロンプトに「回答には必ず出典IDを記載せよ」と指示する。

③ 運用時活用(ライフサイクル管理)

検索品質を維持するための管理用データとして利用する。

・情報の棚卸し: 最終更新日のメタデータを付与し、一定期間更新がないデータを削除する。
・有益度計測: ユーザーからのフィードバックをメタデータに記録し、検索アルゴリズムの改善やドキュメントの修正に役立てる。

3. 推奨データ構造(JSONスキーマ)

上記を踏まえた、ベクトルDBへの推奨格納フォーマットです。
「属性は分離」しつつ、「文脈(タイトル等)のみ注入」しています。
{
  "id": "doc_123_chunk_05",
  "vector": [0.012, -0.054, ...],
  
  // -------------------------------------------------------
  // 【領域1】メタデータ (Payload)
  // 目的:フィルタリング、リランキング、運用管理
  // 原則:ここには全ての属性情報を網羅する
  // -------------------------------------------------------
  "metadata": {
    // A. 検索フィルタ・権限用
    "doc_type": "manual",
    "category": "purchasing",     // 購買
    "department": "sales_div",
    "access_level": ["group_a"],

    // B. リランキング・運用管理用
    "created_at": "2024-01-15",
    "updated_at": "2024-12-01",   // 新しさの判定に使用
    "is_active": true,

    // C. 出力表示用 (Reference)
    "title": "購買管理規程 第3版",
    "section": "第4章 相見積もりの取得",
    "source_url": "https://...",
  },

  // -------------------------------------------------------
  // 【領域2】本文テキスト (Page Content)
  // 目的:ベクトル化による意味検索
  // 原則:ノイズを避けるため属性は入れず、文脈(主語)のみ注入する
  // -------------------------------------------------------
  "page_content": "Title: 購買管理規程 第3版 | Section: 第4章 相見積もりの取得\n10万円以上の物品購入を行う際は、必ず3社以上の相見積もりを取得し..."
}

まとめ

メタデータ活用の基本は、タイトルと見出しのみ本文に入れて、その他の属性はリランキングやフィルタで活用する」という分離運用です。

また、権限管理で悩まれている人は、メタデータで条件フィルターすると、閲覧権限ごとにRAGシステムを複数構築する必要がなくなり、単一インデックスでの運用が可能になります。