RAGの全体像：Indexing, Retrieval, Generationの3ステップ

仕組みは分かった、で、何から作るのか

RAG の考え方は「資料を見せてから答えさせる」だけです。ところが実際に作ろうとすると、資料をどこに置くのか、どうやって関係のある箇所だけ取り出すのか、という問いが一気に押し寄せてきます。

RAG は 3 つの工程に分かれています。Indexing（索引作り）、Retrieval（検索）、Generation（生成）です。以降のレッスンはすべてこの 3 つのどれかの話なので、ここで全体の地図を作っておきます。

聞かれる前に済ませておく仕事

Indexing は、質問が来る前に終わらせておく準備です。PDF や社内 Wiki を読み込み、扱いやすい長さに切り分け、それぞれを数値の並びに変換して、専用のデータベースにしまいます。

ここが「事前」である点が重要です。数百ページの資料を毎回読み直していては、回答に何十秒もかかります。切って数値にしておくことで、質問が来てからの仕事を一瞬で終わらせられます。

裏を返すと、資料を追加したり差し替えたりしたときは、この工程だけを回し直す必要があります。ファイルを置いただけでは索引に入りません。運用に乗せるときは、更新をどのタイミングで反映するかを最初に決めておいてください。

聞かれてからの仕事は 2 つだけ

質問が届いたら、まずその質問文を、資料と同じ方法で数値に変換します。そしてデータベースの中から数値が近いものを数件だけ取り出します。これが Retrieval です。

取り出すのは全部ではなく、上位の 3 件から 5 件です。全部渡すと元の木阿弥ですし、1 件に絞ると外したときに何も残りません。この件数は後で必ず調整することになります。

取り出した本文を質問と一緒に LLM へ渡し、この資料に基づいて答えるよう指示するのが Generation です。ここで LLM がやっているのは、記憶を探すことではなく、渡された文章を読んで質問の形に整えることです。文章力は使いますが、知識は使いません。

的外れな回答が出たとき、どこを疑うか

社内チャットボットが関係のない話を返してきたとします。原因はこの 3 つのどこかにあります。

資料の切り方が雑で、必要な記述が別々の断片に散っているなら Indexing の問題です。この場合、どれだけ検索を工夫しても、そもそも意味の通る断片がデータベースの中に存在しません。

資料は正しく入っているのに、質問と噛み合う断片が取れていないなら Retrieval の問題です。質問の言い回しと資料の書き方が違いすぎる、といったことが起きています。

正しい断片が渡っているのに、それを無視した回答が返ってくるなら Generation の問題です。プロンプトが資料の外を使うことを許してしまっています。

順番も決まっています。Indexing が崩れていれば下流は何をしても直りません。上流から順に潰してください。「精度が悪い」とひとまとめにせず、この 3 つのどこで崩れたかを先に決める。RAG の改善は、ほぼこれに尽きます。