RAGのチャンク分割(chunking)とは｜検索品質を左右する文書の区切り方

RAGの精度が出ないという相談を受けたとき、原因が生成ではなく検索側にあることは珍しくありません。そして検索側の中でも、意外と見落とされがちなのが「文書をどう区切ってからベクトル化したか」というチャンク分割(chunking)です。同じ文書・同じ埋め込みモデルでも、区切り方を変えるだけで検索でヒットする断片が変わり、回答の質が目に見えて動きます。この記事では、なぜ分割が必要かという原理から、主な分割戦略、オーバーラップやサイズのトレードオフ、発展的な文脈付与までを、実務で判断するための粒度で整理します。

なぜチャンク分割が必要か#

文書をそのまま丸ごとベクトル化して検索に使えないのには、いくつか理由があります。

一つ目はコンテキスト長の制約です。埋め込みモデルには一度に処理できる入力長の上限があり、LLMに渡すプロンプトにも実用上の限りがあります。長い文書を一つのベクトルに押し込めると、細部の情報が平均化されて薄まり、ピンポイントの検索に効かなくなります。

二つ目は検索の粒度です。ベクトル検索は「質問と意味が近い断片」を返す仕組みなので、断片が適切な大きさで意味的にまとまっているほど、狙った箇所を引き当てやすくなります。逆に一つのチャンクに複数の話題が混在していると、ベクトルの向きが定まらず、どの質問にも中途半端にしか一致しません。

三つ目はノイズです。関係の薄い文章まで一緒に検索結果へ入り込むと、LLMは余計な情報に引っ張られ、回答がぶれます。適切に区切ることは、検索でヒットさせたい情報の純度を上げる作業でもあります。

主な分割戦略#

分割戦略は大きく4系統に整理できます。上から順に実装が単純で、下にいくほど文書の意味や構造を尊重します。

固定長分割(文字/トークン基準)#

決めた文字数またはトークン数ごとに機械的に切る、最も単純な方法です。実装が速く、ログや文字起こしのように構造の乏しいデータには十分機能します。一方で、文・箇条書き・表・コードブロックを途中でぶつ切りにしやすく、意味の切れ目を無視するため、整った文書では検索精度が落ちやすいのが弱点です。プロトタイピングの出発点と割り切るのが無難です。

再帰的分割(区切りを尊重する)#

段落・改行・文・単語といった区切り文字を優先順位の高い順に試し、目標サイズに収まるところで切る方法です。LangChainのRecursiveCharacterTextSplitterが代表例で、既定では段落(空行) -> 改行 -> スペース -> 文字の順に分割を試み、意味的にまとまりやすい単位をできるだけ壊さないように働きます。LangChainの公式ドキュメントでも汎用テキスト向けの推奨手法とされており、多くのRAGでまず選ぶ現実的な既定値になります。

構造/レイアウト認識分割#

Markdownの見出し、HTMLのタグ、PDFのレイアウト、コードの関数境界など、文書が持つ構造そのものを手がかりに区切る方法です。見出し単位でまとめる、表を一塊に保つ、といった処理により、書式の意味を保ったまま分割できます。仕様書・マニュアル・技術文書のように構造が明確なデータで効果が出やすい一方、レイアウトの崩れたPDFなどでは前処理の作り込みが必要になります。

意味的(semantic)分割#

隣り合う文を埋め込みベクトルで比較し、意味の類似度が下がった箇所を話題の切れ目とみなして区切る方法です。文字数ではなく内容の変わり目で切るため、複数の話題を含む論文や記事で相性が良いとされます。ただし分割時にも埋め込み計算が走るためコストと処理時間が増え、閾値の調整も必要です。まず単純な戦略で土台を作り、精度が頭打ちになってから検討する順序が現実的です。

オーバーラップの役割#

チャンクを切ると、境界をまたぐ情報が両側で欠ける問題が起きます。たとえば「この条件を満たす場合は」という一文がチャンク末尾で切れ、続く「申請が必要です」が次のチャンク先頭に入ると、どちらの断片も単独では意味が完結しません。

