到底是谁会相信RAG已死啊？

最近一两年，互联网上各种为RAG赛博哭坟的帖子不胜枚举。

但观点永远是那些陈词滥调：大模型上下文已经够长了、agent万岁、embedding增加系统复杂度。

但真到了需要语义检索的时候，又有几个人能把RAG真正从系统里拿掉？

原因也简单。即使拿掉切 chunk、算 embedding、top-k 塞进 prompt这些繁琐环节，模型必须访问外部知识这件事依然是无法避免的。因为LLM 不知道你的私有文档、最新接口、线上故障记录和内部决策过程。

但传统RAG真的有那么好用吗？那也未必。

拿以下这个RAG代码做个示例：

from pymilvus import MilvusClient

from openai import OpenAI

openai = OpenAI()

milvus = MilvusClient(uri="http://localhost:19530")

query = "为什么服务高并发下报 502？"

query_vec = openai.embeddings.create(

    input=query,

    model="text-embedding-3-small"

).data[0].embedding

results = milvus.search(

    collection_name="knowledge_base",

    data=[query_vec],

    limit=3,

    output_fields=["content", "source"]

)

这段代码没问题，但它的隐含条件是：用户的问题描述已经足够清楚，并且相似度最高的文本就能支撑回答。但真实场景通常不会这么简单。

比如，用户问高并发下为什么报 502，答案可能分散在 Nginx 错误码说明、upstream 超时配置、健康检查、发布记录和监控日志里。只做一次向量检索，很可能召回错误码说明，因为它语义最接近问题，但这只能解释 502 是什么，解释不了为什么现在才出现。

再比如，用户问怎么让 Python 跑得快，文档写的是 CPython profiling、GIL contention、NumPy vectorization。两边说的是同一类问题，但字面表达和语义重心都不完全一样。向量相似度能缓解这个问题，不能保证每次都跨过去。

这也是 RAG 被反复质疑的原因。

但这些失败并不说明检索没价值，它们暴露的是另一个问题：很多RAG系统把检索当成了一次性动作，那么该如何纠正这个问题？本文将对此做重点解读。

01 

RAG升级一：混合检索补全语义短板

如果传统nativeRAG 解决不了问题，我们可以做的第一轮修补，引入混合检索，让检索别只依赖语义相似度。

在技术文档、故障排查和企业知识库里，关键词的重要性不比语义更低。错误码、配置项、函数名、合同编号、产品型号，这些东西不能只靠语义猜。502、timeout、proxy_read_timeout 这种词一旦丢掉，模型再会总结也没用。

混合检索的价值就在这里：由稠密向量负责捕捉语义层面的相近性，由 BM25 或稀疏检索负责实现关键词的精确命中，最后通过 RRF 或加权策略将两类检索结果融合，兼顾语义相关性与关键词准确性。

在混合检索的落地过程中，过往很多系统采用向量数据库做语义检索+外挂 Elasticsearch 做关键词检索的方案，但这种方式很容易会因两套索引、两套写入链路以及两套系统的一致性问题陷入困境，难以稳定运行。

而 Milvus 混合检索很好的解决了这一痛点，它可将稠密向量、稀疏向量、BM25 全文检索、元数据过滤及结果融合，整合到同一条检索链路中，彻底规避了多系统并行的繁琐与隐患。

具体来看，Milvus 实现混合检索有两种方式：

一是使用外部稀疏模型（如 BGE-M3），可将稠密向量与稀疏向量均作为向量字段进行检索；

二是使用 Milvus 内置的 BM25 功能，此时只需为原始文本字段开启分析器，Milvus 会自动生成稀疏向量，查询时直接输入文本即可触发 BM25 检索。

这里需要特别注意一个易混淆点：BM25 功能的输出字段并非由应用侧手动插入的向量，而是 Milvus 根据文本字段自动生成的。

不过，混合检索的核心作用只局限于改善特定场景的检索效果，即用户问题中包含明确术语。但当问题本身方向不清晰，或者答案需要多轮收集证据时，混合检索就不够用了。

02 

RAG升级二：Agentic RAG 把检索变成一个循环

Agentic RAG 往前走了一步：让模型参与检索过程。

