
大约一年前,2023 年 10 月,我们推出了全球首个支持 8K 上下文长度的开源 Embedding 模型 —— jina-embeddings-v2-base-en。自此,长文本在 Embedding 模型中的应用引发了广泛讨论和争议。
-
信息压缩问题:将数千字的长文本编码为单一 Embedding 表示会导致语义信息的"过度压缩",使得检索系统难以准确定位特定信息。
-
检索粒度不足:许多应用,尤其是检索增强生成(RAG)系统,需要检索文档中的较小片段,而非整个长文档。
-
短文本检索优势:基于密集向量的检索系统在处理短文本时通常表现更好,因为短文本的语义信息更容易被准确编码和检索。

一个典型的 RAG Pineline 包括:分块-Embedding-检索-生成。
那么,如果行业只需要具有 512 上下文长度的 Embedding 模型,那么训练 8192 上下文长度的模型又有什么意义呢?
在本文中,我们通过探讨 RAG 中传统分块 -> Embeddings 流程的局限性,来重新审视这个问题。同时,我们还引入了一种新策略,称为 迟****分(Late Chunking),能够在保留长文本 Embedding 模型优势的同时,也能满足精细粒度检索的需求。
上下文丢失问题
传统的分块 - Embedding - 检索 - 生成流程在处理长文档时可能会丢失长距离的上下文依赖关系,这对于信息检索和理解是一大隐患。换句话说,当关键信息散落在多个文本块中,脱离上下文的文本片段很可能失去其原有的意义,导致处理效果大打折扣。
以维基百科上的一篇关于柏林的文章为例,若将其分割为句子块,不难发现诸如“其”和“这座城市”等指代表达,实际上指向的是文章开头提到的“柏林”。这种情况下,Embedding 模型很难将这些指代正确链接到实体,进而产生质量低下的向量表示。

这意味着,若我们将一篇长文按照句子长度进行分块处理,RAG 系统在回答诸如“柏林的总人口是多少?”之类的查询时,可能会遇到困难。因为城市名称和人口数据从未出现在同一文本块中,且缺乏更大的文档上下文,处理这些块的 LLM 难以解决这样的指代问题。
尽管有一些启发式算法试图缓解这一问题,如滑动窗口重新采样、多种上下文窗口长度及多次文档扫描等,然而,像所有启发式算法一样,这些方法时灵时不灵;它们可能在某些情况下有效,但没有理论上的保证。
迟分让 Embedding 更懂上下文
在传统的文本编码领域,我们常常采用一种“预先分块”的策略,即先分块,再过 Embedding 模型。首先依据句子、段落或预设的最大长度对文本进行切割。随后,Embedding 模型会对这些切割好的文本块逐一进行处理,通过平均池化等方法,将 token 级的 Embedding 聚合成单一的块 Embedding 向量。如下图左侧所示:

左侧为传统分块策略,右侧为迟分策略的图解。
然而,本文提出的“迟分”策略,则是先过 Embedding 模型再分块,我们先将 Embedding 模型的 transformer 层应用到整个文本或尽可能多的连续文本,为每个 token 生成一个包含丰富上下文信息的向量表示序列。随后,再对这些 token 向量****序列进行平均池化,进而得到考虑了整个文本上下文的块 Embedding。
与传统的独立同分布(i.i.d.)块 Embedding 不同,迟分生成的块 Embedding 是“有条件的”,这意味着每个块都编码了更多的上下文信息,从而大大提升了编码的质量和准确性。
值得注意的是,为了充分发挥迟分的优势,我们需要借助支持长上下文的 Embedding 模型,如 jina-embeddings-v2-base-en,它能够处理长达 8192 个 token 的文本(相当于 10 页 A4 纸),基本满足了大多数长文本的上下文需求。
当然,迟分也并非完美,它同样需要边界线索来辅助处理。但与传统方法不同的是,这些边界线索是在获取到 token 级 Embedding 之后才使用的,这也是“迟分”名称的由来。
|
| 传统分块 | 迟分 |
| — | — | — |
| 边界线索需求 | 是 | 是 |
| 边界线索使用时机 | 预处理阶段 | transformer 层处理后 |
| 块 Embedding 特性 | 独立同分布(i.i.d.) | 有条件,编码更多上下文信息 |
| 邻近块上下文保留 | 易丢失,需启发式方法缓解 | 长文本 Embedding 模型能有效保留 |
迟分效果一览,定性评估案例
Google Colab: https://colab.research.google.com/drive/15vNZb6AsU7byjYoaEtXuNu567JWNzXOz
迟分的实现可以在上述链接的 Google Colab 中找到。在这里,我们利用了最近在 Tokenizer API 中的最新功能,借助所有可能的边界线索,将长文档分割成有意义的块。关于此功能背后的算法的更多讨论可以在 twitter@JinaAI_ 上找到。
Tokenizer API: https://jina.ai/tokenizer/
当将迟分应用于上述柏林的维基百科示例时,可以立即看到语义相似性的改善。例如,以“这座城市”和“柏林”的指代关系为例,采用迟分后,“这座城市”的向量表示成功捕捉到了与“柏林”的关联信息,在与涉及该城市名称的查询匹配时表现得更为出色。
以下是具体的数值对比结果,展示了“柏林”一词的 Embedding 与柏林维基百科文章中各个句子的余弦相似性。从表格中可以清晰地看出,与传统分块相比,迟分在提升语义相似性方面取得了显著成效。
| 查询 | 块 | 传统分块下的相似性 | 迟分下的相似性 |
|---|---|---|---|
| 柏林 | 柏林是德国的首都和最大的城市,无论是面积还是人口都是如此。 | 0.849 | 0.850 |
| 柏林 | 其超过 385 万人口使其成为欧盟人口最多的城市,以市区人口计。 | 0.708 | 0.825 |
| 柏林 | 这座城市也是德国的一个州,在面积上是全国第三小的州。 | 0.753 | 0.850 |
BEIR 实验验证,迟分效果显著
为了全面验证迟分在各种场景下的有效性,我们借助 BEIR 中的检索基准进行了一系列严谨的测试。这些测试涵盖了查询集、文本文档语料库以及存储查询与文档关联信息的 QRels 文件。
在评估过程中,我们将文档分块并编码至 Embedding 索引,通过 k 近邻(kNN)算法寻找与查询 Embedding 最相似的块。随后,将块的 kNN 排名转换为文档排名,并与真实排名进行对比,计算 nDCG@10 等检索指标。
整个评估流程的脚本已开源,可在此处获取:https://github.com/jina-ai/late-chunking
我们在多个 BeIR 数据集上进行了传统分块与迟分的对比测试。为提取边界线索,我们采用正则表达式将文本切分为约 256 个 token 的字符串。同时,选用 jina-embeddings-v2-small-en 作为 Embedding 模型,虽为较小版本的模型,但仍具备 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 模型的重要性,还能激发更多关于这一主题的研究。
如何学习大模型 AI ?
由于新岗位的生产效率,要优于被取代岗位的生产效率,所以实际上整个社会的生产效率是提升的。
但是具体到个人,只能说是:
“最先掌握AI的人,将会比较晚掌握AI的人有竞争优势”。
这句话,放在计算机、互联网、移动互联网的开局时期,都是一样的道理。
我在一线互联网企业工作十余年里,指导过不少同行后辈。帮助很多人得到了学习和成长。
我意识到有很多经验和知识值得分享给大家,也可以通过我们的能力和经验解答大家在人工智能学习中的很多困惑,所以在工作繁忙的情况下还是坚持各种整理和分享。但苦于知识传播途径有限,很多互联网行业朋友无法获得正确的资料得到学习提升,故此将并将重要的AI大模型资料包括AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频免费分享出来。

