RAG技术真的已经过时了吗？深度解析RAG的演进之路

最近一两年来，关于RAG（检索增强生成）技术是否“已死”的讨论甚嚣尘上。持此观点的人主要基于以下理由：大模型的上下文窗口已经足够长，Agent才是未来，而Embedding机制会增加系统复杂度。然而，当真正需要语义检索时，又有多少系统能够完全脱离RAG？答案显而易见——即使去掉chunk切分、向量计算、top-k召回这些环节，模型必须访问外部知识这一核心需求依然无法回避。LLM无法凭空知道企业的私有文档、最新接口文档、线上故障记录和内部决策过程。

混合检索：弥补语义检索的天然短板

那么，传统RAG是否真的如想象中那般完美？答案同样是否定的。以一个典型的RAG代码为例：当用户询问“为什么服务高并发下报502”时，传统RAG系统只能进行一次向量检索，召回语义最相似的文档。但在真实场景中，答案往往分散在多个地方——Nginx错误码说明、upstream超时配置、健康检查文档、发布记录以及监控日志等。单次向量检索很可能只召回错误码说明文档，因为它在语义上最接近问题，但这只能解释502是什么，却无法解释为什么现在才出现。再比如，用户询问如何让Python代码运行得更快，而文档可能从CPython性能分析、GIL锁竞争、NumPy向量化等不同角度进行阐述——表达方式和语义重心存在差异。向量相似度能缓解这一问题，但无法保证每次都能准确跨过语义鸿沟。

Agentic RAG：从单次检索到智能循环

面对传统RAG的局限性，第一轮升级方向是引入混合检索机制。混合检索的核心价值在于：让检索不再仅仅依赖语义相似度，同时兼顾关键词的精确匹配。在技术文档、故障排查和企业知识库场景中，关键词的重要性丝毫不亚于语义理解。错误码（如502）、配置项（如proxy_read_timeout）、函数名、合同编号、产品型号等实体，不能仅靠语义猜测来召回。混合检索由稠密向量负责捕捉语义层面的相近性，由BM25或稀疏检索负责实现关键词的精确命中，最后通过RRF（倒数排名融合）或加权策略将两类检索结果融合，兼顾语义相关性与关键词准确性。Milvus等向量数据库已将稠密向量、稀疏向量、BM25全文检索、元数据过滤及结果融合整合到同一条检索链路中，避免了多系统并行的复杂性。

当问题方向不清晰，或答案需要多轮收集证据时，混合检索便显得力不从心。此时，Agentic RAG成为更优选择。它让模型参与检索过程，不再默认第一次检索就足够。Agent会先查看检索结果，判断信息缺口，改写查询语句，拆分复杂问题，然后继续进行下一轮检索。以高并发502问题为例，Agent会先查询错误码定义，再查询upstream超时配置，再补充健康检查和最近发布记录——检索从一次动作变成了一个循环。这种方式特别适合问题方向明确但信息分散的场景，如分析服务变慢的原因或排查指标异常的可能配置因素。

Agentic RAG虽然强大，但当问题需要切换信息源、调用不同工具、遵守不同权限时，其局限性便显现出来。Agent Skills的出现正是为了解决这一问题——它将知识访问的粒度从单纯的检索提升到了操作规程的层面。每个Skill背后是一组元数据、执行说明和资源配置：元数据定义该能力适合什么问题，执行说明规定先查什么、失败时如何处理、何时需要反问用户，资源配置则整合向量库、文档、API、脚本和权限边界。此时检索不再只是search(query)，而是带上操作规程的智能流程。

Agent Skills与智能分流：构建企业级知识访问体系

然而，以上三种升级方式并没有所谓的最优解。实际工程中，系统需要一个更明确的判断标准来分流处理——什么问题该走短路径，什么问题必须交给Agent反复探索。总体而言，有明确对象、关键词和资料边界的问题（如查询某个API参数或错误码）天然适合混合检索；而问题方向明确但信息分散的情况更适合Agentic RAG；问题一开始就不清楚（如排查线上问题或评估客户投诉根因）则需要Agent Skills在文档、日志、工单、监控、变更记录之间灵活移动。

如有侵权，请联系删除。