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

大约一年前，2023 年 10 月，我们推出了全球首个支持 8K 上下文长度的开源 Embedding 模型 —— jina-embeddings-v2-base-en。自此，长文本在 Embedding 模型中的应用引发了广泛讨论和争议。

1. 信息压缩问题：将数千字的长文本编码为单一 Embedding 表示会导致语义信息的"过度压缩"，使得检索系统难以准确定位特定信息。

2. 检索粒度不足：许多应用，尤其是检索增强生成（RAG）系统，需要检索文档中的较小片段，而非整个长文档。

3. 短文本检索优势：基于密集向量的检索系统在处理短文本时通常表现更好，因为短文本的语义信息更容易被准确编码和检索。

一个典型的 RAG Pineline 包括：分块-Embedding-检索-生成。

那么，如果行业只需要具有 512 上下文长度的 Embedding 模型，那么训练 8192 上下文长度的模型又有什么意义呢？

在本文中，我们通过探讨 RAG 中传统分块 -> Embeddings 流程的局限性，来重新审视这个问题。同时，我们还引入了一种新策略，称为 迟分(Late Chunking)，能够在保留长文本 Embedding 模型优势的同时，也能满足精细粒度检索的需求。

上下文丢失问题

传统的分块 - Embedding - 检索 - 生成流程在处理长文档时可能会丢失长距离的上下文依赖关系，这对于信息检索和理解是一大隐患。换句话说，当关键信息散落在多个文本块中，脱离上下文的文本片段很可能失去其原有的意义，导致处理效果大打折扣。

以维基百科上的一篇关于柏林的文章为例，若将其分割为句子块，不难发现诸如“其”和“这座城市”等指代表达，实际上指向的是文章开头提到的“柏林