长文本 Embedding 模型中的“迟分”策略

时间回到2023年10月，我们推出了全球首个支持8K上下文长度的开源Embedding模型——jina-embeddings-v2-base-en。从那以后，长文本在Embedding模型中的应用，就一直是大家讨论的焦点，甚至激起了不少争议。

争议主要集中在几个点上：

1. 信息压缩问题
   ：把几千字的长文本压缩成一个单一的Embedding，这听起来就很“暴力”。这样做的后果就是，语义信息被过度压缩，检索系统很难精准定位到你想要的具体信息。

2. 检索粒度不足
   ：在很多实际应用，比如检索增强生成（RAG）系统里，我们需要的是文档中的某个片段，而不是整篇长篇大论。这种粗粒度的方式，很难满足精细检索的需求。

3. 短文本检索优势
   ：基于密集向量的检索系统，处理短文本时效果往往更好。原因很简单，短文本的语义信息更集中，更容易被准确编码和检索。

疑惑点来了：如果行业只认512上下文长度的Embedding模型，那费那么大工夫训练8192上下文长度的模型，图啥？

本文就来重新审视这个问题，重点探讨传统RAG流程（分块 -> Embedding）中的局限性。同时，还会介绍一种新的应对策略——

，它能在保留长文本Embedding模型优势的同时，满足更精细化的检索需求。

上下文丢失问题

传统的“分块-Embedding-检索-生成”这条流水线，在处理长文档时，常常会丢掉长距离的上下文依赖关系。这可不只是个技术细节，而是信息检索和理解中的一个大坑。换句话说，当关键信息分散在不同的文本块中，脱离了上下文的片段就像断线的风筝，往往会“变味”。

拿维基百科上一篇关于柏林的文章举例。如果我们把它切成一个接一个的句子块，你会发现“其”和“这座城市”这些指代词，实际上指代的是文章开头的“柏林”。

这意味着，如果你把长文按句子长度分块，RAG系统想回答“柏林的总人口是多少？”这种问题时，就会遇到麻烦。因为城市名和人口数据从来不会出现在同一个文本块里，而缺少了更大的上下文语境，后面的LLM处理起来也没法解决这种指代问题。

当然，也有一些启发式算法试图救场，比如滑动窗口重采样、用不同上下文窗口长度、多轮扫描文档等等。但就像所有启发式算法一样，这些方法只能说“时灵时不灵”。它们在某个场景下可能还行，但始终没有理论上的保障。

迟分让Embedding更懂上下文

在传统的文本编码中，我们常习惯用“预先分块”的策略：先分块，再过Embedding模型。也就是先根据句子、段落或预设的最大长度把文本切好，然后让Embedding模型一个个处理这些块，再通过平均池化等方法，把Token级别的Embedding拼成一个单一的块Embedding向量。就像下面这张图的左边所示：

左边是传统分块，右边是迟分策略。

但“迟分”策略的思路正好相反：先过Embedding模型，再分块。我们先把Embedding模型的Transformer层应用到整篇文本（或者尽可能多的连续文本上），为每一个Token生成一个包含丰富上下文信息的向量表示序列。然后，

与传统那种“各自为政”的独立同分布块Embedding不同，

。这意味着每个块都编码了比它自身多得多的上下文信息，编码质量和准确性自然也上了一个台阶。

必须承认的是，要充分发挥迟分的作用，得依赖一个能处理长上下文的Embedding模型，比如jina-embeddings-v2-base-en。它能一口气处理8192个token（差不多10页A4纸），基本覆盖了大多数长文本的上下文需求。

当然了，迟分也不是万能的，它同样需要边界线索来帮忙切分。但和传统方法不同，这些边界线索是在我们拿到Token级别的Embedding之后才用的，这也是“迟分”这个名字的由来。

	传统分块	迟分
边界线索需求	是	是
边界线索使用时机	预处理阶段	Transformer层处理后
块Embedding特性	独立同分布(i.i.d.)	有条件，编码更多上下文信息
邻近块上下文保留	易丢失，需启发式方法缓解	长文本Embedding模型能有效保留

迟分效果一览，定性评估案例

我们来看几个具体的例子。把迟分应用到前面提到的柏林维基百科示例上，能立刻看到语义相似性的提升。就拿“这座城市”和“柏林”的指代关系来说，用上迟分后，“这座城市”的向量表示成功捕捉到了它和“柏林”的关联，再跟涉及城市名称的查询匹配时，表现就强多了。

下面的表格是具体的数值对比，展示了“柏林”这个词的Embedding，跟柏林维基百科中各个句子的余弦相似度。很明显，迟分在提升语义相似性上，比传统分块强出一大截。

查询	块	传统分块下的相似性	迟分下的相似性
柏林	柏林是德国的首都和最大的城市，无论是面积还是人口都是如此。	0.849	0.850
柏林	其超过385万人口使其成为欧盟人口最多的城市，以市区人口计。	0.708	0.825
柏林	这座城市也是德国的一个州，在面积上是全国第三小的州。	0.753	0.850

BEIR实验验证，迟分效果显著

为了更全面地验证迟分的有效性，我们用BEIR里的检索基准做了一系列严谨的测试。测试涵盖查询集、文档语料库以及记录查询和文档关联信息的QRels文件。

评估过程是这样的：先把文档分块并编码到Embedding索引里，再通过k近邻（kNN）算法找最相似的块。然后，把块的kNN排名映射回文档排名，跟真实的排名对比，最后用nDCG@10等指标来评估。

我们在多个BeIR数据集上对传统分块和迟分做了对比。为了提取边界线索，用正则表达式把文本切成大约256个token的字符串。Embedding模型选的是jina-embeddings-v2-small-en，虽然是这款模型的“小号”，但依然具备8192-token的处理能力。

具体结果如下：

数据集	文档平均长度（字符）	传统分块（nDCG@10）	迟分（nDCG@10）	无分块（nDCG@10）
SciFact	1498.4	64.20%	66.10%	63.89%
TRECCOVID	1116.7	63.36%	64.70%	65.18%
FiQA2018	767.2	33.25%	33.84%	33.43%
NFCorpus	1589.8	23.46%	29.98%	30.40%
Quora	62.2	87.19%	87.19%	87.19%

从数据来看，迟分在多数情况下都优于传统分块，甚至在某些场景下击败了把整个文档编码成一个Embedding的做法。当然，也有例外，比如在一些数据集里，不分块反而拿到了最好的结果（不过这种情况在实际应用中很少见，而且通常我们都需要对块进行排名）。

再把传统分块和迟分的性能差距，跟文档长度关联起来分析，会发现一个有意思的规律：文档越长，迟分带来的nDCG得分提升就越明显。也就是说，

结论

这篇文章介绍了一种叫“迟分”的高效文本处理方法。它的核心，就是巧妙借助长上下文Embedding模型的优势，给短文本块注入丰富的上下文信息。我们清晰地看到了传统分块Embedding在保留上下文信息上的不足，以及由此带来的检索效果不佳的问题。

而迟分，正是对症下药的那剂良方。它以简单但极其有效的方式，在每个文本块里保持并调整上下文信息，显著提升了文本处理的准确性和效果。而且，文档越长，效果越好。这一切，都离不开像jina-embeddings-v2-base-en这样的高级长上下文Embedding模型的支持。希望这项工作不仅能验证长上下文Embedding模型的价值，也能激发更多围绕这一方向的研究。