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

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

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

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

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

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

from pymilvus import MilvusClientfrom openai import OpenAIopenai = OpenAI()milvus = MilvusClient(uri="http://localhost:19530")query = "为什么服务高并发下报 502？"query_vec = openai.embeddings.create(    input=query,    model="text-embedding-3-small").data[0].embeddingresults = 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 留出更有多样性的候选证据。