Late Chunking
了解晚分块如何创建上下文感知嵌入、提高检索和 RAG 准确性，并在相关文本块之间保留文档含义。
Late chunking 是一种文档嵌入技术，它通过在为较小片段生成嵌入之前对长文档进行编码来保留周围的上下文。它不是先分割文本并独立嵌入每个块，而是使用长上下文模型来创建具有上下文感知能力的标记表示，然后将属于每个块的标记汇聚成一个单独的向量。由此产生的 embeddings 既适合检索，又携带了更广泛文档中的信息。
Late Chunking 的工作原理#
传统的检索流水线通常遵循以下顺序：分割、编码、存储。这虽然高效，但一个孤立的块可能包含诸如“该组件”、“此结果”或“它失败了”之类的短语，却没有指明它们指的是什么。
Late chunking 改变了这个顺序：
- 文档被划分为 tokens，同时记录其所需的块边界。
- 完整的标记序列，或适合模型 context window 的最大部分，通过一个长上下文 transformer。
- 通过模型的 attention mechanism，每个标记表示都结合了该上下文中其他标记的信息。
- 标记向量根据记录的边界进行分组并组合，通常通过平均池化（mean pooling）来为每个块产生一个嵌入。
关键区别在于时机：边界仍然存在，但它们是在上下文编码之后而不是之前应用的。Jina AI explanation of late chunking 提供了这两种处理顺序的直观对比。
为什么上下文保留至关重要#
分块有助于文档适应模型的限制，并使搜索系统能够检索精确的段落。Microsoft’s document chunking guidance 指出，用一个向量表示整个大型文档也可能会把太多的想法压缩到单一的表示中。
然而，较小的块会增加上下文丢失的风险。考虑以下相邻段落：
- “XR-12 泵安装在冷却歧管旁。”
- “运行 10,000 小时后必须更换。”
如果独立嵌入，第二段无法识别“它”意味着什么。通过 late chunking，其标记表示已经关注了“XR-12 泵”，从而使该段落对于诸如“什么时候应该更换 XR-12 泵？”之类的查询更有用。
Late chunking 与 retrieval-augmented generation 尤其相关，其中选定的段落为语言模型提供基础上下文。更广泛的 Google Cloud RAG overview 解释了检索如何连接嵌入、向量搜索和基准生成。
相关的分块和检索方法#
Late chunking 解决了与几种名称相似的技术不同的问题：
- Semantic chunking 根据含义的变化选择边界。Late chunking 决定了上下文编码发生的时间，因此这两种技术可以结合使用。
- Contextual retrieval 在索引之前使用额外的解释性文本或元数据丰富块。Late chunking 则是通过标记表示隐式传递上下文。
- Chunk overlap 重复相邻边界附近的文本。它虽然可以保留局部线索，但会增加索引大小并可能产生重复结果。Cohere’s chunking strategy guide 探讨了块大小和重叠度如何影响检索。
- Late interaction 存储多个标记级别的向量并在检索过程中进行比较。Late chunking 通常为每个块存储一个汇聚向量，使其与传统的 vector database 兼容。
重排器（reranker）也是互补的而非等效的：它在初始搜索后对检索到的候选对象进行重新排序，正如 Google Cloud ranking workflow 所图示的那样。
实际实施#
一些嵌入 API 直接公开了 late chunking。以下请求将来自一个文档的有序段落发送到 Jina Embedding API，并为每个段落返回一个上下文嵌入：
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 中所演示的那样。
实际应用与指导#
两个实际应用展示了这种上下文的重要性所在：
- 技术知识助手： 产品手册通常会先引入一个部件一次，然后在后面间接引用它。Late chunking 有助于支持系统检索正确的维护步骤，而不是包含相似通用语言的另一个段落。
- 计算机视觉报告搜索： computer vision and RAG workflow 可能会结合检测、检查说明、标题和维护记录。在 Ultralytics YOLO26 检测到设备或缺陷后，late chunking 可以改善整个关联文本报告的检索。还可以使用 image similarity search workflow 探索视觉记录。
当文档包含交叉引用、代词、定义或叙事依赖关系时，请使用 late chunking。在文档顺序中保持相关的块，遵守嵌入模型的上下文限制，保留标题和源元数据，并使用现实的查询评估检索。它会增加编码成本，因为更多的标记会被一起处理，因此对于简短、自包含的记录，独立的块嵌入可能仍然是首选。
