2026年7月9日 周四晚上19:30,报名腾讯会议了解“如何构建自进化的动态知识库(Brain)”(限30人)
免费POC, 零成本试错
FDE知识库

FDE知识库

学习大模型的前沿技术与行业落地应用


收藏

都有混合检索与智能路由了,谁还在给RAG赛博哭坟?

发布日期:2026-01-08 18:15:43 浏览次数: 2292
作者:Zilliz

微信搜一搜,关注“Zilliz”

推荐语

RAG技术并未过时,反而进化出更智能的混合检索与路由决策能力,为企业级应用带来质的飞跃。

核心内容:
1. 传统RAG与大模型全量上下文的局限性分析
2. 新型RAG的智能路由决策机制详解
3. 混合检索技术在质量与成本间的平衡之道

杨芳贤
53AI创始人/腾讯云(TVP)最具价值专家
最近一年,互联网上各种为RAG赛博哭坟的帖子不胜枚举。
所有内容总结一句话,其实还是那些陈词滥调:大模型上下文已经够长了,可以取代RAG了。
但果真如此吗?
要知道,上下文再大,本质还是一次性的记忆空间,全量加载token不仅浪费算力,大模型本身的注意力也是有限的,过长的上下文,只会导致上下文输出时模糊重点,反而导致质量下滑。
也是因此,RAG不但没死,还从单纯的语义检索进化成了先想清楚该不该检、检什么、怎么检的一套流程。但传统的RAG只能根据内容相似度做机械式检索,无法满足智能检索、混合检索的高级需求。
那么,要如何解决这个问题?本文将深入解答。

01 

为什么传统的RAG与大模型上下文,无法带来输出质量提升?

无论是依赖大模型全量加载上下文,还是沿用传统RAG模式,最终都难以实现输出质量的稳定提升,核心症结在于两者均存在无法规避的底层检索质量问题,且这些问题在企业规模化落地场景中会被进一步放大。

(1)大模型全量加载上下文:成本和准确率成为问题

对于大规模知识库而言,若每次查询都全量加载上下文,token成本会呈线性增长。按照当前主流大模型的定价标准,月度token费用将成为企业落地的沉重负担;同时,全量加载带来的首次响应延迟,也会严重影响用户体验。
相比成本问题,准确率不足更是致命缺陷。《Lost in the Middle》研究数据明确显示,当目标信息位于上下文中段时,模型的检索准确率会显著低于信息位于开头或结尾的情况。尽管长上下文扩大了模型的记忆空间,但注意力机制的计算瓶颈并未突破,随着token数量的增加,超长文档中的信息定位成功率会持续下降。

(2)传统RAG的问题:盲目检索

传统RAG采用一刀切的固定流程:向量编码→ANN搜索→召回top-k→生成答案。
这种机械性流程会导致两个核心问题:
一是冗余检索,对于“2+2等于多少”这类常识性问题,本可直接生成答案,却仍需走完整检索流程,浪费算力与时间;
二是检索失效,面对复杂问题时,原始查询表达往往不够精确,容易导致检索效果下滑,同时同义词、多语言表达的匹配失败,也会直接造成召回率不足。
而解决以上两大问题,我们需要在检索层增加一个混合检索支撑起的决策机制。

02 

新型RAG应该如何搭建

2023年的RAG大多采用的是一种盲目检索策略,每个查询都走同样的流程。但2025年的RAG已经变成条件决策系统。
系统通常会通过在四个关键节点的层层判断,实现检索资源的最优配置与输出质量的稳定提升。

节点1,IF:路由决策

这是决策机制的第一步,核心目标是过滤冗余检索需求。系统会先对用户查询进行分类:对于“2+2等于多少”这类常识性问题,直接调用大模型生成答案,无需检索;对于“产品技术规格”这类依赖知识库的问题,触发检索流程;对于“巴黎这周末天气”这类实时信息需求,则调用外部API获取数据。
这一层通常采用F1分数评估路由准确率,通过精准过滤,可大幅降低不必要的检索成本。

节点2,WHAT:查询构造

若路由决策判定需要检索,下一步则是将原始查询转化为最优检索条件。
例如,用户原始查询“LightOn的Q3报告主要数字”,会被拆解为结构化过滤条件:时间范围限定2025年7月1日至9月30日、文档类型为“报告”、所属部门为“财务”。
这一步的核心价值是提升检索精准度,其效果可通过查询改写前后的召回率差异进行评估。

节点3,WHERE & HOW:策略选择

第三步聚焦检索策略与目标集合的匹配:针对代码查询,选择词法检索;针对自然语言问答,选择语义检索;针对财务报表这类包含图表的文档,则采用多模态检索捕捉视觉与文本信息。
这一决策的实现,依赖于离线预计算的文档元数据——通过提前标注文档类型、语言、领域等信息,运行时可快速匹配最优检索策略与目标集合。
这一层需分别评估检索召回率与重排序质量,确保检索结果的相关性。

节点4,GENERATE:最小上下文生成

