株式会社renue
コマースエージェント
コマースエージェントで、この記事のテーマを実務に落とし込めます
renueが社内で運用しているシステムをサービス化したものです。何ができるか、どう動くかをサービスページでご覧ください。
RAGチャンク戦略とは｜検索精度を左右するチャンク設計
RAG(Retrieval-Augmented Generation)の検索結果に影響する要素の一つがチャンク戦略です。Chromaの2024年の実験でも、チャンクの作り方による検索性能の差が測定されています。本記事では、変更の影響を切り分けるため、前段のチャンキングを先に評価・見直す手順を提案します。
本記事では7つの主要チャンキング戦略(Recursive Character/Semantic/Page-level/LLM-based/Size-based/Sentence-based/Late Chunking)の詳細比較、初期設定と比較方法(本記事ではRecursive 400-512 tokensから試し、overlap 0・10・20%を比較)、文書タイプ別の選定マトリクス、そして運用者視点での「チャンク戦略7原則」を解説します。
関連: ハイブリッド検索完全ガイド、Embeddingモデル徹底比較、Reranker完全ガイド、マルチモーダルRAG、GraphRAG、RAG評価。
なぜチャンキングが重要か｜Embedding は「塊単位」でしか理解しない
ベクトル検索は文書を「チャンク」という単位に分割してEmbeddingを計算し、クエリベクトルとの類似度で検索します。このため:
- チャンクが大きすぎる → 1つのベクトルに複数トピックが混在し、類似度が希釈される
- チャンクが小さすぎる → 文脈が切れて意味不明、関連する情報が分断される
- 境界が不自然 → 文の途中で切れてEmbeddingが崩れる
Embeddingモデルを最高級のものに替えても、入力となるチャンクの質が悪ければ検索精度の上限が決まるのです。
7つの主要チャンキング戦略
1. Recursive Character Chunking(再帰的文字分割)｜最初に比較する手法
指定したサイズ上限とオーバーラップに従い、段落・行・空白などの区切り文字を順に試して分割する手法。LangChainのRecursiveCharacterTextSplitterは、標準では文字数で長さを測り、段落区切り・改行・空白・空文字の順に分割します。トークン上限で管理する場合は、from_tiktoken_encoder等で利用モデルに合うトークナイザーを指定します。class/defの区切りはPythonコード向け設定であり、一般文書の既定値ではありません。
- 本記事の試験開始設定: トークン数で制御して400〜512 tokensから試し、overlap 0・10・20%を比較
- Recall: 評価データや検索条件によって大きく変動します
- コスト: 極めて安い(文字列操作のみ)
- 向く: ほぼ全ての汎用文書、コード、Markdown
- 本記事での立ち位置: 比較の基準となる初期実装。公式の既定パラメータとは区別する
2. Semantic Chunking(セマンティック分割)
Embedding 類似度に基づき「意味的な境界」で分割する手法。各文の Embedding を計算し、隣接文との類似度が急落する箇所で分割します。
- Recall: Chromaの2024年実験では、ClusterSemanticChunkerが91.3%、Recursiveが89.5%。いずれも最大400トークン・重複0、上位5チャンクを取得したトークン単位のRecallです。5種類のコーパスとtext-embedding-3-largeを用いた結果で、上記の隣接文の境界検出とは別実装です
- コスト: 高い(すべての文を Embedding する必要あり)
- 向く: トピックが多岐にわたる長文、論文、研究レポート
- トレードオフ: この実験の差は1.8ポイントです。手法全般の改善幅とせず、同じ評価セット・取得件数・指標で、分割用Embeddingの追加費用に見合う改善が得られるか確認します
3. Late Chunking(レイトチャンキング)
文書全体（モデルのコンテキスト長に収まる範囲）をTransformerでトークン単位のベクトルに変換し、チャンク境界ごとにトークン出力をmean-poolする手法。全文双方向 Attention を経た Embedding なので、代名詞解決や前後参照が効いた文脈付きベクトルになります。
- 特に有効な文書: 技術マニュアル、法的契約、研究論文、「それ」「前述の通り」等の代名詞が多い文書
- コスト: コンテキスト長に収まる入力ならTransformerを1回通し、その出力をチャンクごとにプーリングします。上限を超える文書の扱いと実行時間・メモリを測り、他の分割法と比較します
- 提案と実装: Jina AIが2024年に公開。前後参照を含む長文などで、通常の事前分割との違いを検証できる
4. Page-level Chunking(ページ単位)
PDF等のページ区切りをそのままチャンク境界にする手法。シンプルだが、ページ跨ぎの情報は失われがち。
- 向く: プレゼンスライド、スキャンPDF、論文のページ構造が意味を持つ場合
- 組み合わせ推奨: マルチモーダルRAG(ColPali/ColQwen)との併用で強力
5. LLM-based Chunking(LLM生成チャンク)
LLM に「この文書を意味単位で分割せよ」と指示して分割させる手法。最も柔軟だがコストとレイテンシが重い。
- 向く: 小規模だが構造複雑な文書、少量文書の高精度インデックス
- コスト: 文書量に比例して高騰、大量文書には不向き
6. Size-based / Fixed-size Chunking(固定サイズ)
単純に N トークン毎に切る原始的手法。境界を考慮しないため品質は低い。
- 向く: 実装の最初の1日、素早く動かすテスト用
- 本番では推奨されない: Recursive Character が同じコストで上位互換
7. Sentence-based Chunking(文単位)
句点・改行などで分割する方法と、GiNZA/spaCy等で文境界を判定する方法があります。LangChainの日本語向け例も句読点を区切りに追加しており、専用ライブラリは必須ではありません。
- 向く: FAQ、Q&A ペア、短文が多いデータセット
- 日本語の注意点: 英語の nltk.sent_tokenize は日本語に使えない
用途に応じて比較する分割方法
| 選択 | 推奨 |
|---|---|
| 本記事の初期試験 | Recursive Character 400-512 tokens、overlap 0・10・20%を比較 |
| 長文narrative(論文/契約/マニュアル) | Late Chunking |
| トピック多岐の長文 | Semantic Chunking (コスト許容時) |
| PDF主体・図表あり | Page-level + マルチモーダルRAG |
| FAQ/Q&A | Sentence/Pair-based |
| プロダクションで最高精度 | Recursive + Semantic + Late のハイブリッド |
一般的な指針としては「複数手法の組み合わせが有効な場合がある」です。まずRecursive Character を堅実に動かし、評価で頭打ちになったら Semantic/Late を加えるのが王道です。
チャンクサイズとオーバーラップの調整軸
- 小さいチャンク(100-300 tokens): 精密な検索、FAQ、短い事実、Recall 重視
- 中サイズ(400-600 tokens): 本記事で初期比較する範囲。検索で必要な情報量と余分な情報の混入を確認
- 大サイズ(800-1500 tokens): 文脈保持、narrative 文書、複雑な推論タスク
オーバーラップ(隣接チャンク間の重複部分)は、本記事では0%と10〜20%を比較します。重複を設ける効果は境界の位置や検索対象で変わるため、必要な情報の回収率と重複トークン数・保存量を一緒に測定します。
評価すべき3指標
- Recall@K: 質問ごとの正解チャンク総数のうち、上位K件で回収できた割合。本記事では質問間の平均で評価します。1件以上の正解が得られた質問の比率であるHit Rate@Kとは区別します（LlamaIndexの実装）
- Precision@K: 上位K件のうち実際に有用なチャンクの率
- MRR(Mean Reciprocal Rank) / NDCG: 正解の順位品質
これらをRAG評価で継続計測し、チャンク戦略を変えたときの前後比較をします。
日本語特有の注意点
- トークナイザーの問題: tiktokenのトークン化は同じ入力・エンコーディング・設定なら同じ結果になります。文字数とトークン数の比は語やエンコーディングで変わるため、文字数から固定比率で換算せず、利用するEmbeddingモデルのトークナイザーで長さを数えます
- 句読点認識: 英語の nltk.sent_tokenize は使えない。GiNZA / spaCy-ja 等の日本語NLPライブラリ推奨
- 漢字とかなの混在: Embeddingモデルの選定が特に重要(ruri-v3 等の日本語特化モデルと相性確認)
- 縦書き・表・図注: 多くのPDF抽出ツールが日本語縦書きを壊す。マルチモーダルRAG(ColQwen)で画像ベース処理の方が有利な場合あり
RAG運用者視点のチャンク戦略7原則
文書特性の異なる複数のRAGを運用してきた経験から、チャンク戦略の7つの原則を整理します。
(1) Recursive Character 400-512 tokensを起点に重複量を比較する: 本記事の試験開始設定として、重複0・10・20%を同じ条件で比較します。自社評価セットで測ったRecall@Kが業務上の目標に届くか確認し、未達の質問の原因から次の手法を選びます。文字列処理で分割できるため、分割専用のEmbedding呼び出しは不要です。複雑な戦略から始めると「動く前に止まる」罠に陥ります。
(2) 評価セットを先に作ってから戦略を変える: Golden Set + Recall@K の計測がないまま Semantic/Late に切り替えても効果は見えません。20〜100件の代表クエリ+期待チャンクの対応表を先に作ります。
(3) Late Chunking は長文narrative(論文/契約/マニュアル)でのみ試す: 向かない文書タイプに適用しても計算コストだけ増えて恩恵が薄いです。代名詞・前後参照が多い文書でこそ真価を発揮します。
(4) ハイブリッドは評価後に追加する: 最初から「Recursive + Semantic + Late」の三段階を組んでも、どれが効いているか分かりません。Recursive → 評価 → Semantic 追加 → 評価 → Late 追加 → 評価、の順で段階的に組み立てます。
(5) 日本語の区切り・長さ・検索性能を確認する: 利用するモデルのトークナイザーで長さを数え、句点・改行などの日本語の境界を確認します。句読点を区切りに追加する方法から試し、必要に応じてruri-v3等の日本語特化モデルやGiNZA/spaCy-jaを比較します。これらの特定の組み合わせを必須とはしません。
(6) PDF・図表が中心の文書はマルチモーダルRAGも検討: テキスト抽出→チャンク の古典フローで苦戦するなら、ColPali/ColQwen 系の「画像のままベクトル化」方式を並行検討します。チャンク戦略の土俵を変える選択肢です。
(7) チャンク戦略もコスト SLO に組み込む: Semantic/Late chunking は文書数に応じて Embedding 計算コストが線形〜二次で増えます。FinOps for AIのコスト上限を意識しないと、本番投入後に請求書ショックが発生します。
よくある失敗パターン
- いきなり Semantic Chunking:Recursive で足りるかを試さず高コスト戦略から始める
- オーバーラップを評価せず決定:境界付近の情報の回収率と重複による保存量・処理量を比較していない
- 日本語の分割設定を未確認:英語用の文分割設定をそのまま使う、文字数とモデルのトークン数を混同して上限を決める
- 評価セットなしで戦略変更:どれが効いているか不明
- 単一戦略に固執:文書タイプが混在しているのに同じ戦略を適用
- PDF の図表無視:テキスト抽出段階で情報が失われている
- チャンクサイズを固定で決める:文書ごとに最適サイズは違う、実験で見つける
よくある質問（FAQ）
Q1. 最初に選ぶべき戦略は何ですか？
本記事ではRecursive Character Chunkingをトークン数で制御し、400-512 tokens、overlap 0・10・20%を初期比較する手順を提案します。同じ質問と正解定義でRecall@K等を測定し、目標に届かない場合に次の戦略を検討します。
Q2. チャンクサイズは大きい方が良いですか？
いいえ、トレードオフです。大きいと文脈保持に有利ですが、複数トピック混在で類似度が希釈されます。本記事では400-600 tokensを比較範囲の一つにし、より小さい・大きい設定との検索結果と取得トークン数の差を測ります。
Q3. 日本語と英語で戦略を変えるべきですか？
手法を一律に変える必要はありません。利用モデルのトークナイザーで長さを数え、句読点・改行などの日本語の境界とEmbeddingモデルの日本語での検索性能を確認します。専用の形態素解析や文分割ライブラリは、単純な区切り設定では要件を満たせない場合に比較します。
Q4. 精度の頭打ちを突破するには？
Recursiveで頭打ちしたら順に: (1)ハイブリッド検索(BM25+ベクトル)、(2)Reranker追加、(3)Semantic/Late Chunking、(4)マルチモーダルRAG、(5)GraphRAGを段階評価します。
Q5. renue はチャンク戦略の設計を支援していますか？
はい。文書特性分析・戦略選定・評価セット設計・段階評価・本番運用までワンストップで支援しています。特に日本語の長文narrative/PDF/図表混在文書での実績があります。
関連記事
- ハイブリッド検索完全ガイド2026
- Embeddingモデル徹底比較2026
- Reranker完全ガイド2026
- RAG評価完全ガイド2026
- マルチモーダルRAG完全ガイド2026
- GraphRAG完全ガイド2026
- プロンプト vs RAG vs ファインチューニング
- FinOps for AI完全ガイド2026
RAGチャンク戦略の設計相談はrenueへ
renueは複数のAIエージェント事業を自社運用するAIエージェント開発企業として、文書特性に応じたチャンク戦略選定・評価セット設計・段階評価・日本語特化対応まで一貫して支援しています。「Recursiveで頭打ち」「日本語PDFで精度が出ない」等でお困りの方はお気軽にご相談ください。
本記事の参考情報
- Firecrawl: Best Chunking Strategies for RAG (and LLMs) in 2026
- Weaviate: Chunking Strategies to Improve LLM RAG Pipeline Performance
- Databricks: The Ultimate Guide to Chunking Strategies for RAG Applications
- IBM: Chunking strategies for RAG tutorial using Granite
- DataCamp: Chunking Strategies for AI and RAG Applications
- F22 Labs: 7 Chunking Strategies for RAG Systems
- Stack Overflow Blog: Breaking Up is Hard to Do — Chunking in RAG Applications
- Atlassc: Text Chunking Strategies for RAG Comprehensive Guide (2026年3月)
- Cohere Docs: Effective Chunking Strategies for RAG
- Agenta: The Ultimate Guide to RAG Chunking Strategies
