概述

Jina在2024年推出了一种新的文本切分方法，在论文Late chunking: contextual chunk embeddings using long-context embedding models中做了系统阐述。

来源：https://jina.ai/news/late-chunking-in-long-context-embedding-models/对中文实现Late Chunking，本文应该是第一篇，本文尽可能简单地介绍这项工作的动机、原理以及中文实现，并对结果做一个分析。

动机

正常在撰写文章的过程中，使用一些代词是非常常见的，Jina指出，由于切分导致文本会切分到不同的片段中，而有些片段中只有代词而没有代词所指对象，这可能会导致检索失败。

例如下面的这段文本，比如文档按下图右侧的方式切分，用户的问题是“柏林有多少居民”，很明显使用第二个片段可以回答是3.85百万，但由于它使用的是Its，导致这个片段有可能是检索不到的，或者即使检索到了，大模型也没有办法明确知道Its指代的是Berlin。

所以说，此处给了我们一个论文思路，是不是可以在切分前，统一做一个指代消解，然后再切分，这样第二段就会变“Berlin’s more than 3.85 million inhabitants make it the European Union’s most populous city, as measured by population within city limits.” 这样检索时就不会有代词的问题了。感兴趣的朋友可以做个实验。

原理

RAG一般的流程是先做文本切分，然后再向量化，而Jina给出的解决方案正如其名——Late Chunking，它是先直接对整段文本做向量化，然后再切分。

具体是怎么做的呢，首先取知识库中的一整篇文档过Embedding模型，然后会得到一整篇文档每个token位置的Embedding向量，然后按照选取的切分方式，取特定范围的向量做平均，从而得到这个片段的Embedding向量。

例如“DeepSeek是由杭州幻方量化所成立的子公司所开发的大语言模型。它真的很强大！”，

我们假设这段话tokenize后是这样的：

[, , , , , , , , , , , , , , , , , , , , , , ]

共计23个token，对Embedding模型设置参数，输出每个问题的hidden state（也是个向量，也就是下图中的Token Embedding），如果维度是1024，那就意味着“DeepSeek”这个位置就会有一个1024维的向量，“是”这个位置也是一样。因为是作为一整个句子送入Embedding模型的，所以“它”这个token的hidden state其实融合了整个句子的信息，知道“它”其实指代的是DeepSeek。那如果我们按照句子切分，取“它真的很强”对应位置（上面19-23位置）的hidden state然后做平均，那平均后得到的向量其实表达的含义是“DeepSeek真的很强大”。

这里面涉及3个问题：

1. 为什么是取一整篇文档而不是整个知识库：因为实际情况几乎不会出现跨文档还使用代词指代的情况，Late Chunking要解决的是切分导致代词不知其所指的问题，取整个知识库拼接没有意义；

2. 所以最后是怎么切分的：Jina官方的代码仓库中有几种方法，分别是按语意、按句子、按token长度，切分之后片段的Embedding，是对片段切分点范围内的Token Embeddings取平均得到的；

3. 一整篇文档过Embedding模型不担心超长吗：所以此处Jina要求尽量使用支持长输入的Embedding模型，如果还是超长，那就按照Embedding模型支持的最大长度（例如8192）先切分，假设向量维度是1024，按8192切分后得到7个片段，最终把这7个片段的8192 个维度为1024的向量拼接起来，然后还是按2中提到的方法获取片段的Embedding。这里面其实涉及到很多操作问题，首先比如是按8192切分，其实是token的长度是8192，而不是句子长度，其次是切分后字符的索引要和token的索引对应，最后如果超过Embedding模型的最大长度，需要考虑模型的第一个位置是否有特殊字符，要把它移除。

结果

官方使用了“Berlin”作为Query，分别计算与下面3个句子的相似度。对这3个句子分别使用了两种方式做向量化，一种是传统的先切分再向量化，记为Traditional，另一种是Late Chunking。

第一个句子不存在指代不明的问题，所以两种方法计算的余弦相似度很接近，这个是符合预期的。

第二个句子中有代词Its、it，第三个句子中有The city，使用传统方式计算的余弦相似度就相对较低，而使用Late Chunking方式计算的余弦相似度比较高，这就体现出了Late Chunking的优势。

相似度高意味着什么，意味知识库比较大时，如果输入“柏林的常驻人口有多少”，使用Late Chunking第2个句子会排在候选中更靠前的位置，从而有更大的概率被召回，而传统方法则会排在比较靠后的位置。