第一阶段(10天):初阶应用
该阶段让大家对大模型 AI有一个最前沿的认识,对大模型 AI 的理解超过 95% 的人,可以在相关讨论时发表高级、不跟风、又接地气的见解,别人只会和 AI 聊天,而你能调教 AI,并能用代码将大模型和业务衔接。
- 大模型 AI 能干什么?
- 大模型是怎样获得「智能」的?
- 用好 AI 的核心心法
- 大模型应用业务架构
- 大模型应用技术架构
- 代码示例:向 GPT-3.5 灌入新知识
- 提示工程的意义和核心思想
- Prompt 典型构成
- 指令调优方法论
- 思维链和思维树
- Prompt 攻击和防范
- …
第二阶段(30天):高阶应用
该阶段我们正式进入大模型 AI 进阶实战学习,学会构造私有知识库,扩展 AI 的能力。快速开发一个完整的基于 agent 对话机器人。掌握功能最强的大模型开发框架,抓住最新的技术进展,适合 Python 和 JavaScript 程序员。
- 为什么要做 RAG
- 搭建一个简单的 ChatPDF
- 检索的基础概念
- 什么是向量表示(Embeddings)
- 向量数据库与向量检索
- 基于向量检索的 RAG
- 搭建 RAG 系统的扩展知识
- 混合检索与 RAG-Fusion 简介
- 向量模型本地部署
- …
第三阶段(30天):模型训练
恭喜你,如果学到这里,你基本可以找到一份大模型 AI相关的工作,自己也能训练 GPT 了!通过微调,训练自己的垂直大模型,能独立训练开源多模态大模型,掌握更多技术方案。
到此为止,大概2个月的时间。你已经成为了一名“AI小子”。那么你还想往下探索吗?
- 为什么要做 RAG
- 什么是模型
- 什么是模型训练
- 求解器 & 损失函数简介
- 小实验2:手写一个简单的神经网络并训练它
- 什么是训练/预训练/微调/轻量化微调
- Transformer结构简介
- 轻量化微调
- 实验数据集的构建
- …
第四阶段(20天):商业闭环
对全球大模型从性能、吞吐量、成本等方面有一定的认知,可以在云端和本地等多种环境下部署大模型,找到适合自己的项目/创业方向,做一名被 AI 武装的产品经理。
- 硬件选型
- 带你了解全球大模型
- 使用国产大模型服务
- 搭建 OpenAI 代理
- 热身:基于阿里云 PAI 部署 Stable Diffusion
- 在本地计算机运行大模型
- 大模型的私有化部署
- 基于 vLLM 部署大模型
- 案例:如何优雅地在阿里云私有部署开源大模型
- 部署一套开源 LLM 项目
- 内容安全
- 互联网信息服务算法备案
- …
学习是一个过程,只要学习就会有挑战。天道酬勤,你越努力,就会成为越优秀的自己。
如果你能在15天内完成所有的任务,那你堪称天才。然而,如果你能完成 60-70% 的内容,你就已经开始具备成为一名大模型 AI 的正确特征了。
这份完整版的大模型 AI 学习资料已经上传优快云,朋友们如果需要可以微信扫描下方优快云官方认证二维码免费领取【保证100%免费】

5630

被折叠的 条评论
为什么被折叠?



