1. 从检索到行动RAG 在 Agent 时代到底变了什么如果你这两年一直在做 AI 应用大概率会有一种割裂感一边是 RAGRetrieval-Augmented Generation检索增强生成已经被讲烂了好像谁都会搭一个文档问答另一边是 Agent 突然成了主角所有人都在聊工具调用、任务规划、多轮自主执行。于是问题来了——当模型开始自己决定要不要查、查什么、查几次的时候传统那套先检索再拼 prompt的 RAG 还够用吗答案是不够但也不是推倒重来。RAG 的底层逻辑——用外部知识补足模型参数里没有的东西——在 Agent 时代反而更重要了因为 Agent 要做的决策越多它对准确、及时、结构化的外部信息的依赖就越强。变的不是要不要检索而是谁来发起检索、检索什么粒度、检索结果怎么进入推理循环。这篇我想把 Agent 时代真正在工程里跑得起来的 8 种 RAG 形态一次讲清楚。不是罗列概念而是按它解决什么问题、核心机制是什么、什么场景该用它、落地时坑在哪这个顺序来拆。关键词里出现的 GraphRAG、LightRAG、Agentic RAG、Ontology RAG 都会覆盖到同时我会把 Naive RAG、Hybrid RAG、Self-RAG、Corrective RAG、Multimodal RAG 这些也串进来因为它们不是互相替代的关系而是同一套系统里不同层级的组件。适合谁看如果你已经搭过最基础的向量检索问答想往 Agent 方向升级或者你在做 Agent 项目发现模型老是幻觉式检索、查了等于没查、多跳问题一塌糊涂那这篇就是给你写的。我会尽量把每个环节的为什么这么设计讲透而不是甩一堆名词让你自己拼。先说一个我踩过的坑作为引子早期我给一个 Agent 接了最朴素的向量 RAG结果它遇到对比 A 产品和 B 产品在 2023 年之后的政策差异这种问题时检索回来的永远是零散段落模型要么漏掉一边要么把两边信息张冠李戴。后来我才意识到问题不在检索器而在我把 RAG 当成了一个一次性函数而 Agent 需要的是一个可反复调用的工具。这个认知转变是理解后面 8 种形态的钥匙。2. Naive RAG 与 Hybrid RAG地基没打牢上面全是空中楼阁很多人一上来就想搞 GraphRAG、Agentic RAG结果连最基础的检索质量都没解决。我见过太多项目向量库塞了几十万条 chunk召回率却惨不忍睹然后归咎于模型不行。其实问题往往出在地基上。所以这一章先把两种看起来最土但最不能省的形态讲透。2.1 Naive RAG 的真实瓶颈不是检索是切分和召回Naive RAG 的流程大家都熟文档切分成 chunk → 向量化 → 存向量库 → 查询时向量化问题 → 相似度召回 Top-K → 拼进 prompt。听起来没毛病但实际跑起来80% 的失败案例都死在 chunk 切分和召回策略上。我做过一个对比实验同一份 200 页的技术手册用三种切分方式切分策略chunk 大小召回准确率主要问题固定长度512 token61%句子被拦腰截断语义破碎按段落不定长74%长段落超长短段落信息不足语义切分 重叠256-512 token重叠 6486%实现复杂需调参固定长度切分最省事但也是最坑的。一个完整的操作步骤被切成两半模型拿到前半段根本不知道后半段在讲什么。我的经验是优先按语义边界切标题、段落、列表项再对超长块做二次切分并且一定要加 10%-15% 的重叠。重叠部分看似冗余但它能保证跨块的语义连续性这点在 Agent 反复检索时尤其重要。另一个常被忽略的点是元数据。光有文本向量是不够的你得把来源、章节、时间、文档类型这些一起存进去。为什么因为 Agent 在做多轮检索时需要根据元数据做过滤——比如只查 2024 年之后的文档只查 API 参考手册。没有元数据Agent 就只能靠语义相似度硬碰效果差一大截。提示如果你的 RAG 召回率低于 70%先别急着换框架回去检查 chunk 切分和元数据设计十有八九问题在这。2.2 Hybrid RAG向量检索不是万能的关键词得补位向量检索擅长语义匹配但对精确术语、编号、专有名词很无力。比如用户问错误码 E5021 怎么解决向量检索可能召回一堆错误处理的泛泛内容却漏掉真正包含 E5021 的那一段。这时候就需要 Hybrid RAG——向量检索 关键词检索BM25双路召回再融合排序。融合排序常用两种方法RRFReciprocal Rank Fusion倒数排名融合和加权分数融合。RRF 更省心不需要归一化分数公式是score Σ 1/(k rank)k 一般取 60。我实测下来RRF 在大多数场景下比加权融合更稳因为它对两路检索的分数尺度不敏感。# RRF 融合的简化实现 def rrf_fusion(vector_results, bm25_results, k60): scores {} for rank, doc in enumerate(vector_results): scores[doc.id] scores.get(doc.id, 0) 1 / (k rank 1) for rank, doc in enumerate(bm25_results): scores[doc.id] scores.get(doc.id, 0) 1 / (k rank 1) return sorted(scores.items(), keylambda x: x[1], reverseTrue)Hybrid RAG 的代价是延迟翻倍两路检索并行还好串行就难受了和调参成本。我的建议是如果业务里精确查询占比高比如客服、技术支持Hybrid 是必选项如果是纯开放域问答Naive RAG 调好切分也能凑合。这里有个 Agent 场景的特殊考量Agent 可以自己决定用哪路检索。比如它判断问题是精确匹配就走 BM25是语义理解就走向量。这就自然过渡到了后面的 Agentic RAG。3. GraphRAG 与 LightRAG当问题需要跨文档推理时传统 RAG 有个致命短板它只能回答某个片段里写了什么回答不了这些片段之间是什么关系。当用户问公司 A 收购了 BB 的创始人之前在哪家公司那家公司现在和 A 有竞争吗这种多跳问题时向量检索召回的永远是零散段落模型只能靠猜。GraphRAG 就是为解决这类问题生的。3.1 GraphRAG 的核心把文档变成知识图谱GraphRAG 的思路是先用 LLM 从文档里抽取实体和关系构建知识图谱然后查询时既走图遍历也走社区摘要。微软那套 GraphRAG 的流程大致是实体与关系抽取LLM 逐块读文档抽出实体-关系-实体三元组。社区检测用 Leiden 算法把图划分成层次化社区。社区摘要生成对每个社区用 LLM 生成摘要。查询时局部问题走实体邻域全局问题走社区摘要。这套东西效果确实好尤其在全局性总结类问题上比如这份报告的主要矛盾是什么GraphRAG 比向量 RAG 强太多。但它的代价也很明显构建成本极高。一份 100 万字的文档光实体抽取的 LLM 调用费用就可能上千块而且抽取质量高度依赖 prompt 设计。我踩过的坑早期用 GraphRAG 时实体抽取没有做归一化结果苹果公司Apple苹果被当成三个实体图谱直接乱掉。后来加了实体消歧用 embedding 相似度 规则合并才勉强能用。所以如果你要上 GraphRAG实体归一化这一步绝对不能省。3.2 LightRAGGraphRAG 的轻量化妥协GraphRAG 太重于是有了 LightRAG。它的核心改进是双层检索低层检索实体和关系高层检索主题和概念同时把图结构和向量索引结合避免了 GraphRAG 那种全量社区摘要的开销。LightRAG 的构建流程比 GraphRAG 简单抽取实体关系 → 建图 → 同时为节点和边生成 embedding → 查询时图遍历 向量召回混合。它的优势是增量更新友好——新文档来了抽完实体直接往图里加不用重建整个社区结构。这点对 Agent 场景很关键因为 Agent 面对的知识库往往是动态增长的。我实测下来LightRAG 在中等规模几万到几十万 chunk的知识库上效果接近 GraphRAG 的 80%但构建成本只有它的 30% 左右。如果你的场景是多跳问答 动态知识库LightRAG 是性价比更高的选择。维度GraphRAGLightRAG构建成本高中增量更新差需重建社区好全局总结强中多跳推理强较强适用规模中小规模、静态中大规模、动态注意GraphRAG 和 LightRAG 都不是开箱即用的实体抽取的 prompt 需要针对你的领域反复调。通用 prompt 在专业领域医疗、法律、金融上抽取质量会断崖式下跌。4. Self-RAG 与 Corrective RAG让检索学会自我怀疑前面讲的都是怎么检得更准但 Agent 时代有个更根本的问题模型怎么知道自己检得对不对传统 RAG 是无脑检索、无脑拼接检索错了也照单全收结果就是幻觉。Self-RAG 和 Corrective RAG 就是来解决检索质量自省的。4.1 Self-RAG用反思 token 控制检索行为Self-RAG 的核心思想是训练模型生成特殊的反思 token比如[Retrieve]要不要检索[IsRel]检索到的内容相关吗[IsSup]生成的内容有检索内容支持吗[IsUse]生成的内容有用吗模型在生成时自己决定要不要检索、检索后自己判断相关性、生成后自己验证支持度。这套机制的好处是按需检索——简单问题不检索复杂问题多检索避免了无脑检索带来的噪声和延迟。但 Self-RAG 有个现实问题它需要专门训练的模型。原论文是拿 Llama2 微调的普通开发者很难复现。所以工程上更常见的是用 prompt 模拟 Self-RAG 行为——让 Agent 在检索前后插入自检步骤。这就引出了 Agentic RAG。4.2 Corrective RAG检索不好就重检Corrective RAGCRAG更务实。它的流程是检索 → 用轻量评估器判断检索质量 → 分三种情况处理Correct检索质量高直接用。Incorrect检索质量低丢弃改用网络搜索或重新检索。Ambiguous模棱两可两者结合。评估器可以是一个小模型比如 T5-large 微调也可以直接用 LLM 打分。我实测下来用 LLM 打分的成本比想象中低因为只需要判断相关/不相关prompt 很短token 消耗可控。CRAG 的价值在于它给了 Agent 一个纠错回路。传统 RAG 是一条直线CRAG 是一个带反馈的环。这个环在 Agent 场景里特别重要因为 Agent 本来就有多轮循环的能力把 CRAG 嵌进去几乎零成本。# CRAG 的简化决策逻辑 def corrective_retrieve(query, retriever, evaluator, llm): docs retriever.search(query, top_k5) quality evaluator.score(query, docs) # 0-1 if quality 0.7: return docs elif quality 0.3: # 检索失败尝试改写查询重检 new_query llm.rewrite(query) return retriever.search(new_query, top_k5) else: # 模糊结合两路 return docs retriever.search(llm.rewrite(query), top_k3)这里有个实操心得查询改写query rewriting是 CRAG 里最值钱的一步。很多检索失败不是知识库没有而是用户问法和文档写法对不上。让 LLM 把口语化问题改写成文档风格的查询召回率能提升 20% 以上。5. Agentic RAG把检索变成 Agent 的一个工具前面铺垫了这么多终于到核心了。Agentic RAG 不是一个具体的算法而是一种架构范式把检索能力封装成 Agent 可调用的工具由 Agent 根据任务需要自主决定何时检索、检索什么、检索几次、如何整合。5.1 为什么 Agent 需要自主检索而不是固定检索传统 RAG 是一问一检一答Agentic RAG 是边想边检边答。区别在哪举个例子用户问帮我分析这份财报的风险点。传统 RAG 会检索一次把 Top-K 段落拼进去模型一次性生成。但这个问题其实需要先检索财务数据 → 发现应收账款异常 → 再检索应收账款相关政策 → 发现某大客户占比过高 → 再检索该客户信息 → 综合判断。这是一个多跳、动态的检索过程固定的一次性检索根本做不到。Agentic RAG 让 Agent 自己规划检索路径每一步的检索结果影响下一步的决策。这才是 Agent 时代 RAG 的真正形态。5.2 Agentic RAG 的三种典型模式我在项目里总结出三种模式按复杂度递增模式一工具调用式。把检索器注册成一个 toolAgent 用 function calling 调用。最简单适合大多数场景。关键是 tool 的描述要写清楚——什么时候该用这个工具比这个工具能干什么更重要。模式二规划-执行式。Agent 先拆解任务生成检索计划要查哪几个子问题再逐个执行最后综合。适合复杂分析类任务。这里可以用 ReAct 或 Plan-and-Execute 框架。模式三多 Agent 协作式。一个 Agent 负责规划一个负责检索一个负责验证互相协作。适合超复杂场景但工程复杂度也最高容易失控。我的建议是从模式一开始别一上来就搞多 Agent。我见过太多项目三个 Agent 互相调用最后调试到崩溃。单 Agent 好的工具设计能解决 80% 的问题。5.3 Agentic RAG 的检索工具该怎么设计这是最容易被低估的部分。很多人把检索工具设计成search(query) - docs太粗糙了。好的检索工具应该有这些参数query查询文本top_k返回数量filters元数据过滤时间、来源、类型mode检索模式向量/关键词/混合/图rerank是否重排为什么因为 Agent 需要精细控制。它可能知道我只要 2024 年的数据或者这次要精确匹配错误码。工具参数越丰富Agent 的决策空间越大效果越好。提示检索工具的 docstring 要写得像给新人看的说明书包含什么时候用什么时候不用参数怎么填。Agent 读 docstring 的能力比你想象中强。6. Multimodal RAG 与 Ontology RAG两个容易被忽视的进阶方向前面六种偏通用这一章讲两种特定场景下才需要、但一旦需要就绕不开的形态。6.1 Multimodal RAG当知识库里有图片和表格热词里有人问rag 知识库能存储图片嘛答案是能但方式有讲究。Multimodal RAG 处理的是图文混排、表格、图表这类内容。常见做法有三种图片转文本用多模态模型如 GPT-4V 类能力把图片描述成文字再走文本 RAG。简单但丢失视觉细节。多向量索引图片用 CLIP 类模型编码文本用文本模型编码查询时跨模态检索。适合以图搜图或文搜图。统一多模态 embedding用统一模型把图文编码到同一空间。最优雅但模型选择少。我踩过的坑表格千万别直接转文本。一个财务表格转成文字后行列关系全乱模型根本读不懂。正确做法是表格结构化提取转成 Markdown 表格或 JSON保留行列语义。图表则建议图片 文字描述双存检索时用文字展示时用图片。6.2 Ontology RAG用本体约束检索的语义边界Ontology RAG本体 RAG是 GraphRAG 的进阶版。区别在于GraphRAG 的图谱是从文档里抽出来的而 Ontology RAG 的图谱是预先定义好的本体结构文档只是往这个结构里填实例。举个例子医疗场景下你可以先定义本体疾病、症状、药物、检查项以及它们之间的关系治疗导致检查。然后文档抽取时只抽这些预定义类型的实体和关系。好处是图谱质量高、可控坏处是本体设计成本高且难以覆盖长尾。Ontology RAG 适合领域边界清晰、术语体系稳定的场景比如医疗、法律、工业设备。开放域场景下本体根本定义不完还是 GraphRAG 更实际。形态图谱来源可控性适用场景GraphRAG文档抽取中开放域多跳问答Ontology RAG预定义本体高垂直领域、术语稳定7. 八种 RAG 怎么选一张决策表和三条实战原则讲了这么多最后落到我到底该用哪个。先给一张决策表再讲三条我踩坑总结的原则。RAG 形态核心解决的问题构建成本适用场景Naive RAG基础文档问答低简单问答、原型验证Hybrid RAG精确术语 语义混合查询中客服、技术支持GraphRAG跨文档多跳推理、全局总结高研究分析、复杂知识库LightRAG动态知识库的多跳问答中增量更新的知识库Self-RAG按需检索、自我验证高需训练对准确性要求极高的场景Corrective RAG检索纠错、查询改写中检索质量不稳定的场景Agentic RAG动态多跳、任务驱动检索中高Agent 项目、复杂任务Multimodal RAG图文表格混合检索中高含图表的知识库Ontology RAG垂直领域语义约束高医疗、法律、工业原则一别追求最先进追求最匹配。我见过一个内部文档问答项目硬上 GraphRAG结果构建花了两周效果还不如调好切分的 Hybrid RAG。GraphRAG 的价值在多跳和全局总结如果你的问题都是某文档里某段说了什么它纯属浪费。原则二RAG 形态可以叠加不是单选。真实系统里往往是 Hybrid RAG 做召回Corrective RAG 做纠错Agentic RAG 做调度GraphRAG 做特定子问题的补充。把它们看成积木按需组合。原则三先解决数据质量再谈架构。我见过太多项目文档本身格式混乱、重复、过时然后指望 RAG 架构来救。垃圾进垃圾出这话在 RAG 上尤其成立。花在数据清洗上的时间回报率远高于换框架。8. 我在 Agent 项目里踩过的 RAG 坑与调优心得最后分享几个具体的、文档里不会写的坑都是真金白银换来的。坑一Agent 会过度检索。给它一个检索工具它会疯狂调用一个问题查七八次token 烧得飞快。解决办法是在工具描述里明确同一信息不要重复检索或者加一个检索次数上限。我一般设 3-5 次超过就强制它基于已有信息回答。坑二检索结果的排序比数量重要。早期我 Top-K 设 10结果噪声太多模型被带偏。后来改成 Top-5 重排rerank效果好很多。重排模型用轻量的 cross-encoder 就行延迟增加不多但精度提升明显。坑三多轮对话里的查询改写不能省。用户第二轮问那它呢Agent 直接拿那它呢去检索必然失败。必须结合对话历史改写查询。这一步在 Agentic RAG 里尤其关键因为 Agent 的多轮检索依赖上下文连贯。坑四别忘了给检索结果加来源标注。Agent 生成答案时如果能引用来源根据 XX 文档第 3 节可信度会高很多也方便用户核查。这在企业场景里几乎是刚需。坑五评估体系要早建。别等到上线才发现效果不行。建一个 50-100 条的小评测集覆盖典型问题每次改动都跑一遍。召回率、准确率、延迟三个指标盯着比拍脑袋调参靠谱得多。关于并发热词里有人问ai agent 怎么扛并发。RAG 侧的瓶颈通常在向量库和 LLM 调用。向量库选支持并发查询的大多数都支持LLM 调用要做限流和缓存。缓存是性价比最高的优化——相同查询直接返回缓存结果能省掉一大半 LLM 调用。我一般用查询的 embedding 做缓存 key相似度超过阈值就命中。这套东西我陆陆续续调了大半年从最朴素的 Naive RAG 一路演进到现在的 Agentic Hybrid Corrective 组合。回头看最大的体会是RAG 不是一个组件而是一套需要持续调优的系统。没有银弹只有针对你具体场景的反复打磨。Agent 时代给了 RAG 更大的舞台但也对工程能力提出了更高要求。把基础打牢再往上叠高级形态这条路走得慢但走得稳。
