RAGの精度はChunking前に決まる：生ドキュメントを検索可能な単位に変える

1. 生のドキュメントから検索可能な単位へ

RAG のこの層では、生のドキュメントを 検索可能な単位 に変換していきます。

生のドキュメント → 検索可能な単位

RAG システムは、通常、PDF やマニュアル全体をそのまま検索するわけではありません。あらかじめ準備された単位を検索します。

検索可能な単位 = テキスト + 構造 + メタデータ

たとえば、社員ハンドブックの中に、次の質問への答えが含まれているとします。

新入社員は何日間の有給休暇を取れるのか？

しかし、処理が不適切だと、根拠となる部分が壊れた形になることがあります。

新入社員は最大

15ページ

10日間の有給休暇を...

答え自体は存在しています。しかし、取得された単位が壊れた形になっています。よりよく準備された単位では、本文と出典・位置情報を一緒に保持します。

text = 新入社員は最大10日間の有給休暇を取ることができる。
source = employee_handbook_2026.pdf
section = Paid Leave > New Employees
date = 2026-04-01
permission = employees_only

つまり、チャンク化は単にテキストを切る作業ではありません。後続の RAG ステップで検索できるように、クリーンで追跡可能な単位を準備する作業です。

2. ドキュメント処理の流れ

ドキュメント処理の層は、次の要素で構成されます。

要素	役割
Loading / parsing	ソースドキュメントからテキストと利用可能な構造を取り出す
Cleaning / normalization	意味のある構造を残しながらノイズを取り除き、表記を一貫させる
Chunking	検索可能な単位の境界を決める
Metadata attachment	source、section、date、language、permission などを付与する
Failure modes	準備の弱さが後続の RAG の品質をどう壊すかを診断する

ソースは最初、未整理な状態にあります。そこから段階的に利用可能な形へ整えていきます。

ソースは未整理な状態
  ↓
テキストと構造を取り出す
  ↓
意味を保ちながらノイズを取り除く
  ↓
検索可能な単位の境界を決める
  ↓
メタデータを付与する
  ↓
RAG パイプラインの後続ステップが使える単位を作る

3. チャンク化の前に：読み込み、解析、クリーニング、正規化

チャンク化は、生のソースが クリーンで、正規化され、構造を持つテキスト になってから初めてうまく機能します。

生のソース → 利用可能なテキスト + 有用な構造 → クリーンで正規化された構造付きテキスト

3.1 読み込み / 解析（Loading / Parsing）

Loading は、ソースをパイプラインに取り込むことです。Parsing は、そのソースからテキストと構造を復元することです。

Markdown や HTML では、見出しやリストが構造として明示されていることが多いです。一方、PDF、Excel、Word、Wiki ページ、データベースレコードでは、意味がレイアウト、表、ページ、シート、階層に依存することがあるため、より丁寧な解析が必要になります。

良い loading / parsing とは、次の状態を作ることです。

利用可能なテキスト + 有用な構造

たとえば、parsing が不十分だと、社員ハンドブックが次のように平坦化されることがあります。

新入社員ポリシー 有給休暇 社員は10日間取得できる...

より良い parsing では、構造を保ちます。

Document: Employee Handbook
Section: Paid Leave Policy
Text: 新入社員は10日間の有給休暇を取ることができる...

実装の詳細はソースの種類によって変わります。LlamaIndex Loading Documents は loading の全体像を見るのに役立ち、LangChain Document Loaders は loader の例を確認するのに使えます。Docling は、PDF 解析のように複雑な parsing が主な問題になる場合に有用です。

3.2 クリーニング / 正規化（Cleaning / Normalization）

Cleaning は検索ノイズを取り除く処理です。Normalization は、抽出されたテキストを一貫した形に整える処理です。たとえば、壊れた改行を直す、空白を統一する、全角 / 半角などの文字表記を揃える、見出しやリスト記号の表記を揃える、といった処理が含まれます。

社員ハンドブックでは、繰り返し出てくるヘッダー、フッター、ページ番号、定型文、壊れた改行、繰り返しの注意書きなどはノイズになりえます。一方で、セクションタイトル、階層、箇条書き、表、バージョン番号、更新日は構造になりえます。

この違いは重要です。

新入社員は最大10日間の有給休暇を取ることができる。

これは、次の形よりも利用しにくいです。

Document: Employee Handbook
Section: Paid Leave > New Employees
Text: 新入社員は最大10日間の有給休暇を取ることができる。

文そのものは似ていますが、後者のほうが検索、追跡、フィルタリング、デバッグをしやすくなります。

4. 検索単位の設計としてのチャンク化

チャンク化は、検索対象にする知識の単位を決める処理です。