最后一步是基于重排序后的检索结果,提取最小且充分的上下文供大模型生成答案。
相比全量加载上下文,仅加载目标片段可使成本降低一个数量级,即使考虑缓存机制,效率优势仍十分明显。这一层的评估重点是答案对检索来源的准确引用,以及任务完成度,确保生成内容的可靠性与有效性。
需要强调的是,若仅评估最终答案质量,会导致问题定位失效。因为RAG系统的失败具有级联传播特性:若路由决策错误,后续所有环节都会偏离方向。因此,必须对每个决策节点进行独立评估,才能精准定位问题根源。

03

 关键技术节点1:混合检索带来RAG效果提升

四层决策模型的第三层(词法、语义、多模态等策略选择)在落地时,经常会遇到架构挑战。
因为不同检索策略的适配场景存在明确边界,而企业文档场景的复杂性,决定了单一检索策略无法满足全面需求。
当然,也有人说Claude Code使用grep导航就搞定了问题,根本不需要复杂检索策略。但它的成功前提是代码具备高结构化、命名规范统一的特征,企业日常文档场景完全不同。
首先,企业自然语言文档存在普遍的同义词问题。在技术文档中,“优化内存使用”与“降低内存占用”表述不同但核心概念一致,若采用词法匹配的检索方式,只能命中其中一种表述;而在跨语言场景中,这一问题会进一步放大,中文分词、日文假名、德文复合词等不同语言特征,需要针对性的处理规则,单一检索策略无法全覆盖。
企业文档的第二个特征是包含大量视觉信息。工程图纸的空间布局、财务报表的表格结构、医疗影像的病灶特征,其核心语义依赖视觉逻辑。尽管OCR技术可提取文本信息,但无法理解视觉布局背后的关联关系,这就需要检索策略能够兼顾文本语义与视觉特征。
本质而言,不同内容类型对应不同的最优检索策略:代码查询适合词法检索,自然语言问答适合语义检索,多模态文档需要词法与语义检索的结合。
因此,混合检索是适配企业复杂场景的必选项,也是支撑智能决策机制的基础。
但如何做好混合检索并不容易。
传统方案是分离式架构:BM25检索和语义检索由不同系统负责,查询时需要分别调用再合并结果。这带来维护两套索引的存储成本和一致性保证问题,以及合并结果时的额外延迟。多语言场景让问题更复杂。
统一的混合检索架构可以解决这个问题
Milvus 2.6在Collection层面同时支持稠密向量和稀疏向量,同一条文档记录既存储语义向量也存储BM25向量,查询时一次API调用就能返回融合结果。这个架构简化了第三层的实现复杂度,策略选择变成在同一个Collection内调整向量权重,不需要跨系统合并结果。

04 

关键技术节点2:如何对RAG结果做评估

只评估最终答案质量是灾难性的。RAG系统失败时,问题可能出在路由判断、查询改写、检索召回、重排序、生成引用任何一个环节,但如果只看最终输出的答案对错,无法定位根因。
实际生产中的典型场景是用户反馈查询结果不准确。这个问题可能是路由层误判了查询类型,也可能是查询改写丢失了关键实体,还可能是检索策略选错了集合,或者重排序把正确文档排到了后面。
没有分层指标就只能盲目调参,改了一个地方可能把另一个地方做出新问题。
因此,我们需要在每一层需要独立的评估指标。
  • 路由层看F1分数,假阴性率过高说明太多需要检索的查询被误判为直接生成。
  • 查询改写层看实体识别准确率和同义词覆盖率。
  • 检索层看Recall@K和NDCG@10,这两个指标分别反映召回能力和排序质量。
  • 重排序层看top-3文档的相关性得分分布。
  • 生成层看答案对召回文档的引用准确率。
此外,离线预计算的元数据在评估阶段同样重要。每个查询类型在验证集上的指标分布可以作为阈值参考,运行时如果某一层的指标低于历史正常范围,就触发告警。这种分层监控机制能在用户反馈之前发现问题。

05 

写在最后

长上下文的成本问题短期内无法消失。RAG从盲目检索进化到条件决策系统,落地时需要注意几点:
先做路由判断。很多查询根本不需要检索,用简单的分类器过滤掉这些查询,检索压力立刻下降。
别维护两套系统做混合检索。Milvus 2.6在Collection层面统一存储稠密和稀疏向量,查询时一次调用就能拿到融合结果,多语言分词也是自动检测的。
每一层都要有独立指标。没有分层指标就只能盲目调参。路由层看F1分数,检索层看Recall@K,生成层看引用准确率。
RAG没有死,它从固定流程变成了智能决策。先从路由判断和混合检索开始,基础设施选对了,后面再扩展才不会推倒重来

53AI,企业落地大模型首选服务商

产品:场景落地咨询+大模型应用平台+行业解决方案

承诺:免费POC验证,效果达标后再合作。零风险落地应用大模型,已交付160+中大型企业

联系我们

售前咨询
186 6662 7370
预约演示
185 8882 0121

微信扫码

添加专属顾问

