Late Chunking
レイトチャンキングがどのようにコンテキストを意識した埋め込みを作成し、検索とRAGの精度を向上させ、関連するテキストチャンク全体でドキュメントの意味を保持するかを学びます。
Late chunkingは、小さなセクションの埋め込みを生成する前に長文をエンコードすることで、周囲のコンテキストを維持するドキュメント埋め込みのテクニックです。最初にテキストを分割して各チャンクを個別に埋め込むのではなく、ロングコンテキストモデルを使用してコンテキストを認識したトークン表現を作成し、各チャンクに属するトークンを別々のベクトルにプールします。結果として得られるembeddingsは、より広いドキュメントからの情報を保持したまま、検索に適した状態を維持します。
Late Chunkingの仕組み#
従来の検索パイプラインは通常、分割、エンコード、保存という順序に従います。これは効率的ですが、孤立したチャンクには、何指しているのかを特定せずに「このコンポーネント」「この結果」「それが失敗した」といったフレーズが含まれる場合があります。
Late chunkingでは順序が変わります。
- ドキュメントはtokensに分割され、同時に目的のチャンク境界が記録されます。
- 完全なトークンシーケンス、またはモデルのcontext windowに収まる最大の部分が、ロングコンテキストtransformerを通過します。
- モデルのattention mechanismを介して、各トークン表現はそのコンテキスト内の他のトークンからの情報を統合します。
- トークンベクトルは記録された境界に従ってグループ化され、通常は平均プーリングによって結合され、チャンクごとに1つの埋め込みが生成されます。
重要な違いはタイミングです。境界は存在しますが、事前ではなくコンテキストエンコーディングの適用後に適用されます。Jina AI explanation of late chunkingは、これら2つの処理順序の視覚的な比較を提供します。
コンテキストの維持が重要な理由#
チャンキングはドキュメントをモデルの制限に合わせるのに役立ち、検索システムが正確なパッセージを検索できるようにします。Microsoft’s document chunking guidanceは、単一のベクトルで大きなドキュメント全体を表すと、多すぎるアイデアが単一の表現に圧縮されすぎる可能性があると指摘しています。
しかし、小さなチャンクはコンテキストが失われるリスクを高めます。次の隣接するパッセージを検討してください。
- 「XR-12ポンプは冷却マニホールドの横に設置されています。」
- 「10,000稼働時間後に交換する必要があります。」
独立して埋め込まれた場合、2番目のパッセージは「それ」が何を意味するかを特定しません。Late chunkingを使用すると、そのトークン表現はすでに「XR-12ポンプ」にアテンションを向けているため、「XR-12ポンプはいつ交換する必要がありますか？」などのクエリに対してパッセージがより有用になります。
Late chunkingはretrieval-augmented generationに特に関連しており、選択されたパッセージが言語モデルにグラウンディングコンテキストを提供します。より広いGoogle Cloud RAG overviewでは、検索が埋め込み、ベクトル検索、グラウンディングされた生成をどのように接続するかを説明しています。
関連するチャンキングと検索の手法#
Late chunkingは、同様の名前を持ついくつかの手法とは異なる問題を解決します。
- **Semantic chunking**は、意味の変化に基づいて境界を選択します。Late chunkingはコンテキストエンコーディングが発生するタイミングを決定するため、これら2つのテクニックを組み合わせることができます。
- **Contextual retrieval**は、インデックス作成の前に、追加の説明テキストやメタデータでチャンクを豊かにします。代わりに、Late chunkingはトークン表現を介して暗黙的にコンテキストを転送します。
- Chunk overlapは、隣接する境界付近のテキストを繰り返します。ローカルの手がかりを保持することはできますが、インデックスサイズが増加し、重複した結果を作成する可能性があります。Cohere’s chunking strategy guideでは、チャンクのサイズとオーバーラップが検索にどのように影響するかについて説明しています。
- Late interactionは、複数のトークンレベルのベクトルを保存し、検索中にそれらを比較します。Late chunkingは通常、チャンクごとに1つのプールされたベクトルを保存するため、従来のvector databaseと互換性があります。
リランカーも同等ではなく補完的です。初期検索後に取得された候補を並べ替えます。これは、Google Cloud ranking workflowによって示されています。
実践的な実装#
一部の埋め込みAPIは、late chunkingを直接公開しています。次のリクエストは、1つのドキュメントからの順序付けられたパッセージをJina Embedding APIに送信し、各パッセージに対して1つのコンテキスト埋め込みを返します。
import os
import requests
chunks = [
"The XR-12 pump is installed beside the cooling manifold.",
"It must be replaced after 10,000 operating hours.",
]
payload = {
"model": "jina-embeddings-v3",
"task": "retrieval.passage",
"late_chunking": True,
"input": chunks,
}
headers = {"Authorization": f"Bearer {os.environ['JINA_API_KEY']}"}
response = requests.post(
"https://api.jina.ai/v1/embeddings",
headers=headers,
json=payload,
timeout=30,
)
response.raise_for_status()
print(len(response.json()["data"]))出力数は入力チャンクの数と一致しますが、各ベクトルは共有されたドキュメントコンテキストを反映しています。代替の自己管理型ワークフローでは、完全なトークンシーケンスをエンコードし、後でスパンをプールします。これは、Elasticのlate chunking implementation for vector searchで示されています。
実際のアプリケーションとガイダンス#
2つの実用的なアプリケーションは、このコンテキストが重要である場所を示しています。
- テクニカルナレッジアシスタント: 製品マニュアルでは、パーツを一度紹介し、後で間接的に言及することがよくあります。Late chunkingは、同様の汎用言語を含む別のパッセージではなく、サポートシステムが正しいメンテナンスステップを検索するのに役立ちます。
- computer vision and RAG workflowなどの**Computer vision report search:**では、検出、検査ノート、キャプション、メンテナンス記録を組み合わせることができます。Ultralytics YOLO26が機器や欠陥を検出した後、late chunkingにより、関連するテキストレポート全体の検索が向上します。ビジュアルレコードは、image similarity search workflowを使用して探索することもできます。
ドキュメントにクロスリファレンス、代名詞、定義、または物語の依存関係が含まれている場合は、late chunkingを使用します。関連するチャンクをドキュメントの順序に維持し、埋め込みモデルのコンテキスト制限を尊重し、見出しとソースメタデータを保持し、現実的なクエリで検索を評価します。より多くのトークンが一緒に処理されるためエンコーディングコストが増加するため、短くて自己完結型のレコードでは、独立したチャンクの埋め込みが好ましい場合があります。