これを緩和するのがオーバーラップで、隣り合うチャンクの末尾と先頭を意図的に重複させます。境界付近の文が両方のチャンクに含まれるようになり、どちらが検索されても文脈が保たれやすくなります。重複を増やすほど安全側になりますが、その分ベクトル数と保存コストが増え、同じ内容が複数ヒットして結果が冗長になることもあるため、過剰な重ねすぎは避けます。

チャンクサイズのトレードオフ#

サイズ設計は「小さすぎ」と「大きすぎ」の間を取る作業です。

小さすぎるチャンクは、検索の精度は高くても一つの断片に入る文脈が少なく、回答に必要な前提が別チャンクに散らばって欠落しがちです。逆に大きすぎるチャンクは、関係の薄い文章まで巻き込んでノイズが増え、埋め込みの焦点がぼやけ、トークン消費も増えます。加えて、長い文脈の中央に置かれた情報をモデルが拾いにくくなる、いわゆる「lost in the middle(中間の見落とし)」の影響も受けやすくなります。

初期値の考え方として、一般的な解説では数百トークン程度のチャンクに1割から2割ほどのオーバーラップを添える範囲が出発点としてよく挙げられます。技術文書のように密度が高いデータは小さめ、物語的で文脈依存の強いデータは大きめ、といった調整も紹介されます。ただしこれらはあくまで目安であり、最適値は文書の性質・埋め込みモデル・想定質問によって変わります。数値をそのまま採用するのではなく、必ず自社データでの評価を通して決めてください。

メタデータ付与と発展的な手法#

分割は「切る」だけでは終わりません。各チャンクに、出典ファイル名・見出し・作成日・部署・アクセス権限といったメタデータを付けておくと、検索時のフィルタリングや、回答への根拠表示、権限に応じた絞り込みに使えます。分割段階でメタデータを一緒に持たせる設計は、後工程の精度と運用の両方に効きます。

さらに一歩進んだ手法もあります。

一つは親子構造(small-to-big、親子チャンク)です。検索は小さいチャンクで精度良く行い、LLMへ渡す際には対応する大きな親チャンク(たとえば同じ節全体)を渡す、という二段構えにすることで、検索の精度と回答の文脈量を両立させます。

もう一つが文脈付与です。Anthropicが公開したContextual Retrievalは、各チャンクに対して「この断片が文書全体のどこに位置づくか」を説明する短い文脈(同社の解説では50から100トークン程度)をLLMで生成して先頭に付けてから、埋め込みとBM25の索引を作る手法です。同社の発表では、この文脈付与を埋め込みとBM25の両方に適用すると検索失敗が49%減り、さらに再ランキングを加えると上位20件の取得失敗が67%減ったと報告されています。いずれも同社の実験に基づく発表値で、データや構成により変動する前提の数値として捉えてください。

向かない・効きにくい場面#

チャンク分割の工夫が効くのは、あくまで「関連する断片を検索で引き当てる」タイプの質問です。次のような要件では、分割をいくら磨いても限界があります。

文書全体を集計・網羅する質問(全契約書のうち更新月が3月のものを数える、規程の禁止事項をすべて挙げる等)は、検索が上位数件〜数十件しか返さない以上、原理的に取りこぼします。これはデータベースや全文処理など別の仕組みで補う領域です。また、そもそも元文書が古い・版が混在している状態では、どんなに賢く区切っても誤った情報がヒットするだけです。分割は文書整備の代わりにはなりません。表や図に情報が集中している文書も、テキスト化・構造化の前処理が伴わなければ、分割戦略だけでは精度は上がりにくくなります。

分割設計の進め方#

分割手法の具体的な実装(区切り文字の指定・サイズ設定・文脈付与など)は各ライブラリ・各社の公式ドキュメントで更新されます。LangChainやLlamaIndex等のドキュメントで現行の推奨とパラメータ名を確認してから実装してください。

よくある質問#

まとめ#

チャンク分割は、派手さはないものの、RAGの検索品質を実際に動かす土台です。区切り方に唯一の正解はなく、自社データと評価で測って決めるという地道な姿勢が結局は近道になります。分割の前提となる埋め込み・ベクトル検索の考え方や、RAG全体の設計判断もあわせて押さえておくと、どこを直せば効くのかの見通しが良くなります。