第3章 — アドバンスト・チャンキングのフレームワーク
LLM Primer III: RAGで強化するエンタープライズAI を章ごとに紹介していくウォークスルー、第3回です。素朴な選択が下流のすべてをもっとも静かに劣化させる場所と、最近の2つの手法がフロンティアで何を変えたか。
この章がなぜあるのか
文書がパースされたあと、次の判断はもっとも結果に効く判断でもあります — どう分割すれば、埋め込められるほど小さく、それ単独でまだ意味を持つほど大きいか。これがチャンキングです。定義から限定句を切り離すチャンクは、自信を持って検索され、間違えます。無関係な5つの話題を束ねたチャンクは、自分が触るすべての埋め込みを薄めます。その上に作る検索システムは、チャンキングが残したものしか復元できません。そして失敗モードはここでも静かです — 検索器は候補を返し続け、モデルは流暢に答え続け、ユーザーだけが微妙な誤りに気づきます。
3.1 チャンキングのスペクトラム
戦略を「文書について何を知っているか」の順に並べると分かりやすくなります。一方の端、固定長チャンキング は何も知りません — トークンを数えて切る。速く、決定的で、文体的に均一な短文(チャットの書き起こし、FAQ、レビュー)には許容できます。構造化された技術文書では静かな災害です。再帰的チャンキング は、優先度つきの区切り — 段落、改行、文、単語 — のリストを適用し、目標サイズに収まる最優先の境界で切ります。ほぼ固定長と同じくらい安く、実質的に良くなる。多くのチームにとって、これが正しい既定値です。
セマンティック・チャンキング は判断を構文から意味に移します — 各文を埋め込み、列を歩きながら、隣接文の類似度が閾値を割った点をトピックの境界にする。構造的手がかりが弱い長文の散文(アナリストレポート、インタビュー書き起こし)では効きますが、密な相互参照や繰り返しの定型文が文の埋め込みを混乱させる構造化技術文書では悪く出ます。構造認識チャンキング は、パースされた文書を木と見て、それに沿って切ります — 節ごと、見出しのレベルごと、コード関数ごと。うまくやればもっとも忠実な形ですが、レイアウト認識パーサーが上流にないと、構造そのものが抽出されておらず、再帰的チャンキングと変わらない結果になります。この4つは併用ではなく、選択肢の関係です。
3.2 オーバーラップの神話と「コンテキストの崖」
ほぼすべてのチュートリアルが、15〜20% のチャンクオーバーラップを推奨します。直感は範囲内では正しい — オーバーラップは境界での損失を防ぐ — のですが、曲線はすぐに平らになります。最初の10% でほとんどの利得が回収される。25% を超えるとほぼ平坦で、コストは3軸で増えます。埋め込みの請求はチャンク数に線形、インデックスサイズとクエリレイテンシは増え、検索器の上位結果は互いにほぼ重複しはじめる。ユーザーのクエリがA、B、Cで同じ箇所にマッチし、コンテキスト窓は新しい情報なしに消費され、リランカーは同一内容の異本を並べ替えることに予算を使う。30〜40% のオーバーラップを欲しくなったら、それはチャンカーが間違っているサインで、オーバーラップが足りないサインではありません。
関連するけれど別物が コンテキストの崖 です — チャンクから、それを見つけられるようにしていたアンカー語が落ちたときに起きる、検索品質の急落のことです。「2023年改訂のPolicy 47-Bは、全支店に〜を求めた」で始まり、要件が続く段落を想像してください。冒頭のあとで切ると、要件を述べたチャンクには「ポリシー」も「改訂」も「年」もありません。それは無関係なクエリに対して自信を持って引かれ、正しいクエリでは外れます。検索は top-k で、チャンクは浮上するかしないかの二択 — 段階的な劣化はありません。代名詞や略形が前出を運ぶ技術コーパスでは、これが支配的な失敗モードです。
3.3 クエリの種類にチャンクサイズを合わせる
チャンクサイズはしばしば「唯一の正解」があるかのように議論されますが、ありません。正解はシステムが受け取るクエリ次第です。事実型のクエリ — 「2024年の Policy 47-B の自己負担額は?」 — は 150〜300 トークンを欲しがります。曖昧さを除けるくらい狭く、しかし広い。推論型のクエリ — 「2023年版と2024年版の差をまとめ、更新にどう影響するか説明して」 — は、節内の結合組織を保つために 800〜1,200 トークン欲しい。最適サイズは両者で4〜8倍違い、本番のトラフィックはたいてい混在します。
実りのある対応は2つ。多粒度インデックス は同じコーパスを複数のチャンクサイズで保ち、意図分類でクエリを振り分けます。階層的検索 は精度のために小さなチャンクをインデックスしつつ、コンテキストのために親節を返します — インデックスは1つ、クエリ時に条件付けする方式で、意図分類が外れても段階的に劣化するので本番では主流です。親文書パターンは、本番検索の文献でもっとも価値の高い技法のひとつです。
3.4 コンテクスチュアル・リトリーバルとレイトチャンキング
フロンティアでの認識は、「チャンク」と「埋め込み」は分離可能な関心事だ、ということです。最近の2つの手法が、その分離を逆方向に活かします。コンテクスチュアル・リトリーバル は、2024年に Anthropic が広めた手法で、各チャンクと文書全体を安価な LLM に渡し、そのチャンクが文書のどこに位置するかを1〜2文で書いてもらいます — 「このチャンクは、Policy 47-B への2024年改訂で導入された自己負担計算の変更を論じている」 — そしてそれを埋め込み前にチャンクテキストに前置きします。チャンクは、その本文が名指ししなかったクエリでも見つかるようになります。Anthropic の評価では検索失敗が約49%減、ハイブリッド検索とリランキングを重ねるとさらに改善という報告です。経済性を成立させるトリックはプロンプトキャッシュ — 文書は1回送り、各チャンクをキャッシュ済み版に対して処理します。
レイトチャンキング は、2024年に Jina AI が紹介した手法で、同じ問題を反対側から攻めます。文書全体を長文脈の埋め込みモデルに1回通し、文書全体に渡ってすでに文脈化されたトークン単位の埋め込みを得る。そのあとで 文書をチャンクし、各チャンクの埋め込みは、文脈化済みのトークンからプールする。追加のLLM 呼び出しはなく、埋め込みは暗黙に文書レベルの文脈を継承します。制約は、埋め込みモデルがネイティブで対応していること(jina-embeddings-v3/v4 や一部の研究モデルが対応)と、文書がモデルの窓に収まることです。収まる文書なら、レイトチャンキングはコンテクスチュアル・リトリーバルに迫りつつ、インデックス時のコストはずっと低い。収まらない文書では、コンテクスチュアル・リトリーバルのほうが汎用です。両者は排他ではなく、本番では重複除去を挟んで併用するシステムもよく見ます。
第3章を踏まえて
チャンキングはパース済み文書を、検索可能な単位の集団に変えます。各単位はどこかに棲む必要があります — 保存され、インデックスされ、低レイテンシでクエリされ、コーパスの変化につれて更新される。その「どこか」がベクトルデータベースで、その選択はチャンキングの選択とは性格が違います。チャンキングはソフトウェアコストのあるソフトウェア問題。データベース選定は、インフラ・運用・規制の帰結を持つソフトウェア問題で、誤った選択は6ヶ月かけて巻き戻すこともあります。
次回 — 第4章: 適切なベクトルデータベースの選定。 専用設計か拡張型か、マネージドの主役、オープンソースの陣営、そして実際の選択を決める3軸 — レジデンシー、運用、総コスト。
