RAGのチャンキング戦略を比較：リトリーバーが答えの半分しか見つけない理由

検索システムがたいていの場合に答えの一部を見つけているなら、ダッシュボードが示すより頻繁に失敗している可能性が高いです。10月に出たチャンキングについての一連の論文と、そのアイデアのうち5つを並べて試した1つの丁寧な実験は、同じ教訓を示しています。文書をどう切るかで何が見つかるかが決まり、最適な切り方は、送れるコンテキストの量によって変わるということです。

チャンキングが再び議題に上がった理由

検索拡張生成（RAG）は、文書を断片に切り、質問に合う断片を見つけてモデルに渡します。モデルは渡されたものしか使えません。The Bottleneck Is Retrieval, Not Reading（arXiv、10月18日）は、10のフロンティアモデルと3つのオープンウェイトモデルを試し、すべてで同じパターンを見つけました。検索は、複数の事実を必要とする質問に要るチャンクの一部は確実に見つけますが、すべては見つけません。そしてチャンキングは、ある段落を別の段落と結びつける文書レベルの文脈を取り除いてしまいます。

10月の3つの論文が、この問題に異なる側面から取り組んでいます。

QESChunker（10月27日）は、チャンキングを最適化として扱います。例となる質問とそれに答える文が与えられると、検索可能な証拠を最も多く残す切れ目を選びます。重なりがなければ、動的計画法で厳密な最適解が求まります。重なりがあると問題はNP困難になり、貪欲法で最適解から証明された範囲内に収まります。

StrucChunk（10月19日）は、著者がすでに書いた構造を使います。条項をまたいで切ることはせず、「see Section 4.2」のような相互参照をインデックス作成前に解決し、キーワード検索（BM25）と密な埋め込みを融合します。インドの刑事訴訟法についての501の質問で、Recall@5は0.557から0.804に上がり、著者はその向上の88%をチャンキングだけによるものとしています。

SpectRAG（10月27日）は、チャンクを独立したものとして扱うのをやめます。隣接関係、セクションの階層、共通のエンティティ、引用からチャンクの重み付きグラフを作り、最初の検索結果からそのグラフを通じて関連度を広げ、決められたトークン予算の中でコンテキストを組み立てます。

1つの実験、5つのチャンカー

Vishal Mysoreは、誰でも再実行できるブラウザのラボで、これらのアイデアを互いに比べました。文書は、番号付きのセクション、定義、相互参照を持つ、規程集のように書かれた架空の天文台のハンドブックです。検索はBM25のみなので、すべての数値は決定的です。各チャンカーには同じ制限が与えられます。チャンクは最大450文字、コンテキストの予算は120語です。

5つのチャンカーは、数百文字ごとに切る固定ウィンドウ、文をまるごと詰める文ウィンドウ、StrucChunk風の構造を意識したチャンカー（番号付きセクションごとに1チャンク、見出しのパスを付け、相互参照された定義を貼り込む）、そしてQESChunkerの厳密版と重なりあり版です。

どのチャンカーも、すべての証拠の文をどこかで欠けずに保っていました。違いは、正しい断片が見つかり、予算に収まるかどうかにあります。

結果が示すこと

部分的な再現率は実態をよく見せる。どの戦略も、質問の69から92%で少なくとも1つの証拠の文を見つけました。既定のチャンカーが完全な答えを組み立てられたのは4分の1未満でした。部分的なヒットで評価するパイプラインは、複数の事実を要する答えの4つに3つが証拠の半分で作られていても、健全に見えてしまいます。

コンテキストが限られているときは、小さく構造化されたチャンクが勝つ。セクションの大きさのチャンクは平均285文字で、ウィンドウは約400文字だったため、ウィンドウなら1つしか入らない120語に2つか3つ入ります。40語の予算では、10%を超えたのは構造を意識したチャンカーだけでした。300語ではウィンドウのチャンカーが追いつき、400語では上回りましたが、構造を意識したチャンカーは77%で頭打ちになりました。予算が十分にあれば、文書のかなりの部分を送ることになるので、ほとんどどのチャンカーでも証拠を拾えます。

