RAGにおけるチャンキングとは、大規模ドキュメントを検索・取得に適した小さなテキスト断片（チャンク）に分割する処理であり、分割戦略の選択がRAGシステム全体の検索精度と回答品質に直結する。
チャンキング（Chunking）は、RAGパイプラインのIngestion段階における最も重要な前処理ステップの一つである。適切なチャンキングは検索精度を高め、LLMに質の高いコンテキストを提供する。一方、不適切なチャンキングは関連情報の分断や無関係な情報の混入を引き起こし、RAG全体の性能を著しく低下させる。
チャンキングの設計で考慮すべき主要なトレードオフは「チャンクサイズ」である。チャンクが小さすぎると文脈が失われ、大きすぎるとノイズが増加しEmbeddingの精度が低下する。一般的に256〜1024トークンが推奨されるが、ドキュメントの種類やユースケースに応じた最適値の探索が必要である。
RAGで使用されるチャンキング戦略は大きく4つに分類される。
| 戦略 | 概要 | 適用場面 | メリット | デメリット |
|---|---|---|---|---|
| 固定長分割 | 文字数・トークン数で機械的に分割 | 構造が均一なテキスト | 実装が単純、予測可能 | 文脈の途中で分断される |
| セマンティック分割 | 意味的な区切りを検出して分割 | 長文・論文・書籍 | 意味的一貫性が高い | 計算コストが高い |
| 再帰的分割 | 区切り文字の優先順位に従い段階的に分割 | 汎用的な文書 | バランスが良い | パラメータ調整が必要 |
| ドキュメント構造ベース | HTML/Markdown/PDFの構造を活用 | 構造化された文書 | 論理構造を保持 | パーサーの品質に依存 |
固定長チャンキング（Fixed-size Chunking）は、テキストを一定のトークン数または文字数で機械的に分割する最も基本的な手法である。実装が容易で処理速度も速いが、文の途中や段落の途中で分割が発生するリスクがある。
このリスクを緩和するため、オーバーラップ（重複）を設定することが一般的である。例えば、チャンクサイズ512トークン、オーバーラップ50トークンとすると、隣接するチャンク間で50トークンが共有され、分断による文脈損失を軽減できる。オーバーラップが大きすぎるとストレージコストとEmbeddingコストが増加するため、チャンクサイズの10〜20%が目安とされる。
LangChainのCharacterTextSplitterやLlamaIndexのTokenTextSplitterが代表的な実装である。
セマンティックチャンキング（Semantic Chunking）は、テキストの意味的な区切りを自動検出して分割する高度な手法である。Greg Kamradt氏が提唱した手法では、隣接する文の埋め込みベクトル間のコサイン類似度を計算し、類似度が大きく低下する箇所（ブレイクポイント）でチャンクを分割する。
具体的なアルゴリズムは以下の通りである:
この手法のメリットは、意味的に一貫した単位でチャンクが生成されるため、検索時に関連性の高い情報が1つのチャンクに含まれやすい点である。デメリットは、Embeddingの計算コストが文数に比例して増大する点と、チャンクサイズのばらつきが大きくなる点である。
LlamaIndexのSemanticSplitterNodeParserやLangChainのSemanticChunkerが利用可能である。
再帰的チャンキング（Recursive Chunking）は、LangChainのRecursiveCharacterTextSplitterで実装されている手法で、複数の区切り文字を優先順位に従って段階的に適用する。
デフォルトの区切り文字優先順位は ["\n\n", "\n", " ", ""] である。まず段落区切り（\n\n）で分割を試み、結果のチャンクが指定サイズを超える場合は改行（\n）で、さらに超える場合はスペースで分割する。最終手段として文字単位の分割を行う。
この手法は固定長分割とセマンティック分割の中間に位置し、計算コストを抑えつつ文の途中での分断を最小化できるバランスの良さから、実務で最も広く採用されている。
Markdown文書に対しては、見出し（#、##、###）を最優先の区切り文字として追加するMarkdownHeaderTextSplitterが有効である。
HTML、Markdown、PDF、DOCX等の構造化文書では、ドキュメント自体の論理構造（見出し階層、セクション区切り、テーブル、リスト等）を活用してチャンキングを行う手法が効果的である。
PDFの場合、Docling（IBM Research）やUnstructuredを使用すると、テーブル・ヘッダー・フッター・図表キャプション等を構造的に解析し、論理的なセクション単位でチャンクを生成できる。各チャンクにはセクションタイトルやページ番号等のメタデータが自動付与されるため、検索時のフィルタリングや回答時の出典表示に活用できる。
| チャンクサイズ | 特徴 | 推奨場面 |
|---|---|---|
| 128〜256トークン | 精密な検索、ピンポイント回答 | FAQ、定義検索、事実確認 |
| 256〜512トークン | バランス型（最も汎用的） | 一般的なQA、ドキュメント検索 |
| 512〜1024トークン | 広い文脈、複雑な推論 | 論文要約、法律文書分析 |
| 1024トークン以上 | 章単位の理解 | 書籍、レポートの包括的分析 |
最適なチャンクサイズはユースケースに依存するため、RAGASなどの評価フレームワークを用いて複数のサイズで実験し、Faithfulness・Answer Relevancyなどの指標で比較することが推奨される。
2025年以降、LLMを活用した高度なチャンキング手法が登場している:
jina-embeddings-v2-base-enが対応しているQ: チャンクのオーバーラップはどの程度が最適ですか？ A: チャンクサイズの10〜20%が一般的な目安である。512トークンのチャンクなら50〜100トークンのオーバーラップが妥当である。オーバーラップが大きすぎるとストレージとEmbeddingのコストが増加し、検索時に重複するチャンクが多く返されるため逆効果になる。
Q: 多言語ドキュメントのチャンキングで注意すべき点は？ A: 日本語・中国語など単語間にスペースがない言語では、文字数ベースの分割よりもトークンベースの分割が推奨される。また、多言語対応のEmbeddingモデル（BGE-M3、multilingual-e5-large等）を使用し、トークナイザの違いによるチャンクサイズの不均一性に注意する必要がある。
Q: テーブルやコードブロックを含む文書はどうチャンキングしますか？
A: テーブルやコードブロックは途中で分割すると意味が損なわれるため、「不可分要素」として扱い、チャンクサイズの上限を一時的に超過してでも1つのチャンクに収めるべきである。Unstructuredのpartition関数やDoclingはテーブルを構造的に認識して1チャンクとして保持する機能を持つ。