效果

虽然动机看起来站得住脚，原理好像也说得通，但实验的结果却表现很差。后文会进行分析。此处不是完全控制变量实验，有两个变量，除了切分方法不同外，向量模型也不同，其余的生成模型、评估模型与其他实验保持一致。

核心代码

本文代码已开源，地址在：https://github.com/Steven-Luo/MasteringRAG/blob/main/split/05_late_chunking.ipynb

Late Chunking最核心的部分，其实不是切分动作在前还是在后，而是片段中的向量表示，要能融合上下文。源代码提供的是按照英文句子、token数等方式的切分，与中文习惯差异较大，所以本文中的实现还是按换行进行了切分，但每个片段的Embedding使用的是融合了整个文档语意信息的。

   (model, tokenizer, document, batch_size=):      tokenized_document = tokenizer(document, return_tensors=)      tokens = tokenized_document.tokens()        outputs = []   i  trange(, (tokens), batch_size):            start = i          end   = (i + batch_size, (tokens))            batch_inputs = {k: v[:, start:end].to(device)  k, v  tokenized_document.items()}     torch.no_grad():              model_output = model(**batch_inputs)            outputs.append(model_output.last_hidden_state)        model_output = torch.cat(outputs, dim=)   model_output       (token_embeddings, span_annotation, max_length=):      outputs = []   embeddings, annotations  (token_embeddings, span_annotation):   (max_length   ):              annotations = [                  (start, (end, max_length - ))   (start, end)  annotations   start < (max_length - )              ]          pooled_embeddings = []     idx, (start, end)  (annotations):   chunks[idx] == tokenizer.decode(doc_input_ids[start: end]),    (end - start) >= :                  pooled_embeddings.append(                        embeddings[start:end].mean(dim=).cpu().numpy()                  )  :   ()            pooled_embeddings = [              embedding / np.linalg.norm(embedding)  embedding  pooled_embeddings          ]          outputs.append(pooled_embeddings)   outputs      span_annotations = []    doc_input_ids = doc_tokens[][]  start_pos =   seperator_len = (tokenizer(, return_tensors=)[][]) -      chunk_idx, chunk  (chunks):        chunk_input_ids = tokenizer(chunk, return_tensors=)[][][:-]      chunk_token_len = (chunk_input_ids)     (doc_input_ids[start_pos: start_pos + chunk_token_len] == chunk_input_ids).detach().numpy().mean() != :          start_pos +=      (doc_input_ids[start_pos: start_pos + chunk_token_len] == chunk_input_ids).detach().numpy().mean() == , chunk_idx      span_annotations.append((start_pos, start_pos + chunk_token_len))      start_pos += chunk_token_len      document_embeddings = document_to_token_embeddings(model, tokenizer, processed_doc, batch_size=)    late_embeddings = late_chunking(document_embeddings, [span_annotations])

结果分析

考虑到我们的测试集是中文的，而Jina的官方代码是英文的，所以我一度以为是我的实现有bug，但对英文的数据分析后，发现同样存在一样的问题。

此处只展示最关键的分析，更多分析大家可以查看分析部分的源代码：https://github.com/Steven-Luo/MasteringRAG/blob/main/split/05_late_chunking_en_debug.ipynb

对于一个知识库片段，使用它自身作为Query去检索，如果只保留Top1，绝大多数情况下应该检索到它自身才对，而在Late Chunking中却不是这样。

下面的分析使用维基百科中DeepSeek词条的部分文本作为知识库，使用Jina公布的代码切分得到片段，然后分别拿每个片段作为Query，分别过Embedding模型得到Query的向量，与作为知识库片段的向量两两之间计算相似度，从这个结果来看，最相似的片段，并不总是自己，前5个句子，似乎都跟第一个句子最相似。

由于Late Chunking是将整个片段每个位置的hidden state做平均，所以可以想想，短句、代词较多的句子，应该会跟其他句子更相似。简便起见，此处检查句子长度。

下图中，横轴的0表示以每个片段作为Query，最相似的不是自身，1表是是自身，从结果可以看出，长句普遍都和自身最相似，而短句则和其他句子最相似。这也好理解，因为短句大都要借助前面的内容作为上下文，其中会有相对较多的代词。

从RAG全流程评估结果和英文的分析结果来看，这种方法似乎不是一种非常通用的能提升切分效果的方法，欢迎大家尝试，如果发现了我代码中的bug，欢迎反馈。

往期文章