大学も卒業したので、やっているときにはあまり考えられなかったところを、かじった程度の視点から考えてみました。
RAGってそもそも何？
AI（大規模言語モデル＝LLM）は賢いけれど、社内固有情報や新事実に対してはそのままでは弱い。「うちの会社の就業規則は？」と聞いても知らないし、昨日のニュースも知らない（最近のChatサービスでは答えられますが…🫠）。
そこで考えられたのがRAG（Retrieval-Augmented Generation 検索拡張生成）という仕組みです。AIに質問する前に、手元のデータベースから関連情報を「検索」して、それをAIに渡して回答させる。つまり「カンニングペーパー付きのテスト」のようなものです。
最近では、このRAGにはもいくつかのパターンがあり、どれを選ぶかで精度もコストも使い勝手も大きく変わるようです。私も大学で学んでいるときにRAGを使った経験があるので、そのときの実感も交えながら、4つの代表的なRAGパターンを比較してみたいと思います。
素人なりの視点からの考察ですが、RAGをこれから導入しようと考えている人や、RAGの違いがよくわからない人の参考になれば幸いです。
4つのRAGパターン
1. 従来型 RAG
一言で言うと、質問に似た文書を探してきて、AIに読ませる
質問 → ベクトル化 → 似た文書を検索 → AIが回答
文章を多くの実装では「ベクトル」という数値の列に変換し、質問と似ている文書をコサイン類似度や距離で探す。シンプルで高速。多くの場合、最初に検討するパターン。
向いている場面 FAQ、社内文書検索、マニュアル参照
良いところ🤗
- 構築が簡単で、動くものがすぐ作れる
- 応答が速い
- 「この質問にはこの文書が関連する」という直感的な仕組み
つらいところ😢
- 「似ている」と「正しい」は別物。的外れな文書を拾うこともある
- 文書の切り分け方（チャンキング）の良し悪しで精度が大きく変わる
- 要素間の関係性（AだからB、AなのにC）は理解できない
私の実感 自分も最初にこのパターンを試した。「料理番組」で検索すると似た料理番組は出てくるが、「料理×お笑い」のような異質な分野の組み合わせは、単純な類似度検索だけでは拾いにくい。似ていないものを探す能力には乏しいかもしれない。
2. エージェント型 RAG
一言で言うと、AIが自分で検索計画を立て、何度も調べ直してから答える
質問 → AIが分析・計画 → 検索 → 足りなければ再検索 → 検証 → 回答
従来型のRAGが「一発検索」なのに対し、エージェント型RAGはAI自身が「この情報だけでは足りない」と判断して、クエリを書き換えたり、追加で検索したりする。人間が調べ物をするときの試行錯誤に近い。
向いている場面 調査レポート、複雑な質問、複数情報源の統合
良いところ🤗
- 複雑な質問にも対応できる
- 検索結果の品質をAI自身が検証する
- 人間の調査プロセスに最も近い
つらいところ😢
- 遅い。検索を何往復もするので体感的に待たされる
- API呼び出しが増えるのでコストが嵩む
- 構築が複雑で、デバッグが大変
私の実感 精度は確かに上がるが、レイテンシの問題は深刻。ユーザーが「待てる」用途でないと使いにくい。ただし、全部をエージェント型にするのではなく、「最初の検索結果が不十分なときだけ追加検索する」という軽量版なら実用的かもしれない。
3. Graph RAG（知識グラフ型RAG）
一言で言うと、情報を「関係性のネットワーク」として持ち、つながりを辿って答える
質問 → 関連する要素を特定 → グラフ上の関係性を探索 → 回答
情報を「AはBと関係がある」「BはCの原因である」というネットワーク（知識グラフ）として構造化する。ベクトル検索が「似た文書」を探すのに対し、Graph RAGは「関係している情報」を芋づる式に辿る。
向いている場面 人物関係、組織構造、因果関係の分析
良いところ🤗
- 「AとBの関係は？」という問いに強い
- 複数の情報をまたいだ推論（マルチホップ）ができる
- 回答の根拠をグラフ上のパスとして示せる（説明可能性）
つらいところ😢 * 知識グラフの構築と維持に手間とコストがかかる * グラフの設計（スキーマ）にドメイン知識が必要 * 大きなグラフでは検索が遅くなりがち
私の実感 自分はNeo4jにneosemanticsを使ってRDFを取り込み知識グラフを構築した。情報の関係性をノードとエッジで表現でき、従来型RAGでは不可能だった関係性の探索が可能になった。一方、スキーマ設計は試行錯誤の連続で、「何をノードにし、何をエッジにするか」という判断自体にドメインの専門知識が求められる。実務知識が必要なのが大きなハードルかもしれない。
4. ベクトルレス型 RAG
一言で言うと、ベクトル変換を使わず、キーワードの一致で検索する
質問 → AIがキーワードを生成 → キーワードで文書を検索 → 回答
ベクトル埋め込みを使わず、BM25などのキーワードマッチングアルゴリズムで検索する。ベクトル変換のコストがゼロになるため、最も軽量で安価。
BM25（Best Matching 25）は、全文検索で最も広く使われているキーワードベースのランキングアルゴリズム。
向いている場面 予算制約のあるPoC、固有名詞が重要な検索、ローカル環境
良いところ🤗
- 埋め込みモデルが不要なのでコストが低い
- パイプラインがシンプルで理解しやすい
- 固有名詞や専門用語の完全一致に強い
つらいところ😢
- 「意味的に近い」検索ができない（同義語や言い換えに弱い）
- スケールに限界がある
- 検索の柔軟性が低い
私の実感 実は実用的な場面は多いと考える。特にローカルLLM（Ollama等）と組み合わせれば、外部APIに一切データを送らずにRAGシステムが組める可能性もある。企業の機密情報を扱う場面では、これだけで十分なケースもある。
全体を俯瞰して見えてくること
どう選ぶか ── 4つの判断軸
| 判断軸 | 従来型 | エージェント型 | Graph RAG | ベクトルレス型 |
|---|---|---|---|---|
| スピード重視 | ◎ | △ | ○ | ◎ |
| 精度重視 | ○ | ◎ | ◎ | △ |
| コスト重視 | ○ | △ | △ | ◎ |
| 構築の手軽さ | ◎ | △ | × | ◎ |
⚠️正解は一つではなく、適応する分野や正確性などによって正解は変わる。複雑な業務では単一方式では足りないことが多い。 BM25のキーワード検索、ベクトルの意味検索、Graph RAGの関係性検索を組み合わせた「ハイブリッド型」が現実的な最適解かもしれない。
RAG全体に共通する課題
4つのパターンを見比べてみると、パターン固有の課題とは別に、RAGという仕組み自体が抱える構造的な課題が浮かび上がってくる。
1. データ管理の問題
RAGの精度は、結局のところ「元のデータの質」に依存する。どんなに高度な検索アルゴリズムを使っても、元のデータが雑然としていれば、出力も雑然とする。チャンキングの方法、メタデータの付与、データの鮮度管理である。これらの地味な作業が精度を左右するが、十分に体系化されていないようにも感じる。
2. レイテンシの問題
精度を上げようとすると、処理が重くなる傾向がある。エージェント型RAGの反復検索、Graph RAGのグラフ走査、ハイブリッド型の複数検索統合。精度とスピードはトレードオフの関係にあり、用途に応じた妥協点を見つける必要があると感じる。
3. データ変換時の情報損失
これが本質的な課題だと考えている。体験を言語にし、言語を構造化データにし、構造化データをベクトルにする。変換のたびに元の情報は不可逆的に圧縮される。RDF-Starのようにメタ情報を付与して損失を減らす工夫はできるが、「完全な保存」は原理的に不可能だろう。
おわりに
技術的な進化
- ハイブリッド検索の成熟 … BM25 + ベクトル + グラフの三層統合が標準になる可能性がある。各手法の弱点を補完し合い、並列実行でレイテンシも抑えられる。
- データガバナンス層の確立 … 検索アルゴリズムの高度化よりも、データの品質管理の方がROIが高い。ここが今後最も発展する領域かもしれない。
- ローカルRAGの台頭 … ローカルLLMの性能向上により、機密データを外部に出さずに実用的なRAGを構築できるようになりつつある。ここも企業活動からすればメリットが大きい。
原理的な限界と、それでもできること
RAGは「既知の情報の検索と再構成」の技術であり、「まだ存在しない知識の創出」はできない。LLM自体が学習データの確率分布からのサンプリングである以上、RAGで高品質なデータを注入しても、「確率的にありそうな出力の精度が上がる」以上のことは原理的に起きない。
しかし、だからといってRAGに価値がないわけではない。RAGは「人間の知的活動を代替すること」ではなく、「人間が考えるための足場（scaffolding）を提供すること」ではないかと考えている。 所詮、完全な知識継承は、実は人間同士でも不可能なのだから。知識というものは、受け手の中で常に「別のもの」として再構築されることが往々にある。AIにできるのは、その再構築を効率よく促す「良い足場」を提供するところであろう。
今回みた、4つのパターンは、その足場の組み方のバリエーションだ。どのパターンが優れているかではなく、どの場面でどの足場が有効かを見極めることが、RAGを活用する上での本質ではないかと。
少し真面目に考えたので、頭が痛くなった🤣
