Lotook
RAG向けに文書を効果的にチャンク分割するには、まず既存の文書構造に沿ってファイルを分け、大きすぎるセクションには文単位の重複を設けてトークン長の上限を適用し、各パッセージに出典のメタデータを付けます。トークン、意味、構造に基づく分割の選択は、コーパスが均質な文章、移り変わる話題、または書式のある表や見出しのどれで構成されているかによって決まります。
なぜRAGのチャンク分割が検索品質を左右するのか？
Retrieval-Augmented Generation（RAG）では、元文書を短いパッセージに分割してから、それらを埋め込み、検索インデックスに保存します。問い合わせ時には、システムが最も関連性の高いチャンクを検索し、ユーザーの質問とともに言語モデルに渡します。文書全体では通常、特定の質問にうまく一致させるには範囲が広すぎ、他の候補とともにモデルのコンテキストウィンドウに収めるには大きすぎるため、チャンク分割が検索単位を決めます。
Patrick Lewisらが2020年のNeurIPS論文（Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks）でこの枠組みを発表した際、実験では各Wikipedia記事を重複しない約100語のチャンクに分割し、約2100万件のパッセージを生成しました。この100語の分割は、2020年のWikipediaを対象とした実験設定であり、2026年の本番環境の標準設定ではありません。2026年11月時点の最新の本番RAGは通常、元のエンドツーエンドで微分可能なDPRとBARTの構成ではなく、モジュール式のエンジニアリングパイプライン（分割、埋め込み、インデックス作成、検索、生成）として動作します。
RAGの主なチャンク分割方法は何か？
RAGのチャンク分割方法は、トークンベース、意味ベース、構造を考慮した分割の3種類に分かれます。それぞれ長さ、意味、文書のマークアップを使ってパッセージの開始位置と終了位置を決めます。
| 分割方法 | 分割の基準 | 適した対象 | 主なリスク | インデックス作成コスト |
|---|---|---|---|---|
| トークン（または長さ）による分割 | 重複をずらしながら設ける固定長のトークンまたは文字のウィンドウ | 均質な文章、プレーンテキスト、構造分割後の長さ制限 | 文、表の行、コードブロック、定義が途中で切れる | 低 |
| 意味ベースの分割 | 隣接する文の埋め込み類似度の低下 | 見出しがなく文書の途中で話題が変わる、書式のない文章 | インデックス作成が遅く高コストになり、チャンクサイズが不均一になる | 高 |
| 構造を考慮した分割 | 見出し、段落、リスト、表、コードブロック、ページ | Markdown、HTML、APIドキュメント、法的条項、構造化されたマニュアル | スキャンしたPDFの構造は不明瞭で、単一セクションが非常に大きい場合もある | 低〜中 |
1. トークンと文字によるチャンク分割
トークンによる分割では、テキストをトークン数または文字数で測った固定長のウィンドウに分け、多くの場合は重複をずらしながら設けます。トークンで測る方法はモデルの動作に合っています。埋め込みモデルとLLMには厳密なトークン制限があり、APIはトークン数で課金され、同じ段落でもモデルの系統によってトークン化の結果が異なるためです。文字数は大まかな目安にすぎません。
チームは通常、埋め込みモデルの制限内に収まるウィンドウサイズから始め（チュートリアルでは数百トークンから始めることが多い）、検索の失敗を確認してから調整します。固定ウィンドウの主なリスクは、構文やレイアウトを無視して文、表の行、コードブロック、定義を途中で切り、質問に答える節を落としてしまうことです。
2. 意味ベースのチャンク分割
意味ベースの分割では、固定のトークン数ではなく、隣接する文の埋め込み類似度が下がったときや談話の境界が現れたときなど、意味が変わる場所でテキストを分けます。見出しのない文書の途中で話題が変わる場合、完全な考えを1つのチャンクに収めると検索に役立ちます。
ただし、分割自体に埋め込みの呼び出しが必要になる場合があるため、インデックス作成は遅く高コストになります。ノイズの多い類似度のしきい値によって、テキストが過剰または不十分に分割され、サイズが不均一になることもあります。また、文の類似度は表、フォーム、コードに対して自動的に優れているわけではありません。
3. 構造を考慮したチャンク分割
構造を考慮した分割では、MarkdownやHTMLの見出し、段落、リスト、セクション、ページ、区切り付きコードブロック、表の境界など、既存の文書構造を最初の分割に利用します。AWS Prescriptive GuidanceのRAGに関する解説にあるように、文書構造を保つと、論理的に関連するコンテキストをそのまま維持できます。返金ポリシーの見出しから始まりセクション全体を含むチャンクは、文の途中から始まるウィンドウよりも検索して引用しやすくなります。
多くのPDFやスキャン文書には明確な見出しがなく（1つの見出しが20ページにわたることもあるため）、本番パイプラインでは通常、複数の方法を組み合わせます。
- まず構造に従って階層的に分割する： 文書をセクションまたは見出しで分け、次に段落またはブロックで分けます。コードブロック、表、リストはそのまま保ちます。
- 次にトークン長の上限を適用する： セクションがまだ大きすぎる場合は、トークンウィンドウで分割します。
- 非構造化テキストには代替の分割方法を使う： スキャンしたPDFや長い非構造化セクションでは、ページ単位の分割、トークンウィンドウ、意味の境界を使います。
チャンクの重複とRAGメタデータはどう設定すべきか？
チャンクの重複とパッセージのメタデータは、境界にある節の欠落を防ぎ、検索された抜粋を元文書に結び付けます。
チャンクの重複を設定する
チャンクの重複では、あるチャンクの末尾を次のチャンクの先頭で繰り返します。これにより、境界にある文や定義が、検索された少なくとも1つのパッセージに完全な形で現れます。固定ウィンドウや代替の分割方法が考えの途中で切る場合の簡単な備えになります。
重複は、コーパス内の典型的な文を1〜2文分カバーしつつ、ほぼ同じチャンクを二重に保存しない程度に小さく設定します。重複は埋め込み、保存、検索するトークン数を増やし、インデックスを大きくするとともに、結果にほぼ重複した候補を加えます。検索でほぼ同じチャンクが頻繁に返される場合は、重複やチャンクサイズを減らすか、検索後の重複排除ステップを追加します。
RAGメタデータを付ける
RAGメタデータは各チャンクとともに保存される構造化フィールドで、次のものを含みます。
- 元文書のIDまたはURLとタイトル
- セクションまたは見出しのパスとページ番号
- 作成日または更新日と文書タイプ（ポリシー、チケット、APIリファレンス）
- アクセスと権限のラベル、言語、安定したチャンクID
生のIDやタイムスタンプが類似度を損なう場合、チームはメタデータを埋め込みから除外できます。一方、検索を改善する場合は、選択したフィールド（セクションタイトルなど）を埋め込み対象のテキストの先頭に追加できます。メタデータは本番環境の3つの要件を支えます。
- 引用： UIやモデルは、単なるパッセージではなく、ファイル、見出し、ページ番号を引用できます。
- 権限とバージョンのフィルター： ポリシーの最新版、特定の製品、またはユーザーが閲覧を許可された文書だけを検索します。非公開文書をフィルターのないRAGインデックスに入れると、システムに問い合わせられる誰もがアクセスできるため、権限はプロンプトだけでなくインデックスのフィルターに設定します。
- デバッグと更新： 元文書が変わったら、その文書を再分割して再度埋め込み、古いチャンクIDを廃止して、古い事実が事実誤認を引き起こさないようにします。
チャンクが大きすぎるか小さすぎるかをどう判断するか？
実際のユーザーの質問に対して検索されたチャンクを調べると、パッセージが大きすぎるか、細切れになっているかが分かります。
チャンクが大きすぎる兆候
- 埋もれた回答： 検索語に言及する長いセクションが返されても、実際の回答が埋もれているため、モデルが探さなければならないか、見落とします。
- 過密なプロンプト： プロンプトに少数のチャンクしか収まらず、平凡な一致がより良い候補を押し出します。
- コストと遅延の増加： 無関係なトークンを大量に送ると、費用と応答時間が増えます。
- 注意散漫の悪化： 余分なノイズはcontext rotを悪化させます。モデルは大きなプロンプト内に正しい事実を持っていても、学習時の記憶や隣接する誤った文に頼ります。
チャンクが小さすぎる兆候
- 文脈のない断片： 検索されたチャンクが前の文なしでは理解できません（例えば、ルールを示さずに法人プランの例外を述べる文）。
- 複数部分からなる回答の分断： 定義とその例外、関数とそのパラメーター、またはポリシーとその発効日が別々のチャンクに入り、top-kでは一部しか返されません。
- ほぼ同一の断片： 繰り返しの多い抜粋を多数検索しても完全な考えが得られず、各文が別々の出典になるため引用も煩雑になります。
実際にサイズを調整するには、実際の質問と検索されたチャンクを確認し、そのパッセージだけを渡された人が回答できるかを考えます。必要な文が検索されなかった隣のチャンクにある場合は、重複、構造ルール、またはサイズを調整します。必要な文が検索されたチャンク内で無関係なテキストに囲まれている場合は、より小さく分割するか、より絞り込んだチャンクを少数検索します。
RAGのチャンク分割はcontext rotにどう影響するか？
RAGのチャンク分割は、context rotへの直接的な対策です。これは、プロンプトが長くなったり雑然としたりするにつれ、公表されているコンテキスト上限を大幅に下回っていても、モデルの推論品質、指示への追従、想起が低下する現象です。
RAGは、コーパス全体をプロンプトに投入せずに済むようにするためのものです。しかし、大きすぎるチャンクを検索したり、念のためにtop-kを増やして漠然と似たチャンクを大量にプロンプトに詰め込んだりすると、再び長くノイズの多いコンテキストが生まれます。コンテキストが多ければ自動的に正確になるわけではありません。チャンクを絞り込むとプロンプトの煩雑さは減りますが、適切な分割だけでは、質の悪い埋め込みモデルを修正したり、モデルが検索されたテキストを無視する場合のAIのハルシネーションをなくしたりすることはできません。
FAQ
RAGのチャンクサイズはトークン数と文字数のどちらで測るべきか？
可能な限りトークン数で測ります。埋め込みモデルと言語モデルはトークン単位でコンテキスト制限を適用し、APIの使用料もトークン単位で請求されます。文字数は大まかな目安にすぎません。同じ段落でも言語、コードブロック、モデルの系統によって異なるトークン数に分割されるためです。埋め込みモデルのトークナイザーを使うと、インデックス作成時の予期しない切り詰めを防げます。
意味ベースの分割は常にトークンによる分割より優れているか？
意味ベースの分割は、トークンや構造を考慮した分割より自動的に優れているわけではありません。文の類似度が下がったところで分割すると、非構造化の文章で考えをまとめておくのに役立ちますが、インデックス作成時に追加の埋め込み処理が必要で、チャンクサイズが不均一になり、ノイズの多いしきい値では過剰または不十分に分割されることがあります。書式のある文書では、見出し、表、コードブロックに沿った分割の方が速く、著者が意図した境界に従います。
RAG向けに表やコードブロックをどう分割すべきか？
表、請求書、法的条項、コードには、ブロックをそのまま保つ構造を考慮したルールが必要です。Markdownの表や関数本体を単純に文字やトークンで途中から分割すると、値が列見出しから離れたり構文が壊れたりして、使えないチャンクができます。可能な限りコードブロック、表、リストを丸ごと保ち、単一のブロックがモデルの制限を超える場合にのみ、構造を考慮した代替方法を適用します。
メタデータをチャンクの埋め込みに含めるべきか？
メタデータを埋め込み対象のテキストに含めるかは、フィールドによって異なる設計上の選択です。段落が見出しからコンテキストを得ている場合、文書タイトルやセクションの見出しパスをチャンクのテキストの先頭に追加すると、検索が改善されることがよくあります。生の識別子、タイムスタンプ、アクセスラベルは、埋め込みの類似度を損なわないよう、フィルター可能な別のメタデータフィールドに保持すべきです。
元文書が変更されたらどうなるか？
元文書が変更されたら、取り込みパイプラインはその文書を再分割して再度埋め込み、古いチャンクIDをインデックスから廃止する必要があります。更新済みのチャンクとともに古いチャンクを有効なままにすると、検索システムが古いポリシーや矛盾するパッセージを提示し、インデックス管理の見落としが最終回答の事実誤認につながります。