多くの基本的な RAG システムでは、この単位が チャンク です。チャンクとは、後続のステップで検索可能な形に変換できるよう準備されたドキュメントテキストの一部です。

社員ハンドブックの場合、単位の候補には次のようなものがあります。

単位の候補	問題
ハンドブック全体	大きすぎて焦点がぼやける
章全体	関係の薄い複数のポリシーを含むことがある
1つのセクション	ポリシードキュメントでは有用なことが多い
1つの段落	精密だが、周辺文脈を失うことがある
1文	非常に精密だが、細かく分断されすぎることが多い

チャンク化は単なる「テキストの切り分け」ではありません。システムが検索できる知識の単位を定義する処理です。

4.1 サイズとオーバーラップ

すべてのチャンク化手法は、チャンクサイズ と チャンクオーバーラップ の影響を受けます。

チャンクサイズ	利点	リスク
大きいチャンク	文脈を多く含められる	検索結果がぼやけやすい
小さいチャンク	焦点の合った検索結果を得やすい	必要な文脈を失いやすい

オーバーラップは、境界部分の情報落ちを減らします。

Chunk 1: A B C D
Chunk 2: C D E F
Chunk 3: E F G H

ただし、オーバーラップが多すぎると重複が増えます。重複したチャンクは検索結果にノイズを増やし、LLM に渡せるコンテキスト枠を無駄に消費する可能性があります。

「最適なチャンクサイズは何か？」よりも、次の問いのほうが実用的です。

このドキュメントの種類とクエリの種類には、どのチャンク設計が合うか？

たとえば、FAQ では 1つの Q&A ペアを 1チャンクにすると機能しやすい場合があります。ポリシードキュメントでは、セクション単位や条項単位のほうが合うことがあります。API ドキュメントでは、見出し、パラメータ、例を一緒に保つ必要があることが多いです。コードドキュメントでは、説明とコードブロックを一緒に保つほうがよい場合が多いです。

社員ハンドブックでは、任意の文字数で切るよりも、ポリシーのセクションやサブセクションを出発点にするほうが適していることが多いです。

4.2 チャンク化のアプローチ

チャンク化手法の違いは、1つのチャンクがどこで終わり、次のチャンクがどこから始まるかを何で決めるかにあります。

実際には、複数の手がかりを組み合わせることがあります。まずドキュメント構造を使い、次に段落境界を使い、その上でトークン数の上限を適用し、必要に応じてオーバーラップを入れる、という形です。

アプローチ	境界を何で決めるか	主なリスク	リファレンス
Size-based splitting	トークン数または文字数	意味の途中で切れてしまうことがある	LangChain: Splitting by token
Boundary-based splitting	文、段落、再帰的な区切り文字	ドキュメント構造を無視してしまうことがある	LangChain: Recursive Text Splitter
Structure-aware splitting	見出し、表、コードブロック、ドキュメントセクション	parsing の段階でそれらの構造が保持されている必要がある	LangChain: Split HTML
Meaning-aware splitting	トピックや意味の変化	デバッグが難しく、モデル依存になりやすい	LlamaIndex: Semantic Splitter

Structure-aware splitting は、適切な parsing に依存します。構造の復元が難しい場合は、上の loading / parsing のリソースを参照するとよいです。

Meaning-aware splitting は、実装リソースでは semantic chunking と呼ばれることが多いです。

4.3 親子構造を持つ単位設計

ドキュメントによっては、小さな検索単位と、大きな文脈単位の両方が必要になります。

たとえば、システムは次のような小さな単位を準備することがあります。

Section: Paid Leave -> New Employees
Text: 新入社員は最大10日間の有給休暇を取ることができる。

そして、それが属する大きな親セクションとの関係も保持します。

Parent section: Paid Leave
Subsections:
- New Employees
- Application Procedure
- Unused Leave

これにより、小さな単位の利点を保ちながら、周辺文脈を完全に失うことを避けられます。

小さな単位	大きな親単位（parent unit）
焦点の合った検索に向いている	周辺文脈を保ちやすい
具体的な質問に対応しやすい	関連する説明を失いにくい
文脈が不足することがある	無関係なテキストを含むことがある

Parent-child unit design は、fixed-size splitting とは異なります。Fixed-size splitting は長さによってチャンク境界を決めます。Parent-child unit design は、小さなドキュメント単位と大きなドキュメント単位の関係を保持します。

その関係をどう使うかは、後続の検索ステップ（retrieval）で決まります。

LlamaIndex Recursive Retriever は、node を使って、文書単位どうしの関係を扱う例として参考になります。ここでいう node は、フレームワーク上で扱われる文書単位です。

4.4 通常のチャンク化で文脈が失われる場合

通常のチャンク化では、チャンクが周囲のテキストに強く依存している場合、文脈が失われることがあります。

