RAGチャンキング戦略：検索データで比較した7つの手法（2026）

RAGチャンキング戦略：検索データで比較した7つの手法（2026）

RAGチャンキング戦略は、最初のクエリが実行されるより前に、リトリーバーが何を見つけられるかを決めます。Chromaが2024年7月に公開した調査では、text-embedding-3-largeを使い、5つのコーパスに対して472件のクエリを実行しました。選んだスプリッターによってリコールは約5ポイント動きます。素のトークンスプリッターで86.7%、GPT-4oを使ったもので91.7%、いずれもクエリあたり5チャンク取得した条件です。プレシジョンの振れ幅はもっと大きい。レポート全体では1.5%から8.0%まで広がっており、チャンクサイズの選択は品質の仮面をかぶったコスト判断になります。それなのに、検索1ページ目のガイドはどれも同じ7つの手法を並べるだけで、どれがより良く検索するかを示していません。

主要ポイント

• チャンキングは埋め込みの前にドキュメントを分割する工程です。分割点が、リトリーバーが何を見つけられ、何を見つけられないかを決めます。
• Chromaの2024年7月の472クエリ調査では、測定されたスプリッター間でリコールが86.7%から91.7%まで動きました。
• プレシジョンはリコールより数倍大きく変動するため、チャンクサイズはほぼトークンコストの判断です。
• まず512トークン、オーバーラップ10%から始め、その後は自分の評価セットで調整してください。

どのRAGチャンキング戦略を使うべきか？（順位付き）

平坦な文章を扱うほとんどのチームにとって、再帰的文字チャンキングを512トークン、オーバーラップ10%で使うのが正しい既定値です。段落と文の境界を尊重し、追加コストはゼロで、Chromaの472クエリベンチマークではLLMベースのスプリッターにリコールで3.2ポイント及ばないだけでした。ドキュメントに強い構造がある場合や、評価セットが別の結果を示した場合だけ、この既定から離れてください。

私たちの読み：再帰的文字から始めてください。ChromaのデータではクラスタとLLMスプリッターに次ぐリコールで、LLMスプリッターのプレシジョン3.9%は、関連トークン1件あたり約2倍のノイズを生成器に渡すことを意味します。ほとんどのチームはチャンキングの問題を抱えていません。一度も測定したことがないチャンクサイズの問題を抱えているだけです。

データはチャンクサイズについて実際何を語っているか？

RAGチャンキング戦略を直接比較した唯一の公開調査は、Chromaの技術レポート「Evaluating Chunking Strategies for Retrieval」（Brandon SmithとAnton Troynikov、2024年7月3日公開）です。彼らは5つのコーパス（328,208トークン）に対して472件のクエリを実行し、すべてをOpenAIのtext-embedding-3-largeで埋め込み、クエリごとに5チャンクを取得しました。以下の行は、同レポートの付録テーブルから、text-embedding-3-large・取得チャンク5の全コーパス数値を引いたもので、互いに直接比較できます。

Chromaの主結果テーブルは別の検索設定を報告しており、クラスタチャンカーの最高プレシジョンを8.0%（リコール87.3%）とし、全スプリッターのプレシジョン範囲を1.5%（KamradtSemanticChunker）から8.0%まで広げています。出典：Chroma Research, Evaluating Chunking Strategies

Anthropicの「Introducing Contextual Retrieval」（2024年9月19日公開）は、別の角度からこの問題に挑みます。彼らのベースラインのtop-20検索失敗率は5.7%でした。文脈埋め込みだけで3.7%（35%削減）に下がり、その上に文脈BM25を足して2.9%（49%）、リランキングで1.9%（67%）まで押し下げました。Anthropicは使った正確なチャンクサイズやオーバーラップを公開していないため、これらは手法レベルの根拠として扱い、サイズレベルの根拠としては扱わないでください。出典：Anthropic, Contextual Retrieval

