RAG(Retrieval-Augmented Generation)でIndexingと呼ばれるのは、社内文書を検索できる形に作り替えて索引へ登録するまでの工程です。ここで決めたチャンクの切り方と埋め込みモデルは、あとから検索アルゴリズムを差し替えても取り返せません。この記事では、Indexingが担う4つの作業と設計の判断基準を実測値つきで整理し、研究側の呼び名であるNaive RAG・Advanced RAG・Modular RAGの3分類が、それぞれ何を改良した段階なのかを一次論文の日付とともに突き合わせます。
まとめ:Indexing設計と3分類を読み解く要点
先に結論をまとめます。
- Indexingは4工程(読み込み・チャンク分割・埋め込み・索引登録)で構成されます。索引に載らなかった情報は後段で回収できないため、取り出せる情報の範囲はこの段階で決まります。
- チャンクサイズの既定値は、フレームワーク間で単位も大小関係も揃っていません。llama-index-core 0.14.23 は1024トークン、langchain-text-splitters 1.1.2 は4000文字が既定で、どちらが大きいかは扱う言語で逆転します。
- langchain の既定セパレータには日本語の句点が入っていません。日本語の長い段落は文字数だけを見て切られます。
- Naive・Advanced・Modularの3分類は2023年12月のサーベイ論文(arXiv:2312.10997)が示した整理で、製品名でも規格でもありません。Advanced RAGは検索の前後処理、Modular RAGはモジュール分解と再構成を指します。
- Advanced RAGの再ランキングを入れる前に、Indexingを疑うのが順序です。
- Agentic RAGのような反復型は、費用と遅延が反復回数に応じて積み上がります。反復プロンプティングを含む推論計算の配分を扱った研究(arXiv:2410.04343)は、最適に配分した場合に標準的なRAGと比べ最大58.9%の改善を報告しています。
以下、Indexingの中身から順に見ていきます。
RAGのIndexing|索引構築が担う4工程と設計の分かれ目
Indexingは、検索対象の文書を「意味で引ける状態」に変換して保存する工程です。実行はユーザーの質問より前、多くは夜間バッチや文書更新のタイミングで行われます。質問のたびに走るRetrievalやGenerationと違い、やり直しには全文書の再処理が必要になるため、設計ミスの回収コストが最も高い工程でもあります。
読み込み・チャンク分割・埋め込み・索引登録の4作業
Indexingの内訳は次の4つです。
| 作業 | 入力 | 出力 | 主な失敗 |
|---|---|---|---|
| 読み込み | PDF・Office・HTML | プレーンテキスト | 表とヘッダーの崩れ |
| チャンク分割 | プレーンテキスト | 断片の配列 | 文の途中で切断 |
| 埋め込み | 断片の配列 | ベクトル | モデルの次元不一致 |
| 索引登録 | ベクトルとメタデータ | 検索可能な索引 | メタデータの欠落 |
このうち読み込みは軽視されがちですが、PDFの表を1行ずつのテキストに潰してしまうと、そのあとどれだけ検索を工夫しても表の意味は復元できません。スキャンPDFや複雑なレイアウトを含む文書群では、この段階でレイアウト解析を挟むかどうかが結果を分けます。埋め込みと索引の内部構造についてはベクトル化とインデックス構造から理解するベクトルデータベースの仕組みで扱っています。
チャンクサイズの既定値が言語によって逆転する理由
「チャンクサイズは何文字が正解か」という問いにフレームワークが答えていると思われがちですが、実際には既定値そのものが揃っていません。配布パッケージの実装を確認すると次のとおりです。
| パッケージ(版) | クラス | 既定サイズ | 既定の重なり | 単位 |
|---|---|---|---|---|
| llama-index-core 0.14.23 | SentenceSplitter | 1024 | 200 | トークン |
| langchain-text-splitters 1.1.2 | RecursiveCharacterTextSplitter | 4000 | 200 | 文字 |
単位が違う点が要注意です。langchain-text-splitters の基底クラスは長さの計測に組み込み関数のlenを使うため、既定では文字数で数えます。一方 llama-index-core の SentenceSplitter は既定でトークナイザ cl100k_base を使います。この条件で換算すると、日本語は1文字あたり約1.08トークンなので4000文字は約4,300トークン相当、つまり1024トークンのおよそ4.2倍です。ところが英文は1トークンあたり約6文字なので、4000文字は約660トークンにしかならず、1024トークンの0.65倍まで縮みます。
既定値の大小関係は、扱う言語で逆転します。「langchainのほうが大きめ」といった比較は日本語文書でしか成り立ちません。結局のところ、埋め込みモデルの入力上限から逆算してトークン数で明示指定するのが唯一の正解です。分割手法の比較はチャンク分割とは?チャンクとトークンの違いから代表的な手法・RAGで効く最適なチャンクサイズまで徹底解説【2026年版】にまとめています。
日本語文書で既定セパレータが機能しない条件
もう一段細かい落とし穴があります。RecursiveCharacterTextSplitter の既定セパレータは、改行2つ(段落区切り)・改行・半角スペース・空文字の4つだけです。日本語の文章には句点で区切られた長い段落が続き、半角スペースはほとんど現れません。結果として、段落区切りで分けきれない長い塊は最後の空文字にフォールバックし、文字数だけを見て機械的に切断されます。
実際に、社内規程を模した同じ本文を chunk_size=120 で分割すると、既定のセパレータでは5チャンク中4つが文の途中で切れます。区切り文字に句点と読点を足し、区切り文字を直前のチャンク末尾に残す設定にすると、6チャンクすべてが句点で終わります。
from langchain_text_splitters import RecursiveCharacterTextSplitter
splitter = RecursiveCharacterTextSplitter(
separators=["\n\n", "\n", "。", "、", " ", ""],
keep_separator="end",
chunk_size=120,
chunk_overlap=0,
)
llama-index-core 側の事情は少し違います。一次の文分割に使われるのは英語向けのNLTK Punktで、日本語の長い塊はここでは割れません。ただしその塊が chunk_size を超えたときの再分割用正規表現に全角の句点・疑問符・感嘆符が入っているため、最終的には文の切れ目に寄ります。日本語の社内文書を扱うなら、区切り文字に句点と読点を明示的に足すこと。これは好みの問題ではなく、既定のままだと文の途中で切れるという実装上の帰結です。意味の切れ目で分ける手法はセマンティックチャンキングとは?意味の切れ目で分ける仕組みと実装・採否判断【2026年版】で比較しています。
メタデータと構造化インデックスで検索範囲を絞る場面
チャンクに部署名・文書種別・有効期限・版番号を持たせておくと、検索時に「営業部の現行版だけ」といった絞り込みができます。これが効くのは、似た文面の文書が版違いで大量に存在する社内規程やマニュアルです。逆に、文書数が数百件程度で種別も一様なら、メタデータ設計に時間をかけるより埋め込みモデルの選定に回したほうが精度に効きます。モデル選定の観点は埋め込みモデルとは?仕組みと日本語モデルの選び方・RAG実装での判断基準【2026年版】を参照してください。
再インデックスが避けられない4つの変更
Indexingは一度きりの作業ではありません。次の変更が入ったときは、既存の索引を作り直す必要があります。
- 埋め込みモデルの変更・更新(ベクトル空間が変わるため、旧ベクトルとの距離計算が無意味になります)
- チャンクサイズや分割方針の変更
- メタデータ項目の追加(後付けできる実装もありますが、既存チャンクには値が入りません)
- 元文書の改訂(差分だけの更新で済ませられるかは、文書とチャンクの対応付けを保持しているかで決まります)
特に1つ目は見落とされやすく、埋め込みモデルのマイナー更新でも新旧のベクトルが混在すると検索結果が静かに劣化します。取り込み処理と再索引の実装判断はRAGパイプラインとは?取り込み系と推論系に分ける工程設計と再索引の実装判断で具体的に扱っています。
Indexing・Retrieval・Generationの責務分担|精度低下の切り分け
RAGの処理はIndexing、Retrieval、Generationの3工程に分かれます。回答がおかしいときにどこを直すかを決めるには、各工程が何に責任を持つかを分けて考える必要があります。
Indexingは索引に載っているかどうかに責任を持ちます。索引に無い情報は、後段のどんな工夫でも取り出せません。Retrievalは載っているものを上位に持ってこられるかに責任を持ちます。ここでの失敗は、正解チャンクが検索結果の20位に沈むといった形で現れます。Generationは渡された文脈から逸脱しないかに責任を持ち、検索結果に無い内容を答えてしまう幻覚はここの問題です。
切り分けの実務では、質問集に対して「正解チャンクが検索上位に入っているか」を先に測ります。入っていなければIndexingかRetrievalの問題で、入っているのに回答が誤るならGenerationの問題です。この2段階の測り方はRAG評価とは?検索と生成を分けて測る指標・Ragasでの実装・運用への組み込み【2026年版】で指標まで踏み込んでいます。検索工程そのものの改善手段はリトリーバルとは?RAGの検索工程の仕組みと実装・精度改善の判断基準【2026年版】にまとめました。
Naive・Advanced・Modular RAGの違い|サーベイが示した3分類
この3つの呼び名は、Gao らのサーベイ論文「Retrieval-Augmented Generation for Large Language Models: A Survey」(arXiv:2312.10997、v1が2023年12月18日公開、v5が2024年3月27日更新)が整理したものです。製品カテゴリでもバージョン番号でもなく、研究の発展段階を後から振り返って名付けた分類だという点を押さえておくと、資料を読むときの混乱が減ります。
Naive RAG|検索して渡すだけの最小構成
質問をそのまま検索にかけ、上位の文書をプロンプトに連結して生成するだけの構成です。実装は最も短く、主要フレームワークなら既定設定のまま数十行で組めます。限界も明快で、質問の言い回しが文書の表現と違うと拾えない、複数文書をまたぐ推論ができない、無関係な文書が混じっても除去されない、という3点に集約されます。
Advanced RAG|検索の前後に処理を足す段階
Naive RAGの弱点を、検索の前と後で補う段階です。検索前にはクエリの書き換えや展開、検索後には再ランキングや文脈の圧縮が入ります。細かい粒度のチャンク分割やメタデータを考慮した検索といった索引側の改良も該当します。キーワード検索とベクトル検索を組み合わせる手法もこの層の代表例です。仕組みと実装はハイブリッド検索とは?RAGでBM25とベクトル検索を統合する仕組み・RRF・実装コードをご覧ください。
Modular RAG|工程をモジュールへ分解して組み替える段階
同じ Gao らが2024年7月26日に公開した「Modular RAG: Transforming RAG Systems into LEGO-like Reconfigurable Frameworks」(arXiv:2407.21059)が、この段階を独立して扱っています。検索してから生成するという直線的な流れを前提にせず、独立したモジュールと演算子へ分解し、ルーティング・スケジューリング・融合を組み込む考え方です。同論文は実際のRAG構成に繰り返し現れる型として、直線型(linear)・条件型(conditional)・分岐型(branching)・ループ型(looping)の4パターンを挙げています。条件型は質問の種類で経路を1つ選ぶ形、分岐型は複数経路を走らせて結果を統合する形を指し、名前は似ていますが挙動が違います。
3分類の選び分け|どこで止めるかの判断基準
| 分類 | 主な改良点 | 向く場面 | 主な出典 |
|---|---|---|---|
| Naive RAG | なし(検索して生成) | 実現性の検証 | arXiv:2312.10997 |
| Advanced RAG | 検索前後の処理と索引改良 | 社内文書QAの本番運用 | arXiv:2312.10997 |
| Modular RAG | モジュール分解と再構成 | 複数データ源の使い分け | arXiv:2407.21059 |
3つの呼称はいずれも2023年12月のサーベイが同時に提示したもので、Naive RAGが指す構成そのものは2020年の原論文の延長にあたります。社内文書の質問応答という一般的な用途であれば、Advanced RAGの範囲で十分に実用水準へ届きます。Modular RAGが必要になるのは、構造化データベースと文書検索を質問の種類で切り替えるなど、経路そのものを分岐させたい場合です。構築手順の全体像はRAG構築の手順とは?データ整備から精度向上・本番運用までの進め方にまとめています。
RAG研究の起点と年表|2020年の原論文から2025年まで
RAGという名前が付いたのは2020年です。Lewis らの「Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks」(arXiv:2005.11401)がv1を2020年5月22日に公開し、NeurIPS 2020に採択されました。著者は12名で、当時のFacebook AI Researchを中心にユニヴァーシティ・カレッジ・ロンドンとニューヨーク大学の研究者が加わっています。事前学習済みモデルの内部に閉じた知識ではなく、外部の非パラメトリックな記憶へ微分可能な形でアクセスする、という発想がこの論文の核です。
その後の主要な節目は次のとおりです。日付はいずれもarXivのv1公開日です。
| 公開日 | 論文 | arXiv ID | 位置づけ |
|---|---|---|---|
| 2020-05-22 | RAG for Knowledge-Intensive NLP Tasks | 2005.11401 | RAGの原論文 |
| 2023-12-18 | RAG for LLMs: A Survey | 2312.10997 | 3分類の提示 |
| 2024-04-24 | From Local to Global: A Graph RAG Approach | 2404.16130 | GraphRAG |
| 2024-07-26 | Modular RAG | 2407.21059 | 4パターンの整理 |
| 2024-10-06 | Inference Scaling for Long-Context RAG | 2410.04343 | 推論計算の配分 |
| 2025-01-15 | A Survey on Agentic RAG | 2501.09136 | エージェント統合 |
この並びを見ると、2020年から2023年までは「検索して生成する」枠組みの精緻化が中心で、2024年以降は枠組み自体を分解・再構成する方向へ研究の重心が移っていることが分かります。GraphRAGはその先駆けで、Edge らが2024年4月24日に公開した論文(arXiv:2404.16130、v2は2025年2月19日)は、コーパス全体に対する「主要なテーマは何か」といった大域的な質問に従来のRAGが答えられない点を出発点にしています。
未解決の研究課題|長文脈・反復・マルチホップ
研究側で今も決着していない論点のうち、実装判断に直結するものを3つ挙げます。
1つ目は長文脈モデルとの役割分担です。文脈長が伸びれば検索は不要になるという見方に対し、arXiv:2410.04343 は「知識を有効に使えなければ、文脈を広げるだけでは必ずしも性能が向上するとは限らない」と述べています。同論文は検索文書数と生成ステップ数への計算配分を最適化した場合、標準的なRAGと比べ最大58.9%の改善を報告しており、争点は文脈の長さではなく配分の設計に移っています。
2つ目は反復型の制御です。Agentic RAGのサーベイ(arXiv:2501.09136、v1が2025年1月15日、v4が2026年4月1日更新)は、反省・計画・ツール利用・複数エージェント協調という設計パターンでRAGパイプラインへ自律エージェントを組み込む流れを整理したうえで、評価・協調・メモリ管理・効率・ガバナンスを未解決課題として挙げています。アーキテクチャの具体はAgentic RAGのアーキテクチャと構成要素を詳しく解説で扱っています。
3つ目は複数文書をまたぐ推論です。1回の検索で答えが揃わない質問に対し、検索と推論を交互に回すマルチホップ型の手法が提案されていますが、何回で打ち切るかの基準は用途ごとに決めるしかないのが現状です。打ち切り条件を持たないまま運用に入れると、応答時間とトークン費用の上限が消えます。
研究の分類をそのまま実装に持ち込むと失敗する場面
ここからは、論文の分類を設計図として使ったときに起きる典型的な失敗を挙げます。
最初からModular RAGを設計するのは避けるべきです。 Modular RAGの4パターンのうち条件型・分岐型・ループ型は、どの経路を通ったかで結果が変わります。経路が複数ある状態で精度を測っても、改善がどのモジュールの効果なのかを分離できません。まず直線型で組み、検索と生成を分けて測れる状態を作ってから分岐を足す順序が現実的です。
再ランキングをIndexingの見直しより先に入れるのも順序が逆です。 再ランキングは検索結果の並べ替えであり、検索候補に入らなかったチャンクを呼び戻す機能はありません。正解チャンクが上位50件にすら入っていないなら、原因はチャンクの切り方か埋め込みモデルの側にあります。この場合、再ランキングのモデルを追加しても推論費用が増えるだけで、精度は動きません。
Agentic RAGを一次回答の経路に置くのも慎重に判断すべきです。 反復回数が増えるほど応答時間とトークン消費が積み上がり、社内問い合わせのように件数が多く1件あたりの単価を抑えたい用途とは相性が良くありません。反復型が向くのは、調査レポート作成のように1件あたりの許容時間が長く、回答の網羅性が費用に見合う用途です。
共通しているのは、研究の分類が「新しいほど良い」順序ではないという点です。3分類は達成度の序列ではなく、どの制約を解こうとした段階かを示すラベルです。自分たちが直面している制約が索引の粒度なら、Modular RAGの議論は関係ありません。
よくある質問
RAGのIndexingとRetrievalの違いは何ですか?
Indexingは質問が来る前に実行する準備工程で、文書を読み込み、チャンクに分割し、埋め込みへ変換して索引に登録するまでを担います。Retrievalは質問が来てから実行される検索工程で、登録済みの索引から関連するチャンクを取り出す役割です。責任範囲が違うため、回答精度が出ないときは、まず正解チャンクが索引に存在するかを確認し、次にそれが検索上位に来ているかを見る順序になります。
RAGのインデックスには何が保存されているのですか?
チャンクごとの埋め込みベクトルと、元のテキスト、そしてメタデータの3点が基本です。メタデータには文書名・部署・版番号・有効期限などを持たせ、検索時の絞り込みに使います。ベクトルは近似最近傍探索のためのグラフやクラスタ構造に組み込まれて保存されるため、埋め込みモデルを変更した場合は既存のベクトルが使えず、索引の作り直しが必要になります。
RAGの種類はいくつありますか?
研究文献でよく使われるのは、Naive RAG・Advanced RAG・Modular RAGの3分類です。これはGao らのサーベイ論文(arXiv:2312.10997、2023年12月18日公開)が整理したもので、規格や製品カテゴリではありません。この3つに加えて、グラフ構造を使うGraphRAG(arXiv:2404.16130)、エージェントを組み込むAgentic RAG(arXiv:2501.09136)といった派生が2024年以降に提案されています。
RAGはいつから研究されているのですか?
RAGという名称が付いた原論文は2020年5月22日にarXivへ公開されたLewis らの論文(arXiv:2005.11401)で、NeurIPS 2020に採択されています。それ以前にも検索と生成を組み合わせる研究はありましたが、外部の非パラメトリックな記憶へ微分可能な形でアクセスする汎用の枠組みとして定式化したのがこの論文です。なお、Naive・Advanced・Modularという3分類が現れたのは2023年12月であり、原論文より3年半あとの整理になります。
Naive RAGからAdvanced RAGへ移行する判断基準は何ですか?
質問集に対して正解チャンクが検索上位に入る割合を測り、その値が実用水準に届かない場合が移行の目安です。言い換えの多い質問で取りこぼすならクエリの書き換えを、上位に無関係な文書が混じるなら再ランキングを、というように症状に対応する処理を1つずつ足します。移行の判断を体感ではなく数値で行うために、検索工程と生成工程を分けて測る評価の仕組みを先に用意しておく必要があります。