RAGって結局なに？ Agentic RAGまでの進化を整理してみた

——東大・松尾岩澤研究室 学習支援ChatBot講義から学んだこと【技術編】

前回の記事では「知識の汎化能力」という話を中心に書きました。今回はもう少し技術寄りに、講義で学んだRAGの仕組みと進化の流れを整理します。

「LLMは知ってるけどRAGはよくわからない」という方に向けて、できるだけ読みやすく書いていきます。私自身も学びながら書いているので、一緒に理解していく感覚で読んでもらえたら嬉しいです。

まず「RAG」って何？

RAGとは Retrieval Augmented Generation の略で、日本語にすると「検索拡張生成」です。

LLMはとても賢いのですが、学習データに含まれていない情報は答えられません。たとえば「鹿児島県のかたすみにある体操教室の月謝は？」なんて、LLMが知っているわけがない。

そこでRAGの出番です。

事前に用意したドキュメントをデータベースに蓄積しておき、質問が来たときに関連する情報を検索して、それをLLMに渡して回答させる手法。

流れをざっくり書くとこうです：

質問が来る
　↓
ドキュメントDBを検索（Retrieval）
　↓
関連する情報をLLMに渡す
　↓
LLMが回答を生成（Generation）

これによってLLMは「自分の知識」だけでなく、「用意されたドキュメント」を根拠に回答できるようになります。ハルシネーション（事実と異なる回答）を減らせるのも大きなメリットです。

Classical RAGの仕組みと課題

従来のRAG（講義では「Classical RAG」と呼んでいました）では、こんな事前準備が必要です。

ドキュメントを用意する
　↓
チャンク分割（小さな断片に切り分ける）
　↓
Embedding（ベクトル数値に変換）
　↓
ベクトルDBに格納

「チャンク」とは文書を検索しやすい大きさに切り分けたもの、「Embedding」とは文章の意味を数値の配列で表現したもの、「ベクトルDB」はその数値を格納する専用データベースのことです。

この準備が整って初めて、検索ができるようになります。

ただここに課題があります。ドキュメントを更新するたびにこの処理を最初からやり直す必要がある。松尾研では文字起こしの修正や講義資料の更新のたびに手作業が発生していたそうで、それが大きな運用コストになっていました。

Agentic RAGとは何が違うのか

Classical RAGは「1回検索して答えを出す」シンプルな構造でした。

Agentic RAGはそこに「自律性」が加わります。

LLMが自律的に探索空間を計画し、必要なデータを収集・評価し、十分でなければさらに探索を繰り返して、最終的な回答を生成する手法。

キーになるのが「ReAct」という考え方です。

質問が来る
　↓
考える（Thought）
　↓
ツールを使う（Tool）
　↓
結果を確認（Output）
　↓　← 十分でなければここに戻る
回答を生成（Answer）

つまりAIが「これで十分か？」と自分で判断しながら、必要なだけ調査を繰り返してくれるわけです。

松尾研では、質問の種類に応じて「講義内容」「運営資料」「演習資料」の3つのデータ空間を使い分けるよう設計されていました。どの空間を探索するかをAI自身が判断する——これがAgenticな部分です。

Classical RAG vs Agentic RAG まとめ

「Embeddingなしで動く」PageIndexという発想

今日の講義でいちばん驚いたのがこれでした。

「PageIndex」というオープンソースの手法は、Embeddingもチャンク分割も不要なRAGです。GitHubのトレンドで1位になるくらい注目されています。

仕組みはシンプルで、目次のように構造化されたデータを、AIが階層をたどりながら探索します。

目次（大見出し）
　├── セクション1
　│   ├── 小項目A
　│   └── 小項目B
　└── セクション2
　    └── 小項目C

上から全部読み込むのではなく、必要そうな場所を判断して階層を潜っていく。トークンの節約にもなるし、更新も構造を編集するだけでいい。

Notionで階層構造を作っておけば、事前のEmbedding処理なしに同様のことができる可能性があります。小規模な事業者にとっては、導入と運用のハードルが大きく下がる手法です。

精度を保つための工夫：ループ制限とFew-shot

松尾研のChatBotでは、ハルシネーション（AIが事実と異なることを自信満々に答えてしまう問題）を防ぐためにいくつもの工夫をしていました。その中でも特に気になったのがこちら。

① ループをの回数を制限する

Agentic RAGは「十分でなければ再探索」を繰り返しますが、無限に繰り返すとコストがかかるし、かえって答えがブレてしまうことも。そこで最大ループ数を決めて、それ以上は探索しない設計にしているそうです。

② Few-shotでよくある質問を事前に入れる

Few-shotとは、「こういう質問にはこう答える」という例をあらかじめLLMに見せておく手法です。よくある質問とその模範回答を入れておくことで、回答の質と一貫性が上がります。

シンプルな工夫ですが、これが実務では効いてくるんだなと学びました。

おわりに

RAGの基本からAgentic RAGの進化、PageIndexという新しいアプローチまで、今日学んだことを整理しました。

技術は難しく見えますが、根底にある発想は「AIに正確な情報を渡して、より良い回答をさせる」というシンプルなものです。その実現方法がどんどん賢くなっていっている。

次回は第3弾として、実務活用編を書く予定です。小規模の事業者がどう使えるか、具体的に考えてみます。

今日もいっぱい学びました！

#LLM #RAG #AgenticRAG #PageIndex #AI #松尾研 #AI教育 #機械学習 #ChatBot