私たちの読み：計算から3つの結論が出ます。第一に、スプリッターの選択は実際のリコールに見合う価値があり、Chromaも明言しています。ある戦略は他の戦略よりリコールで最大9%上回ります。主結果テーブル全体ではリコールが83.6%（KamradtSemanticChunker）から91.9%（LLMSemanticChunker）まで走り、上の取得5チャンクの行の中でも86.7%から91.7%まで開きます。同じデータでプレシジョンは数倍大きく動き、1.5%から8.0%、リコールの1.1倍に対して5.3倍の開きです。つまりリコールは数ポイントを拾う場所で、プレシジョンとトークンコストこそが選択が実際に効いてくる場所です。第二に、LLMベースのスプリッターは最高のリコールを最悪のプレシジョンで買います。ドキュメントごとにLLM呼び出しを払い、生成器により多くのノイズを渡します。第三に、Anthropicの数値は、チャンクを文脈で豊かにすること（5.7%から3.7%）が、Chromaのテーブルのどのスプリッター選択よりも失敗率を大きく動かしたことを示します。スプリッターを再調整する前に、チャンクを豊かにしてください。リランキングはスプリッターが壊したチャンクを回復させ、ハイブリッド検索はBM25とベクトル検索を組み合わせます。同じ理由からです。

正直な限界：両方の調査とも単一の埋め込みモデルを使い、英語のみのコーパスで、あなたのコーパスを対象にした対照試験ではありません。472クエリ全体で、最良と最悪のスプリッターの差は取得5チャンクでリコール約5ポイント、プレシジョンでは比例的にずっと大きな差でした。

なぜチャンクサイズが検索品質を決めるのか？

チャンクサイズは検索キーの粒度を決めます。400トークンのチャンクは特定のクエリに一致する焦点の絞れた埋め込みを生みます。4,000トークンのチャンクは多くのトピックを平均化し、何にも正確に一致しません。小さいチャンクは正確な一節を取得しますが、回答を複数結果に断片化するかもしれません。大きいチャンクは文脈をまとめますが、埋め込みのシグナルを弱めます。

埋め込みモデルのコンテキスト上限も重要です。モデルの入力上限が512トークンで、800トークンを渡した場合、末尾は黙って切り捨てられます。埋め込みはチャンクの3分の2しか表現しません。エラーは記録されません。

次は生成器側です。Liuらは"Lost in the Middle"（arXiv 2307.03172、2023年）で、関連ドキュメントが長い文脈の真ん中にあるとき、LLMの精度が20%以上落ちることを示しました。1,000トークンのチャンクを5つ取得すると、プロンプトに5,000トークンを放り込むことになります。必要な回答は、モデルが最も読みにくい位置に着地するかもしれません。小さいチャンクは、関連する一節をモデルがうまく扱える位置に近づけます。

図書館の索引カードのように考えてください。「4.2節、3段落目：返金ポリシー」と書かれたカードは、あなたをそのページへ導きます。「20世紀の商取引に関するすべて」と書かれたカードは、建物へ導くだけです。あなたの埋め込みがそのカードです。RAGアプリケーションをエンドツーエンドで構築して、チャンキングがパイプラインのどこに位置するかを確認し、コンテキストエンジニアリングガイドで、取得したチャンクがどうプロンプトトークンになるかを読んでください。Pineconeのチャンキングガイドは、同じトレードオフをベクトルデータベース側から説明しています。

固定サイズと再帰的チャンキング（ここから始める）

固定サイズはすべてを測定するための基準です。再帰的は、実際に本番へ出すものです。

固定サイズトークンチャンキング

内容に関係なく、Nトークンごとに分割します。

def fixed_size_chunks(text: str, size: int = 512, overlap: int = 50) -> list[str]:
    tokens = text.split()  # whitespace proxy; use tiktoken for real token counts
    chunks = []
    step = size - overlap
    for i in range(0, len(tokens), step):
        chunk = " ".join(tokens[i : i + size])
        chunks.append(chunk)
        if i + size >= len(tokens):
            break
    return chunks

正しい場面：見出し構造のない平坦な文章、素早いプロトタイプ、あらゆる基準比較。愚かな方法ではありません。対照群です。

再帰的文字チャンキング

LangChainのRecursiveCharacterTextSplitterは区切り文字の階層で分割します。まず\n\n（段落）、次に\n（行）、次に. （文）、そして （単語）です。各チャンクは、収まる最大の自然な境界を尊重しながらchunk_size未満に保たれます。

from langchain_text_splitters import RecursiveCharacterTextSplitter

