最先端AIを技術の中身まで読み解く「AIウォッチ」の連載記事です（RAG 全10回・第1回）。初出・全10回の一覧は本サイトにあります → https://aiwatch-jp.pages.dev/rag-overview-01

まず、具体的な話からします。

私は yuewei という個人の AI 情報収集システムを運用しています。
84 の情報源から集めた記事が、いま 3961 本以上あります。

このシステムの検索は、最初はキーワード検索（BM25）で作っていました。
でも、言い換えられた表現を取りこぼします。
「画像認識」で探しても「ビジョンモデル」と書かれた記事に届かない、という類のことです。

そこで後から、ベクトル（意味）検索を足しました。
今度は逆の弱点が出ました。
固有名詞や「特定の人の特定の発言」に弱いのです。
ある人物の一言を探したいのに、似た話題の一般的な解説ばかりが上位に来る。

結局いまは、両方を混ぜるハイブリッドに落ち着いています。

この運用の経験が、この連載の出発点です。
RAG を「検索して答える仕組み」と一言で呼べないのは、まさにこの「どう探すか」の設計が中心になるからです。

RAG は、一度流行語になりました。

社内文書を検索して答える。
PDF を読ませて質問に答える。
ベクトルデータベースにつないで、関連する文章を取ってくる。

この説明は間違っていません。
ただ、いまの RAG を見るには、少し狭すぎます。

実際の現場では、問題は「検索できるか」だけではありません。

必要な資料が見つからない。
見つかったけれど、関係ない断片も混ざる。
文書の一部だけを見て答えてしまう。
複数の資料をまたぐ質問になると、途中で足りないまま答える。
あとから見ると、答えの根拠がどこにあったのか分からない。

RAG の難しさは、このあたりにあります。

いま起きている変化は、もっとはっきりしています。
RAG は、モデルの外にある事実を引いてくるための部品ではなく、どの情報を、どの順番で、どこまで見て、いつ止めるかを決める仕組みになりつつあります。

この連載では、まずその全体像を押さえます。

このあと全10回で、BM25 / RRF / ハイブリッド検索、grep とベクトル検索の使い分け、Agentic RAG、PageIndex、評価と失敗モード、グラフ検索、マルチモーダル、企業知識ベース、そして Context Engine まで扱います。
ただし、用語を並べるだけの連載にはしません。RAG を、検索・文書・運用・記憶まで含むシステムとして見ていきます。

RAG がまだ必要な理由

LLM は明らかに賢くなりました。
コンテキストも長くなりました。
ファイルを読ませる体験も、以前よりずっと自然になっています。

それでも、「全部をモデルに覚えさせればいい」にはなりません。

理由は単純です。

モデルの中に入っていない情報は、やはり外にあります。
社内文書、議事録、仕様書、PDF、表、コード、最新ニュース、個人の作業履歴。
しかも、その多くは毎日変わります。

ここで RAG の役割が出てきます。

RAG は、モデルに全部を暗記させる代わりに、必要な事実を必要なときだけ持ってくる。
つまり、モデルの記憶だけに頼らず、外にある事実を使うやり方です。

この考え方は古く見えて、実はまだかなり強いです。
なぜなら、現実の知識は動き続けるからです。

モデルが賢くなるほど、RAG はいらなくなる。
そう見える時期もありました。

でも実際には、逆の面もあります。
モデルが賢くなるほど、外部情報をただ貼るだけではもったいない。
どの情報を見せるか、どう順番を組むか、いつ追加で調べるかまで設計したほうが、モデルの力を引き出せます。

だから RAG は消えるというより、形を変えています。

RAG の仕事は「探す」だけではない

RAG を「検索」とだけ呼ぶと、少し足りません。

実際には、だいたい次のような流れがあります。

何を聞かれているかを分解する
どの情報源を見に行くかを決める
候補を拾う
雑音を落とす
足りなければもう一度探す
答えとしてまとめる

ここで大事なのは、最後の生成より前に、かなり多くの判断が入っていることです。

本当に効く RAG は、検索結果をそのまま並べるだけではありません。
どの情報を残し、どの情報を捨て、いつ追加で見に行くかを決めます。

だから RAG は、検索エンジンというより、検索を含んだ作業の組み立て方に近いです。

失敗の多くは「見つからない」か「混ざりすぎる」か

RAG が難しい理由は、だいたい 2 つに分かれます。

1 つ目は、必要なものが見つからないことです。
関連文書があるのに拾えない。
表現が違うだけで外す。
長い文書の奥にある重要箇所を取りこぼす。

2 つ目は、見つかりすぎることです。
関係ない断片まで混ざる。
似ているけれど違う情報が入る。
その結果、モデルが余計な文脈に引っ張られる。

今の RAG の主戦場は、単純な再現率だけではありません。
どれだけ拾うか と どれだけ雑音を抑えるか の両方です。

長いコンテキストが伸びても、この問題は消えません。
大量の文脈を入れれば安心、という話にはならないからです。
入れた文脈の質が悪ければ、モデルはむしろ迷います。

だから最初に見るべきこと

この連載の最初に押さえたいのは、RAG には少なくとも 3 層あるということです。

何を探すかを決める層
どう探すかを決める層
どこで止めるかを決める層

1 は問いの分解です。
2 は BM25、ベクトル、ハイブリッド検索、再ランキングの話です。
3 は Agentic RAG や PageIndex のような、「まだ足りないなら続ける」判断です。

この 3 層を分けて見ないと、RAG の議論はすぐに雑になります。

たとえば「ベクトル検索が弱い」と言うだけでは足りません。
何を探していたのか。
キーワード一致が必要だったのか。
雑音が多すぎたのか。
そもそも問いが複数段階だったのか。
そこまで分けないと、改善策は出ません。

全10回で見ていくこと

このシリーズでは、RAG を次の流れで見ます。

RAG の全体像
BM25 / RRF / ハイブリッド検索
grep とベクトル検索の使い分け
Agentic RAG
PageIndex と階層型検索
評価と失敗モード
グラフ検索とマルチホップ
マルチモーダルと文書処理
企業知識ベースと改善ループ
Context Engine への収束

前半では、RAG の骨格を作ります。
後半では、その骨格を実際の文書、画像、企業知識ベース、運用ループへ広げます。

つまり、この連載の狙いは、RAG を流行語として説明することではありません。
どういうときに RAG が必要で、どういうときに別のやり方に負けるのか を、作業工程として見える形にすることです。

先に言っておく結論

RAG の進化方向は、「もっと大きいベクトルデータベース」ではありません。

本当に進んでいるのは、検索をどう制御するか です。
問いをどう割るか。
どの情報源を当てるか。
どこまで拾えば十分か。
どの雑音を切るか。
いつもう一度探すか。

この判断がうまくなるほど、RAG は単なる補助機能ではなくなります。
システムの中で、事実を扱うための中核になります。

この連載では、ここを一つずつ分解していきます。

次回は、その土台になる BM25、RRF、ハイブリッド検索を扱います。
キーワード検索とベクトル検索は、どちらが新しいかで比べるものではありません。
失敗の仕方が違うから、一緒に使う価値があります。

本シリーズ（全10回）の続きと一覧は、AIウォッチ本サイトでまとめて読めます。
👉 https://aiwatch-jp.pages.dev/rag-overview-01

―― AI未来編集室「AIウォッチ」