到底是谁会相信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(urihttp://localhost:19530) query 为什么服务高并发下报 502 query_vec openai.embeddings.create( inputquery, modeltext-embedding-3-small ).data[0].embedding results milvus.search( collection_nameknowledge_base, data[query_vec], limit3, output_fields[content, source] )这段代码没问题但它的隐含条件是用户的问题描述已经足够清楚并且相似度最高的文本就能支撑回答。但真实场景通常不会这么简单。比如用户问高并发下为什么报 502答案可能分散在 Nginx 错误码说明、upstream 超时配置、健康检查、发布记录和监控日志里。只做一次向量检索很可能召回错误码说明因为它语义最接近问题但这只能解释 502 是什么解释不了为什么现在才出现。再比如用户问怎么让 Python 跑得快文档写的是 CPython profiling、GIL contention、NumPy vectorization。两边说的是同一类问题但字面表达和语义重心都不完全一样。向量相似度能缓解这个问题不能保证每次都跨过去。这也是 RAG 被反复质疑的原因。但这些失败并不说明检索没价值它们暴露的是另一个问题很多RAG系统把检索当成了一次性动作那么该如何纠正这个问题本文将对此做重点解读。01RAG升级一混合检索补全语义短板如果传统nativeRAG 解决不了问题我们可以做的第一轮修补引入混合检索让检索别只依赖语义相似度。在技术文档、故障排查和企业知识库里关键词的重要性不比语义更低。错误码、配置项、函数名、合同编号、产品型号这些东西不能只靠语义猜。502、timeout、proxy_read_timeout 这种词一旦丢掉模型再会总结也没用。混合检索的价值就在这里由稠密向量负责捕捉语义层面的相近性由 BM25 或稀疏检索负责实现关键词的精确命中最后通过 RRF 或加权策略将两类检索结果融合兼顾语义相关性与关键词准确性。在混合检索的落地过程中过往很多系统采用向量数据库做语义检索外挂 Elasticsearch 做关键词检索的方案但这种方式很容易会因两套索引、两套写入链路以及两套系统的一致性问题陷入困境难以稳定运行。而 Milvus 混合检索很好的解决了这一痛点它可将稠密向量、稀疏向量、BM25 全文检索、元数据过滤及结果融合整合到同一条检索链路中彻底规避了多系统并行的繁琐与隐患。具体来看Milvus 实现混合检索有两种方式一是使用外部稀疏模型如 BGE-M3可将稠密向量与稀疏向量均作为向量字段进行检索二是使用 Milvus 内置的 BM25 功能此时只需为原始文本字段开启分析器Milvus 会自动生成稀疏向量查询时直接输入文本即可触发 BM25 检索。这里需要特别注意一个易混淆点BM25 功能的输出字段并非由应用侧手动插入的向量而是 Milvus 根据文本字段自动生成的。不过混合检索的核心作用只局限于改善特定场景的检索效果即用户问题中包含明确术语。但当问题本身方向不清晰或者答案需要多轮收集证据时混合检索就不够用了。02RAG升级二Agentic RAG 把检索变成一个循环Agentic RAG 往前走了一步让模型参与检索过程。它不再默认第一次检索就足够而是让 Agent 看结果、判断缺口、改写 query、拆分问题再继续搜。用户问高并发 502Agent 会先查错误码再查 upstream timeout再补一轮健康检查和最近发布记录。检索从一次动作变成了一个循环。Agentic RAG 最核心的优化在于检索循环。它能把查一次变成查多次把一个 query 变成多个 query把粗糙问题变成更接近文档表达的问题。但它默认知识访问工具还是同一个search_docs。Agent 在这个工具里能做的事主要是换问法、换关键词、换拆解方式。这就是它的强项也是它的限制。如果问题只是信息没办法一次召回全Agentic RAG 很有用。如果问题需要切换信息源、调用不同工具、遵守不同权限、按组织或租户平衡结果只依靠检索工具就开始无法满足需求。换句话说当向量相似度高不等于答案正确再多的搜索次数也没法解决问题。03RAG升级三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 用不用得顺手的差别它决定了每次查到的材料是否可控、可解释是否符合权限。04RAG升级四分流以上三种方式没有所谓的最优解大多数时候系统需要一个更明确的判断标准什么问题该走短路径什么问题必须交给 Agent 反复探索。总结来说有些问题天然适合native RAG混合检索。它有明确对象、明确关键词、明确资料边界比如查某个 API 参数、某个错误码、某条政策说明。这种情况下混合检索、过滤和 rerank 做扎实收益比引入复杂 Agent 更大。Agentic RAG 更适合问题方向明确但信息分散的情况。比如为什么这个服务最近变慢或者某个指标异常可能和哪些配置有关。它需要拆解需要补查需要根据第一轮结果修正 query。Agent Skills 则适合那些问题一开始就不清楚的情况。比如帮我排查这个线上问题或者评估这个客户投诉背后的根因。这里没有一个固定 query 可以直接打进向量库。系统需要在文档、日志、工单、监控、变更记录之间移动需要决定下一步查什么甚至需要先问用户补充环境。过去RAG 之所以总被判死刑是因为很多人把它等同于一次向量召回。而RAG 之所以总能诈尸是因为外部知识需求从来没消失。真正消失的是那种把检索当成 prompt 前置步骤的粗糙设计。留下来的是更底层、更工程化的知识访问层。而在这个演进过程中我们始终需要一个能处理简单查找也要能支撑多轮探索能召回语义相近的内容也能抓住精确术语能把结果交给模型也能配合模型解释这些结果来自哪里、满足什么权限的企业级向量数据库。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】