splitter = RecursiveCharacterTextSplitter(
    chunk_size=512,
    chunk_overlap=50,
    separators=["\n\n", "\n", ". ", " ", ""],
    length_function=len,  # swap for tiktoken len for true token counts
)
chunks = splitter.split_text(document)

この区切り文字リストこそ、競合が省略する部分です。スプリッターはまず\n\nを試み、段落がchunk_sizeを超えるときだけ. へ降りていきます。Markdownに見出しがあるなら、"\n\n"の前に"## "を追加して、セクションをそのまま保ってください。

チャンクオーバーラップの計算： 512トークン、オーバーラップ50トークンなら、ステップは462です。10,000トークンのドキュメントはceil(10000 / 462) = 22チャンクを生みます。埋め込みトークン総数：22 x 512 = 11,264。つまりコーパスの約12.6%をオーバーラップとして再埋め込みします。これが、境界の文を孤立させないためのストレージとAPIのコストです。

セマンティックチャンキングはどう動き、コストに見合うのか？

セマンティックチャンキングはすべての文を埋め込み、隣接する文埋め込み間のコサイン距離を測り、その距離がパーセンタイル閾値（一般的に95パーセンタイル）を超えたところで分割します。チャンクは任意のトークン数ではなく、トピックの転換点で切れます。Greg Kamradtの"5 Levels of Text Splitting"ノートブックがこのパーセンタイルブレークポイント手法を生み出し、Chromaの調査は彼の名前付きチャンカーをベンチマークしています。

from langchain_experimental.text_splitter import SemanticChunker
from langchain_openai import OpenAIEmbeddings

embeddings = OpenAIEmbeddings(model="text-embedding-3-large")
splitter = SemanticChunker(
    embeddings,
    breakpoint_threshold_type="percentile",
    breakpoint_threshold_amount=95,
)
chunks = splitter.split_text(document)

コスト計算は、誰も最初に示さない部分です。セマンティックチャンキングはコーパスを2回埋め込みます。1回は文の距離を計算してブレークポイントを見つけるため、もう1回は結果のチャンクをインデックス用に埋め込むためです。OpenAIのtext-embedding-3-largeの価格、1Mトークンあたり0.13ドルでは、1,000万トークンのコーパスは通常1.30ドル、セマンティックチャンキングでは2.60ドルかかります。最初のクエリが走る前に、2倍を払うことになります。

それで何が買えるのか？Chromaの取得5チャンクの行では、クラスタベースのセマンティックチャンカーがリコール89.0%・プレシジョン6.7%で、同じ200トークンサイズの再帰的88.5%・7.0%に対して並びます。主結果テーブルでは、同じチャンカーが調査最高のプレシジョン8.0%をリコール87.3%で記録します。どちらに転んでもリコールは0.5ポイント差で、プレシジョンはどの検索設定を読むかで符号が反転する結果を、2倍の埋め込み請求書で買うことになります。私たちの結論：セマンティックチャンキングは、固定境界が日常的にトピックの途中を切る、トピック多様なコーパス（ニュースアーカイブ、論文コレクション）で報われます。均質なコーパス（製品ドキュメント、単一のナレッジベース）では、再帰的が半額のコストで品質の95%を届けます。Ollamaで埋め込みモデルをローカル実行しているなら、2倍埋め込みのコストは計算時間に下がります。

ドキュメント認識チャンキング：Markdown、HTML、コード

構造認識の分割は、文字数ではなくドキュメント自身の境界（見出し、リスト項目、関数定義）を使います。MarkdownのH2は人間が意図的に置いた意味的な境界です。文字スプリッターはそれをずたずたにします。

from langchain_text_splitters import MarkdownHeaderTextSplitter

headers = [("#", "h1"), ("##", "h2"), ("###", "h3")]
splitter = MarkdownHeaderTextSplitter(headers_to_split_on=headers)
splits = splitter.split_text(markdown_doc)
# Each split carries metadata: {"h1": "...", "h2": "...", "h3": "..."}

コードの場合、境界はASTノードです。LlamaIndexのNodeParsersは、関数定義とクラス定義で切る言語認識スプリッターを提供します。重要な詳細：インポートブロックと外側のクラスシグネチャを、各関数チャンクにくっつけたままにしてください。インポートのない関数本体は埋め込み不能なノイズです。両方をすべてのチャンクの先頭に付ければ、埋め込みはその関数が何をするかと、何に依存するかを捉えます。

