最近一年里我陆续参与了好几个RAG相关项目发现一个挺有意思的现象大家一开始都是用最朴素的“向量检索大模型生成”路线跑通demo之后就忍不住开始加东西——加查询改写、加检索路由、加多轮对话记忆、加Agent循环、甚至上多Agent协作。而那次经历让我印象特别深刻一个同事问我为什么他的RAG系统检索结果总是不准明明top-k都取到10了大模型还是答非所问。我看了他的架构其实就是最传统的embedding检索说实话问题根源不是k值而是整套检索链路压根没有“决策”能力。于是就有了这篇文章的主题复杂架构怎么取舍具体就是Agentic RAG、LLM Wiki与Multi-Agent这三条演进路径。这篇文章适合两类人一类是已经在做RAG但效果卡壳、想搞清楚下一步往哪走的工程师另一类是对架构设计有选择困难、想知道什么场景该上多复杂方案的技术负责人。我会结合实操经验把这三种架构的核心原理、实施方法、成本和坑点一次性讲透。1. 从传统RAG到复杂架构演进背后的真实动因1.1 传统RAG的瓶颈到底在哪传统RAG的流程所有人都很熟悉先把文档做切分embedding之后存向量库用户问题来了直接用问题的embedding去向量库召回top-k段落然后把用户问题和召回段落拼到上下文里丢给大模型生成答案。这套流程在小规模、单一知识域、问题模式固定的场景下是可以工作的而且工程成本很低几行代码就能跑起来。但它有三个绕不开的瓶颈。第一召回策略是固定的不管用户问的是“XX功能的配置参数”还是“XX方案的整体设计思路”它都拿同一个embedding去向量库里找相似片段。可实际问题类型差异巨大有的该做关键词检索、有的该做全文检索、有的最好用图谱检索传统RAG没有能力动态选择。第二召回结果没有任何校验top-k是根据相似度硬截断的相似度低、但其实包含关键答案的文档很容易被丢掉而相似度高、但实际不相关的噪声文档却会被塞进上下文大模型被干扰之后只能胡编。第三多轮对话场景下非常笨用户说“那第二个方案呢”系统不知道“那”指代什么只能把上一个问题重复检索或者盲目扩大召回范围效果自然一塌糊涂。这些问题的共同点就是整个检索链路是静态的、没有自适应能力。传统RAG把“生成”这个环节交给了大模型但“检索”环节依然是开发者手写的固定程序。要解决这类问题升级方向就变得很自然让模型参与检索决策把知识组织成更合理的形态或者干脆让多个模型分工协作——这正是Agentic RAG、LLM Wiki、Multi-Agent三条路线的出发点。1.2 三条路线的核心差异一句话说清我自己的理解是这三条路线的侧重点完全不同不是互相替代的关系。Agentic RAG解决的是“怎么检索”的问题。它把检索策略从开发者写死变成模型动态决策——模型决定是直接向量检索、还是先改写问题、还是多种检索组合、以及召回结果是否足够回答当前问题。本质是给RAG装上了一个“策略大脑”。LLM Wiki解决的是“知识怎么组织”的问题。它把平坦的文档切片集合升级为有结构的、可导航的知识网络让检索器可以精准定位知识节点而不是盲找相似片段。本质是给RAG换了一套更合理的“记忆存储结构”。Multi-Agent解决的是“任务怎么分工”的问题。它把复杂的用户请求拆解成多个子任务由多个Agent并行或串行处理各司其职最后汇总产出。本质是从单线程作业升级为分布式团队协作。理解了这个差异后面选型就有框架了先判断问题出在“检索策略”“知识组织”还是“任务分工”再决定上哪套架构。接下来我会逐一展开。2. Agentic RAG把检索决策权交给模型2.1 Agentic RAG到底改变了什么设计逻辑先看一段传统的RAG调用逻辑这是很多初版系统的写法def rag_answer(question): query_embedding embed(question) chunks vector_db.search(query_embedding, top_k5) context \\n\\n.join(chunks) prompt build_prompt(question, context) return llm.chat(prompt)这段代码的核心假设是用户问题不需要处理、检索方式不需要变化、召回结果不需要验证。在一个受控的demo场景里没问题但在真实业务中问题千奇百怪这套假设就集体崩塌了。Agentic RAG的设计逻辑完全不同它把“检索”这件事从单次函数调用改成了一个带决策循环的任务。最基础的流程长这样收到问题先让模型判断该用什么检索方式再按计划执行检索拿到结果之后让另一个模型判断结果够不够回答不够就触发额外的检索动作换个关键词、换个索引、或者搜一下原文的引用来源足够就进入生成阶段。这一步设计上的改变是把“检索策略的选择”从代码逻辑转移到了模型推理上。换句话说模型不再只是用搜索结果生成文本而是要先学会“如何搜索”。实际项目中这个改变往往比想象中更有效。我做一个内部知识库问答时最初固定用向量召回准确率在60%左右徘徊后来加上了一个路由模块让模型对常见配置类问题走“关键词检索全文检索”让方案设计类问题走“向量检索摘要索引召回”准确率一下拉到了80%以上。2.2 最小可用的Agentic RAG怎么落地我强烈建议不要一上来就搞复杂的agent框架直接用一个路由验证的最简方案就足够解决80%的问题。我常用的结构是三个模块Planner负责解析问题、制定检索计划、Retriever按计划执行多种检索方式、Grader验证召回内容是否切题决定是否需要二次检索。模块间用结构化JSON传递消息把决策过程暴露在日志里方便排查。以下是一个可以直接跑通的最小设计class AgenticRAG: def run(self, question, history): # 1. 路由决策判断该用哪种检索策略 plan self.planner(question, history) # 2. 执行检索计划 chunks self.retrieve(question, plan) # 3. 校验召回结果 for round in range(2): need_more, refine_query self.grader(question, chunks) if not need_more: break chunks self.retrieve(refine_query, plan) # 4. 生成最终回答 return self.llm.chat(build_prompt(question, chunks))路由决策的prompt我最常用的一种设计核心是让模型从几个固定选项里选择一个而不是自由发挥你要判断用户问题的最佳检索策略。可选策略vector_search默认、keyword_search适合查配置信息、专有名词、fulltext_search适合查长文档细节、multi_search适合复杂对比问题。请从上述选项中选择一个输出JSON形如{strategy: keyword_search, reason: ...}Grader的prompt也很关键它决定多轮检索是否继续我常写请判断已有检索内容是否足够回答用户问题。如果信息不充分指出缺少什么并给出一个用于补充检索的查询词。输出JSON{sufficient: true/false, missing: ..., refine_query: ...}这套结构跑通之后效果提升是明显可感的。但要特别注意Planner和Grader的本质是大模型推理它自己也会犯错——尤其当路由选项设置不合理时比如两种策略实际召回的片段高度重合加不加路由几乎没有区别。所以任何路由判断都要留一个默认兜底我一般在路由预测置信度不高时直接切vector_search而不是让模型自由发挥。2.3 隐性成本延迟和Token消耗比你想的更贵Agentic RAG的工程成本不只在代码实现上更在线上运行时的开销。每一次路由决策和验证都是一次LLM调用都会增加延迟。如果多次检索响应时间可能从传统RAG的2秒涨到8秒以上在面向终端用户的场景里这个体感差异很大。Token消耗也是重要问题。Agentic RAG的调用次数比传统RAG多每次还有system prompt、历史记录、召回片段累计起来一次完整请求的成本可能是传统RAG的3到5倍。我的经验是给Planner和Grader用更小、更快的模型比如一个7B级别的模型只在最终生成阶段用大模型。这样既能控制成本又不会明显损失路由判断质量。还有一个值得试的技巧就是给Planner和Grader的结果加一层缓存对同一问题或高度类似的查询直接复用之前的检索计划。3. LLM Wiki知识组织形态对效果的影响比想象中大3.1 LLM Wiki不是简单文档库而是一种知识网络说到LLM Wiki很多人第一反应是一个用LLM搭建的wiki系统但这只是表面。在RAG语境下LLM Wiki更深层的价值是一种知识组织方式——把原本扁平化的文档切块升级为以“概念”和“实体”为中心的知识网络。我经历过一个项目知识库里有几千篇技术文档用传统切分方式建索引之后检索结果有一个通病文档片段本身是相关的但答非所问。后来拆开分析发现原因是切分粒度太粗召回单位是“大段落”而答案往往埋在段落的一句话里向量相似度带着大量无效信息干扰了定位。传统RAG把知识切成一堆互不关联的碎片检索时靠“余弦相似度”硬找相似片段本质上丢失了文档结构信息、概念层级信息、以及不同文档之间的关联。数据组织方式决定了检索质量的上限这个问题用“知识的导航地图”这个类比最好理解文档仓库里几千篇文件没有目录、没有索引、没有链接关系一个新人进去找资料只能扫描。向量检索相当于给了新人一个“语义搜索引擎”能搜到相关区域但搜出来的是一堆楼层照片不一定能找到具体房间。LLM Wiki要做的是把资料室改造成一个带目录、带门牌号、带指路牌的图书馆。3.2 三层知识节点让检索器像人一样先定位再阅读在实操中我倾向于把知识层组织成三层结构摘要节点、概念节点、原文片段节点。总结一下就是先通过摘要和概念节点快速缩小范围再通过指向关系定位原文中的具体段落。摘要节点每个核心知识点对应一条精炼摘要它可以是一句话或一小段概括某篇文档或某章内容的核心信息。概念节点这是整个体系的关键库里的专有名词、技术概念、产品名、功能名都作为单独的节点并记录它在哪里被详细解释、在哪篇文档里使用过。原文片段节点保留完整的原始文档切块但切分粒度更小尽量控制在300~500字避免一大块全混在一起。这套三层的设计让检索路径变成两步先用摘要节点和概念节点定位相关主题再沿链接去读取具体的原文片段。我自己的实现方法并不复杂构建时用LLM给每篇文档生成摘要然后做一次关键的实体/概念抽取把概念和文档片段做成一张关系表检索时第一轮还原是召回摘要节点和概念节点然后把对应片段捞出来再送入生成模型。这个方法在小规模知识库上效果提升非常明显。参数上我常用的切分策略和选择理由如下参数推荐值原因chunk_size300~500字更精确地定位答案避免噪声过多chunk_overlap50~80字保持段落间语义衔接防止信息断裂summary节点数每文档1~3条覆盖全文核心信息又不过度碎片化concept节点数按实体抽取不设硬性上限概念节点是导航索引越多路径越丰富3.3 LLM Wiki要做多少投入才算合理很多人听说LLM Wiki效果好一上来就想把整个知识库全量重构结果发现不仅要做摘要还要抽实体、建关联工作量巨大。我的建议是不需要一上来就全量重建先在问题最集中、检索最差的模块上做试点。比如一个项目知识库里最常用的是“API参考手册”。那我就只对API手册部分做摘要节点和概念节点其他部分保持传统切分。这样改动范围小、构建成本可控还能直接对比新旧效果。做了之后发现跟API相关的问答准确率提升很明显用户明显感觉回答更准确了而其他部分没动也不影响大局之后可以按周分批扩展。还有一个小技巧LLM Wiki的构建过程本身可以用Agent化处理批量读取文档依次生成摘要、抽取实体、标记关联跑一个定时任务就能慢慢把库建设起来。不用手工逐条维护不过仍需要人为抽检质量的环节否则概念节点会越来越脏。4. Multi-Agent协作不是堆Agent数量而是设计分工4.1 什么场景真的需要Multi-Agent什么时候不需要Multi-Agent可能是这三条路线里被滥用最多的一个。我一向建议能用单Agent解决的问题绝对不要上Multi-Agent。单Agent最省心通信开销小逻辑链路清晰出bug也好查。那什么场景确实需要呢我总结两个强信号任务可以被清晰拆解且各步骤之间目标差异大或者单Agent的上下文太长导致决策质量明显下降。我实际验证过一个场景用户的问题经常包含多个子问题比如“对比A、B两种方法的适用条件再给出C的使用步骤和D的风险规避”。如果全部塞给一个Agent处理模型容易在长上下文里迷失优先处理最后一个问题而忽略前面的。拆成“对比Agent”“步骤Agent”“风险Agent”三个专职Agent由主控Agent分配查询内容再汇总结果整体输出质量会高不少。说白了Multi-Agent的价值不是“解决单Agent解决不了的问题”而是在复杂任务中通过专业化分工提升精确度和可控性。一个Agent做所有事就像一个全栈开发者既要写前端、又要写后端、还要管运维容易在复杂场景下出错分工之后反而各自都更专业。4.2 主控、路由、执行一套清晰的角色拆分模板Multi-Agent系统的核心不是每个子Agent有多聪明而是主控Agent的任务分解和结果汇总能力。我把角色模板拆成三类主控Agent负责任务理解、分解、调度、汇总、路由/检索Agent负责与知识库、向量库、API等外部工具交互、评审Agent负责对中间结果做质量校验。这个模板的实用性很强几乎可以套用到大部分知识问答场景。一个可以复用的通信协议案例我通常用结构化JSON作为Agent间的消息格式每个消息包含task_id标识任务、agent_name产生消息的Agent、status进行中/完成/失败、data实际数据、metadata上下文信息。这样每个Agent只关心自己消费的字段调试时也能明确追踪是哪一环出了问题。任务分解上常见做法是主控Agent先把用户问题拆成若干子任务并为每个子任务指定执行Agent和期望输出格式。比如{ tasks: [ {task_id: 1, action: compare, target: [A方法, B方法], assignee: compare_agent}, {task_id: 2, action: steps, target: C方法, assignee: howto_agent}, {task_id: 3, action: risks, target: D方法, assignee: risk_agent} ] }汇总阶段主控Agent不直接把所有子模块的原始输出拼起来而是要求各Agent把结果压成“要点证据”结构主控再把要点按逻辑重新组织成完整回答。这样最终输出有逻辑层次而不是几个模块输出堆在一起的大杂烩。4.3 最常见的失控模式与兜底策略Multi-Agent系统的常见问题我在项目里几乎都踩过。最典型的是子Agent之间互相踢皮球A把任务转给BB觉得自己没权限又转回A来回循环最后超时——这需要给每个Agent的响应范围做硬性约束不能自由转派任务任何转派都必须经过主控Agent其次是使任务越拆越细、越拆越碎本来一个问题三句话能答完拆成五个Agent之后多了一堆中间产物最终答案反而更零碎——这需要在任务分解时就严格控制子任务数量如果不超过三个子问题根本不需要多Agent单Agent足够。还有一个是共享上下文爆炸——每个Agent都要携带完整的聊天记录和文档片段token消耗失控需要让子Agent只接收完成本任务必要的输入不传递全量上下文相关的基础信息统一放在一个共享状态区里按需读取。我在实际项目中给主控Agent设计过一个兜底指令效果很好“如果你发现子Agent返回的结果彼此冲突不要自行取舍把冲突内容原样保留并在最终回答中如实说明同时标注需要用户确认。”这个兜底让模型在冲突场景下不会强行编造一致性回答反而更可信。5. 三种架构怎么选基于场景的取舍框架5.1 先回答三个问题再选型做技术选型不要先看哪个架构更高级而是先回答三个问题第一我的查询类型有多少种变化如果用户问题模式固定传统RAG用规则路由就够了Agentic RAG的意义不大。如果问题类型繁多、经常有复合型问题才需要给检索做决策能力。第二我的知识库规模和组织复杂程度如何几百条纯文本可以直接向量检索但几千篇含大量概念关联的知识文档不做结构化的知识组织检索效果很难上去这时候LLM Wiki的收益最大。第三我的任务是否需要多个不同能力协作如果一个请求可以被拆成多个子任务且各子任务需要不同信息和策略那才考虑Multi-Agent。如果任务本身链式线性单Agent够用。这三个问题会导向完全不同的架构路线传统的“先进架构优先”思路往往造成大量不必要的复杂度。5.2 一张选型对照表按需取用架构最适合的场景主要成本典型延迟维护复杂度推荐前提传统RAG简单知识问答、小规模库、问题模式固定最低1~2秒低只作为baselineAgentic RAG问题类型多样、需要多策略检索和校验中高多次LLM调用3~8秒中传统RAG效果明显不达预期时LLM Wiki知识库规模大、概念关联复杂、要求精准中构建阶段成本高2~4秒中检索结果噪声大、片段定位不准时Multi-Agent任务复杂、可拆解、各步骤目标差异明显高通信和token成本高5~15秒高单一Agent输出质量不达预期时这张表我想强调一点这些架构不是排他关系。我做过的一个项目最终形态是底层用LLM Wiki组织知识上层用Agentic RAG做检索路由再叠加一个轻量Multi-Agent做复杂任务的拆解与汇总。三者是层次互补的关系不矛盾。选择顺序上我的经验是先低成本优化传统RAG调切分、调embedding模型、调召回策略仍然不够时上Agentic RAG同时评估是否需要补知识层结构最后才考虑Multi-Agent。换句话说复杂度应该像挤牙膏一样逐步释放而不是一次上全套。6. 实操过程中的常见问题与排查经验6.1 检索结果不理想时的排查顺序很多项目出问题之后第一反应是调prompt或者换大模型但我实测下来检索阶段的问题占了大多数。排查的时候我习惯按这个顺序来先查召回内容是否切题直接打印每次召回的top-3片段看一眼如果片段本身就跑偏生成结果一定跑偏这时候该修索引和知识组织再查路由判断是否准确确认模型选用的检索策略是否符合问题类型必要时把路由log加进监控最后才查生成阶段的问题看prompt是否把信息用错了、是否存在幻觉。实际操作中我强烈建议所有稍微复杂点的RAG项目都要加一个日志层把检索计划、召回段落、打分结果全部打出来。这个日志在调试时能帮你节省大量时间——很多时候一种错误的答案来自一个错误的检索计划而不模型本身的推理问题。6.2 Token开销失控的治理方案复杂架构带来的一个直接结果就是Token成本上升。我治理Token开销的办法一是给子模块用不同等级的模型路由、摘要、校验这些非生成任务完全可以交给便宜且快速的小模型只有最终面向用户的答案才用大模型生成二是对中间结果做压缩Agent间传递的内容只保留关键结论和证据不传递整篇文档三是控制检索片段的数量Agentic RAG场景下每轮检索维持top-3就够了比传统RAG的top-5到top-8少很多因为Agent本身可以多次检索第一次召回结果差后面可以通过精化的查询词再补召回没必要在开始时贪多。我还专门设计过一个“是否值得多轮检索”的token预算策略设定一个阈值如果Grader连续两轮都提示信息不足就停止继续检索并且如实告诉用户“当前知识库覆盖不够”而不是无限循环烧Token。6.3 警惕过度设计复杂架构什么时候该叫停复杂架构是好东西但最容易出现的错误是“为了复杂而复杂”。我看过一个项目团队花了两周时间上了Multi-Agent框架每个Agent套了一个角色prompt结果用户测试时发现答案和单Agent没有本质区别反而响应慢了好几秒。这类问题背后的原因往往是任务本身不够复杂、各Agent分工没有真正区分开、或者底层知识库质量太差——架构再复杂也弥补不了知识库本身脏乱差的问题。还有一个信号值得警惕如果团队里只有一到两个工程师维护系统却要撑起一个包含5个以上Agent的架构成本会非常高。这种时候应该优先做减法把非核心链路用最简单的方式实现只留下真正提升效果的那一环。我自己在几个项目里来回试出来的一个体会是复杂架构的收益曲线并不是线性增加的它早期会有明显提升中期边际收益递减后期可能因为维护成本过高而出现负收益。找到那条曲线的拐点就是工程上最舒服的状态。从实用角度看这篇内容最值得带走的一句话是先在能直接看到效果的地方做加法而不是为了架构的完整性做加法。Agentic RAG帮你把检索做聪明LLM Wiki帮你把知识理顺Multi-Agent帮你把任务拆得恰到好处但它的前提是你确实遇到了对应的卡点。没卡点就不要动。我之前一直有个习惯做完一轮架构升级之后会要求自己同时回答两个问题效果到底提升了多少、成本增加了多少。如果提升不显著哪怕架构看起来更像“下一代”也会立刻回滚。毕竟对用户来说他感受到的是回答是否准确、是否快、是否稳定而不是你用了多少个Agent。 RAG进阶：Agentic RAG、LLM Wiki与Multi-Agent架构取舍指南
最近一年里我陆续参与了好几个RAG相关项目发现一个挺有意思的现象大家一开始都是用最朴素的“向量检索大模型生成”路线跑通demo之后就忍不住开始加东西——加查询改写、加检索路由、加多轮对话记忆、加Agent循环、甚至上多Agent协作。而那次经历让我印象特别深刻一个同事问我为什么他的RAG系统检索结果总是不准明明top-k都取到10了大模型还是答非所问。我看了他的架构其实就是最传统的embedding检索说实话问题根源不是k值而是整套检索链路压根没有“决策”能力。于是就有了这篇文章的主题复杂架构怎么取舍具体就是Agentic RAG、LLM Wiki与Multi-Agent这三条演进路径。这篇文章适合两类人一类是已经在做RAG但效果卡壳、想搞清楚下一步往哪走的工程师另一类是对架构设计有选择困难、想知道什么场景该上多复杂方案的技术负责人。我会结合实操经验把这三种架构的核心原理、实施方法、成本和坑点一次性讲透。1. 从传统RAG到复杂架构演进背后的真实动因1.1 传统RAG的瓶颈到底在哪传统RAG的流程所有人都很熟悉先把文档做切分embedding之后存向量库用户问题来了直接用问题的embedding去向量库召回top-k段落然后把用户问题和召回段落拼到上下文里丢给大模型生成答案。这套流程在小规模、单一知识域、问题模式固定的场景下是可以工作的而且工程成本很低几行代码就能跑起来。但它有三个绕不开的瓶颈。第一召回策略是固定的不管用户问的是“XX功能的配置参数”还是“XX方案的整体设计思路”它都拿同一个embedding去向量库里找相似片段。可实际问题类型差异巨大有的该做关键词检索、有的该做全文检索、有的最好用图谱检索传统RAG没有能力动态选择。第二召回结果没有任何校验top-k是根据相似度硬截断的相似度低、但其实包含关键答案的文档很容易被丢掉而相似度高、但实际不相关的噪声文档却会被塞进上下文大模型被干扰之后只能胡编。第三多轮对话场景下非常笨用户说“那第二个方案呢”系统不知道“那”指代什么只能把上一个问题重复检索或者盲目扩大召回范围效果自然一塌糊涂。这些问题的共同点就是整个检索链路是静态的、没有自适应能力。传统RAG把“生成”这个环节交给了大模型但“检索”环节依然是开发者手写的固定程序。要解决这类问题升级方向就变得很自然让模型参与检索决策把知识组织成更合理的形态或者干脆让多个模型分工协作——这正是Agentic RAG、LLM Wiki、Multi-Agent三条路线的出发点。1.2 三条路线的核心差异一句话说清我自己的理解是这三条路线的侧重点完全不同不是互相替代的关系。Agentic RAG解决的是“怎么检索”的问题。它把检索策略从开发者写死变成模型动态决策——模型决定是直接向量检索、还是先改写问题、还是多种检索组合、以及召回结果是否足够回答当前问题。本质是给RAG装上了一个“策略大脑”。LLM Wiki解决的是“知识怎么组织”的问题。它把平坦的文档切片集合升级为有结构的、可导航的知识网络让检索器可以精准定位知识节点而不是盲找相似片段。本质是给RAG换了一套更合理的“记忆存储结构”。Multi-Agent解决的是“任务怎么分工”的问题。它把复杂的用户请求拆解成多个子任务由多个Agent并行或串行处理各司其职最后汇总产出。本质是从单线程作业升级为分布式团队协作。理解了这个差异后面选型就有框架了先判断问题出在“检索策略”“知识组织”还是“任务分工”再决定上哪套架构。接下来我会逐一展开。2. Agentic RAG把检索决策权交给模型2.1 Agentic RAG到底改变了什么设计逻辑先看一段传统的RAG调用逻辑这是很多初版系统的写法def rag_answer(question): query_embedding embed(question) chunks vector_db.search(query_embedding, top_k5) context \\n\\n.join(chunks) prompt build_prompt(question, context) return llm.chat(prompt)这段代码的核心假设是用户问题不需要处理、检索方式不需要变化、召回结果不需要验证。在一个受控的demo场景里没问题但在真实业务中问题千奇百怪这套假设就集体崩塌了。Agentic RAG的设计逻辑完全不同它把“检索”这件事从单次函数调用改成了一个带决策循环的任务。最基础的流程长这样收到问题先让模型判断该用什么检索方式再按计划执行检索拿到结果之后让另一个模型判断结果够不够回答不够就触发额外的检索动作换个关键词、换个索引、或者搜一下原文的引用来源足够就进入生成阶段。这一步设计上的改变是把“检索策略的选择”从代码逻辑转移到了模型推理上。换句话说模型不再只是用搜索结果生成文本而是要先学会“如何搜索”。实际项目中这个改变往往比想象中更有效。我做一个内部知识库问答时最初固定用向量召回准确率在60%左右徘徊后来加上了一个路由模块让模型对常见配置类问题走“关键词检索全文检索”让方案设计类问题走“向量检索摘要索引召回”准确率一下拉到了80%以上。2.2 最小可用的Agentic RAG怎么落地我强烈建议不要一上来就搞复杂的agent框架直接用一个路由验证的最简方案就足够解决80%的问题。我常用的结构是三个模块Planner负责解析问题、制定检索计划、Retriever按计划执行多种检索方式、Grader验证召回内容是否切题决定是否需要二次检索。模块间用结构化JSON传递消息把决策过程暴露在日志里方便排查。以下是一个可以直接跑通的最小设计class AgenticRAG: def run(self, question, history): # 1. 路由决策判断该用哪种检索策略 plan self.planner(question, history) # 2. 执行检索计划 chunks self.retrieve(question, plan) # 3. 校验召回结果 for round in range(2): need_more, refine_query self.grader(question, chunks) if not need_more: break chunks self.retrieve(refine_query, plan) # 4. 生成最终回答 return self.llm.chat(build_prompt(question, chunks))路由决策的prompt我最常用的一种设计核心是让模型从几个固定选项里选择一个而不是自由发挥你要判断用户问题的最佳检索策略。可选策略vector_search默认、keyword_search适合查配置信息、专有名词、fulltext_search适合查长文档细节、multi_search适合复杂对比问题。请从上述选项中选择一个输出JSON形如{strategy: keyword_search, reason: ...}Grader的prompt也很关键它决定多轮检索是否继续我常写请判断已有检索内容是否足够回答用户问题。如果信息不充分指出缺少什么并给出一个用于补充检索的查询词。输出JSON{sufficient: true/false, missing: ..., refine_query: ...}这套结构跑通之后效果提升是明显可感的。但要特别注意Planner和Grader的本质是大模型推理它自己也会犯错——尤其当路由选项设置不合理时比如两种策略实际召回的片段高度重合加不加路由几乎没有区别。所以任何路由判断都要留一个默认兜底我一般在路由预测置信度不高时直接切vector_search而不是让模型自由发挥。2.3 隐性成本延迟和Token消耗比你想的更贵Agentic RAG的工程成本不只在代码实现上更在线上运行时的开销。每一次路由决策和验证都是一次LLM调用都会增加延迟。如果多次检索响应时间可能从传统RAG的2秒涨到8秒以上在面向终端用户的场景里这个体感差异很大。Token消耗也是重要问题。Agentic RAG的调用次数比传统RAG多每次还有system prompt、历史记录、召回片段累计起来一次完整请求的成本可能是传统RAG的3到5倍。我的经验是给Planner和Grader用更小、更快的模型比如一个7B级别的模型只在最终生成阶段用大模型。这样既能控制成本又不会明显损失路由判断质量。还有一个值得试的技巧就是给Planner和Grader的结果加一层缓存对同一问题或高度类似的查询直接复用之前的检索计划。3. LLM Wiki知识组织形态对效果的影响比想象中大3.1 LLM Wiki不是简单文档库而是一种知识网络说到LLM Wiki很多人第一反应是一个用LLM搭建的wiki系统但这只是表面。在RAG语境下LLM Wiki更深层的价值是一种知识组织方式——把原本扁平化的文档切块升级为以“概念”和“实体”为中心的知识网络。我经历过一个项目知识库里有几千篇技术文档用传统切分方式建索引之后检索结果有一个通病文档片段本身是相关的但答非所问。后来拆开分析发现原因是切分粒度太粗召回单位是“大段落”而答案往往埋在段落的一句话里向量相似度带着大量无效信息干扰了定位。传统RAG把知识切成一堆互不关联的碎片检索时靠“余弦相似度”硬找相似片段本质上丢失了文档结构信息、概念层级信息、以及不同文档之间的关联。数据组织方式决定了检索质量的上限这个问题用“知识的导航地图”这个类比最好理解文档仓库里几千篇文件没有目录、没有索引、没有链接关系一个新人进去找资料只能扫描。向量检索相当于给了新人一个“语义搜索引擎”能搜到相关区域但搜出来的是一堆楼层照片不一定能找到具体房间。LLM Wiki要做的是把资料室改造成一个带目录、带门牌号、带指路牌的图书馆。3.2 三层知识节点让检索器像人一样先定位再阅读在实操中我倾向于把知识层组织成三层结构摘要节点、概念节点、原文片段节点。总结一下就是先通过摘要和概念节点快速缩小范围再通过指向关系定位原文中的具体段落。摘要节点每个核心知识点对应一条精炼摘要它可以是一句话或一小段概括某篇文档或某章内容的核心信息。概念节点这是整个体系的关键库里的专有名词、技术概念、产品名、功能名都作为单独的节点并记录它在哪里被详细解释、在哪篇文档里使用过。原文片段节点保留完整的原始文档切块但切分粒度更小尽量控制在300~500字避免一大块全混在一起。这套三层的设计让检索路径变成两步先用摘要节点和概念节点定位相关主题再沿链接去读取具体的原文片段。我自己的实现方法并不复杂构建时用LLM给每篇文档生成摘要然后做一次关键的实体/概念抽取把概念和文档片段做成一张关系表检索时第一轮还原是召回摘要节点和概念节点然后把对应片段捞出来再送入生成模型。这个方法在小规模知识库上效果提升非常明显。参数上我常用的切分策略和选择理由如下参数推荐值原因chunk_size300~500字更精确地定位答案避免噪声过多chunk_overlap50~80字保持段落间语义衔接防止信息断裂summary节点数每文档1~3条覆盖全文核心信息又不过度碎片化concept节点数按实体抽取不设硬性上限概念节点是导航索引越多路径越丰富3.3 LLM Wiki要做多少投入才算合理很多人听说LLM Wiki效果好一上来就想把整个知识库全量重构结果发现不仅要做摘要还要抽实体、建关联工作量巨大。我的建议是不需要一上来就全量重建先在问题最集中、检索最差的模块上做试点。比如一个项目知识库里最常用的是“API参考手册”。那我就只对API手册部分做摘要节点和概念节点其他部分保持传统切分。这样改动范围小、构建成本可控还能直接对比新旧效果。做了之后发现跟API相关的问答准确率提升很明显用户明显感觉回答更准确了而其他部分没动也不影响大局之后可以按周分批扩展。还有一个小技巧LLM Wiki的构建过程本身可以用Agent化处理批量读取文档依次生成摘要、抽取实体、标记关联跑一个定时任务就能慢慢把库建设起来。不用手工逐条维护不过仍需要人为抽检质量的环节否则概念节点会越来越脏。4. Multi-Agent协作不是堆Agent数量而是设计分工4.1 什么场景真的需要Multi-Agent什么时候不需要Multi-Agent可能是这三条路线里被滥用最多的一个。我一向建议能用单Agent解决的问题绝对不要上Multi-Agent。单Agent最省心通信开销小逻辑链路清晰出bug也好查。那什么场景确实需要呢我总结两个强信号任务可以被清晰拆解且各步骤之间目标差异大或者单Agent的上下文太长导致决策质量明显下降。我实际验证过一个场景用户的问题经常包含多个子问题比如“对比A、B两种方法的适用条件再给出C的使用步骤和D的风险规避”。如果全部塞给一个Agent处理模型容易在长上下文里迷失优先处理最后一个问题而忽略前面的。拆成“对比Agent”“步骤Agent”“风险Agent”三个专职Agent由主控Agent分配查询内容再汇总结果整体输出质量会高不少。说白了Multi-Agent的价值不是“解决单Agent解决不了的问题”而是在复杂任务中通过专业化分工提升精确度和可控性。一个Agent做所有事就像一个全栈开发者既要写前端、又要写后端、还要管运维容易在复杂场景下出错分工之后反而各自都更专业。4.2 主控、路由、执行一套清晰的角色拆分模板Multi-Agent系统的核心不是每个子Agent有多聪明而是主控Agent的任务分解和结果汇总能力。我把角色模板拆成三类主控Agent负责任务理解、分解、调度、汇总、路由/检索Agent负责与知识库、向量库、API等外部工具交互、评审Agent负责对中间结果做质量校验。这个模板的实用性很强几乎可以套用到大部分知识问答场景。一个可以复用的通信协议案例我通常用结构化JSON作为Agent间的消息格式每个消息包含task_id标识任务、agent_name产生消息的Agent、status进行中/完成/失败、data实际数据、metadata上下文信息。这样每个Agent只关心自己消费的字段调试时也能明确追踪是哪一环出了问题。任务分解上常见做法是主控Agent先把用户问题拆成若干子任务并为每个子任务指定执行Agent和期望输出格式。比如{ tasks: [ {task_id: 1, action: compare, target: [A方法, B方法], assignee: compare_agent}, {task_id: 2, action: steps, target: C方法, assignee: howto_agent}, {task_id: 3, action: risks, target: D方法, assignee: risk_agent} ] }汇总阶段主控Agent不直接把所有子模块的原始输出拼起来而是要求各Agent把结果压成“要点证据”结构主控再把要点按逻辑重新组织成完整回答。这样最终输出有逻辑层次而不是几个模块输出堆在一起的大杂烩。4.3 最常见的失控模式与兜底策略Multi-Agent系统的常见问题我在项目里几乎都踩过。最典型的是子Agent之间互相踢皮球A把任务转给BB觉得自己没权限又转回A来回循环最后超时——这需要给每个Agent的响应范围做硬性约束不能自由转派任务任何转派都必须经过主控Agent其次是使任务越拆越细、越拆越碎本来一个问题三句话能答完拆成五个Agent之后多了一堆中间产物最终答案反而更零碎——这需要在任务分解时就严格控制子任务数量如果不超过三个子问题根本不需要多Agent单Agent足够。还有一个是共享上下文爆炸——每个Agent都要携带完整的聊天记录和文档片段token消耗失控需要让子Agent只接收完成本任务必要的输入不传递全量上下文相关的基础信息统一放在一个共享状态区里按需读取。我在实际项目中给主控Agent设计过一个兜底指令效果很好“如果你发现子Agent返回的结果彼此冲突不要自行取舍把冲突内容原样保留并在最终回答中如实说明同时标注需要用户确认。”这个兜底让模型在冲突场景下不会强行编造一致性回答反而更可信。5. 三种架构怎么选基于场景的取舍框架5.1 先回答三个问题再选型做技术选型不要先看哪个架构更高级而是先回答三个问题第一我的查询类型有多少种变化如果用户问题模式固定传统RAG用规则路由就够了Agentic RAG的意义不大。如果问题类型繁多、经常有复合型问题才需要给检索做决策能力。第二我的知识库规模和组织复杂程度如何几百条纯文本可以直接向量检索但几千篇含大量概念关联的知识文档不做结构化的知识组织检索效果很难上去这时候LLM Wiki的收益最大。第三我的任务是否需要多个不同能力协作如果一个请求可以被拆成多个子任务且各子任务需要不同信息和策略那才考虑Multi-Agent。如果任务本身链式线性单Agent够用。这三个问题会导向完全不同的架构路线传统的“先进架构优先”思路往往造成大量不必要的复杂度。5.2 一张选型对照表按需取用架构最适合的场景主要成本典型延迟维护复杂度推荐前提传统RAG简单知识问答、小规模库、问题模式固定最低1~2秒低只作为baselineAgentic RAG问题类型多样、需要多策略检索和校验中高多次LLM调用3~8秒中传统RAG效果明显不达预期时LLM Wiki知识库规模大、概念关联复杂、要求精准中构建阶段成本高2~4秒中检索结果噪声大、片段定位不准时Multi-Agent任务复杂、可拆解、各步骤目标差异明显高通信和token成本高5~15秒高单一Agent输出质量不达预期时这张表我想强调一点这些架构不是排他关系。我做过的一个项目最终形态是底层用LLM Wiki组织知识上层用Agentic RAG做检索路由再叠加一个轻量Multi-Agent做复杂任务的拆解与汇总。三者是层次互补的关系不矛盾。选择顺序上我的经验是先低成本优化传统RAG调切分、调embedding模型、调召回策略仍然不够时上Agentic RAG同时评估是否需要补知识层结构最后才考虑Multi-Agent。换句话说复杂度应该像挤牙膏一样逐步释放而不是一次上全套。6. 实操过程中的常见问题与排查经验6.1 检索结果不理想时的排查顺序很多项目出问题之后第一反应是调prompt或者换大模型但我实测下来检索阶段的问题占了大多数。排查的时候我习惯按这个顺序来先查召回内容是否切题直接打印每次召回的top-3片段看一眼如果片段本身就跑偏生成结果一定跑偏这时候该修索引和知识组织再查路由判断是否准确确认模型选用的检索策略是否符合问题类型必要时把路由log加进监控最后才查生成阶段的问题看prompt是否把信息用错了、是否存在幻觉。实际操作中我强烈建议所有稍微复杂点的RAG项目都要加一个日志层把检索计划、召回段落、打分结果全部打出来。这个日志在调试时能帮你节省大量时间——很多时候一种错误的答案来自一个错误的检索计划而不模型本身的推理问题。6.2 Token开销失控的治理方案复杂架构带来的一个直接结果就是Token成本上升。我治理Token开销的办法一是给子模块用不同等级的模型路由、摘要、校验这些非生成任务完全可以交给便宜且快速的小模型只有最终面向用户的答案才用大模型生成二是对中间结果做压缩Agent间传递的内容只保留关键结论和证据不传递整篇文档三是控制检索片段的数量Agentic RAG场景下每轮检索维持top-3就够了比传统RAG的top-5到top-8少很多因为Agent本身可以多次检索第一次召回结果差后面可以通过精化的查询词再补召回没必要在开始时贪多。我还专门设计过一个“是否值得多轮检索”的token预算策略设定一个阈值如果Grader连续两轮都提示信息不足就停止继续检索并且如实告诉用户“当前知识库覆盖不够”而不是无限循环烧Token。6.3 警惕过度设计复杂架构什么时候该叫停复杂架构是好东西但最容易出现的错误是“为了复杂而复杂”。我看过一个项目团队花了两周时间上了Multi-Agent框架每个Agent套了一个角色prompt结果用户测试时发现答案和单Agent没有本质区别反而响应慢了好几秒。这类问题背后的原因往往是任务本身不够复杂、各Agent分工没有真正区分开、或者底层知识库质量太差——架构再复杂也弥补不了知识库本身脏乱差的问题。还有一个信号值得警惕如果团队里只有一到两个工程师维护系统却要撑起一个包含5个以上Agent的架构成本会非常高。这种时候应该优先做减法把非核心链路用最简单的方式实现只留下真正提升效果的那一环。我自己在几个项目里来回试出来的一个体会是复杂架构的收益曲线并不是线性增加的它早期会有明显提升中期边际收益递减后期可能因为维护成本过高而出现负收益。找到那条曲线的拐点就是工程上最舒服的状态。从实用角度看这篇内容最值得带走的一句话是先在能直接看到效果的地方做加法而不是为了架构的完整性做加法。Agentic RAG帮你把检索做聪明LLM Wiki帮你把知识理顺Multi-Agent帮你把任务拆得恰到好处但它的前提是你确实遇到了对应的卡点。没卡点就不要动。我之前一直有个习惯做完一轮架构升级之后会要求自己同时回答两个问题效果到底提升了多少、成本增加了多少。如果提升不显著哪怕架构看起来更像“下一代”也会立刻回滚。毕竟对用户来说他感受到的是回答是否准确、是否快、是否稳定而不是你用了多少个Agent。