告别传统的文档切块！JinaAI提出Late Chunking技巧

处理大规模数据建索引的时候，文档分块几乎是绕不开的一步。通常的做法是先把文档切成短块，比如每块512个token，然后分别做向量化。这么做在过去很合理——一方面受限于早期BERT模型的处理长度，另一方面大家也普遍认为，文本越长、信息越杂，一个向量就越难精准表达它的核心语义。

但有意思的是，如果你一直跟踪向量模型的变化就会发现，无论是开源阵营的BGE系列，还是闭源API，都在拼命把上下文长度往大里做，8192甚至更长已经成了常态。这就引出一个很自然的追问：如果工业界只需要512长度的向量模型，那大家为什么还要费劲去搞8192？说到底，长上下文的需求是真实存在的，只不过传统分块方式把这条路径堵死了。

传统的固定长度切块，带来的最大问题是上下文断裂。说个很常见的场景：一个句子的主语出现在段落开头，后面跟着几句用"It's"、"The city"这类代词来指代前文的表述。等你把段落一切，后面那个句子单独拎出来，主语信息就彻底丢了，简直就是断章取义的标准操作。这种语义上的“掉线”对搜索和召回的打击是致命的。

JinaAI最新提出的“Late Chunking”方法，思路恰恰相反——先把尽可能长的文本一股脑儿喂给嵌入模型，在输出层为每个token生成向量表示，这时候每个向量都已包含了整个文本的上下文信息。然后再根据需要，按照指定的块大小对向量进行聚合，从而得到每个chunk的embedding。这个做法的妙处在于：既用上了长上下文模型的全部能力，又没有因为块太大而让信息过载，最终影响向量表征的质量。

从测试结果来看，Late Chunking在所有场景下都比传统分块方式有提升，召回率ndcg@10的改善非常明显。某些情况下，它的表现甚至比把整篇文档编码成单个嵌入还要好。而且越长的文档，Late Chunking带来的收益就越显著——这其实也好理解，文本越长，传统切块丢失的上下文信息就越多，反过来说，Late Chunking对上下文信息的利用效率也就越高。