コードRAGに限定した話：AST境界分割、インポートを先頭に、関数ごとに256-512トークン、オーバーラップゼロ。

レイト、階層型、エージェント型チャンキングはどうか？

これらは「RAG 2.0」の騒ぎの背後にある高度なRAGチャンキング戦略で、3つとも検索結果のカバレッジはまだ1/10です。

レイトチャンキング

レイトチャンキングは、Güntherらが"Late Chunking: Contextual Chunk Embeddings Using Long-Context Embedding Models"（arXiv 2409.04701、2024年9月）で導入しました。まず全文を長文脈モデルで埋め込み、次にトークンレベルの埋め込みをチャンクベクトルへプールします。各チャンクがドキュメント全体の文脈を運び、「月額40ドルかかる」の「それ」が何を指すか分かります。要旨はタスク全体で優れた検索を主張しますが、私たちが検証できた見出しの数値は公開していません。Weaviateの解説は仕組みを説明しますが、対照比較までは踏み込んでいません。根拠の状態：有望、未定量。

階層型（親子）チャンキング

検索用に小さいチャンク（256トークン）をインデックスし、生成器には親（1,024トークン）を返します。リトリーバーが針を見つけ、生成器は周囲の干し草の山を受け取ります。インデックスは2レベルと親子マッピングを維持します。この効果を分離した公開ベンチマークはありません。

LLMベース／エージェント型チャンキング

Chroma調査のLLMSemanticChunkerはGPT-4oを使い、ドキュメントごとに分割点を決めます。リコール91.7%（最高）、プレシジョン3.9%（最低）です。インデックス時にドキュメントごとにLLM呼び出しを払い（10,000ドキュメントのコーパスで約100ドル）、生成器により多くのノイズを渡します。本当に不規則なコーパス、つまり法的提出書類や抽出可能な見出しのないスキャンPDFにとっておいてください。

どのチャンクサイズが埋め込みモデルに合うか？

埋め込みモデルの最大入力トークンは切り捨て上限であって、推奨値ではありません。8,192トークンを受け付けるモデルが、512のときより8,192のとき良く埋め込むわけではありません。品質は上限のはるか前から希釈で劣化します。モデルはより多くのトークンにわたって意味を平均化し、ベクトルはコーパスの重心へ漂います。以下の推奨列はベンダーのガイダンスではなく、Techsyの解釈です。

出典：OpenAI embeddings guide、Cohere embed docs、Voyage embeddings docs、BGE model card

パターン：512トークンの硬い上限を持つモデル（Cohere v3、BGE）は、512を十分下回るチャンクを要求します。切り捨ては黙って起きるからです。600トークンを渡すと、最後の88トークンはエラーなく埋め込みから消えます。大きな上限を持つモデル（OpenAI、Voyage、Cohere v4）はより大きいチャンクを許容しますが、報いません。モデルの最大入力長は切り捨て制限であって、推奨値ではありません。

モデルを決める前に、RAG向けベスト埋め込みモデルのまとめ、MTEBスコアが実際に測るもの、そしてVoyage、OpenAI、Cohere埋め込みの横比較を合わせて読んでください。

英語以外のドキュメントをどうチャンクするか？

トークナイザーは言語中立ではありません。Petrovらは"Language Model Tokenizers Introduce Unfairness Between Languages"（arXiv 2305.15425、2023年）で、同じテキストを言語間で翻訳すると、トークン化後の長さが最大15倍異なることを示しました。文字レベルやバイトレベルのモデルでさえ、ある言語ペアでは4倍以上の差が出ます。512トークンのチャンクは、トルコ語、アラビア語、日本語では英語よりはるかに少ない意味しか持ちません。

同じ文をtiktokenのcl100k_baseエンコーディング（GPT-4のトークナイザー）でトークン化した例です。

import tiktoken
enc = tiktoken.get_encoding("cl100k_base")
en = "The retrieval system returns relevant documents."
tr = "Erişim sistemi ilgili belgeleri döndürür."
ja = "検索システムは関連文書を返します。"
print(len(enc.encode(en)), len(enc.encode(tr)), len(enc.encode(ja)))
# 7 tokens, 19 tokens, 19 tokens: same meaning, 2.7x token spread