它不再默认第一次检索就足够，而是让 Agent 看结果、判断缺口、改写 query、拆分问题，再继续搜。用户问高并发 502，Agent 会先查错误码，再查 upstream timeout，再补一轮健康检查和最近发布记录。检索从一次动作变成了一个循环。

Agentic RAG 最核心的优化在于检索循环。它能把查一次变成查多次，把一个 query 变成多个 query，把粗糙问题变成更接近文档表达的问题。但它默认知识访问工具还是同一个：search_docs。Agent 在这个工具里能做的事，主要是换问法、换关键词、换拆解方式。

这就是它的强项，也是它的限制。

如果问题只是信息没办法一次召回全，Agentic RAG 很有用。如果问题需要切换信息源、调用不同工具、遵守不同权限、按组织或租户平衡结果，只依靠检索工具就开始无法满足需求。

换句话说，当向量相似度高不等于答案正确；再多的搜索次数也没法解决问题。

03 

RAG升级三：Agent Skills 让知识访问带上操作规程

Agent Skills 的意义，在于改变的是知识访问的粒度。

一个 Skill 背后通常是一组元数据、执行说明和资源配置。元数据会告诉 Agent 这个能力适合什么问题；执行说明告诉它先查什么、失败时怎么办、什么时候需要反问；资源配置则把向量库、文档、API、脚本或权限边界放进去。

这时检索已经不只是 search(query)，它开始带上操作规程。

比如一个故障排查 Skill 可以规定：先根据错误码查知识库，再根据服务名查最近变更，如果证据不足就查监控摘要；涉及客户数据时必须带上 tenant_id 过滤；同一租户或同一文档的 chunk 不能挤满全部结果；最后回答时列出证据来源。

这就比单纯的 Agentic RAG 更接近真实工程系统。因为Agent 不再只是反复询问同一个搜索框，而是在一个受约束的流程里探索。

Milvus 在这个位置上的价值在于，给 Skills 提供更合适的知识访问底座。混合检索让 Skill 同时处理语义和精确术语；metadata filtering 让它把权限、时间、版本、租户这些条件前置；多向量字段让它按 title、content、summary 或不同模态选择检索入口；Grouping Search 可以避免同一个文档、同一个用户占满 top-k，给 Agent 留出更有多样性的候选证据。

这些能力单独看算不上突破性革命，但组合起来就是 Agent 用不用得顺手的差别，它决定了每次查到的材料是否可控、可解释，是否符合权限。

04 

RAG升级四：分流

以上三种方式没有所谓的最优解，大多数时候，系统需要一个更明确的判断标准：什么问题该走短路径，什么问题必须交给 Agent 反复探索。

总结来说，有些问题天然适合native  RAG+混合检索。它有明确对象、明确关键词、明确资料边界，比如查某个 API 参数、某个错误码、某条政策说明。这种情况下，混合检索、过滤和 rerank 做扎实，收益比引入复杂 Agent 更大。

Agentic RAG 更适合问题方向明确，但信息分散的情况。比如为什么这个服务最近变慢，或者某个指标异常可能和哪些配置有关。它需要拆解，需要补查，需要根据第一轮结果修正 query。

Agent Skills 则适合那些问题一开始就不清楚的情况。比如帮我排查这个线上问题，或者评估这个客户投诉背后的根因。这里没有一个固定 query 可以直接打进向量库。系统需要在文档、日志、工单、监控、变更记录之间移动，需要决定下一步查什么，甚至需要先问用户补充环境。

过去，RAG 之所以总被判死刑，是因为很多人把它等同于一次向量召回。而RAG 之所以总能诈尸，是因为外部知识需求从来没消失。

真正消失的，是那种把检索当成 prompt 前置步骤的粗糙设计。留下来的，是更底层、更工程化的知识访问层。

而在这个演进过程中，我们始终需要一个能处理简单查找，也要能支撑多轮探索；能召回语义相近的内容，也能抓住精确术语；能把结果交给模型，也能配合模型解释这些结果来自哪里、满足什么权限的企业级向量数据库。

作者介绍

Zilliz黄金写手：尹珉

文章来自于"Zilliz"，作者 "尹珉"。