记得👇关注我，加星标★

🌟 你好呀，我是羽师，见字欢喜，感恩有你。

你有没有遇到过这种情况：

辛辛苦苦搭了一套 RAG 知识库，把所有文档切成小块，喂给向量数据库。结果用户搜“上次说的那个参数怎么调”，AI 要么找不到，要么答非所问。

你排查了 Embedding 模型，换了更大参数的版本，甚至把 Chunk Size 调了无数遍，效果还是忽好忽坏。

问题很可能不在模型本身，而在你切文档的方式。

今天聊一个能显著提升长文档检索质量的技术：Late Chunking（延迟分块）。读完你会发现，过去很多做法，从一开始就搞错了顺序。

一、传统切块，到底错在哪

我们把文字变成计算机能懂的向量，需要用到 Embedding 模型。

早期模型胃口很小，一次只能吃下 512 个 token。你手里一篇三千字的产品手册，必须切成 A、B、C 好几个小块，然后分别喂进去，每个块独立输出一个向量。

这就是传统做法，我管它叫 Early Chunking：先切块，后编码。

问题出在“独立”这两个字上。当模型处理 B 块时，它根本不知道 A 块说过什么，也不知道 C 块即将说什么。

举个例子。文档里有两段话：

张小明昨天买了一辆新车。他非常喜欢它的引擎声。

如果你的切块边界刚好把第二句话单独切出去，那么模型在处理这一块时，眼前只有孤零零的“他非常喜欢它的引擎声”。

“他”是谁？“它”又是什么？没有上下文，模型只能瞎猜。最终生成的向量，携带的信息是残缺的。

跨块的代词指代、因果逻辑、背景铺垫，在编码这一刻就彻底断裂了。后面你再怎么优化检索策略，也弥补不了向量本身的先天不足。

二、反过来做，奇迹就出现了

Late Chunking 的思路很简单：既然问题出在顺序上，那就把顺序倒过来。

先编码，后切块。

第一步，不是切文档，而是把整篇文档原封不动地丢给 Embedding 模型。假设模型支持 8192 token 的长上下文，那就让模型一口气读完。

模型内部有一个叫“注意力机制”的东西，它会让每个 token 在计算自己的向量时，看到全文所有其他 token 的信息。

于是“他”这个 token，因为前面出现过“张小明”，自动带上了“男性、具体是张小明”的含义。“它”也因为前面出现过“车”，明确指向那辆新车。

全文读完，模型会输出每一个 token 的向量。这些向量不再是孤立的词义，而是浸透了整篇文章的上下文。

到这一步，才开始切块。

按照之前定好的块边界，把落在同一个块里的所有 token 向量取出来，求一个平均值。这个平均值，就是这个块最终的向量。

你拿到的 B 块向量虽然只取了最后一句话的几个 token，但每个 token 内部已经融入了前文的信息。所以这个向量天然知道“他”是张小明，“它”是那辆新车。

切开的只是物理边界，上下文血脉依旧畅通。

三、一个比喻，让你彻底记住

传统做法像这样：

你有一本推理小说，要分给三个人去写摘要。你先动手把书撕成三叠，每人只拿着自己那叠去读。读第一章的人永远不知道凶手在第三章才暴露，他写出的摘要自然不可能包含全局线索。

Late Chunking 的做法是：

先让一个人通读全书，并且在每一页的空白处密密麻麻写满批注——这些批注是基于全书理解写下的。等他批注完全书，你才把书按章节裁开。虽然纸裁开了，但每一页的批注仍然保留着整个故事的伏笔。

你再把每章的批注浓缩成一小段总结，这段总结依然带着全局视角。

这就是“延迟”两个字的真正含义：把切块这个动作，从编码前推迟到编码后。

四、一张表看清本质

差别一目了然。

五、哪些场景非用 Late Chunking 不可

如果你手里的文档符合以下任何一种特征，Late Chunking 带来的提升会是立竿见影的。

第一类：长文档的精细化搜索

典型如企业知识库、技术手册、故障排查文档。用户常常用口语化、指代性的语言提问，比如“那个报错怎么处理”。传统分块经常把报错现象和解决方案切在不同块里，搜不到。Late Chunking 可以让方案块的向量自动关联上前面描述的现象。

第二类：多跳推理与跨段落实体关联

年报、财报里，前面定义了一个术语，后面直接用“该指标”“上述交易”来指代。Late Chunking 能保证每个块在编码时就带着这些定义的烙印，检索时不会因为指代断裂而漏掉关键信息。

第三类：法律合同、学术论文

几十页的合同，开头是长篇累牍的定义条款。如果先切块再编码，后面所有条款块的向量都会丢失“甲方”“许可范围”的真实指向。Late Chunking 让每一条款在向量空间里都天然带着全局定义。

第四类：叙事型长文本

小说、传记、对话记录，人物关系复杂，同一个人有多个称呼。Late Chunking 能让所有出现的“他”“那位先生”都正确绑定到具体人物，进行人物关系问答时优势巨大。

第五类：无法精确控制切块边界，但又依赖上下文的任务

现实中的文档格式千奇百怪，你永远做不到完美避开语义断裂的切分。Late Chunking 给你更高的容错率，即使切得不理想，每个 token 也早已看过全文，损伤相对小得多。

六、也不是万能药，这些地方别硬用

技术圈从来不缺拿着锤子找钉子的故事。Late Chunking 再好，也有它的能力边界。

短文本场景没必要上。 商品标题、问答对、单句话检索，本身就不怎么切块，或者切了也没有跨块依赖，老老实实用传统编码足够。

文档过长、超出模型窗口时无能为力。 Late Chunking 的前提是一次前向传播吃进全文。如果文档长度超出了模型最大上下文窗口，还是得先切，这时只能配合分层策略，无法完整发挥优势。

资源极度受限的环境要慎重。 保留全文所有 token 的中间向量需要额外显存和计算时间。在一些离线终端或者实时性要求极高的场景，可能会吃不消。

底层模型不支持长上下文，不要硬来。 窗口不够，输入会被截断，反而引入噪音。你得先确认模型能力，比如 Jina 的 jina-embeddings-v2 支持 8192 token，最近一些新模型甚至达到 32k 以上，这种才撑得起 Late Chunking。

七、写在最后

很多人花大量时间调 Chunk Size、调 Overlap、换检索策略，却很少去想：问题可能出在编码阶段就已经丢失了上下文。

Late Chunking 不是一个复杂的算法改进，它只是把处理顺序换了一下。但就是这一个顺序的交换，让每个块的向量从一座孤岛，变成了一张连接着全文信息的大网上的一个节点。

如果你正在做长文档的 RAG 应用，不妨试试：找一篇文档，用传统方式建库，再用 Late Chunking 建库，跑同一批真实用户的 Query，看看召回率的变化。很大概率，你会有惊喜。

技术选型永远不是为了炫技，而是为了解决真实的痛点。当你的文档天然具有跨块语义依赖，当你的用户习惯用指代、上下文提问，Late Chunking 就是你工具箱里不该绕过的那一件。

希望这篇拆解能让你对这个“延迟”二字有更立体的理解。有任何落地过程中的实际问题，欢迎在评论区交流，我们一起把这条路走得更清晰一些。

微信5000好友位将满👇

PS：因公众号平台更改了推送规则，如果不想错过内容，记得读完点一下“❤️推荐❤️”，加个“星标”，这样每次新文章推送才会第一时间出现在你的订阅列表里。
点“❤️推荐❤️”支持羽师,码字原创不易