チャンク分割の設計 — 検索精度の8割はここで決まる
RAGの精度が出ない原因の多くはチャンク設計にある。固定長・文単位・意味的・親子の4方式を使い分け、粒度とオーバーラップを根拠を持って決められるようになる。
- チャンクは「検索で当てたい単位」と「生成に渡したい単位」の両方を兼ねさせられがちだが、この2つは本来別物。小さく引いて大きく渡す設計が効くのはこのため。
- 固定長分割は実装が最も簡単だが文の途中で切れて意味が壊れる。実務の既定は「構造で切ってから長さで調整する」ハイブリッドで、見出しやリスト境界を尊重する。
- オーバーラップは境界に落ちた情報を救う保険で、10〜20%が目安。増やすほど再現率は上がるがインデックスと生成コストが比例して増える。
RAG の回答品質が上がらないとき、多くのチームがまず LLM を強いモデルに替えます。しかし基本のRAGで見たとおり、生成の質は検索で引いた文脈の質を超えられません。関係のない断片を渡せば、どれだけ強力なモデルでもそれに引きずられます。そして検索の質を最初に決めてしまうのが、文書をどう切るかというチャンク分割です。
横にスクロール
なぜ切り方で精度が変わるのか
埋め込みモデルは、チャンク1つを1本のベクトルに潰します。この圧縮が、切り方の良し悪しを直接精度に変えます。
- チャンクが大きすぎると、1本のベクトルに複数の話題が混ざります。ベクトルは話題の平均のような位置に置かれ、どのクエリにも中途半端にしか近くなりません。加えて、当たっても無関係な部分が大量に文脈へ入り、生成が薄まります。
- チャンクが小さすぎると、意味が自己完結しません。「この設定は既定で有効です」という1文だけを引いても、何の設定かが分からず答えられません。代名詞や省略された主語が解決できない断片は、検索で当たっても役に立ちません。
つまり良いチャンクとは、それ単独で読んで意味が通る最小の単位です。この基準は、長さではなく文書の構造から決まります。
「どのチャンクを引くか」の精度を上げたいなら小さいほうが有利で、「引いた後に十分な文脈を渡す」なら大きいほうが有利です。この2つを1つのチャンクに兼ねさせるから無理が生じます。分離する設計がsmall-to-big（親子チャンク）で、チャンク設計に行き詰まったら真っ先に検討する価値があります。
4つの方式
| 方式 | 切り方 | 強み | 弱み |
|---|---|---|---|
| 固定長 | N文字ごとに機械的に分割 | 実装が最も簡単、長さが揃う | 文や語の途中で切れて意味が壊れる |
| 文・段落単位 | 句点や空行など自然な境界で分割 | 意味の切れ目を尊重できる | 長さがばらつき、極端に短い断片が出る |
| 構造単位 | 見出し・リスト・表・コードブロックの境界 | 文書の論理構造をそのまま活かせる | 構造の無いプレーンテキストには使えない |
| 意味的分割 | 隣接文の埋め込み類似度が落ちる点で切る | 話題の転換点を自動で見つけられる | 埋め込み計算のコストと閾値調整が要る |
実務の既定解は「構造で切ってから長さで調整する」です。まず見出しやリストで大きく区切り、それでも長すぎるブロックだけを文単位で分割し、短すぎる断片は隣と結合します。純粋な固定長分割は、実装の速さ以外に選ぶ理由がほとんどありません。
意味的分割は魅力的に見えますが、閾値の調整が難しく、構造分割との差が小さいことも多いので、構造分割で頭打ちになってから試す順序が現実的です。
オーバーラップ：境界に落ちた情報を救う
どこで切っても、答えが切れ目にまたがる可能性は残ります。これに対する保険がチャンク間のオーバーラップ（重複）です。
オーバーラップなし
[ ...設定Aの説明。既定値は ] [ 30秒である。変更するには... ]
→ 「既定値は」で切れ、どちらのチャンクも単独では答えられない
オーバーラップ10〜20%
[ ...設定Aの説明。既定値は30秒である。 ]
[ 既定値は30秒である。変更するには... ]
→ 後者だけでも答えが完結する
目安は10〜20%です。増やすほど再現率は上がりますが、インデックスのサイズも埋め込みの計算量も比例して増え、検索結果に重複した内容が並んで文脈枠を無駄に食います。オーバーラップを大きくしないと救えない状況は、たいていチャンクが小さすぎるサインなので、まず粒度のほうを見直すべきです。
粒度の決め方
「何文字が正解か」に一般解はありませんが、決め方には順序があります。
- 想定質問から逆算する。 実際に来る質問を20〜30件集め、その答えが原文のどれくらいの範囲に書かれているかを測ります。答えが1〜2段落に収まるなら、その大きさが出発点です。
- 埋め込みモデルの入力上限を確認する。 上限を超えた部分は黙って切り捨てられることがあり、後半の内容が検索に一切効かなくなります。これは気づきにくい重大な失敗で、長いチャンクを使うときは必ず確認します。
- 生成側の文脈枠から上限を割る。 上位k件を渡すなら、1チャンクの上限はおおよそ「使える文脈枠 ÷ k」に制約されます。
- 実測で調整する。 粒度は理屈だけでは決まりません。ゴールデンセットを作って検索の再現率を測り、数パターンを比べます。
1つのコーパスに全部同じ切り方を適用する必要はありません。APIリファレンスは項目単位、議事録は発言単位、長文の解説記事は見出し単位、表は行単位——文書の種類ごとに最適な単位は違います。取り込みパイプラインを種類別に分岐させるのは、複雑さに見合う効果があります。表を機械的に固定長で切ると、ヘッダー行と値が分離して完全に無意味な断片になるのが典型例です。
メタデータを一緒に持たせる
チャンクを保存するとき、本文だけでなく出所の情報を必ず一緒に格納します。
チャンク本文 : 「タイムアウトの既定値は30秒である。」
メタデータ : 文書ID / タイトル / 見出しパス / 更新日 / 権限スコープ / ページ番号
これが効く場面は3つあります。第一に、メタデータフィルタで検索範囲を事前に絞れます。第二に、生成時に出典を示せます。第三に、見出しパスをチャンク本文の先頭に埋め込むと、断片が自己完結に近づいて検索精度が上がります。
本文だけ : 「既定値は30秒である。」
見出しパスを前置 : 「設定リファレンス > 接続 > タイムアウト
既定値は30秒である。」
後者はそれ単独で何の話か分かるため、クエリとの類似度が正しく計算されます。チャンク分割の改善で最も費用対効果が高い一手がこれです。
まとめ
- 良いチャンクはそれ単独で読んで意味が通る最小の単位。基準は長さではなく文書の構造から決まる。
- 実務の既定は構造で切ってから長さで調整するハイブリッド。純粋な固定長分割は実装の速さ以外に利点がない。
- オーバーラップは10〜20%が目安。それ以上必要なら、粒度そのものを見直すサイン。
- 埋め込みモデルの入力上限超過は黙って切り捨てられるため、長いチャンクでは必ず確認する。
- 見出しパスをチャンク先頭に前置するのが、最も費用対効果の高い精度改善。メタデータは検索の絞り込みと出典表示の両方に効く。
- 検索したい単位と渡したい単位が食い違うなら、small-to-bigで分離する。
RAG設計パターンの記事ガイド
チャンク分割の設計 — 検索精度の8割はここで決まるを実務で読む
TL;DRは入口です。実際に選ぶ・使う段階では、何を解決するか、何と比較するか、導入後にどこで詰まるかまで見る必要があります。
解決すること
RAG
比較で見る軸
難易度: advanced / カテゴリ: RAG設計パターン / タグ数: 5
導入後に効く点
固定長分割は実装が最も簡単だが文の途中で切れて意味が壊れる。実務の既定は「構造で切ってから長さで調整する」ハイブリッドで、見出しやリスト境界を尊重する。
先に潰すリスク
用語だけ覚えても、設計・実装・運用でどこに効くかを確認しないと判断を誤る。
- 難易度
- advanced
- カテゴリ
- RAG設計パターン
- タグ数
- 5
判断チェックリスト
- 自社の用途が「RAG / チャンク分割」に近いか確認する。
- 強みである「チャンクは「検索で当てたい単位」と「生成に渡したい単位」の両方を兼ねさせられがちだが、この2つは本来別物。小さく引いて大きく渡す設計が効くのはこのため。」が本当に評価軸になるか確認する。
- 注意点の「用語だけ覚えても、設計・実装・運用でどこに効くかを確認しないと判断を誤る。」を運用で吸収できるか確認する。
- 公開値や仕様値は、対象プラン・対象機種・対象リージョンまで確認する。
- 既存システム、ID、ネットワーク、監視、バックアップとの接続方法を先に洗い出す。
- 小さく試してから、本番移行、権限設計、障害時手順、コスト監視を決める。