最近这段时间“Agent”可以说是整个AI圈子里出现频率最高的词。几乎每天都有朋友来问我Agent这么火我的RAG项目还要不要继续做或者反过来说RAG做起来又慢又笨是不是应该直接上Agent这些问题我踩了不少坑才慢慢想明白。RAG和Agent从来就不是二选一的对立关系。在真实业务落地里RAG是Agent的“补给线”负责把外部知识准确送到模型嘴边Agent则是RAG的“调度中枢”决定什么时候该查、该查什么、查完怎么用。这篇指南就是想把这两件事彻底讲清楚什么场景单纯做RAG就够了什么场景必须升级成Agentic RAG框架怎么选才不会踩坑以及实战落地时那些文档里查不到的细节。如果你是刚接触RAG的初学者这篇文章能帮你避开“Demo做得出来、生产上不去”的尴尬如果你已经做了几个RAG项目正在纠结要不要引入Agent那你更能在里面找到直接的选型判断和实战经验。1. Agent时代RAG为什么反而更重要1.1 先搞清楚RAG到底解决什么问题很多人在聊RAG时第一反应就是“向量数据库加向量检索”。这个理解不能算错但太表面了。RAG的全称是检索增强生成Retrieval-Augmented Generation它的核心价值其实有两条第一给大模型补充它没见过的事实知识第二给大模型提供可追溯的来源依据。大模型训练语料再大也逃不过“知识截止时间”和“幻觉”这两个硬伤。业务场景里恰恰最不缺这两种问题——用户问的是刚刚更新的政策条款、内部知识库里某个流程的细节、产品手册里某句话的具体出处。这些数据大模型在预训练阶段根本没看过直接问它它只能靠相似文本去“编”。而RAG做的事情就是在模型开口之前先到外部知识源里把相关材料捞回来塞进上下文作为证据让模型“照着材料说”。我习惯把这个过程比喻成一个带研究员岗位的客服团队。大模型是那个负责说话的客服RAG是旁边随时待命的资料员。用户问“咱们公司今年报销规则改成什么了”客服不用背下整套制度它会叫资料员去查文档查到之后照着念再附上出处。这样做的好处非常直接回答的准确性大幅提升遇到没把握的问题敢说“我不知道”而不是理直气壮地瞎编而且每一句话背后都有据可查。这三点恰好是企业级应用最看重的。1.2 传统RAG的三个死穴但传统RAG有一个很尴尬的现状Demo做得出来生产上不去。我自己就经历过那个阶段调通了第一个RAG原型丢进去几十个文档回答得很漂亮结果把语料扩大到几千份之后准确率直线下滑甚至连环翻车。复盘下来传统RAG在真实场景里绕不过三个死穴。第一个是单轮检索的局限。传统RAG的流程非常线性收问题、向量化、检索Top-K、拼上下文、生成答案。问题一复杂就露馅。比如用户问“帮我对比一下A产品跟B产品在数据安全上的差异”单个向量检索很容易把两个产品的文档混在一起Top-K返回的结果要么全是A产品要么A和B的相关段落根本没被同时召回模型根本凑不齐对比材料回答自然支离破碎。第二个是查询表达跟语料表达之间的鸿沟。用户提问是口语化的“报销单要盖几个章才算数”而企业内部文档里的表述是“审批流程需完成签字及盖章后方可生效”。这两种文本在向量空间里的距离很远直接拿用户原话去检索召回率非常差。这个坑我一开始完全没意识到总以为是Embedding模型不够好后来才发现问题出在查询和文档的语言风格不在一个频道上。第三个是缺少工具能力。传统RAG只能“查”不能“算”不能“调接口”不能“多步迭代”。它没有办法完成需要先查数据库再按逻辑计算的任务也没有办法在查到多个候选答案之后做二次核实。一旦业务逻辑涉及到“查询、计算、比对、判断”这种多步骤动作传统RAG的单次检索-生成流程就彻底不够用了。这三个死穴正是我们考虑Agent化的真正原因。RAG并没有过时而是需要被Agent升级。1.3 Agent给RAG补了哪些关键能力Agent给RAG带来的变化不是换了个名字而是把“一条流水线”变成了“一个会做计划的人”。Agent可以自主决定检索的时机和次数可以把一个复杂问题拆成多个子查询可以在检索结果上继续推理还能动态调用其他工具。现在很多人说的Agentic RAG本质上就比传统RAG多了三个核心能力。第一是查询分解与规划。面对一个复杂任务Agent会自己判断该拆成几个子问题按顺序逐个检索。比如“帮我整理一份新员工入职需要完成的全部事项”Agent不会只查一次文档它会拆分出行政流程、IT账号、财务报销、培训安排这几个子问题分别完成检索后再汇总成一份完整清单。第二是工具编排。除了查向量知识库Agent还能同时使用SQL查询、业务接口、外部搜索甚至另一个Agent工具。整个系统从“只能检索文本”变成“可以调用任意数据源和业务系统”。这一步是质的飞跃它能解决很多RAG完全处理不了的场景比如“查一下上个月订单量最高的三个区域并把对应区域的负责人联系方式整理出来”。第三是记忆与反思。Agent可以记住前几步查到了什么。如果发现证据不足它会尝试换一批关键词再查一轮或者对已经拿到的检索结果做交叉验证。这不再是“问一次查一次”的呆板流程而是有迭代、有反馈的智能检索过程。理解完Agent给RAG补的这三板斧你再看市面上的各种方案就会有一个清醒的判断如果业务场景只需要简单的问答Agent是多余的成本如果业务场景需要多步推理、多源整合、动态判断传统RAG又远远不够。2. RAG的技术路线到底怎么选2.1 从Naive RAG到Advanced RAG再到Agentic RAG业界通常把RAG的发展分成三个阶段Naive RAG、Advanced RAG和Agentic/Modular RAG。理解这条演进路线你就知道“技术选型”到底在选什么。Naive RAG就是最朴实无华的那套“检索-增强-生成”流程文档切块、向量化、存向量库、检索Top-K、拼Prompt、给LLM生成。它的优势是理解成本低、搭建速度快适合文档量小、问题类型单一的问答场景。我见过不少中小企业用它做规章制度问答效果就够用。短板也很明显语义鸿沟、跨文档聚合能力弱、对复杂问题无能为力。做出来的系统本质上是个“高级搜索框”离真正的知识助手差距很大。Advanced RAG针对Naive RAG的短板在检索前和检索后两条链路都做了增强。检索前增加查询改写、路由判断、HyDE一种让模型先尝试生成伪文档再做相似检索的思路等策略把用户口语化的问题转化成更贴近文档的表达检索后增加重排序Re-ranking、上下文压缩、去重和融合把Top-K结果的质量再提一层。中间阶段还可以使用混合检索把稀疏检索BM25等和稠密检索向量Embedding结合起来提高数字、编号、专有名词类查询的召回率。这一阶段的目标很明确不引入Agent复杂度但把“搜得准”这件事尽量做到极致。Agentic RAG则进一步打破了流水线结构。它引入一个LLM驱动的Agent充当调度器把查询改写、检索、总结、判断这些步骤都变成可被调用的模块由模型根据上下文动态路由。处理复杂问题时Agent能自己决定多查几次、换个方式查、查完再按需计算。它的能力上限比前两者高得多但代价是更长的延迟、更高的Token消耗和更棘手的调试难度。所以选型时必须想清楚你的业务到底值不值得付这笔“智能税”。2.2 六种主流RAG架构及其适用场景结合我自己的项目经验我一般把当前实际能落地的RAG方案归成六种你可以在选型时直接对照。基础向量RAG适合单一知识库、问法简单的问答场景。比如企业内部的规章制度问答文档就几百份用户问题也不复杂直接用最基础的切块、向量化、Top-K流程就够了。这种方案成本低、上线快别为了追热点硬上Agent。高级RAG查询改写加混合检索加重排适合文档量偏大、长尾问题多、准确率要求高的场景。典型表现是知识库有好几个GB用户提问千奇百怪这时候单纯靠基础向量检索根本顶不住。把检索链路上的细节打磨到位命中率能有非常明显的提升。多路召回RAG多个知识库加路由适合企业多个部门知识库并存、需要自动选择正确数据源的场景。比如法律部、财务部、运营部各有一套文档面对用户问题要先判断该搜哪个库或者同时检索再融合。这种方案可以配合路由模型或规则把请求分流到对应知识库。图RAGGraphRAG / Ontology RAG适合强关系类的问答。比如组织机构关系、合同条款之间的关联、产品线上下游依赖。图结构能把实体之间的关联关系显式表达出来回答“A部门和B部门在哪些项目上有协作”“这个产品变更会影响哪些下游系统”这类问题时效果远比纯向量检索好。Agentic RAG适合复杂的业务问答、需要调用工具和API的流程型任务。比如“查一下这个客户的最后三笔订单再结合退货政策给出处理建议”单靠RAG做不了必须有Agent规划、调用多个工具、汇总答案。微调加RAG混合适合专业术语极多、输出格式要求统一的垂直领域比如医疗、法律、金融风控。纯RAG召回的专业表述可能不够规范先做一个领域微调的小模型再配合RAG实时检索资料两者叠加往往能达到业务可用的效果。关于GraphRAG这个方向如果你正在做企业知识图谱或者复杂实体关系问答可以专门去了解一下。它的核心思想是在文档块的基础上抽取实体和关系构建图索引再配合图查询完成检索。虽然构建成本不低但在关系类问题上收益确实明显。2.3 选型决策的四个判断问题面对这么多路线很多人的第一反应是“能不能给个标准答案”。我可以很明确地说没有标准答案但有一套判断逻辑。我建议在选型时直接问自己四个问题。第一知识库有多大规模、更新频率怎么样几千份以内基础RAG加简单优化就能应付上百万级甚至千万级的文档你必须考虑用更重的方案比如GraphRAG、多级索引、并行检索集群。更新频繁的话还要考虑增量索引的合理设计。第二用户的问题是简单的还是复杂的你翻一翻历史工单、客服聊天记录统计一下问题类型。如果八成是FAQ式的“一句话问题”不要上Agent如果有不少问题是“帮我准备一份季度复盘”“梳理一下这个客户的完整投诉记录”你就需要Agent做规划和多轮检索。第三有没有外部系统交互需求需要查数据库、调第三方接口、发工单、更新订单状态这类场景没有Agent化几乎是做不到的Agent的工具调用能力就是刚需。第四你的预算和时间允许折腾多少Agent调试的复杂度远高于普通RAG。它不像RAG那样“输入输出是确定的”Agent在某些边界情况下会做出意料之外的工具调用这需要更多测试用例和更严格的护栏。如果项目只有三周工期建议优先考虑Advanced RAG方案把检索做扎实比硬塞一个不可控的Agent稳妥得多。3. 框架选型的真正关键点3.1 主流RAG与Agent框架盘点框架选型是最容易让人焦虑的环节。每次点开技术社区都有新的框架冒出来热度排行榜上你追我赶。我的建议是别只看热度用你自己的语料去实测。先聊几个我用过的框架谈谈真实感受。LangChain生态最大、资料最多但抽象层级非常多刚上手会觉得“这是一层套一层的洋葱”。它的好处是组件丰富字符串切块、向量存储、提示模板什么都包含社区遇到问题搜一下基本能找到案例。适合愿意投入学习成本、需要快速验证想法的团队。LlamaIndex对RAG的理解更专注。它对文档切分、索引组织、检索器组合的粒度控制非常细做纯知识库问答的场景上手体验比LangChain顺畅。如果核心诉求就是“把检索做得足够好”LlamaIndex很值得优先测试。Java技术栈的团队目前主流选择是Spring AI和LangChain4j。Spring AI是Spring生态官方的AI集成方案跟Spring Boot项目的亲和度最高LangChain4j则在接口设计上更贴近LangChain的思路中文社区里也有不少教程。这两个框架的RAG能力都已经比较完善向量检索、Prompt组装、简单的Agent工具调用都能做。如果你所在团队全员Java与其硬上Python不如认真考察这两个方向。Agent专用编排框架比如LangGraph、CrewAI、AgentScope等。LangGraph用图式工作流定义节点和边适合对流程有强控制的复杂AgentCrewAI强调多角色协作适合做“策划、执行、审核”这类角色分工明确的场景AgentScope这一类更新的框架则尝试把多Agent通信、任务协作和RAG能力服务化打包。特别是“RAG as a Service”的思路能把知识入库、检索、上下文构建这些能力统一封装成API多个项目共用一套RAG能力对中大型团队非常有吸引力。不要忽略本地化部署的方向。很多知识型团队受数据合规约束不允许把内部知识送到云上只能在本地跑模型。流行的组合是Ollama拉取开源大模型和Embedding模型向量库用Chroma或Qdrant搭一个简易的本地RAG知识库。这套方案最大的好处是零基础也能按教程复现部署成本很低。但要清醒认识到本地方案的体验上限取决于硬件GPU算力不够大模型推理慢最终效果容易被性能拖累别指望一台普通办公机能流畅跑起几十B的模型。3.2 RAG框架与Agent框架拼接时最容易忽略的三件事RAG框架选完之后真正的硬仗在“拼接”环节。我见过太多项目Demo阶段人人点赞接完Agent之后反而效果变差。原因不是Agent不好而是框架之间出现了信息割裂。第一RAG的检索结果能不能以结构化方式传给Agent很多RAG框架默认返回的是“拼好的一段上下文文本”Agent拿到之后看似顺滑但一旦需要判断该不该引用、该引用哪个来源它就无从下手。正确的做法是让RAG工具返回结构化结果比如每条结果都包含文本内容、来源文档ID、章节标题、相似度得分这些字段。这样Agent才能做真正的信息判断。第二Agent能不能拿到检索结果的置信度和来源元数据没有元数据的检索结果后面做重排序、可信度验证、引用溯源都会非常痛苦。我在项目里要求所有检索结果必须携带文档出处和时间戳这不只是为了合规更是为了让Agent在回答时能说清楚“这是什么时候的文档”避免拿旧政策回答新问题。第三整条调用链是否可观测Agent调用了哪些工具、每个调用耗时多少、Token消耗多少、中间结果是什么这些都得能记录和回放。调试Agent不像调试普通代码它的行为有一定随机性没有日志和追踪出了问题你只能干瞪眼。建议选型时就确认目标框架支持步进式追踪或者日志输出。另外一个容易被忽略的细节是查询语义的保持。很多Agent框架会默认把用户问题和历史对话一起传给工具如果工具端只做纯向量检索就可能把当前问题跟历史上下文混在一起导致检索漂移。我的解决方案是在Agent和RAG之间加一个显式的“查询抽取与改写”层把真正需要检索的独立问题抽出来再交给向量库。这一步看着不起眼但对命中率的提升非常直接。3.3 框架选型避坑以真实业务为准别只看热榜框架热度这个东西只能当作参考线索。很多框架在社区风评很好一换到自己的业务语料上效果平平。原因很简单开源社区的Demo语料主要是公开网页、新闻和英文技术文章和你的企业内部文档在主题、风格、粒度上完全不同。框架对文档结构的敏感度、对长文本的处理能力、对中文语义的理解都会影响最终效果。我建议选型时一定要做一次“最小可行性验证”。挑出业务里最有代表性的50到100个问题用不同框架各跑一遍记录命中率、首答时长、Token消耗和失败率。这份对比数据比任何评测榜都有参考价值。还有一点团队的技术栈和使用者习惯千万别低估。工具再好团队用不起来就是负资产。如果团队全是Java工程师硬上一个Python系框架后期维护成本会非常不可控。框架选型的本质是用长期维护预算交换短期开发速度的决策心里得时刻想着“这套代码是要维护三年的”这时候你会自然倾向好找人的技术栈、文档完整的框架而不是那个功能炫酷但社区冷清的新贵。4. 实操落地从零搭一个可上线的RAGAgent方案4.1 数据管线构建的三个关键步骤不管选哪种RAG路线数据管线都是地基。地基不稳后面所有优化都是白费。我把实操要点拆成三步。第一步是文档清洗。这一步听着简单实际是最容易翻车的。PDF文档里的页眉页脚、目录页、水印要去掉表格数据要保留结构而不是被打成一段乱文扫描件要先做OCR识别。数据不干净切出来的文本块就会带着大量噪音检索回来的上下文全是“第x页”“目录”之类的垃圾再好的大模型也救不回来。我吃过这个亏老老实实做了一轮数据清洗之后命中率直接上了两个档次。第二步是智能切块。切块大小是个经典问题。固定250字还是500字没有标准答案关键看你的Embedding模型和问答粒度。实际操作时我更推荐“按结构切块”先用Markdown或HTML标签保留文档的标题层级再在段落和小节边界切块同时保留父子块信息。这样检索时既能召回整章内容也能精确定位到具体段落。对于切块边界问题一个辅助技巧是做片段重叠让相邻块保留几十个字的重叠文本避免语义在边界处被切断。第三步是索引与元数据设计。给每个文本块打上来源文件名、章节标题、文档类型、更新时间等元数据。这不只是为了将来做过滤更是Agent回答时追溯来源的骨架。没有元数据的知识库后期做重排序和可信度验证几乎寸步难行。举个简单例子管理员想限定“只查2024年之后的制度文档”如果索引里没有时间字段这个需求就没法实现。4.2 检索质量优化的两个核心参数与两组关键指标上线之后最常见的瓶颈是检索命中率不够。这里说两个最见效的优化方向。第一个是查询改写。别指望用户会按文档语言提问。一个很实用的做法是引入两步检索策略第一轮用原问题直接召回粗结果第二轮根据首轮结果让模型生成两到三个改写后的问题分别再检索最后对多路结果做融合去重。这个策略我在复杂问法下实测过命中率能提升十个到十几个百分点尤其对长尾口语化问题非常明显。第二个是重排序。向量检索的Top-K只是“初步相关”后面一定得再做一次精排。因为向量模型的语义相关度未必等同于“这里真的有正确答案”。用交叉编码器模型把候选从Top-50压缩到Top-5准确率提升非常显著。有人会觉得多一步增加了延迟但在准确率优先的场景里这是值得付的成本。在衡量优化效果时我建议盯住两个指标。一个是Hit Rate命中率也就是正确答案是否出现在检索结果里另一个是MRR平均倒数排名衡量正确答案在排序里的位置。这两个指标能剥离LLM生成环节的干扰单独衡量“检索”本身的质量。不要只盯着端到端的LLM回答效果那是个黑盒出了问题很难归因先单独把检索质量提上去再去调生成环节。4.3 把RAG接入Agent的三层写法最后讲代码落地层面。我建议把RAG接入Agent分成三层来写RAG服务层、工具层、Agent调度层。这样每个角色职责清晰调试时也很容易定位问题。RAG服务层封装所有检索细节对外只暴露一个查询接口返回结构化结果包含文本列表和元数据。工具层把RAG服务包装成Agent可调用的工具函数同时可以继续挂上SQL查询、API调用等其它能力。Agent调度层才由LLM驱动负责基于用户目标和工具返回值决定下一步动作。这里给一个面向Agent更透明的伪码你可以照着理解# 工具层把RAG服务包装成Agent可调用的工具 def search_knowledge(query: str, top_k: int 5) - list[dict]: results rag_service.search(query, top_ktop_k) return [ { content: hit[content], source: hit[metadata][source_doc], score: hit[score], timestamp: hit[metadata][update_time], } for hit in results ] # Agent调度层让大模型决定何时检索、是否需要追加查询 def agent_run(user_query: str): agent create_agent( tools[search_knowledge, query_database, call_order_api] ) return agent.run(user_query)这层的核心原则是工具要返回可追溯的结构化数据而不是拼好的纯文本。另外给Agent加一个“无法确定时如实说明”的提示让它查不到资料时明确承认没有找到而不是硬凑答案。这一个提示词能有效压低幻觉比例。如果你只想先在本地快速跑通一个最小案例我推荐Ollama加Chroma的组合。Ollama负责加载本地Embedding模型和生成模型Chroma做向量存储整个链路只需要一台机器就能运行。很多零基础可复制的RAG教程都是这么搭的拿来验证数据流程和检索效果完全够用。等系统要通过性能测试、接真实用户流量再考虑部署到更高吞吐的方案上。5. 常见问题与排查技巧实录5.1 RAG命中率低先查这四个地方如果你发现RAG回答总是不对劲不要急着换模型先按顺序排查这四个位置。第一是切块质量。抽检几个文本块看看有没有被硬切碎、语义不完整的情况。第二是查询表达。拿用户原问题去检索一次再手动改成文档风格的语言去检索一次对比两个结果就知道是不是查询改写的问题。第三是匹配策略。如果知识库里大量是数字、编号、合同号、专有名词纯向量检索往往吃不住加上BM25这类稀疏检索做混合效果通常立竿见影。第四是干扰数据。看知识库里是不是存在高度相似的噪声文档它们会让候选结果互相打架。用Metadata加过滤条件限定部门、时间范围、文档类型是性价比很高的解法。这四项排查完大部分命中率问题都能定位。如果还没有改善再考虑是不是Embedding模型跟你的领域语言风格不匹配换一个在中文或垂直领域表现更好的Embedding模型或者直接走微调路线。5.2 Agent调用工具失败基本都是这几个原因项目里经常看到类似“Agent execution terminated due to error.”这类报错很多人第一反应是模型不够聪明。但从我排查的经验看绝大多数情况根本不是模型的问题而是工具协议没写对。常见原因有三个。第一个是工具签名太复杂参数要求模糊模型无法正确生成入参。解决办法是给工具写简短的描述每个参数都写明约束和示例。第二个是返回类型不规范。如果工具返回的字段含义不清晰模型在下一步推理时就会迷失。返回结构要固定成JSON并且在工具说明里写明每个字段的含义。第三个是超时设置过紧。Agent执行长链路任务时如果工具响应稍慢就被判定失败整条任务直接中断。给超时留出合理余量并允许Agent在失败后重试一次成功率会明显提升。举个例子一个工具如果定义成“search(query: str, filters: dict)”模型很可能不知道filters应该传什么。改成“search(query: str, doc_type: str ALL, start_date: str )”并且注明“doc_type可选值为ALL、POLICY、ANNOUNCEMENT”模型调用成功率高得多。5.3 成本和延迟失控预算与服务目标如何平衡很多人做技术方案的时候特别容易忽略成本和延迟等上线之后被账单和用户体验打脸。同一个用户问题基础RAG可能只需要一次LLM调用Agentic RAG可能要串四到五次调用Token消耗直接翻几倍。在设计系统的时候几个控制手段非常关键。第一给Agent限定最大迭代步数。不要让Agent无限循环地思考下去给一个合理的上限比如最多5步工具调用超出就直接汇总已有结果。第二在系统提示里明确要求Agent“优先复用已有检索结果不重复搜索”。第三把热点问题和常见知识块的检索结果做缓存。同一个政策问题一天被问几百次每次还跑全链路检索纯属浪费算力。延迟方面先看总耗时构成。如果绝大部分时间花在LLM推理上就得考虑精简Prompt或者换一个小一点的模型如果卡在检索环节可以试试给向量库加索引优化或者把重排序范围缩小。方法本身不难难的是养成“先量化再优化”的习惯。项目上线前最好给服务设定一个预算上限和延迟上限超了要有人专门负责排查归因而不是让“Agent太慢”变成一个没法追责的问题。6 最后说点我的真实体会做了这么多RAG和Agent项目我最深的感受是别追着新概念跑。Agent确实是当前的大方向但它的本质不过是让模型拥有了一个工具箱和一个规划器。你的业务方不会太在意底层用了什么框架他们关心的永远是回答准不准、快不快、成本受不受控、出了问题能不能追溯。把这四件事做好RAG怎么选、Agent怎么上你自然就有了属于自己的取态。在你纠结选型的时候不妨先拉一个真实的小数据集搭个最小的原型跑一遍端到端的流程让业务方亲自体验一次。有了真实反馈再做决定远比在网上翻一百篇评测都管用。 
长河君 · 2026/11/3 23:24:32 · 阅读 1.2k RAG与Agent如何选型与协同？从检索增强到Agentic RAG实战指南
最近这段时间“Agent”可以说是整个AI圈子里出现频率最高的词。几乎每天都有朋友来问我Agent这么火我的RAG项目还要不要继续做或者反过来说RAG做起来又慢又笨是不是应该直接上Agent这些问题我踩了不少坑才慢慢想明白。RAG和Agent从来就不是二选一的对立关系。在真实业务落地里RAG是Agent的“补给线”负责把外部知识准确送到模型嘴边Agent则是RAG的“调度中枢”决定什么时候该查、该查什么、查完怎么用。这篇指南就是想把这两件事彻底讲清楚什么场景单纯做RAG就够了什么场景必须升级成Agentic RAG框架怎么选才不会踩坑以及实战落地时那些文档里查不到的细节。如果你是刚接触RAG的初学者这篇文章能帮你避开“Demo做得出来、生产上不去”的尴尬如果你已经做了几个RAG项目正在纠结要不要引入Agent那你更能在里面找到直接的选型判断和实战经验。1. Agent时代RAG为什么反而更重要1.1 先搞清楚RAG到底解决什么问题很多人在聊RAG时第一反应就是“向量数据库加向量检索”。这个理解不能算错但太表面了。RAG的全称是检索增强生成Retrieval-Augmented Generation它的核心价值其实有两条第一给大模型补充它没见过的事实知识第二给大模型提供可追溯的来源依据。大模型训练语料再大也逃不过“知识截止时间”和“幻觉”这两个硬伤。业务场景里恰恰最不缺这两种问题——用户问的是刚刚更新的政策条款、内部知识库里某个流程的细节、产品手册里某句话的具体出处。这些数据大模型在预训练阶段根本没看过直接问它它只能靠相似文本去“编”。而RAG做的事情就是在模型开口之前先到外部知识源里把相关材料捞回来塞进上下文作为证据让模型“照着材料说”。我习惯把这个过程比喻成一个带研究员岗位的客服团队。大模型是那个负责说话的客服RAG是旁边随时待命的资料员。用户问“咱们公司今年报销规则改成什么了”客服不用背下整套制度它会叫资料员去查文档查到之后照着念再附上出处。这样做的好处非常直接回答的准确性大幅提升遇到没把握的问题敢说“我不知道”而不是理直气壮地瞎编而且每一句话背后都有据可查。这三点恰好是企业级应用最看重的。1.2 传统RAG的三个死穴但传统RAG有一个很尴尬的现状Demo做得出来生产上不去。我自己就经历过那个阶段调通了第一个RAG原型丢进去几十个文档回答得很漂亮结果把语料扩大到几千份之后准确率直线下滑甚至连环翻车。复盘下来传统RAG在真实场景里绕不过三个死穴。第一个是单轮检索的局限。传统RAG的流程非常线性收问题、向量化、检索Top-K、拼上下文、生成答案。问题一复杂就露馅。比如用户问“帮我对比一下A产品跟B产品在数据安全上的差异”单个向量检索很容易把两个产品的文档混在一起Top-K返回的结果要么全是A产品要么A和B的相关段落根本没被同时召回模型根本凑不齐对比材料回答自然支离破碎。第二个是查询表达跟语料表达之间的鸿沟。用户提问是口语化的“报销单要盖几个章才算数”而企业内部文档里的表述是“审批流程需完成签字及盖章后方可生效”。这两种文本在向量空间里的距离很远直接拿用户原话去检索召回率非常差。这个坑我一开始完全没意识到总以为是Embedding模型不够好后来才发现问题出在查询和文档的语言风格不在一个频道上。第三个是缺少工具能力。传统RAG只能“查”不能“算”不能“调接口”不能“多步迭代”。它没有办法完成需要先查数据库再按逻辑计算的任务也没有办法在查到多个候选答案之后做二次核实。一旦业务逻辑涉及到“查询、计算、比对、判断”这种多步骤动作传统RAG的单次检索-生成流程就彻底不够用了。这三个死穴正是我们考虑Agent化的真正原因。RAG并没有过时而是需要被Agent升级。1.3 Agent给RAG补了哪些关键能力Agent给RAG带来的变化不是换了个名字而是把“一条流水线”变成了“一个会做计划的人”。Agent可以自主决定检索的时机和次数可以把一个复杂问题拆成多个子查询可以在检索结果上继续推理还能动态调用其他工具。现在很多人说的Agentic RAG本质上就比传统RAG多了三个核心能力。第一是查询分解与规划。面对一个复杂任务Agent会自己判断该拆成几个子问题按顺序逐个检索。比如“帮我整理一份新员工入职需要完成的全部事项”Agent不会只查一次文档它会拆分出行政流程、IT账号、财务报销、培训安排这几个子问题分别完成检索后再汇总成一份完整清单。第二是工具编排。除了查向量知识库Agent还能同时使用SQL查询、业务接口、外部搜索甚至另一个Agent工具。整个系统从“只能检索文本”变成“可以调用任意数据源和业务系统”。这一步是质的飞跃它能解决很多RAG完全处理不了的场景比如“查一下上个月订单量最高的三个区域并把对应区域的负责人联系方式整理出来”。第三是记忆与反思。Agent可以记住前几步查到了什么。如果发现证据不足它会尝试换一批关键词再查一轮或者对已经拿到的检索结果做交叉验证。这不再是“问一次查一次”的呆板流程而是有迭代、有反馈的智能检索过程。理解完Agent给RAG补的这三板斧你再看市面上的各种方案就会有一个清醒的判断如果业务场景只需要简单的问答Agent是多余的成本如果业务场景需要多步推理、多源整合、动态判断传统RAG又远远不够。2. RAG的技术路线到底怎么选2.1 从Naive RAG到Advanced RAG再到Agentic RAG业界通常把RAG的发展分成三个阶段Naive RAG、Advanced RAG和Agentic/Modular RAG。理解这条演进路线你就知道“技术选型”到底在选什么。Naive RAG就是最朴实无华的那套“检索-增强-生成”流程文档切块、向量化、存向量库、检索Top-K、拼Prompt、给LLM生成。它的优势是理解成本低、搭建速度快适合文档量小、问题类型单一的问答场景。我见过不少中小企业用它做规章制度问答效果就够用。短板也很明显语义鸿沟、跨文档聚合能力弱、对复杂问题无能为力。做出来的系统本质上是个“高级搜索框”离真正的知识助手差距很大。Advanced RAG针对Naive RAG的短板在检索前和检索后两条链路都做了增强。检索前增加查询改写、路由判断、HyDE一种让模型先尝试生成伪文档再做相似检索的思路等策略把用户口语化的问题转化成更贴近文档的表达检索后增加重排序Re-ranking、上下文压缩、去重和融合把Top-K结果的质量再提一层。中间阶段还可以使用混合检索把稀疏检索BM25等和稠密检索向量Embedding结合起来提高数字、编号、专有名词类查询的召回率。这一阶段的目标很明确不引入Agent复杂度但把“搜得准”这件事尽量做到极致。Agentic RAG则进一步打破了流水线结构。它引入一个LLM驱动的Agent充当调度器把查询改写、检索、总结、判断这些步骤都变成可被调用的模块由模型根据上下文动态路由。处理复杂问题时Agent能自己决定多查几次、换个方式查、查完再按需计算。它的能力上限比前两者高得多但代价是更长的延迟、更高的Token消耗和更棘手的调试难度。所以选型时必须想清楚你的业务到底值不值得付这笔“智能税”。2.2 六种主流RAG架构及其适用场景结合我自己的项目经验我一般把当前实际能落地的RAG方案归成六种你可以在选型时直接对照。基础向量RAG适合单一知识库、问法简单的问答场景。比如企业内部的规章制度问答文档就几百份用户问题也不复杂直接用最基础的切块、向量化、Top-K流程就够了。这种方案成本低、上线快别为了追热点硬上Agent。高级RAG查询改写加混合检索加重排适合文档量偏大、长尾问题多、准确率要求高的场景。典型表现是知识库有好几个GB用户提问千奇百怪这时候单纯靠基础向量检索根本顶不住。把检索链路上的细节打磨到位命中率能有非常明显的提升。多路召回RAG多个知识库加路由适合企业多个部门知识库并存、需要自动选择正确数据源的场景。比如法律部、财务部、运营部各有一套文档面对用户问题要先判断该搜哪个库或者同时检索再融合。这种方案可以配合路由模型或规则把请求分流到对应知识库。图RAGGraphRAG / Ontology RAG适合强关系类的问答。比如组织机构关系、合同条款之间的关联、产品线上下游依赖。图结构能把实体之间的关联关系显式表达出来回答“A部门和B部门在哪些项目上有协作”“这个产品变更会影响哪些下游系统”这类问题时效果远比纯向量检索好。Agentic RAG适合复杂的业务问答、需要调用工具和API的流程型任务。比如“查一下这个客户的最后三笔订单再结合退货政策给出处理建议”单靠RAG做不了必须有Agent规划、调用多个工具、汇总答案。微调加RAG混合适合专业术语极多、输出格式要求统一的垂直领域比如医疗、法律、金融风控。纯RAG召回的专业表述可能不够规范先做一个领域微调的小模型再配合RAG实时检索资料两者叠加往往能达到业务可用的效果。关于GraphRAG这个方向如果你正在做企业知识图谱或者复杂实体关系问答可以专门去了解一下。它的核心思想是在文档块的基础上抽取实体和关系构建图索引再配合图查询完成检索。虽然构建成本不低但在关系类问题上收益确实明显。2.3 选型决策的四个判断问题面对这么多路线很多人的第一反应是“能不能给个标准答案”。我可以很明确地说没有标准答案但有一套判断逻辑。我建议在选型时直接问自己四个问题。第一知识库有多大规模、更新频率怎么样几千份以内基础RAG加简单优化就能应付上百万级甚至千万级的文档你必须考虑用更重的方案比如GraphRAG、多级索引、并行检索集群。更新频繁的话还要考虑增量索引的合理设计。第二用户的问题是简单的还是复杂的你翻一翻历史工单、客服聊天记录统计一下问题类型。如果八成是FAQ式的“一句话问题”不要上Agent如果有不少问题是“帮我准备一份季度复盘”“梳理一下这个客户的完整投诉记录”你就需要Agent做规划和多轮检索。第三有没有外部系统交互需求需要查数据库、调第三方接口、发工单、更新订单状态这类场景没有Agent化几乎是做不到的Agent的工具调用能力就是刚需。第四你的预算和时间允许折腾多少Agent调试的复杂度远高于普通RAG。它不像RAG那样“输入输出是确定的”Agent在某些边界情况下会做出意料之外的工具调用这需要更多测试用例和更严格的护栏。如果项目只有三周工期建议优先考虑Advanced RAG方案把检索做扎实比硬塞一个不可控的Agent稳妥得多。3. 框架选型的真正关键点3.1 主流RAG与Agent框架盘点框架选型是最容易让人焦虑的环节。每次点开技术社区都有新的框架冒出来热度排行榜上你追我赶。我的建议是别只看热度用你自己的语料去实测。先聊几个我用过的框架谈谈真实感受。LangChain生态最大、资料最多但抽象层级非常多刚上手会觉得“这是一层套一层的洋葱”。它的好处是组件丰富字符串切块、向量存储、提示模板什么都包含社区遇到问题搜一下基本能找到案例。适合愿意投入学习成本、需要快速验证想法的团队。LlamaIndex对RAG的理解更专注。它对文档切分、索引组织、检索器组合的粒度控制非常细做纯知识库问答的场景上手体验比LangChain顺畅。如果核心诉求就是“把检索做得足够好”LlamaIndex很值得优先测试。Java技术栈的团队目前主流选择是Spring AI和LangChain4j。Spring AI是Spring生态官方的AI集成方案跟Spring Boot项目的亲和度最高LangChain4j则在接口设计上更贴近LangChain的思路中文社区里也有不少教程。这两个框架的RAG能力都已经比较完善向量检索、Prompt组装、简单的Agent工具调用都能做。如果你所在团队全员Java与其硬上Python不如认真考察这两个方向。Agent专用编排框架比如LangGraph、CrewAI、AgentScope等。LangGraph用图式工作流定义节点和边适合对流程有强控制的复杂AgentCrewAI强调多角色协作适合做“策划、执行、审核”这类角色分工明确的场景AgentScope这一类更新的框架则尝试把多Agent通信、任务协作和RAG能力服务化打包。特别是“RAG as a Service”的思路能把知识入库、检索、上下文构建这些能力统一封装成API多个项目共用一套RAG能力对中大型团队非常有吸引力。不要忽略本地化部署的方向。很多知识型团队受数据合规约束不允许把内部知识送到云上只能在本地跑模型。流行的组合是Ollama拉取开源大模型和Embedding模型向量库用Chroma或Qdrant搭一个简易的本地RAG知识库。这套方案最大的好处是零基础也能按教程复现部署成本很低。但要清醒认识到本地方案的体验上限取决于硬件GPU算力不够大模型推理慢最终效果容易被性能拖累别指望一台普通办公机能流畅跑起几十B的模型。3.2 RAG框架与Agent框架拼接时最容易忽略的三件事RAG框架选完之后真正的硬仗在“拼接”环节。我见过太多项目Demo阶段人人点赞接完Agent之后反而效果变差。原因不是Agent不好而是框架之间出现了信息割裂。第一RAG的检索结果能不能以结构化方式传给Agent很多RAG框架默认返回的是“拼好的一段上下文文本”Agent拿到之后看似顺滑但一旦需要判断该不该引用、该引用哪个来源它就无从下手。正确的做法是让RAG工具返回结构化结果比如每条结果都包含文本内容、来源文档ID、章节标题、相似度得分这些字段。这样Agent才能做真正的信息判断。第二Agent能不能拿到检索结果的置信度和来源元数据没有元数据的检索结果后面做重排序、可信度验证、引用溯源都会非常痛苦。我在项目里要求所有检索结果必须携带文档出处和时间戳这不只是为了合规更是为了让Agent在回答时能说清楚“这是什么时候的文档”避免拿旧政策回答新问题。第三整条调用链是否可观测Agent调用了哪些工具、每个调用耗时多少、Token消耗多少、中间结果是什么这些都得能记录和回放。调试Agent不像调试普通代码它的行为有一定随机性没有日志和追踪出了问题你只能干瞪眼。建议选型时就确认目标框架支持步进式追踪或者日志输出。另外一个容易被忽略的细节是查询语义的保持。很多Agent框架会默认把用户问题和历史对话一起传给工具如果工具端只做纯向量检索就可能把当前问题跟历史上下文混在一起导致检索漂移。我的解决方案是在Agent和RAG之间加一个显式的“查询抽取与改写”层把真正需要检索的独立问题抽出来再交给向量库。这一步看着不起眼但对命中率的提升非常直接。3.3 框架选型避坑以真实业务为准别只看热榜框架热度这个东西只能当作参考线索。很多框架在社区风评很好一换到自己的业务语料上效果平平。原因很简单开源社区的Demo语料主要是公开网页、新闻和英文技术文章和你的企业内部文档在主题、风格、粒度上完全不同。框架对文档结构的敏感度、对长文本的处理能力、对中文语义的理解都会影响最终效果。我建议选型时一定要做一次“最小可行性验证”。挑出业务里最有代表性的50到100个问题用不同框架各跑一遍记录命中率、首答时长、Token消耗和失败率。这份对比数据比任何评测榜都有参考价值。还有一点团队的技术栈和使用者习惯千万别低估。工具再好团队用不起来就是负资产。如果团队全是Java工程师硬上一个Python系框架后期维护成本会非常不可控。框架选型的本质是用长期维护预算交换短期开发速度的决策心里得时刻想着“这套代码是要维护三年的”这时候你会自然倾向好找人的技术栈、文档完整的框架而不是那个功能炫酷但社区冷清的新贵。4. 实操落地从零搭一个可上线的RAGAgent方案4.1 数据管线构建的三个关键步骤不管选哪种RAG路线数据管线都是地基。地基不稳后面所有优化都是白费。我把实操要点拆成三步。第一步是文档清洗。这一步听着简单实际是最容易翻车的。PDF文档里的页眉页脚、目录页、水印要去掉表格数据要保留结构而不是被打成一段乱文扫描件要先做OCR识别。数据不干净切出来的文本块就会带着大量噪音检索回来的上下文全是“第x页”“目录”之类的垃圾再好的大模型也救不回来。我吃过这个亏老老实实做了一轮数据清洗之后命中率直接上了两个档次。第二步是智能切块。切块大小是个经典问题。固定250字还是500字没有标准答案关键看你的Embedding模型和问答粒度。实际操作时我更推荐“按结构切块”先用Markdown或HTML标签保留文档的标题层级再在段落和小节边界切块同时保留父子块信息。这样检索时既能召回整章内容也能精确定位到具体段落。对于切块边界问题一个辅助技巧是做片段重叠让相邻块保留几十个字的重叠文本避免语义在边界处被切断。第三步是索引与元数据设计。给每个文本块打上来源文件名、章节标题、文档类型、更新时间等元数据。这不只是为了将来做过滤更是Agent回答时追溯来源的骨架。没有元数据的知识库后期做重排序和可信度验证几乎寸步难行。举个简单例子管理员想限定“只查2024年之后的制度文档”如果索引里没有时间字段这个需求就没法实现。4.2 检索质量优化的两个核心参数与两组关键指标上线之后最常见的瓶颈是检索命中率不够。这里说两个最见效的优化方向。第一个是查询改写。别指望用户会按文档语言提问。一个很实用的做法是引入两步检索策略第一轮用原问题直接召回粗结果第二轮根据首轮结果让模型生成两到三个改写后的问题分别再检索最后对多路结果做融合去重。这个策略我在复杂问法下实测过命中率能提升十个到十几个百分点尤其对长尾口语化问题非常明显。第二个是重排序。向量检索的Top-K只是“初步相关”后面一定得再做一次精排。因为向量模型的语义相关度未必等同于“这里真的有正确答案”。用交叉编码器模型把候选从Top-50压缩到Top-5准确率提升非常显著。有人会觉得多一步增加了延迟但在准确率优先的场景里这是值得付的成本。在衡量优化效果时我建议盯住两个指标。一个是Hit Rate命中率也就是正确答案是否出现在检索结果里另一个是MRR平均倒数排名衡量正确答案在排序里的位置。这两个指标能剥离LLM生成环节的干扰单独衡量“检索”本身的质量。不要只盯着端到端的LLM回答效果那是个黑盒出了问题很难归因先单独把检索质量提上去再去调生成环节。4.3 把RAG接入Agent的三层写法最后讲代码落地层面。我建议把RAG接入Agent分成三层来写RAG服务层、工具层、Agent调度层。这样每个角色职责清晰调试时也很容易定位问题。RAG服务层封装所有检索细节对外只暴露一个查询接口返回结构化结果包含文本列表和元数据。工具层把RAG服务包装成Agent可调用的工具函数同时可以继续挂上SQL查询、API调用等其它能力。Agent调度层才由LLM驱动负责基于用户目标和工具返回值决定下一步动作。这里给一个面向Agent更透明的伪码你可以照着理解# 工具层把RAG服务包装成Agent可调用的工具 def search_knowledge(query: str, top_k: int 5) - list[dict]: results rag_service.search(query, top_ktop_k) return [ { content: hit[content], source: hit[metadata][source_doc], score: hit[score], timestamp: hit[metadata][update_time], } for hit in results ] # Agent调度层让大模型决定何时检索、是否需要追加查询 def agent_run(user_query: str): agent create_agent( tools[search_knowledge, query_database, call_order_api] ) return agent.run(user_query)这层的核心原则是工具要返回可追溯的结构化数据而不是拼好的纯文本。另外给Agent加一个“无法确定时如实说明”的提示让它查不到资料时明确承认没有找到而不是硬凑答案。这一个提示词能有效压低幻觉比例。如果你只想先在本地快速跑通一个最小案例我推荐Ollama加Chroma的组合。Ollama负责加载本地Embedding模型和生成模型Chroma做向量存储整个链路只需要一台机器就能运行。很多零基础可复制的RAG教程都是这么搭的拿来验证数据流程和检索效果完全够用。等系统要通过性能测试、接真实用户流量再考虑部署到更高吞吐的方案上。5. 常见问题与排查技巧实录5.1 RAG命中率低先查这四个地方如果你发现RAG回答总是不对劲不要急着换模型先按顺序排查这四个位置。第一是切块质量。抽检几个文本块看看有没有被硬切碎、语义不完整的情况。第二是查询表达。拿用户原问题去检索一次再手动改成文档风格的语言去检索一次对比两个结果就知道是不是查询改写的问题。第三是匹配策略。如果知识库里大量是数字、编号、合同号、专有名词纯向量检索往往吃不住加上BM25这类稀疏检索做混合效果通常立竿见影。第四是干扰数据。看知识库里是不是存在高度相似的噪声文档它们会让候选结果互相打架。用Metadata加过滤条件限定部门、时间范围、文档类型是性价比很高的解法。这四项排查完大部分命中率问题都能定位。如果还没有改善再考虑是不是Embedding模型跟你的领域语言风格不匹配换一个在中文或垂直领域表现更好的Embedding模型或者直接走微调路线。5.2 Agent调用工具失败基本都是这几个原因项目里经常看到类似“Agent execution terminated due to error.”这类报错很多人第一反应是模型不够聪明。但从我排查的经验看绝大多数情况根本不是模型的问题而是工具协议没写对。常见原因有三个。第一个是工具签名太复杂参数要求模糊模型无法正确生成入参。解决办法是给工具写简短的描述每个参数都写明约束和示例。第二个是返回类型不规范。如果工具返回的字段含义不清晰模型在下一步推理时就会迷失。返回结构要固定成JSON并且在工具说明里写明每个字段的含义。第三个是超时设置过紧。Agent执行长链路任务时如果工具响应稍慢就被判定失败整条任务直接中断。给超时留出合理余量并允许Agent在失败后重试一次成功率会明显提升。举个例子一个工具如果定义成“search(query: str, filters: dict)”模型很可能不知道filters应该传什么。改成“search(query: str, doc_type: str ALL, start_date: str )”并且注明“doc_type可选值为ALL、POLICY、ANNOUNCEMENT”模型调用成功率高得多。5.3 成本和延迟失控预算与服务目标如何平衡很多人做技术方案的时候特别容易忽略成本和延迟等上线之后被账单和用户体验打脸。同一个用户问题基础RAG可能只需要一次LLM调用Agentic RAG可能要串四到五次调用Token消耗直接翻几倍。在设计系统的时候几个控制手段非常关键。第一给Agent限定最大迭代步数。不要让Agent无限循环地思考下去给一个合理的上限比如最多5步工具调用超出就直接汇总已有结果。第二在系统提示里明确要求Agent“优先复用已有检索结果不重复搜索”。第三把热点问题和常见知识块的检索结果做缓存。同一个政策问题一天被问几百次每次还跑全链路检索纯属浪费算力。延迟方面先看总耗时构成。如果绝大部分时间花在LLM推理上就得考虑精简Prompt或者换一个小一点的模型如果卡在检索环节可以试试给向量库加索引优化或者把重排序范围缩小。方法本身不难难的是养成“先量化再优化”的习惯。项目上线前最好给服务设定一个预算上限和延迟上限超了要有人专门负责排查归因而不是让“Agent太慢”变成一个没法追责的问题。6 最后说点我的真实体会做了这么多RAG和Agent项目我最深的感受是别追着新概念跑。Agent确实是当前的大方向但它的本质不过是让模型拥有了一个工具箱和一个规划器。你的业务方不会太在意底层用了什么框架他们关心的永远是回答准不准、快不快、成本受不受控、出了问题能不能追溯。把这四件事做好RAG怎么选、Agent怎么上你自然就有了属于自己的取态。在你纠结选型的时候不妨先拉一个真实的小数据集搭个最小的原型跑一遍端到端的流程让业务方亲自体验一次。有了真实反馈再做决定远比在网上翻一百篇评测都管用。