微信扫码
添加专属顾问
我要投稿
RAG技术如何突破检索瓶颈?揭秘让AI像人类一样"扫视全文"的上下文检索技术。核心内容: 1. 传统RAG系统因文本切块导致的语义割裂问题 2. 文档格式多样性带来的切块规则设计难题 3. 上下文检索技术如何实现更精准的语义理解
尽管大语言模型本身的能力在快速演进,但它依然无法凭空获取训练数据之外最新或专有知识。
检索增强生成(RAG, Retrieval-Augmented Generation)正是为解决这一问题而生:
在回答问题前,先从知识库中检索相关资料,再让模型参考这些资料生成答案。
换言之,RAG让大模型从“闭卷考试”变成了“开卷考试”。
但“开卷”也不一定更容易。如果检索到的资料不完整、不准确,能力再强的大模型也无法给出高质量答案。
因此,检索是RAG的关键,检索的效果取决于系统能否完整、准确地找到与用户问题最相关的内容。
01.
文档切块:不可避免的语义破坏
几乎所有RAG系统都遵循同一条技术路径:
文档解析 → 文本切块(Chunks) → 向量化 → 初步检索 → 精细重排 → 大语言模型生成
RAG系统流程图
由于检索模型的输入长度往往有限,“文本切块”就成为了必要的步骤。 文本块越小,语义匹配也就越精确。
但切块正是影响RAG检索质量的元凶。
为了适应模型限制,原本连贯的长文档被机械切分为多个独立片段,容易因语义缺失、语义歧义或全局结构信息丢失导致检索不完整。
以《中华人民共和国民法典》为例(点击查看原文档,下同),在固定长度切块策略下,第一百二十三条关于知识产权的定义会被切成两块:
当用户提问:“根据知识产权定义,哪些对象可享有专有权利?”时:
最终大模型只回答了法条的前四项内容,而遗漏了后四项。
因切块导致的语义割裂,是 RAG 产生“回答不全”问题的根源。
既然切块会导致断章取义,那能否通过优化切块规则解决问题?
答案是:很难,甚至不可能。
文档格式高度多样、内容结构千差万别,没有一种切块规则能够适用于所有文档。
例如,在《小学生满分作文》中,包含题目、作者、点评等多种非统一格式元素,想用规则自动将完整作文切块非常困难。
《小学生满分作文》石元达作文原文
更重要的是,切块的“合理性”是相对于“提问”而言的。
在用户提问之前,我们根本不知道哪种切块方式是最优的。
以《深圳市前海一方恒融商业保理有限公司2024年度第二期华发优生活四号资产支持票据募集说明书》(简称《募集说明书》)为例,
当用户提问:“华发股份董事会有多少位董事?”
相关的内容文档中有两段:
《募集说明书》第179页
但问题在于,仅看这两段,无法判断两处“公司”具体所指的对象。
我们还要依据第132页“共同债务人一:华发集团”和第499页“共同债务人二:华发股份”,才能确定:
第179页的“公司”,指的是“华发集团”;
第522页的“公司”,指的是“华发股份”。
依据这个问题,理想的切块需要将第132-179页(共48页)切到一个文本块,第499-522页(共24页)切到另一文本块。
但这样大块的内容往往超出了检索模型的可处理长度;同时,切得过粗也会削弱对其他细节类问题的回答精度。
所以:并不存在能适应所有未来提问的“十全十美”的静态切块方案。
只要切块存在,语义连贯性的破坏就不可避免。
既然无法从优化切块上解决问题,我们能否在检索阶段进行补救?
当前主流检索方案采用“逐个评估”方式,检索模型单独判断一个文本块与查询的相关性,从而忽视了切块造成的上下文问题。
为此,我们提出了“上下文重排”模式。
传统重排方式与长上下文重排方式比较
不同于传统重排模型“一次只给一个切片打分”、需要多次独立输入的模式,上下文重排采用“整体评估”模式:
将初步检索到的多个候选文本切片去重、按原文顺序拼接,组成一段包含完整上下文的连续长文本(例如60k tokens,依据硬件配置长度有所不同),一次性输入给重排模型。
这样,重排模型能够感知检索内容间的语义关联,更准确地评估各部分内容与提问的相关性。
回到《民法典》的例子:
当初步检索召回文本块1和2后,重排模型将两个文本块作为整体输入,理解了文本块2的前半部分是文本块1的延续,最终将“知识产权”对应的法规完整返回。
上下文重排流程
但这一方案并非一劳永逸。
如果文档较短,初步检索返回的结果能完整放入60k tokens的上下文窗口,那上下文重排的确能直接解决问题;
但当文档很长,初步检索返回的候选内容长度超过60k tokens时,我们不得不在重排前再做一轮筛选,而这依然可能导致关键信息遗漏。
换言之,上下文重排的效果,其实取决于初步检索是否把关键切片“捞回”。
例如,在《小学生满分作文集》中,石元达的作文被切分成四个文本块。
对于提问:“石元达的作文全文是什么?”
初步检索的60k内容中只包含文本块1和2、传统重排仅能召回文本块1。
引入上下文重排模型后,成功召回了文本块1和2,但文本块3和4仍然缺失。
文本块3和4在初步检索阶段因语义相似度较低被过滤掉,部分相关内容在初步检索阶段就被永久丢失。
为了解决这个问题,我们不妨先回顾一下:
在RAG技术出现之前,人们是如何从文档中获取知识的?
在传统搜索引擎中,系统只需按相关性排序返回片段列表,用户会自行阅读、判断、前后翻阅,从而补全上下文信息;
而在RAG系统中,由于检索结果面向大模型,大模型无法“主动翻页”或“扫视前后文”,只能基于给定片段生成答案。
一旦关键上下文缺失,错误或不完整的回答几乎不可避免。
因此,RAG对检索结果的完整性要求远高于传统搜索引擎。
它不能依赖“用户智慧”来弥补缺口,必须通过检索机制自身来确保信息的充分性。
上下文扩展+一次重排
为了有效实施上下文扩展,我们起初尝试直接依据初步检索阶段的向量相似度分数来决定扩展策略:
向量相似度越⾼的⽂本块,扩展范围越⼤,周围文本被纳入候选集合的可能性也越高。
此时RAG系统的检索流程如下:
上下文扩展+上下文重排
该策略对检索完整性的提升较为有限——许多关键但未被初步检索召回的文本块,依然未能通过上下文扩展被有效补充。
例如,在“石元达的作文”案例中:
初步检索仅召回文本块1和2
对文本块1和2进行上下文扩展
由于文本块1和2的分数较低,仅文本块3纳入候选集合,文本块4并未被包含进候选集合
文本块1、2与3输入重排模型
文本块1-3输入大模型,生成回答中遗漏文本块4
可见,上下文扩展并不能盲目地“多拿一点”,而是需要先精准识别关键片段,再有针对性地扩展其上下文。
上下文扩展+二次重排:先识别后扩展
对此,我们提出“上下文扩展+二次重排”方案,引入两阶段重排机制:
这一流程赋予了RAG系统类似人类的“扫视”能力:
先定位最相关的关键段落,再对其上下文扩展,最终结合更完整语境判断相关性。
上下文扩展+二次重排
回到“石元达的作文”案例:
初步检索仅召回文本块1和2
第一次重排后获得较高分数
上下文扩展将相邻的文本块3和4一并纳入
第二次重排识别全部内容
最终文本块1-4输入大模型,生成准确完整的回答。
可以看到,经过“上下文扩展+二次重排”,RAG系统具备了更强的语义连贯性感知能力。
为验证所提出策略的有效性,我们在50篇长文档上构建了包含855个问题的评测集,平均每个问题涉及11.3个相关段落。
三种检索流程对比
在实验中,我们采用统一的文档解析与切分策略,并使用 BGE-M3 向量模型进行初步检索。
随后,对各类重排模型与重排流程进行了系统评估:
no_rerank:直接使用初步检索的向量召回结果,不进行任何重排;
bge_rerank:采用 BGE-M3 重排模型(“逐个评估”模式),对每个候选文本块与查询进行独立相关性评估;
jina_rerank:采用 Jina-Reranker-v3 模型(“整体评估”模式),作为业界公认性能领先的长上下文重排模型,能够联合评估所有候选文本块与查询的整体相关性;
context_rerank:采用庖丁长上下文重排模型(“整体评估”模式),联合建模查询与全部候选文本块,按照图6所示的“流程一:直接重排”方案执行;
extend_rerank:基于庖丁长上下文重排模型,按照图6所示的“流程二:扩展后重排”方案执行;
rerank_extend_rerank:在庖丁长上下文重排模型的基础上,按照图6所示的“流程三:重排–扩展–重排”方案执行。
对比六种方案,我们分别截取1k、5k 和 10k tokens 的上下文作为最终召回结果,并计算其与人工标注结果之间的召回率。
不同上下文长度下的平均召回率
实验结果表明:
在RAG系统中,文档切块是绕不开的工程妥协,但它带来的语义碎片化是检索完整性的最大敌人。
我们提出的“上下文扩展与二次重排”策略,本质上是让RAG系统模仿人类的阅读习惯:
不只看孤立的片段,更要基于线索去扫视周围的语境。
这种方法并未改变切块的规则,而是改变了检索的逻辑,以极低的成本有效弥补了信息缺口。
对于追求高精度、高完整性的企业级RAG应用而言,这或许是突破“断章取义”瓶颈的最有效路径。
“上下文扩展与二次重排”技术,现已在ChatDOC Studio正式发布上线!
您可以通过PC端访问https://chatdoc.studio/ ,体验不同方案的实际效果。
ChatDOC Studio 提供多种服务形态,您可通过网页端即时检索,也可通过API调用与任意业务系统集成。
ChatDOC Studio操作实机演示
我们仍以石元达作文为例,对比上文不同检索模式的实际表现:
“Basic(初步检索后直接输入)”模式检索结果
“Contextual(上下文扩展+上下文重排)”模式检索结果
能够看到,无论是选用“Basic(初步检索后直接输入)”还是“Contextual(上下文扩展+上下文重排)”模式,在6k token长度下,系统仅能检索召回包含石元达姓名的文本切片(黄色高亮显示),而在检索步骤中就遗漏了所需要的关键信息。
“Expanded(上下文扩展+二次重排)”模式检索结果
而选择“Expanded(上下文扩展+二次重排)”模式时,可以看到,同样token长度下,石元达作文全文被完整召回(黄色高亮显示),证明“上下文扩展+二次重排”在实际应用中具备显著提升检索完整性的优势。
PC端访问 https://chatdoc.studio/,或点击“阅读原文”,体验业界领先的文档检索方案。
53AI,企业落地大模型首选服务商
产品:场景落地咨询+大模型应用平台+行业解决方案
承诺:免费POC验证,效果达标后再合作。零风险落地应用大模型,已交付160+中大型企业
2025-12-22
Uber 如何利用 OpenSearch 实现十亿级向量搜索
2025-12-22
别让大模型在“垃圾堆”里找金子:深度解析 RAG 的上下文压缩技术
2025-12-21
终于,NotebookLM 和 Gemini 合体了。这是什么神之更新?
2025-12-21
Cohere 推出 Rerank 4,将上下文窗口从 8K 扩展至 32K,以交叉编码器架构强化长文档语义理解与跨段落关联捕捉
2025-12-21
4.1K Star!GitHub 上挖到一个救星级别的 RAG 数据流水线项目!
2025-12-20
PageIndex:一种基于推理的 RAG 框架
2025-12-20
深度解析丨智能体架构,利用文件系统重塑上下文工程
2025-12-20
RAG 答非所问?可能是你少了这一步:深度解析 Rerank 与 Cross-Encoder 的“降维打击”
2025-10-11
2025-10-04
2025-09-30
2025-10-12
2025-12-04
2025-11-04
2025-10-31
2025-11-13
2025-10-12
2025-12-03
2025-12-21
2025-12-10
2025-11-23
2025-11-20
2025-11-19
2025-11-04
2025-10-04
2025-09-30