1. 从“当红炸子鸡”到“基础组件”RAG的定位变迁如果你在2023年底到2024年初关注过AI应用开发一定会对“RAG”这个词感到无比熟悉。那时候几乎所有的技术分享、产品发布和创业BP如果不提一嘴RAG似乎就落伍了。它被描绘成解决大模型“幻觉”和知识更新问题的银弹是连接私有数据与通用大模型的桥梁。然而到了2024年下半年一个有趣的现象出现了单独讨论RAG的声音似乎变少了。在技术社区、行业峰会甚至是一些新产品的宣传中RAG不再是一个需要被大书特书的独立概念而是更多地被融入到“AI Agent”、“智能体”或“企业级AI应用”的叙事里成为了一个默认的、基础性的组件。这并不意味着RAG不重要了恰恰相反它变得太重要、太基础了以至于“日用而不自知”。就像我们今天开发一个Web应用不会再把“使用HTTP协议”或“拥有数据库连接池”作为核心卖点来宣传一样。RAG技术本身已经走过了概念验证和早期探索阶段进入了工程化、标准化和深度集成的成熟期。它的核心价值——通过检索外部知识来增强大模型的生成准确性和时效性——已经被广泛接受并成为AI应用设计的默认范式。因此讨论的焦点自然地从“要不要用RAG”转向了“如何更好地用RAG”以及“如何用RAG构建更复杂的智能体Agent”。当前的趋势是RAG作为“知识获取与增强”的核心能力被下沉为AI Agent架构中的一层。一个典型的现代AI Agent架构可以粗略地理解为LLM大语言模型是大脑负责核心推理和决策Agent框架如LangChain、LlamaIndex、Dify等是神经系统和工具集负责协调行动、调用技能而RAG通常与向量数据库、知识图谱等技术结合则是这个智能体的“长期记忆”或“外部知识库”。Harness这类基础设施层则负责包裹在这些核心逻辑之外提供可观测性、评估、安全防护和流程编排等能力。所以当大家热议如何搭建一个能自主处理Zabbix告警的AI Agent或者如何开发一个基于C#的Agent框架时RAG已经是其内部一个不可或缺的、但无需单独强调的模块了。2. RAG技术栈的成熟与挑战固化RAG讨论热度的相对“降温”另一个深层原因是其技术栈已经形成了相对清晰的共识和最佳实践同时其固有的挑战也已被充分认知不再是令人兴奋的“新问题”而是需要扎实工程功夫去解决的“老难题”。2.1 技术栈的收敛与标准化早期RAG的实现五花八门但现在一个高效的生产级RAG系统架构已经趋于稳定通常包含以下几个核心环节这也对应了相关热搜词中的“rag 架构(知识切片、向量化、多路召回、重排序)”知识切片Chunking如何将PDF、Word、网页等非结构化数据切割成适合检索的片段。从简单的按字数/段落切割发展到基于语义的切割如使用嵌入模型判断边界、递归切割以及混合策略目标是在保留上下文完整性和检索精度之间找到平衡。针对“pdf rag 切片”的讨论现在更关注如何根据文档结构标题、图表进行智能分块而非简单的固定长度。向量化Embedding与索引选用什么样的嵌入模型如OpenAI的text-embedding-3系列、BGE、M3E等以及如何构建索引如使用FAISS、Chroma、Pinecone、Weaviate等向量数据库。这部分已经高度工具化开发者只需根据对精度、速度、成本和多语言支持的要求进行选型即可。多路召回Retrieval这是工程优化的重点。除了基础的向量相似度搜索稠密检索成熟的系统会融合关键词搜索稀疏检索如BM25、元数据过滤如日期、作者、甚至基于知识图谱Graph RAG的关系检索。多路召回的目的是提高查全率确保不遗漏任何可能相关的信息。重排序Reranking对召回的多篇文档进行精排。使用专门的重排序模型如BGE-Reranker、Cohere Rerank对初始结果进行二次评分将最相关、质量最高的文档排到最前面显著提升最终输入LLM的上下文质量。这是提升RAG效果性价比最高的手段之一。提示工程与生成将重排序后的顶级文档作为上下文通过精心设计的提示词Prompt交给LLM如Qwen2.5、GLM、GPT-4等生成最终答案。这里涉及上下文窗口的管理、提示词模板的优化等。像LlamaIndex、LangChain这样的框架以及Dify、FastGPT等低代码平台已经将这些环节封装成了可配置的模块。开发者不再需要从零开始搭建管道而是像搭积木一样组合这些组件。因此讨论的重点从“如何实现RAG”变成了“如何用LlamaIndex实现混合检索”或“如何在Dify中优化重排序策略”。2.2 固有挑战的显性化与工程化应对随着应用的深入RAG的痛点也变得非常明确社区讨论转向了如何系统性地解决这些痛点而非仅仅指出它们检索质量瓶颈“垃圾进垃圾出”是铁律。如果知识切片不合理、向量模型不匹配、召回策略单一检索回来的文档质量就差最终生成效果必然不佳。这催生了对“RAG评测系统”的需求需要一套自动化流程来评估切片、检索、生成各环节的效果。上下文窗口与信息丢失即使检索到相关文档如何将长篇文档塞进有限的上下文窗口如何避免关键信息在压缩或摘要过程中丢失这涉及到动态上下文压缩、摘要提取等进阶技术。复杂查询与多跳推理对于需要串联多个文档才能回答的复杂问题基础RAG显得力不从心。这推动了“Agentic RAG”和“Graph RAG”的发展即让AI Agent具备主动、多步检索和推理的能力或者利用知识图谱来建模实体关系实现更复杂的查询。数据更新与一致性知识库更新后如何快速、增量地更新向量索引如何保证检索结果的一致性这需要设计稳健的索引更新管道和版本管理策略。这些挑战的解决方案往往超越了单一的RAG组件需要放在整个AI Agent或应用系统的层面来考量。因此我们看到更多的讨论是关于“AI Agent架构”如何整合RAG或者“Harness基础设施层”如何监控和评估RAG管道的健康状况。3. AI Agent的崛起与RAG的角色内化2024年无疑是“AI Agent”之年。当技术圈的目光被能够自主理解目标、规划任务、调用工具包括搜索、执行代码、操作软件并完成复杂工作的智能体所吸引时作为其能力子集的RAG自然从台前走到了幕后。3.1 RAG成为Agent的“标配技能”一个功能完备的AI Agent其技能Skill工具箱里几乎必然包含“检索增强生成”这一项。无论是让Agent去分析一份最新的财报还是回答关于公司内部政策的问题它都需要调用背后的RAG系统来获取精准知识。在诸如“基于C#开发的AI Agent开发框架”或“Spring AI实现自主Agent”的语境下集成RAG能力是一个基础需求框架提供者会将其作为核心模块之一来设计和实现。例如在“Zabbix接入AI Agent实现自动处理故障”的场景中Agent需要具备以下能力1理解告警信息LLM2根据告警类型从知识库可能是运维文档、历史故障处理记录中检索相似案例和解决方案RAG3根据检索到的知识规划处理步骤如执行某个重启脚本、联系某个负责人4执行行动。在这里RAG是第二步的关键赋能者但它只是Agent完整工作流中的一个环节。3.2 Agentic RAG从被动检索到主动求知这是RAG演进的一个重要方向也是它不再被单独提及的原因——它正在变得更具主动性。传统的RAG是“问答式”的用户提问系统检索然后生成答案。而Agentic RAG则赋予了系统“思考”和“追问”的能力。查询改写与扩展Agent在收到原始问题后会先利用LLM对问题进行改写、分解或扩展生成多个更利于检索的查询词条再进行并行检索最后综合所有结果进行生成。这大大提升了应对模糊或复杂问题的能力。迭代检索与验证Agent在获得初步检索结果后可能会判断信息是否充足。如果不足它可以自主生成新的、更深入的问题发起新一轮检索直到收集到足够的信息来形成可靠答案。这个过程模仿了人类的研究行为。与工具调用的结合Agent可以将RAG检索到的信息如一个API的使用方法作为调用实际工具如执行该API的依据形成“知识-行动”的闭环。在这种范式下RAG不再是终点而是Agent进行持续认知和行动中的一个持续性、交互性的环节。讨论的单元自然就变成了整个“智能体”而非其内部的检索子系统。4. 开发者关切的转移从概念到实施与评估对于广大开发者和技术团队而言关于RAG的讨论焦点发生了切实的转移这直接反映在热搜词的变化上。4.1 学习路径的深化早期问题多是“RAG是什么”、“如何快速搭建一个RAG”。现在问题变成了“AI Agent学习路线”如何系统性地掌握构建智能体所需的知识包括但不限于RAG、工具调用、任务规划、记忆机制等。“RAG项目实战”/“RAG面试题”关注点在于真实的、复杂的业务场景中如何应用和优化RAG以及企业招聘时会对RAG相关工程能力提出哪些具体问题。“深入理解AI Agent”希望从架构和原理层面吃透智能体理解RAG在其中如何与其他组件如记忆流、技能库、规划器协同工作。4.2 工程化与生产就绪“RAG工程化”成为核心关切。这意味着大家不再满足于一个能跑通的Demo而是关心性能与成本检索延迟如何优化向量索引规模大了怎么办嵌入和重排序的API调用成本如何控制可观测性与评估如何监控RAG管道每一步的效果如何搭建一个自动化的“RAG评测系统”来衡量检索相关性、答案准确性如何实施A/B测试对比不同策略数据安全与合规私有数据在向量化和检索过程中的安全如何保障如何满足审计要求运维与部署如何实现知识库的持续、增量更新如何在不同环境开发、测试、生产中部署和配置RAG服务关于“Linux安装PGsql开启RAG”这类问题背后是对稳定、可控的基础设施的需求。4.3 技术选型的细分场景化讨论变得更加具体和场景驱动垂直领域“Ontology RAG”本体论RAG探讨如何在金融、医疗等专业领域利用领域本体来提升检索精度。“Graph RAG”关注如何利用图结构处理高度关联的知识。特定框架“LangChain RAG”和“LlamaIndex RAG”的讨论聚焦于在特定生态下的最佳实践和高级特性。模型选择“事实问答/RAG用Qwen3”这类话题是在具体任务上对不同大语言模型效果的实证探讨。全栈实现“AI Agent开发 工具”和“AI 开发Agent用Java还是Python有哪些生态”则反映了开发者从算法原型向完整、可维护的生产系统构建的转变。5. 未来展望RAG的隐形化与智能化所以RAG并非“过时”或“被淘汰”而是正在经历一场深刻的“隐形化”和“智能化”转型。5.1 深度集成与隐形化未来RAG将更进一步作为标准化的云服务或中间件被提供。应用开发者可能只需要通过一个API调用传入文档和问题就能得到增强后的答案而完全无需关心背后的切片策略、向量模型或召回算法。它将像数据库索引一样成为AI应用开发中一个强大但不可见的基础设施。Harness这类平台所倡导的“基础设施层”概念正是为了管理和优化这些隐形却关键的能力。5.2 与更复杂认知模型的融合单纯的“检索-生成”模式会向更复杂的认知框架演进。例如与推理链Chain-of-Thought结合RAG提供事实依据LLM在此基础上进行逐步推理生成更逻辑严谨的答案。与长期记忆Long-term Memory结合将RAG检索到的信息根据重要性筛选后存入Agent的长期记忆供未来会话参考实现知识的持续积累。多模态RAG检索的对象不再限于文本而是扩展到图像、音频、视频实现真正的多模态知识增强。5.3 对开发者的新要求对于开发者而言单独掌握RAG原理可能不再构成显著优势。未来的竞争力体现在系统架构能力如何将RAG、Agent、工作流引擎、评估系统等组件优雅地整合成一个稳定、高效、可扩展的AI应用系统。领域知识工程能力如何为特定行业如法律、金融、医疗设计和优化知识切片、索引和检索策略打造真正专业的领域智能体。评估与优化能力如何建立数据驱动的迭代闭环通过科学的评估指标持续优化RAG管道乃至整个Agent的性能。总而言之RAG提及的减少是一个技术成熟并融入更大范式的健康标志。它从一个人人谈论的时髦概念沉淀为AI应用特别是AI Agent架构中坚实的一块基石。现在的沉默不是遗忘而是内化。当我们热烈地讨论AI Agent的架构、规划和行动能力时RAG正在其中默默地、可靠地履行着它“知识守门人”的职责。作为开发者我们的视角也应该随之升级从“如何搭建一个RAG”转向“如何设计一个以RAG为知识核心的智能体系统”并解决随之而来的所有工程化挑战。这标志着行业正在从技术探索期迈入价值创造和规模应用的新阶段。