RAGの最低限の型 ― 記事をぶち込むだけでは動かない理由

Retrieval-Augmented Generation（RAG）は、手持ちのドキュメントを検索し、その内容をもとにAIが回答を組み立てる仕組みである。理屈は単純だが、実際に自前データを突っ込んで動かすと、ほとんどの人が同じ壁にぶつかる。つまり、「記事をそのまま入れてもうまく動かない」という壁である。本稿では、その原因と、最低限必要な構造化の型を整理する。

なぜ生記事ではうまくいかないのか

まず、生の記事をそのままナレッジに入れた場合、AIが参照するチャンク（文書の断片）は文脈を失う。記事の途中で別作品に触れたり、比喩や専門語が出てくると、それらが独立した情報として扱われてしまう。その結果、「作品Aについて教えて」と聞いても、別作品の記事の一節がヒットするような誤爆が発生する。

また、自然文の中では語の意味が複数の層にまたがっている。例えば「ダーク」は作風の形容にも、キャラクター性にも使われる。RAGはこれを区別できず、似た単語が出てくる別の記事を拾ってしまう。つまり、文脈を機械が理解するには構造化が足りないのである。

記事側でやるべき前処理

RAGを機能させる第一歩は、ドキュメントを「機械が読み取れる構造」に変えることだ。特別なデータベースを用意する必要はない。Markdownファイルの先頭にメタ情報を追記するだけでよい。

---
PRIMARY_WORK: 作品A
MENTIONED_WORKS: [作品B, 作品C]
TAGS: [ツンデレ, 学園, ダーク]
CHARACTERS:
  - 小紅(ツンデレ/不器用)
CARD: 狂気寄りのフェティッシュ×学園サスペンス。ヒロインは照れ隠しが激しい。
---

このヘッダを「機械が理解できる目印」として焼き込む。さらに、本文の見出しごとに PRIMARY_WORK: を差し込んでおくと、チャンクに作品名が必ず残る。これだけで、検索段階での誤爆は激減する。

検索の構成 ― ハイブリッド検索を前提にする

次に、RAGの検索部分を「ハイブリッド検索」として設計する。ベクトル検索だけでは曖昧一致になりすぎるため、まずBM25でキーワード一致を取り、上位候補をベクトルで再ランクする。これにより、タイトルやタグで明確に一致する文書を優先できる。閾値を設け、スコアが低いものは不採用とすることが重要である。

クエリの分類と処理

質問の内容によって検索戦略を変えると精度が上がる。分類は以下の三種である。

• 作品名指定型：「断裁分離のクライムエッジ」など固有名詞中心の質問。
• 属性型：「ツンデレヒロインの漫画」など特徴や傾向を問う質問。
• 雑談・その他型：曖昧な質問。

作品名指定型では、PRIMARY_WORK: の完全一致を必須とする。属性型では、タグをもとに候補作品を出し、その後で本文を深掘りする二段構成にする。雑談型は推測しない規約を設定し、不回答で返す。

データ層の分離と統合

さらに、文脈的な情報──たとえば「管理人の好み」「過去に高評価した傾向」など──は、記事本文とは別にプロフィール文書として保持する。RAGに混ぜ込むと誤推論の温床になるためである。検索・回答の段階で必要に応じて明示的に参照する設計にした方がよい。

評価指標と検証

運用前に、少数のテストクエリを用意して評価する。
最低限の指標は以下の三つである。

• 正答率@1：一番上に正しい記事が出る率
• 不回答率：わからないときに黙れる率
• 誤爆率：PRIMARY_WORK不一致を拾った率

この三つだけで、閾値やTop-kの調整方針は決まる。

最小構成のまとめ

RAGを安定して動かすための最低限の型を整理すると次のようになる。

おわりに

RAGは「ドキュメントを入れるだけで動く」ように見えて、実際には構造化と規約設計が本体である。記事を構造化し、検索の粒度を整え、推論の境界を明確にする。これができてはじめて、AIは「それっぽいことを言う」段階から、「正しい情報を根拠付きで返す」段階に進む。
最初の一歩で失敗するのは自然だが、構造化の型さえ掴めば、RAGは一気に手の内に入る。