回到顶部

加载中...

扫码咨询

扫码登录
登录即表示您同意《53AI网站服务协议》
服务协议

欢迎您使用【53AI 官方网站】(以下简称“本网站”或“我们”)。本《会员服务协议》(以下简称“本协议”)是您(以下简称“会员”或“用户”)与【深圳市博思协创网络科技有限公司】之间关于注册、登录及使用本网站会员服务所订立的法律协议。

在您注册或登录前,请务必审慎阅读、充分理解各条款内容,特别是免除或限制责任的条款、知识产权条款、争议解决条款等。此类条款将以加粗形式提示您注意。 当您通过微信公众号授权、手机验证码验证或其他方式成功登录本网站时,即视为您已完全理解并同意接受本协议的全部内容。

一、 定义

本网站:指由【深圳市博思协创网络科技有限公司】运营的,域名为【53ai.com】的网站及相关移动端页面。

会员服务:指本网站向注册会员提供的知识库文章查阅、内容检索及其他相关增值服务。

知识库内容:指本网站发布的包括但不限于文字、图表、数据、研究报告、行业分析等数字化内容资源。

二、 账号注册与登录

登录方式:本网站支持以下登录方式,您可根据实际情况选择:

微信公众号授权登录:您同意将您的微信OpenID信息授权给本网站,用于创建或关联会员账号。

手机验证码登录:您需提供真实有效的手机号码,并通过短信验证码完成身份验证与登录/注册。

账号安全:您的账号仅限您本人使用,禁止赠与、借用、租用、转让或售卖。因您保管不善导致的账号被盗、密码泄露等损失,由您自行承担。

实名认证:根据相关法律法规要求,我们可能要求您在特定功能下完成实名认证。如您拒绝提供,可能无法使用部分或全部服务。

未成年人保护:若您未满18周岁,请在法定监护人的陪同下阅读本协议,并在征得监护人同意后使用本服务。

三、 服务内容与规范

知识库查阅权限:会员登录后,有权按照其会员等级对应的权限范围,在线浏览、检索本网站知识库中的相关文章及内容。

服务变更:我们有权根据业务发展需要,调整、变更或终止部分服务内容,并将以网站公告、公众号消息等方式提前通知。

禁止行为:您在使用服务时不得实施以下行为:

利用技术手段批量爬取、下载、转存知识库内容;

将知识库内容用于商业目的或未经授权地向第三方传播;

干扰本网站正常运行或侵犯其他用户合法权益;

发布违法违规信息或从事违反公序良俗的活动。

四、 知识产权声明

权利归属:本网站知识库中的排版设计、软件代码等内容的知识产权均归【公司全称】或原权利人所有,受《中华人民共和国著作权法》等法律保护。

有限许可:本网站授予会员一项非独占、不可转让、不可转授权的普通许可,仅限于个人学习、研究之目的在线查阅知识库内容。

侵权追责:未经书面许可,任何单位或个人不得以任何形式复制、转载、摘编、镜像、汇编或以其他方式使用上述内容。一经发现,我们保留追究其法律责任的权利。

五、 个人信息保护

我们重视对您个人信息的保护。关于我们如何收集、使用、存储和保护您的个人信息,请单独阅读 《隐私政策》。

您通过微信公众号授权或手机号验证所提供的信息,我们将严格按照《个人信息保护法》的规定处理,仅用于身份识别、服务提供及安全验证等必要用途。

您可以随时通过网站设置或联系客服行使查阅、更正、删除个人信息及撤回授权同意的权利。

六、 免责声明

内容准确性:知识库内容仅供参考,不构成专业建议。我们不对其完整性、准确性、时效性作任何明示或暗示的保证,您应自行判断并承担使用风险。

不可抗力:因自然灾害、政策法规变化、网络故障、第三方平台接口异常(如微信接口维护、运营商短信通道故障)等不可抗力导致的服务中断或延迟,我们不承担违约责任。

第三方链接:本网站可能包含指向第三方网站的链接,该等网站的内容和服务不受我们控制,请您自行甄别风险。

七、 违约责任

如您违反本协议约定,我们有权视情节采取警告、限制功能、暂停服务、注销账号等措施,并保留要求赔偿损失的权利。

如因您的违约行为导致我们遭受行政处罚、第三方索赔或商誉损失,您应承担全部赔偿责任(包括但不限于罚款、赔偿金、律师费、公证费等)。

八、 法律适用与争议解决

本协议的订立、执行和解释均适用中华人民共和国大陆地区法律。

因本协议产生的或与本协议有关的任何争议,双方应友好协商解决;协商不成的,任何一方均可向【公司所在地】有管辖权的人民法院提起诉讼。

九、 其他

本协议构成双方就本服务达成的完整协议,取代此前任何口头或书面约定。

本协议任一条款被认定为无效或不可执行的,不影响其他条款的效力。

我们对本协议享有最终解释权,并在法律允许的范围内保留随时修改的权利。修改后的协议一经公布即生效,继续使用服务即视为同意修订内容。


已查阅