たとえば、段落の中に「このルール」「上記の場合」「次の例外」のような表現がある場合、周囲のテキストが欠けると、そのチャンクは理解しにくくなります。

一部の高度な手法では、チャンクにより多くの周辺文脈を与えたり、チャンク表現を作るタイミングを変えたりすることで、この問題を減らそうとします。

より技術的な詳細については、Late Chunking が、chunking と representation のタイミングの関係を変える方法の一例を説明しています。Reconstructing Context は、文脈を保つチャンク化戦略をより広く比較した研究です。

5. メタデータ

検索可能な単位は、テキストだけではありません。テキストにメタデータを加えたものです。

検索可能な単位 = テキスト + source / section / time / language / permission などのメタデータ

社員ハンドブックの場合、有用なメタデータは次のようになります。

{
  "source": "employee_handbook_2026.pdf",
  "title": "Employee Handbook",
  "section": "Paid Leave > New Employees",
  "timestamp": "2026-04-01",
  "document_type": "internal_policy",
  "language": "en",
  "permission": "employees_only"
}

よく使われるメタデータ項目には、次のようなものがあります。

メタデータ	なぜ重要か
source	チャンクの出典
title	ドキュメントタイトル
section	見出しパスまたはセクション名
timestamp	公開日時または更新日時
document type	manual、FAQ、policy、ticket、article など
language	Japanese、English、Chinese など
permission	誰がこのチャンクにアクセスできるか

メタデータは、チャンクを作る時点で作成しておくべきです。RAG パイプラインの後続部分では、このメタデータを保存、フィルタリング、引用、デバッグ、評価、アクセス権限の制御に使うことがあります。

ただし、メタデータそのものがアクセス制御を行うわけではありません。たとえば "permission": "employees_only" を追加しても、それはチャンクにラベルを付けるだけです。実際にアクセスを制御するには、システムの別の部分がそのラベルを使う必要があります。

6. 失敗パターン

失敗パターンは、同じ処理フローに対応づけて整理できます。

失敗箇所	例	結果
Loading / parsing の失敗	抽出漏れ、ページ順の誤り、表の平坦化、見出しの欠落、レイアウト情報の欠落	システムが壊れたソーステキストから始まる
Cleaning / normalization の失敗	繰り返しヘッダーが残る、有用な構造が消える、更新日が消える、階層が平坦化される	準備済みテキストがノイズを含む、または構造的に弱くなる
Chunking の失敗	チャンクが大きすぎる / 小さすぎる、ルールと例外が分離される、表と説明が分離される、無関係なトピックが1つのチャンクに入る	不完全または広すぎる根拠が検索される可能性がある
Metadata の失敗	source、section、timestamp、language、permission、document type が欠ける	単位を追跡、フィルタリング、アクセス権限の確認ができなくなる

ハンドブックの例では、こうした失敗により、システムが「10日間」という情報を見つけても、それが有給休暇の話なのか、どのセクションから来たのか、例外が適用されるのかを判断できなくなる可能性があります。

デバッグ時には、次の2つの問いが役立ちます。

1. この単位だけが取得されたとして、
   実際のユーザー質問に答える助けになるか？

2. この単位を根拠として使う場合、
   元のソースまで追跡できるか？

答えが「いいえ」なら、ドキュメント処理の層が弱い可能性があります。

7. まとめと境界

ドキュメント処理の層は、生のドキュメントを検索可能な単位に変換します。

RAG は生のドキュメントを検索するのではない。
RAG は準備された単位を検索する。

良い検索可能な単位は、検索しやすく、理解しやすく、追跡可能で、ノイズが多すぎず、細かく分断されすぎず、有用なメタデータと結びついている 必要があります。

要するに、次の形です。

準備された単位 = テキスト + 構造 + メタデータ

この層の出力は、準備された単位です。

準備された単位ができたら、次の問題は、それらをどのように表現し、保存し、検索し、選択し、利用するかです。

References

1. LlamaIndex. “Loading Documents”. LlamaIndex Documentation.
2. LangChain. “Document Loaders”. LangChain Documentation.
3. Docling Project. “Docling Documentation”. Docling.
4. LangChain. “Splitting by Token”. LangChain Documentation.
5. LangChain. “Recursive Text Splitter”. LangChain Documentation.
6. LangChain. “Split HTML”. LangChain Documentation.
7. LlamaIndex. “Semantic Chunker”. LlamaIndex Documentation.
8. LlamaIndex. “Recursive Retriever + Node References”. LlamaIndex Documentation.
9. Günther, M., et al. “Late Chunking: Contextual Chunk Embeddings Using Long-Context Embedding Models”. arXiv, 2024.
10. “Reconstructing Context: Evaluating Advanced Chunking Strategies for Retrieval-Augmented Generation”. arXiv, 2025.