カウントはtiktoken cl100k_baseで生成、2026年7月30日。

実務的な指針：固定512トークンのチャンクサイズでは、トルコ語と日本語のチャンクは英語チャンクの約37%の意味しか持たず、アラビア語のチャンクは約26%です。言語ごとに文字数や文数でチャンクするか、トークン予算を比例的に増やしてください（トルコ語で約1,400、アラビア語で約2,000）。CJK言語には空白の単語境界がないため、文字スプリッターの振る舞いが異なります。アラビア語の形態論は複数の文法マーカーを単一トークンに詰め込み、カウントをさらに膨らませます。

チャンキング戦略を選ぶための判断ツリー

What kind of document?
├── Structured (Markdown / HTML / code)
│   └── Document-aware splitting on headers or AST boundaries
│       ├── Docs site → MarkdownHeaderTextSplitter, 512 tokens, 0 overlap
│       └── Codebase → AST/function splitter, 256-512 tokens, imports prepended
├── Flat prose (articles, reports, books)
│   └── RecursiveCharacterTextSplitter, 512 tokens, 50 overlap
│       └── Topic-diverse? → try SemanticChunker at 95th percentile
├── Conversational logs (chat, support tickets)
│   └── Split on turn boundaries, group 3-5 turns per chunk, 256 tokens
└── Mixed corpus
    └── Route by MIME type → apply per-type strategy above
        └── Then: how long are expected answers?
            ├── Short (1-2 sentences) → child 256, no parent
            └── Long (multi-paragraph) → hierarchical: child 256, parent 1,024

3つの簡単な処方箋。ドキュメントチャットボット：MarkdownHeaderTextSplitterを512トークン、オーバーラップゼロ、メタデータに見出しパス。コード検索アシスタント：関数ごとに256-512トークンのAST境界分割、インポートを先頭に。混在する企業コーパス：取り込み時にドキュメント種別でルーティングし、チャンクを格納するベクトルデータベースに種別メタデータ付きで保存して、後で種別ごとに調整できるようにします。そのドキュメントごとのルーティングこそ、RAGアプリケーションにおける適応的チャンキングのすべてです。

ツール：LangChain vs LlamaIndex vs Chonkie

私たちはこれらをどれも売っていません。このキーワードの上位3つのランキングページは、製品CTA付きのベンダーブログです。

出典：LangChain docs、LlamaIndex NodeParsers、Chonkie docs

3つとも同じ中核アルゴリズムを実装しているので、パイプラインがすでに使っているものに合わせて選んでください。スプリッター以外のより広いRAGツールスタックと、ストレージ向けのQdrant、Chroma、pgvector比較は、クラスタガイドを参照してください。

Techsyのチャンキングへの取り組み

クライアントのRAG構築では、Techsyチームは512トークン、オーバーラップ10%から始め、クライアントの実際のサポートチケットから20-50問の評価セットを作るまでスプリッターに触れません。評価セットが先です。それから変数を1つずつ変えます。サイズ、オーバーラップ、戦略。同じ質問で前後の数値を出さずにスプリッターを交換することはありません。検索パイプラインへのセカンドオピニオンには無料相談をご利用ください。

著者について

Mert BaturはTechsy.ioの共同創業者です。チームはB2Bクライアント向けにAIエージェント、自動化システム、音声／SDRパイプラインを出荷しています。Techsyチームが本番で実際に使うLLMツールスタックについて書いており、クライアントのナレッジベース構築の背後にあるRAGと検索の作業も含まれます。LinkedInでつながってください。

よくある質問

RAGにおけるチャンキングとは？

チャンキングは、埋め込みの前にドキュメントをより小さい断片へ分割する前処理ステップです。リトリーバーがファイル全体ではなく焦点の絞れた一節に対してクエリをマッチできるようにします。分割点が、クエリ時にシステムが何を見つけられ、何を見つけられないかを決めます。

RAGに最適なチャンキング戦略は？

一般的なドキュメントを扱うほとんどの本番システムでは、512トークン、オーバーラップ10%の再帰的文字チャンキングが最強の既定値です。Chromaの472クエリ調査（2024年7月）ではリコール88.5%を記録し、最も高価なLLMベース手法から3.2ポイント以内、追加コストゼロでした。

