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

最近一年，互联网上各种为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没有死，它从固定流程变成了智能决策。先从路由判断和混合检索开始，基础设施选对了，后面再扩展才不会推倒重来