RAG の仕組み図と学習ロードマップの記事一覧
以下の記事では、RAG ワークフローを 3 つのフローに分けて整理しています。
各記事は個別にも読めますが、全体を通して読むことで、基本的な RAG システムの流れを少しずつ把握しやすくなると思います。
Indexing flow：ユーザーが質問する前の準備
① 文書を処理・分割する
生のドキュメントを、後続の検索で扱いやすい、クリーンで追跡可能なチャンクに整えます。
- 解析が不十分だと、見出し、表、ページ構造、出典情報などが失われることがあります。
- チャンクの切り方によっては、有用な根拠が retrieval の前に分断されてしまいます。
② ベクトル化して保存する
チャンクをベクトル表現に変換し、後で検索できるようにメタデータと一緒に保存します。
- 意味が近いチャンクでも、含まれる事実は異なる場合があります。
Query-time flow：ユーザーの質問に答える
③ 候補を検索する
保存済みのレコードを検索し、ユーザーの質問に役立つ根拠を含んでいそうな候補チャンクを返します。
- BM25 や Sparse Retrieval は、エラーコード、API 名、バージョン、ID のような正確な語句に強みがあります。
- Hybrid Search は、意味検索と語句ベースの検索を組み合わせたい場合に使われます。
- 検索された候補は、まだ LLM に渡す Context ではありません。
④ コンテキストを選択する
検索された候補を rerank・選択・整理し、LLM に実際に渡す Context を作ります。
- selection は、どの候補を根拠として残すかを決めます。
- compression、重複排除、並べ替え、traceability は、それぞれ異なる役割を持ちます。
- Top-K と Top-N は、RAG ワークフローの異なる段階を表します。
⑤ プロンプトを組み立てる
準備済み Context、ユーザーの質問、grounding rules、出力形式をまとめ、LLM に送る Prompt を作ります。
- Context、ユーザーの質問、指示、回答ルールは明確に分ける必要があります。
- Prompt を工夫しても、検索されなかった根拠を補うことはできません。
Feedback flow：システムを診断・改善する
⑥ 評価して改善する
検索候補、Context、回答、出典参照を確認し、RAG ワークフローのどこを改善すべきかを診断します。
- 検索候補、final context、Prompt、回答、出典参照の順に確認すると、問題が入り込んだ場所を特定しやすくなります。
- retrieval metrics（検索評価指標）は、必要な根拠を取得できたか、適切な順位に並んでいるかを評価します。
このロードマップの目的
RAG を初めて学ぶ人、または RAG の概念をいくつか学んでも、まだ頭の中で整理しきれていない人の助けになればと思い、このロードマップを用意しました。
この記事では、より高度な RAG の話題に進む前に、RAG の基本的な知識構造を整理します。
目的は、RAG の全体像を、ひとつの見取り図として持ちやすくすることです。後で見慣れない RAG の概念に出会ったときも、その見取り図の中に位置づけることで、システムのどの部分に関係するものなのかを理解しやすくなると思います。