RAGの最適チャンクサイズは？

512トークンから始めてください。埋め込みモデルの入力上限が512トークン（Cohere v3、BGE）の場合や、クエリが1文の回答を期待する場合は256へ下げてください。評価セットで複数段落の回答が断片化されていると分かった場合だけ1,024へ上げてください。必ず自分の質問で測定してください。

チャンクオーバーラップはどれくらい使うべき？

チャンクサイズの10-20%（512なら50-100トークン）。オーバーラップは境界の文の孤立を防ぎます。2つのチャンクにまたがった事実は、少なくとも1つでは完全な形で現れます。20%を超えると、見返りの減る中でコーパスを再埋め込みしすぎます。ほとんどのチームは10%に着地し、二度と見直しません。

セマンティックチャンキングは固定サイズより優れる？

わずかに優れますが、埋め込みコストは2倍です。Chromaの2024年7月ベンチマークでは、クラスタベースのセマンティックチャンカーがリコール89.0%・プレシジョン6.7%で、同じトークンサイズの再帰的リコール88.5%・プレシジョン7.0%に対して並び、最高プレシジョン8.0%の結果は別の検索設定から来ています。トピック多様なコーパスでは価値があります。均質なドキュメントセットでは正当化しにくいです。

チャンクサイズは埋め込みモデルに依存する？

はい。512トークン入力上限のモデル（BGE、Cohere v3）は、切り捨てが黙って起きるため、512を十分下回るチャンクを要求します。8,192以上の上限を持つモデルはより大きいチャンクを許容しますが報いません。埋め込み品質は上限の前に希釈で劣化します。モデルごとの開始点は上の対応表を参照してください。

RAGシステム用にコードをどうチャンクする？

トークン数ではなくAST境界（関数定義とクラス定義）で分割してください。各チャンクは関数ごとに256-512トークンに保ち、ファイルのインポートブロックと外側のクラスシグネチャを先頭に付け、関数は自己完結した単位なのでオーバーラップゼロにします。LlamaIndexのCodeSplitterとLangChainの言語認識スプリッターの両方がこれを処理します。

レイトチャンキングとは？

レイトチャンキングは、まず全文を長文脈モデルで埋め込み、次にトークンレベルの埋め込みをチャンクベクトルへプールします。各チャンクの埋め込みがドキュメント全体の文脈を運び、「『それ』は何を指すのか？」問題を解決します。Güntherらが導入（arXiv 2409.04701、2024年9月）。利得を定量した公開の直接比較ベンチマークはまだありません。

英語以外の言語のドキュメントをどうチャンクする？

トークン数は言語中立ではありません。同じ文がトルコ語と日本語では英語の2.7倍、アラビア語では3.9倍のトークンを要しました（tiktoken cl100k_base）。固定512トークン予算は、英語以外のチャンクに黙って少ない意味しか与えません。言語ごとに文字数や文数でチャンクするか、予算を比例的に増やしてください。

チャンキングが実際に機能しているか、どう分かる？

スプリッターに触れる前に、実際のユーザークエリから20-50問の評価セットを作ってください。現在のチャンクに対してhit@5とMRRを記録します。変数を1つ（サイズ、オーバーラップ、戦略）変え、再実行し、比較します。評価セットなしでは、感覚で調整しているだけです。20問あれば始められます。

結論

• 再帰的文字チャンキング、512トークン、オーバーラップ10%から始める。平坦な文章の正しい既定値。
• 誰かが測定した4つのスプリッター系統全体で、Chromaの472クエリはリコールを約5ポイント動かし、プレシジョンは数倍大きく動かします。まずプレシジョンとコストを調整してください。
• チャンクサイズを埋め込みモデルの入力上限に合わせる。512トークン上限のモデルは512未満のチャンクを要求します。
• スプリッターを再調整する前に、チャンクを文脈で豊かにする（Anthropicの失敗率5.7%から3.7%への低下）。
• まず評価セットを作る。前後の数値のないすべてのスプリッター判断は推測です。

チャンキングの選択を取り巻くパイプライン全体は、RAGアプリケーションをエンドツーエンドで構築を参照してください。検索とファインチューニングの間でまだ迷っていますか？RAGかファインチューニングかが、それぞれが勝つ場面を分解します。