結論
「RAGで検索するための文書の断片」
長い文書を小さく分割したもの。検索精度とLLMの処理効率に直結する。
なぜチャンクが必要？
【問題1】LLMのコンテキスト制限
長い文書をそのまま渡せない → 分割必要
【問題2】検索精度
文書全体だと関係ない部分もヒット → 細かく分けて精度UP
【問題3】埋め込みモデルの制限
Embeddingにもトークン上限あり → 分割必要
チャンキング戦略（MECE）
| 戦略 | 説明 | 向き |
|---|---|---|
| 固定サイズ | 500文字ごとに分割 | シンプル、高速 |
| 再帰的 | 段落→文→文字の順で分割 | 汎用的、推奨 |
| 文ベース | 文単位で分割 | 意味の切れ目を保持 |
| セマンティック | 意味の類似度で分割 | 高精度だがコスト高 |
| 構造ベース | 見出し・段落で分割 | Markdown/HTML向け |
図解
【元の文書】
┌─────────────────────────────────────┐
│ 第1章 RAGとは │
│ RAGは検索拡張生成の略です。 │
│ LLMの回答精度を向上させます。 │
│ │
│ 第2章 実装方法 │
│ まずベクトルDBを用意します... │
└─────────────────────────────────────┘
↓ チャンキング
【チャンク1】 【チャンク2】
┌─────────────┐ ┌─────────────┐
│ 第1章 RAGとは│ │ 第2章 実装方法│
│ RAGは検索...│ │ まずベクトル...│
└─────────────┘ └─────────────┘
重要パラメータ
chunk_size: チャンクの最大サイズ（例: 500トークン）
chunk_overlap: チャンク間の重複（例: 50トークン）
←── chunk_size ──→
チャンク1: [====================]
チャンク2: [====================]
←overlap→
※ overlapで文脈の断絶を防ぐ
サイズの目安
小さいチャンク（100-300トークン）
✓ 検索精度が高い
✗ 文脈が失われやすい
大きいチャンク（500-1000トークン）
✓ 文脈が保持される
✗ ノイズが混入しやすい
推奨: 250-500トークンで開始 → 評価しながら調整
よくある失敗
✗ 表やコードの途中で分割 → 意味が壊れる
✗ overlap=0 で分割 → 文脈が断絶
✗ サイズが大きすぎ → 無関係な情報がヒット
✗ 全文書を同じ戦略で → 文書種別に応じて変えるべき
一言まとめ
チャンク = RAGの「検索単位」
小さすぎると文脈が消え、
大きすぎると精度が落ちる。
→ 「再帰的分割 + 適度なoverlap」から始めよ