チャンクの大きさと予算は一緒に決める必要がある。800文字のチャンクでは、固定ウィンドウと文ウィンドウは0%でした。800文字のウィンドウは約130語で、120語の予算を超えるため、1つのチャンクも収まらなかったのです。これは、チャンカーを調整する人とプロンプトを調整する人が別々のときに起きる失敗です。

証明上最適なチャンカーが最下位だった。QESChunkerの厳密版は、評価用に取り分けた質問で15%でした。これは自分の目的関数に対しては最適で、その目的関数は証拠の文を欠けずに保つことを評価します。ある規則を欠けずに保つ最も安い方法は、その直前で切ることで、ハンドブックでは規則の直前の行はその見出しです。見出しが1つのチャンクの末尾に、規則が次のチャンクの先頭に来たため、見出しのキーワード検索は間違ったチャンクを見つけました。見出しで始まるチャンクは1つもありませんでした。この教訓は一般的です。チャンカーは書き下したものを最適化するのであり、欠けていない証拠と見つけられる証拠は同じではありません。重なりあり版はずっと良く、取り分けた質問で46%、調整に使った質問で83%でした。この差は、例となる質問で学習するあらゆるチャンカーへの警告です。インデックスは、あなたが思いついた質問に合わせて形作られてしまいます。

定義がハブになる文書では、チャンクのグラフが役立つ。構造を意識したチャンキングをグラフ検索に切り替えると、62%から69%に上がりました。「Is flash photography allowed on the dome floor?」という質問では、単純なBM25はred-light zoneの定義を3位に置き、予算に収まらなくなっていました。グラフモードでは、他の2つのセクションがその定義を相互参照しているため、関連度がそこに流れ込み、選ばれました。相互参照の解決を止めると、その向上は消えました。ウィンドウのチャンカーではグラフは役に立たず、文ウィンドウでは23%から15%に下がりました。

チャンキングの問題ではない見落としもある。「My 8-year-old is coming. What rule applies on the terrace?」はどこでも失敗しました。規則には「children under 10」と書かれていて、質問と共通の単語がないからです。この溝を埋めるには、密な検索かハイブリッド検索、クエリの書き換え、またはリランカーが必要です。

パイプラインで変えるべきこと

契約書、規程、マニュアル、仕様書など、実際に構造を持つ文書は、セクションごとにチャンクに分け、見出しのパスを付け、インデックス作成時に相互参照を解決して、規則が依存する定義と一緒に運ばれるようにしてください。DoclingやUnstructuredのようなツールはPDFからその構造を復元し、Chonkieはチャンキングそのものを担います。

部分的なヒットではなく、完全な答えを測ってください。複数の事実を要する質問に証拠の半分で答えたものは、正しく見える間違った答えです。Ragasは質問ごとにコンテキストの再現率を採点できます。

チャンクの大きさとコンテキストの予算は同じ場所で設定し、実際に送る予算でテストしてください。120語で最良だったチャンカーは、400語では最良ではありませんでした。

教師ありやグラフベースの手法を試すなら、その目的関数が実際に使うリトリーバーに合っているか確かめてください。9月の2つの論文が別の角度からこれを裏付けています。54の構成を比べた研究は、パーサーとチャンカーの選択が互いに影響し、どこでも最良のリトリーバーは1つもないことを示しました。約464,000本の論文で6つのパイプラインを比べた研究は、リランキングとレイトインタラクションが、第1段階の調整より品質を大きく動かすことを示しました。3つ目の適応的な検索の深さについての論文は、質問の種類ごとに取得するチャンクの数を選ぶことで、簡単なクエリでF1が36%以上向上し、トークンが14%減ったと報告しています。

結論：チャンキングは何を検索できるかを決め、リトリーバーは何が検索されるかを決めます。前者は構造で、後者はハイブリッド検索とCohere Rerank 5やJina Reranker v3.5のようなリランカーで直し、どちらも答え全体が届くかどうかで評価してください。