今回の論文
今回取り上げるのは、Michael Günther、Isabelle Mohr、Daniel James Williams、Bo Wang、Han Xiao による論文「Late Chunking: Contextual Chunk Embeddings Using Long-Context Embedding Models」です。初出は 2024 年 9 月の arXiv で、研究分野は情報検索、RAG、埋め込みモデルです。URL は https://doi.org/10.48550/arXiv.2409.04701 です。
この論文を選んだ理由は、RAG や社内検索で誰でも一度はぶつかる「チャンクに分けた瞬間に文脈が切れる」という問題を、かなり実装しやすい方法で改善しているからです。新しい巨大モデルを前提にせず、既存の長文埋め込みモデルの使い方を変えるだけで効くので、開発現場に持ち込みやすい技術です。
どんな技術か
Late Chunking は、文書を最初に小さく分割してからそれぞれを別々に埋め込むのではなく、まず長い文書全体を一度 Transformer に通し、そのあとでチャンクごとに埋め込みを切り出す手法です。
RAG では通常、長い文書を数百トークン単位のチャンクに分け、各チャンクを独立にベクトル化します。ただしこのやり方だと、「その会社」「この都市」「前述の手法」のような参照表現が、別のチャンクにある主語や前提を失ってしまいます。Late Chunking は、各トークンが全文の文脈を見たあとでチャンク埋め込みを作るので、こうした文脈切れを減らせます。
一言でいえば、チャンク検索の粒度は保ちつつ、埋め込みの意味理解だけは文書全体のコンテキストを使う、という技術です。RAG の精度を上げたいが、マルチベクトル検索や追加 LLM 補助までは入れたくない場面で特に相性がよいです。
課題
この技術が解決しようとしているのは、検索や RAG で「小さく分けたほうが検索しやすいが、小さく分けるほど意味が欠けやすい」という矛盾です。
何が難しいのかというと、埋め込み検索は一般に短いテキスト片のほうが検索対象として扱いやすい一方で、実際の情報は複数文や段落をまたいで意味が成立することが多いからです。たとえば仕様書、議事録、FAQ、法務文書、論文では、ある文が何を指しているかは前の段落を読まないと分かりません。
既存の方法では、固定長チャンク、文単位チャンク、オーバーラップ付きチャンク、セマンティックチャンクなどが使われます。しかし、どれも基本的には「分割してから埋め込む」ため、各チャンクの埋め込みは周辺文脈を十分には持てません。オーバーラップを増やせば多少改善できますが、保存ベクトル数が増え、重複ノイズも増えます。
なぜこの課題を解く必要があるのかというと、RAG の失敗はモデル本体の性能不足より前段の検索ミスで起きることが多いからです。検索対象に「正しい情報を含むチャンク」があっても、そのチャンク単体では意味が弱く、検索に引っかからないことがあります。社内ナレッジ検索、契約書検索、FAQ ボット、開発ドキュメント検索では、この取りこぼしが回答品質を大きく下げます。
つまり Late Chunking は、チャンクサイズ最適化の話ではなく、チャンク埋め込みの意味表現そのものを文脈付きにすることで、検索の入口精度を上げようとする技術です。
用語解説
- 埋め込みモデル
- テキストをベクトルへ変換し、意味の近さを距離で比較できるようにするモデルです。Late Chunking はこの埋め込みモデルの中でも、長文を一度に処理できるモデルを前提にしています。
- Mean Pooling
- 各トークンの表現ベクトルを平均して、ひとつの埋め込みベクトルを作る方法です。Late Chunking は Transformer の出力トークン列を先に作り、その一部分だけを平均してチャンク埋め込みを得るので、この pooling の位置が本質になります。
- チャンク分割
- 長い文書を検索や RAG のために小さな単位へ分割する処理です。この論文ではチャンク分割自体をやめるのではなく、チャンクを決めるタイミングを「埋め込み前」から「埋め込み後」にずらします。
- 長文コンテキスト埋め込み
- 数千トークン規模の入力を扱える埋め込みモデルです。Late Chunking は、チャンク単位ではなく文書全体をいったん読ませるため、長文コンテキストに強い埋め込みモデルがあることが前提になります。
- nDCG@10
- 検索上位 10 件の順位品質を測る評価指標です。関連文書が上位に来るほど高くなります。この論文では、Late Chunking が実際に検索順位を改善したかを測る中心指標として使われています。
技術の仕組み
Late Chunking の基本アイデアはかなりシンプルです。普通は「文書を分割してから各チャンクを埋め込む」ところを、「文書全体を埋め込んでからチャンク境界ごとに平均プーリングする」に変えます。
基本アイデア
通常の naive chunking では、チャンク A とチャンク B は完全に別入力としてモデルに入ります。そのため、チャンク B の中に「それ」「この会社」「その都市」と書かれていても、チャンク A にある参照先を見られません。
Late Chunking では、まず全文をトークン化し、長文埋め込みモデルの Transformer 部分に通します。すると各トークンの表現は、文書全体を見たうえで更新されます。そのあとで、あらかじめ決めておいたチャンク境界に従ってトークン列の一部を取り出し、各チャンクの埋め込みを mean pooling で作ります。
これにより、保存する単位は従来どおりチャンクですが、各チャンクのベクトルには全文由来の文脈が入りやすくなります。
処理の流れ
Late Chunking の流れは次のようになります。
1. チャンク境界を先に決める
固定長、文単位、セマンティックチャンクなど、どの分割戦略を使ってもかまいません。重要なのは、ここではまだ分割後テキストを別々にモデルへ入れないことです。境界情報だけを持っておきます。
2. 文書全体を一度にエンコードする
全文をトークン化し、長文対応の埋め込みモデルへ通します。論文では jina-embeddings-v2-small、jina-embeddings-v3、nomic-embed-text-v1 などを使っています。ここで得られるのは、文書全体の文脈を反映したトークン表現列です。
3. チャンク境界に合わせて span を切り出す
チャンクは文字列として定義されることが多いため、各チャンクがトークン列のどこに対応するかを位置情報で求めます。論文では、トークンごとの文字長を使ってチャンク開始位置と終了位置をトークン列上へ写像しています。
4. 各チャンクだけを平均プーリングする
全文トークン列のうち、対象チャンクに対応する範囲だけを平均し、そのチャンクのベクトルにします。これが Late Chunking の核心です。全文の情報を見たトークンから、局所チャンクのベクトルを作るため、局所性と文脈性を両立できます。
Long Late Chunking
文書がモデルの最大コンテキスト長を超える場合は、そのまま全文を一度に入れられません。そこで論文では Long Late Chunking も提案しています。
これは、複数チャンクを含む大きめのマクロチャンクを作り、隣接マクロチャンクにオーバーラップを持たせながら個別にエンコードする方法です。小チャンク単位の意味は保ちつつ、周辺文脈もある程度引き継げるので、超長文でも Late Chunking の発想を維持できます。
学習なしでも使える設計
この手法の実務上の強みは、追加学習なしで導入できることです。論文でも、既存の長文埋め込みモデルにそのまま適用して改善が出ています。
さらに著者らは、Late Chunking 向けに span pooling ベースの追加学習方法も提案しています。これは、文書全体を見たトークン列のうち「関連スパンだけを平均する」訓練を行い、文脈を含んだチャンク表現をよりうまく作れるようにする方法です。ただし、記事として押さえるべき主役は、まず学習なしで効く Late Chunking 自体です。
実験と結果
論文では、Late Chunking が本当に検索品質を改善するか、どんなチャンクサイズで効くか、超長文にも効くか、追加学習でさらに伸びるかを段階的に検証しています。
何を検証したのか
主な検証ポイントは 4 つです。1 つ目は、naive chunking を late chunking に置き換えるだけで検索精度が上がるかです。2 つ目は、固定長や文単位など分割方法が違っても効果が出るかです。3 つ目は、長文でコンテキスト長を超える場合に Long Late Chunking が有効かです。4 つ目は、span pooling による追加学習でさらに改善できるかです。
ベンチマーク設定
検索評価には BeIR の小規模タスク群を使い、SciFact、NFCorpus、FiQA、TREC-COVID で nDCG@10 を比較しています。モデルは jina-embeddings-v2-small、jina-embeddings-v3、nomic-embed-text-v1 の 3 系統です。チャンク境界は、256 トークン固定長、5 文単位、セマンティックチャンクの 3 種類で検証されています。
検索精度はどう改善したか
論文の Table 2 では、naive chunking を late chunking に変えると、平均で一貫して改善しています。著者らの集計では、4 データセットと 3 モデルの平均で、文単位チャンクでは相対 3.63% 改善、固定長チャンクでは相対 3.46% 改善、セマンティックチャンクでも相対 2.70% 改善でした。絶対値でもそれぞれ 1.9、1.8、1.5 ポイントの改善です。
個別に見ると、たとえば固定長 256 トークンでは、jina-embeddings-v2-small の NFCorpus が 23.5 から 30.0 へ上がっています。jina-embeddings-v3 の TREC-COVID では 73.0 から 77.2、FiQA では 46.3 から 47.6 へ改善しています。すべてのセルが大幅改善ではありませんが、全体として「文脈を失いやすいチャンク検索」で安定して効いているのがポイントです。
小さいチャンクほど効きやすい
チャンクサイズを変えた実験では、Late Chunking は特に小さめのチャンクで有利でした。これは直感的にも自然で、チャンクが小さいほど局所テキストだけでは意味が不足しやすいためです。
一方で論文は、どんなデータでも常に優位だとは言っていません。LongEmbed 系の一部読解データセットでは、大きいチャンクのとき naive chunking のほうが良い場合もありました。著者らは、文書全体の文脈がほぼ無関係で、特定の一文だけを見つければよい synthetic データでは、追加文脈がむしろ役に立たないと説明しています。
超長文では Long Late Chunking が効く
8192 トークンを超える文書では、通常の Late Chunking だけでは全文を一度に見られません。そこで Long Late Chunking を使うと、論文では truncation ありの設定より高い nDCG を出し、超長文でも有効だと示しています。これは、長文 RAG でありがちな「前半しか見ていない」問題への対処として実務上かなり重要です。
追加学習の効果
span pooling による追加学習は、効果は大きすぎないものの、小さく安定した改善を出しています。たとえば jina-embeddings-v3 では、FiQA が 47.40 から 48.22、TREC-COVID が 77.21 から 77.59 へ改善しています。jina-embeddings-v2-small でも、FiQA が 33.87 から 34.52 へ上がっています。
この結果から言えるのは、Late Chunking はまず推論時の工夫だけで価値があり、そのうえで用途が固まったら追加学習で少しずつ詰める余地もある、ということです。
何に使える？
Late Chunking は RAG 専用の小技ではなく、「文書の局所断片を検索したいが、意味理解には全文文脈が必要」という場面全般で使えます。
社内ナレッジ検索
議事録、設計書、手順書、障害報告書では、代名詞や略称が頻繁に出ます。Late Chunking を使うと、各チャンクが前後文脈を踏まえたベクトルになるので、「その件」「本対応」「前回リリース」などの曖昧な表現を含む断片も拾いやすくなります。
RAG の検索前段改善
LLM の回答品質を上げたいとき、まず効くのは生成モデルの交換より検索精度の改善です。Late Chunking はインデックス設計の変更で導入できるので、回答モデルはそのままに、検索ヒット率だけを上げたいケースに向いています。FAQ ボット、法務アシスタント、社内ヘルプデスクなどで特に有効です。
契約書・法務・規程検索
法務文書では、「当該契約」「本条」「甲」「乙」のように参照関係が多く、単独チャンクだと意味が薄くなりがちです。Late Chunking はこの種の文書と相性がよく、条文単位で検索したいが全文の文脈も持たせたいときに使えます。
開発ドキュメントや API 仕様検索
技術文書では、後続の節で「この設定」「このフラグ」「前述のエンドポイント」が登場します。Late Chunking は、章構造をまたぐ前提をチャンク埋め込みへ載せやすいので、開発者向け検索や AI コーディング支援の裏側にも応用しやすいです。
追加 LLM コストを避けたい contextual retrieval
論文では、Anthropic の Contextual Retrieval のように、別の LLM で各チャンクへ補足文脈を付ける方法とも小規模比較しています。Late Chunking は追加 LLM を必要としないため、API コストや前処理時間を増やさずに文脈付き検索へ寄せたい場面で有力です。
開発や事業へのヒント
この論文から得られるヒントは、RAG 改善の打ち手は「chunk size をどうするか」だけではなく、「埋め込みを作るタイミングをどう変えるか」にもあるということです。
まずはチャンク戦略より埋め込み戦略を疑う
RAG の改善では、固定長を 300 にするか 500 にするか、オーバーラップを何文字にするか、といった調整に時間を使いがちです。しかし Late Chunking は、同じチャンク境界のままでも埋め込み生成方法を変えるだけで改善しうると示しています。既存の検索失敗が「意味の薄い断片」に起因しているなら、かなり筋が良い見直しポイントです。
既存基盤を壊しにくい
Late Chunking は、ベクトル DB や検索 API の形を大きく変えずに試せます。保存単位は従来どおりチャンクのままだからです。つまり、マルチベクトル検索や reranker 常用ほど構成を複雑化させずに、前段品質を引き上げられる可能性があります。
小規模プロダクトでも採用しやすい
巨大な追加学習をしなくても使えるため、PoC や小規模 SaaS に向いています。長文対応の埋め込みモデルさえ使えるなら、インデックス作成パイプラインを変えて AB テストしやすいです。特に問い合わせ履歴、業務マニュアル、仕様書など、文脈依存が強いデータを扱うサービスでは費用対効果を出しやすいはずです。
今後注目すべき方向性
今後の検索基盤では、「文書全体の文脈を保持しつつ、検索単位は細かく保つ」設計がさらに重要になるはずです。Late Chunking はその最小構成のひとつです。将来的には、Late Chunking、学習済み reranker、マルチベクトル検索、クエリ拡張をどう組み合わせるかが、RAG 品質の差になっていくと考えられます。ここは論文の直接検証範囲を超える実務的な推測ですが、技術の延長としてかなり自然です。
限界
Late Chunking にも明確な限界があります。まず、長文埋め込みモデルが必要なので、短文専用モデルやコンテキスト長が短いモデルではそのまま使えません。全文を一度に通すぶん、インデックス作成時の前処理コストも naive chunking より重くなりやすいです。
また、文書全体の文脈が常に有益とは限りません。論文でも、Needle-8192 や Passkey-8192 のように、長い無関係テキスト中の一点だけを探す synthetic タスクでは Late Chunking が有利ではありませんでした。つまり、文脈がノイズになるデータでは効きにくい可能性があります。
実装面では、文字単位のチャンク境界をトークン境界へ正しく対応づける必要があります。日本語や記号の多い文書、独自トークナイザを使う環境では、この位置合わせ実装が地味に重要です。
さらに、論文の追加学習は小さな改善に留まっています。したがって、検索品質の問題が埋め込み生成より reranking やメタデータ設計にある場合、Late Chunking だけで劇的に解決するとは限りません。導入時は、検索失敗例を人間が見て、どこで取りこぼしているのかを切り分ける必要があります。
よくある質問
Q. Late Chunking は普通のオーバーラップ付きチャンクと何が違うのですか？
A. オーバーラップはチャンク本文に前後の一部を複製する方法ですが、Late Chunking は全文を一度見たトークン表現からチャンク埋め込みを作ります。つまり、文脈を文字列として足すのではなく、文脈を反映した内部表現を使う点が違います。
Q. RAG でまず試す価値はありますか？
A. 文脈依存の強い文書を扱うなら試す価値は高いです。特に、「答えは入っているのに検索で拾えない」「代名詞や略称を含むチャンクが弱い」という症状があるなら、相性がよい可能性があります。
Q. どんなデータでは効きにくいですか？
A. 文書全体の文脈が不要で、特定フレーズをピンポイントで見つければよいデータでは効きにくいです。論文でも synthetic な needle-in-a-haystack 型タスクでは利点が小さいか、場合によっては不利でした。
Q. 追加学習しないと意味がありませんか？
A. いいえ。論文の主張の中心は、追加学習なしでも改善が出ることです。まずは既存モデルで Late Chunking を試し、必要なら span pooling ベースの追加学習を検討する順番が現実的です。
Q. ベクトル DB や検索基盤を大きく変える必要はありますか？
A. 基本的には不要です。保存するのは従来どおりチャンク単位のベクトルなので、主な変更点はインデックス生成パイプラインです。ただし、全文エンコードやトークン境界処理の実装は追加で必要になります。
今日の学び
この論文は、RAG や検索で文書を小さく分割すると文脈が切れ、正しい情報を含むチャンクでも検索に引っかからなくなる課題を扱いました。これに対して、全文を一度エンコードしてからチャンク埋め込みを作る Late Chunking により、局所チャンクに全文文脈を持たせる方法を示しました。
ここから得られるヒントは、検索品質を上げるにはチャンクの切り方だけでなく、埋め込みを作る順序そのものを見直す価値があるということです。RAG の改善で行き詰まったときは、モデル交換の前にこのレイヤーを疑うだけでも、かなり実務的な打ち手になります。