拓冰网站定制 
从传统 RAG 到 Agentic RAG检索增强生成的新范式大语言模型擅长组织语言却无法天然掌握企业私有数据也无法保证参数中的知识始终准确、及时。RAGRetrieval-Augmented Generation检索增强生成的核心价值就是在生成答案之前引入外部知识让模型尽可能“有据可依”。传统 RAG 通常被概括为用户问题 → 向量化 → 检索 Top-K 文本块 → 拼接上下文 → LLM 生成答案这条链路简单、实用但它只回答了一个问题如何找到与问题相似的文本当任务变成跨文档归纳、关系分析、检索纠错、多步研究或图表理解时仅靠一次向量检索就不够了。GraphRAG、RAPTOR、Self-RAG、CRAG、Adaptive RAG、Agentic RAG 和 Multimodal RAG正是在索引结构、检索策略、结果校验和流程控制等不同位置上扩展了传统 RAG。这些名称并不是互斥的“产品型号”而是不同层面的能力。一个生产系统完全可以同时使用混合检索、重排、GraphRAG、纠错分支和 Agent 调度。1. 先重新认识传统 RAG严格来说RAG 最初的论文描述的是把参数化语言模型与可检索的非参数记忆结合起来今天工程语境中的 RAG 已经更加宽泛通常包含离线索引和在线问答两条链路。1.1 离线索引原始文档 → 解析与清洗 → 分块Chunking → 补充标题、时间、权限等元数据 → 生成向量 / 建立关键词索引 → 写入检索系统1.2 在线问答用户问题 → 查询改写 → 召回候选内容 → 重排与过滤 → 组装上下文 → LLM 生成答案与引用很多所谓的 RAG 问题其实并不出在模型而是出在更前面的环节文档解析丢失了表格、标题层级或页面关系Chunk 太小导致语义不完整太大又引入过多噪声向量检索擅长语义相似却可能漏掉产品编号、报错码和人名Top-K 只返回几个局部片段无法覆盖整个数据集检索到了内容但内容与问题无关、已经过期甚至彼此冲突系统把检索结果直接交给 LLM没有引用、拒答或质量评估机制。因此“升级 RAG”通常不是先换一个更大的模型而是先定位失败发生在解析、召回、排序、上下文还是生成阶段。2. 新型 RAG 到底“新”在哪里技术路线主要改变适合解决的问题主要代价Advanced / Hybrid RAG查询改写、关键词与向量混合召回、重排通用企业知识库、客服问答链路和调参更复杂RAPTOR / Hierarchical RAG对文档递归聚类并生成多层摘要长文档、多层级语义问题建索引成本、摘要误差GraphRAG抽取实体与关系构建图和社区摘要跨文档关系、全局主题分析索引成本高图质量难评估Self-RAG让经过训练的模型按需检索并自我批判需要动态检索与证据判断的生成通常需要专门训练或适配CRAG评估召回质量并在失败时纠正或回退检索结果不稳定的问答增加评估、外部检索成本Adaptive RAG按问题复杂度选择不检索、单次或迭代检索查询难度差异大、成本敏感路由错误会放大下游问题Agentic RAGAgent 规划、拆解任务并多轮调用数据源多来源、开放式复杂任务延迟、成本和安全风险更高Multimodal RAG联合检索文本、图片、表格、版面等信息PDF、图表、扫描件、工业文档模型与存储开销更大其中Advanced / Hybrid RAG 往往是最值得先做的基础升级其余方案应针对已经被评测集证明的具体瓶颈而不是全部堆进系统。3. Advanced / Hybrid RAG先把“检索”做好只使用向量召回时系统容易找到语义接近的内容却可能漏掉精确标识符。例如用户查询ERR_CONN_RESET、SKU-4821-A或某个姓名时关键词检索通常比纯向量检索更可靠。混合检索会并行执行两类搜索稀疏检索例如 BM25擅长关键词、专有名词和精确匹配稠密检索基于 Embedding擅长同义表达和语义相似。两路结果可以通过 RRFReciprocal Rank Fusion等方法合并再由 Reranker 对候选内容做第二次精排。Azure AI Search 的混合检索说明也采用了“全文检索 向量检索 RRF 融合”的思路。┌→ BM25 关键词召回 ─┐ 用户问题 → 查询改写 ─┤ ├→ 结果融合 → Rerank → 生成 └→ 向量语义召回 ───┘在生产环境中这一层还常常包括为模糊问题补全上下文或把一个复杂问题拆成多个子查询使用标题、时间、租户和访问权限做元数据过滤对候选 Chunk 去重、扩展相邻段落再进行重排要求答案提供引用证据不足时明确拒答。这类改造没有 Graph 或 Agent 那么醒目却通常能以更低的成本解决大部分知识库问答问题。4. GraphRAG从相似文本走向实体、关系与全局结构考虑这样一个问题分析过去一年的所有项目会议记录总结延期的主要原因并说明涉及哪些团队及其相互依赖。答案可能散落在几百份文档中。一次 Top-K 检索只能拿回少量与“项目延期”相似的片段很难覆盖整个语料库更难还原团队、项目、事件和原因之间的关系。以微软开源的 GraphRAG 为例索引阶段大致会执行文档 → TextUnit → 抽取实体、关系和关键声明 → 构建知识图谱 → 对图进行层次化社区聚类 → 为每个社区生成摘要报告查询时则可以按问题类型选择不同策略Local Search围绕具体实体及其邻居搜索同时结合原始文本块Global Search对社区报告执行 Map-Reduce回答“整个数据集的主要主题是什么”一类全局问题DRIFT Search用社区信息拓宽局部搜索并生成更具体的后续问题Basic Search对适合普通 Top-K 的问题继续使用基础向量 RAG。这也说明 GraphRAG 并不是“用知识图谱完全替代文本检索”而是为不同问题增加结构化的检索路径。具体查询方式可参考微软的 GraphRAG Query Engine 文档。GraphRAG 的代价同样明显实体和关系抽取需要额外模型调用社区摘要必须随数据更新错误关系还可能沿图传播。微软在 Dynamic Community Selection 的实验中报告在 AP News 数据集的 50 个全局问题上限定相同搜索深度时平均 Token 成本相对静态 Global Search 下降约 77%回答质量相近但搜索到更深层级时总成本也可能反而上升。因此这个数字应理解为特定实验条件下的结果而不是通用承诺。详见微软研究博客。5. RAPTOR给长文档建立“语义目录树”GraphRAG 强调实体和关系RAPTORRecursive Abstractive Processing for Tree-Organized Retrieval则强调不同抽象层级的语义。它会对原始 Chunk 递归执行嵌入、聚类和摘要最终形成一棵树全局摘要 / \ 主题摘要 A 主题摘要 B / \ / \ 章节块 章节块 章节块 章节块查询时系统既能检索底层原文也能命中高层摘要因此更适合长报告、书籍、论文集等需要跨章节理解的内容。RAPTOR 论文在 ICLR 2024 发表方法细节见论文页面。可以这样区分两者关心“谁与谁有什么关系”优先考虑 GraphRAG关心“长文档在不同粒度上讲了什么”优先考虑 RAPTOR两者都依赖生成式摘要因此最终答案仍应回溯到原始证据而不是只引用摘要。6. Self-RAG 与 CRAG不要盲目信任检索结果传统流水线通常默认“检索到的内容可以直接使用”。现实中Top-K 结果可能无关、过期或相互矛盾如果模型仍然被要求回答就会基于错误上下文生成一个看似可信的结论。Self-RAG 和 CRAG 都试图处理这个问题但它们不是同一种方案。6.1 Self-RAG把检索与反思教给模型Self-RAG训练模型生成特殊的 Reflection Tokens使其能够学习当前步骤是否需要检索检索到的段落是否相关生成内容是否得到证据支持当前回答整体上是否有用。它的关键点是经过训练的模型使用反思标记控制检索和生成。在普通工作流中增加一句“请检查答案”可以实现类似的产品行为但严格来说并不等同于 Self-RAG 原论文的方法。6.2 CRAG在流水线中加入纠错分支CRAGCorrective Retrieval-Augmented Generation更像一个可插入现有 RAG 的工程模块Query → Retrieve → Retrieval Evaluator │ ┌───────────┼───────────┐ ↓ ↓ ↓ Correct Ambiguous Incorrect │ │ │ 精炼内容 组合或补充 改写查询 / │ 检索结果 Web Search └───────────┴───────────┘ ↓ GenerateCRAG 论文使用轻量级检索评估器判断文档质量并在本地语料不足时引入 Web Search同时通过“分解—重组”过滤文档中的无关片段。两者的差异可以简化为Self-RAG重点在模型如何学习“按需检索和自我批判”CRAG重点在系统如何评估检索质量并触发纠正动作。它们能提高系统的鲁棒性但不能自动保证事实正确。尤其在医疗、金融和法律等高风险场景中仍需要可靠数据源、引用核验、权限控制和人工复核。7. Adaptive RAG不是每个问题都值得走最重的流程“公司的报销截止日是哪天”可能只需要一次检索“比较三份合同的责任条款并指出冲突”则可能需要拆解问题和多轮搜索。Adaptive RAG 会先判断问题复杂度再选择不同策略简单问题 → 不检索或直接回答 事实问题 → 单次检索 复杂问题 → 多步 / 迭代检索Adaptive-RAG使用分类器在不检索、单步检索和迭代检索之间动态路由。实际系统不一定需要训练专门分类器也可以从规则或小模型路由器开始。它的价值在于控制平均延迟和成本风险则是路由器一旦把复杂问题误判为简单问题后续流程可能连检索机会都没有。因此路由本身也需要独立评测并为低置信度结果设置回退策略。8. Agentic RAG把 RAG 变成 Agent 的一项能力传统 RAG 的流程主要由开发者预先固定Agentic RAG 则让 Agent 根据目标决定去哪里查、查几次以及下一步做什么。用户目标 → 任务拆解 → 选择数据源或工具 → 检索并评估证据 → 信息不足改写问题并继续检索 → 汇总证据、生成结论与引用例如用户提出“分析最近一个月 iOS 用户流失率上升的原因”Agent 可能执行查询指标数据库定位异常开始的时间检索 Release Notes寻找同期功能变更查询客服工单统计登录失败相关投诉检索 Jira寻找对应缺陷和修复进度交叉验证时间线输出结论、证据和不确定项。此时知识库检索只是 Agent 可以反复调用的工具之一。2025 年的 Agentic RAG 综述将常见能力概括为反思、规划、工具使用和多 Agent 协作。不过多 Agent 并不是 Agentic RAG 的必要条件如果单个 Agent 加确定性的工作流已经够用引入更多 Agent 只会增加协调成本。Agentic RAG 的主要风险包括多轮搜索带来的延迟和 Token 成本循环调用、错误规划和不可预测的停止条件外部网页或文档中的提示注入Agent 越权访问数据或执行工具中间证据链缺乏可观测性导致问题难以复现。因此生产系统需要限制工具权限、迭代次数和预算并完整记录查询、召回结果、工具调用与引用来源。9. Multimodal RAG文档不只有文字真实企业文档中大量信息存在于表格、流程图、截图、页面布局和扫描件中。只做 OCR 再切文本可能会破坏行列关系、图文对应关系和视觉层级。多模态 RAG 常见有两条路线解析后检索分别抽取正文、表格、图片描述和元数据再建立多个索引视觉检索直接对页面图像生成多向量表示召回页面后交给视觉语言模型理解。ColPali是第二条路线的代表工作之一它使用视觉语言模型为文档页面生成多向量表示。对于年报、幻灯片、技术手册和扫描 PDF这类方法能够保留比纯文本管线更多的版面信息但也会增加索引体积、推理成本和权限审查难度。10. 如何选择从问题类型而不是技术热度出发主要问题建议先尝试通用知识库问答召回不准优化解析与 Chunk再做 Hybrid Search Rerank产品编号、错误码、人名经常漏召回BM25 向量混合检索需要跨章节理解一份或少量长文档RAPTOR / Hierarchical RAG需要分析大量文档的主题、实体和关系GraphRAG检索结果质量波动大需要失败回退CRAG 或确定性的检索评估工作流查询难度差异大简单问题不想付出高成本Adaptive RAG任务要跨知识库、数据库、Web 和 APIAgentic RAG答案依赖表格、图片和页面布局Multimodal RAG一条更稳妥的演进路线通常是可靠的文档解析 → 混合召回 → Rerank → 引用与拒答 → 离线评测集 → 根据失败案例引入 Graph / Corrective / Adaptive / Agentic 能力11. 上线前应该评估什么只看“最终回答像不像人话”远远不够。RAG 至少要分层评估检索层RecallK、MRR、nDCG以及关键证据是否被召回生成层答案是否正确、是否忠于上下文、引用能否支持对应结论系统层P95 延迟、Token 成本、索引成本、数据新鲜度、拒答率业务层任务完成率、人工接管率、用户反馈和高风险错误率。RAGAS等框架可以帮助自动化评估上下文相关性、忠实度和回答质量但 LLM 评审本身也会产生偏差。关键场景仍应维护一套由人工审核、覆盖真实问题分布的测试集。结语传统 RAG 解决的是“给 LLM 找几段相关资料”新一代 RAG 进一步回答什么时候需要检索应该去哪里检索应该使用文本、图、表格还是外部工具检索结果是否相关、可信和完整不同证据之间有什么关系信息不足时下一步应该查什么RAG 正逐渐从“向量数据库前面的一个问答流程”演变为 AI 系统中的 Knowledge / Retrieval Layer。真正成熟的方案并不是组件最多的方案而是能够用最简单、可评估、可追溯的架构稳定解决目标问题。参考资料Lewis et al., Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks, NeurIPS 2020.Gao et al., Retrieval-Augmented Generation for Large Language Models: A Survey.Microsoft, GraphRAG Documentation.Sarthi et al., RAPTOR: Recursive Abstractive Processing for Tree-Organized Retrieval, ICLR 2024.Asai et al., Self-RAG: Learning to Retrieve, Generate, and Critique through Self-Reflection, ICLR 2024.Yan et al., Corrective Retrieval Augmented Generation, 2024.Jeong et al., Adaptive-RAG: Learning to Adapt Retrieval-Augmented Large Language Models through Question Complexity, NAACL 2024.Faysse et al., ColPali: Efficient Document Retrieval with Vision Language Models, ICLR 2025.Singh et al., Agentic Retrieval-Augmented Generation: A Survey on Agentic RAG, 2025.Es et al., RAGAS: Automated Evaluation of Retrieval Augmented Generation, EACL 2024. RAG 进入 2.0 时代：从传统 RAG 到 Agentic RAG——检索增强生成的新范式
从传统 RAG 到 Agentic RAG检索增强生成的新范式大语言模型擅长组织语言却无法天然掌握企业私有数据也无法保证参数中的知识始终准确、及时。RAGRetrieval-Augmented Generation检索增强生成的核心价值就是在生成答案之前引入外部知识让模型尽可能“有据可依”。传统 RAG 通常被概括为用户问题 → 向量化 → 检索 Top-K 文本块 → 拼接上下文 → LLM 生成答案这条链路简单、实用但它只回答了一个问题如何找到与问题相似的文本当任务变成跨文档归纳、关系分析、检索纠错、多步研究或图表理解时仅靠一次向量检索就不够了。GraphRAG、RAPTOR、Self-RAG、CRAG、Adaptive RAG、Agentic RAG 和 Multimodal RAG正是在索引结构、检索策略、结果校验和流程控制等不同位置上扩展了传统 RAG。这些名称并不是互斥的“产品型号”而是不同层面的能力。一个生产系统完全可以同时使用混合检索、重排、GraphRAG、纠错分支和 Agent 调度。1. 先重新认识传统 RAG严格来说RAG 最初的论文描述的是把参数化语言模型与可检索的非参数记忆结合起来今天工程语境中的 RAG 已经更加宽泛通常包含离线索引和在线问答两条链路。1.1 离线索引原始文档 → 解析与清洗 → 分块Chunking → 补充标题、时间、权限等元数据 → 生成向量 / 建立关键词索引 → 写入检索系统1.2 在线问答用户问题 → 查询改写 → 召回候选内容 → 重排与过滤 → 组装上下文 → LLM 生成答案与引用很多所谓的 RAG 问题其实并不出在模型而是出在更前面的环节文档解析丢失了表格、标题层级或页面关系Chunk 太小导致语义不完整太大又引入过多噪声向量检索擅长语义相似却可能漏掉产品编号、报错码和人名Top-K 只返回几个局部片段无法覆盖整个数据集检索到了内容但内容与问题无关、已经过期甚至彼此冲突系统把检索结果直接交给 LLM没有引用、拒答或质量评估机制。因此“升级 RAG”通常不是先换一个更大的模型而是先定位失败发生在解析、召回、排序、上下文还是生成阶段。2. 新型 RAG 到底“新”在哪里技术路线主要改变适合解决的问题主要代价Advanced / Hybrid RAG查询改写、关键词与向量混合召回、重排通用企业知识库、客服问答链路和调参更复杂RAPTOR / Hierarchical RAG对文档递归聚类并生成多层摘要长文档、多层级语义问题建索引成本、摘要误差GraphRAG抽取实体与关系构建图和社区摘要跨文档关系、全局主题分析索引成本高图质量难评估Self-RAG让经过训练的模型按需检索并自我批判需要动态检索与证据判断的生成通常需要专门训练或适配CRAG评估召回质量并在失败时纠正或回退检索结果不稳定的问答增加评估、外部检索成本Adaptive RAG按问题复杂度选择不检索、单次或迭代检索查询难度差异大、成本敏感路由错误会放大下游问题Agentic RAGAgent 规划、拆解任务并多轮调用数据源多来源、开放式复杂任务延迟、成本和安全风险更高Multimodal RAG联合检索文本、图片、表格、版面等信息PDF、图表、扫描件、工业文档模型与存储开销更大其中Advanced / Hybrid RAG 往往是最值得先做的基础升级其余方案应针对已经被评测集证明的具体瓶颈而不是全部堆进系统。3. Advanced / Hybrid RAG先把“检索”做好只使用向量召回时系统容易找到语义接近的内容却可能漏掉精确标识符。例如用户查询ERR_CONN_RESET、SKU-4821-A或某个姓名时关键词检索通常比纯向量检索更可靠。混合检索会并行执行两类搜索稀疏检索例如 BM25擅长关键词、专有名词和精确匹配稠密检索基于 Embedding擅长同义表达和语义相似。两路结果可以通过 RRFReciprocal Rank Fusion等方法合并再由 Reranker 对候选内容做第二次精排。Azure AI Search 的混合检索说明也采用了“全文检索 向量检索 RRF 融合”的思路。┌→ BM25 关键词召回 ─┐ 用户问题 → 查询改写 ─┤ ├→ 结果融合 → Rerank → 生成 └→ 向量语义召回 ───┘在生产环境中这一层还常常包括为模糊问题补全上下文或把一个复杂问题拆成多个子查询使用标题、时间、租户和访问权限做元数据过滤对候选 Chunk 去重、扩展相邻段落再进行重排要求答案提供引用证据不足时明确拒答。这类改造没有 Graph 或 Agent 那么醒目却通常能以更低的成本解决大部分知识库问答问题。4. GraphRAG从相似文本走向实体、关系与全局结构考虑这样一个问题分析过去一年的所有项目会议记录总结延期的主要原因并说明涉及哪些团队及其相互依赖。答案可能散落在几百份文档中。一次 Top-K 检索只能拿回少量与“项目延期”相似的片段很难覆盖整个语料库更难还原团队、项目、事件和原因之间的关系。以微软开源的 GraphRAG 为例索引阶段大致会执行文档 → TextUnit → 抽取实体、关系和关键声明 → 构建知识图谱 → 对图进行层次化社区聚类 → 为每个社区生成摘要报告查询时则可以按问题类型选择不同策略Local Search围绕具体实体及其邻居搜索同时结合原始文本块Global Search对社区报告执行 Map-Reduce回答“整个数据集的主要主题是什么”一类全局问题DRIFT Search用社区信息拓宽局部搜索并生成更具体的后续问题Basic Search对适合普通 Top-K 的问题继续使用基础向量 RAG。这也说明 GraphRAG 并不是“用知识图谱完全替代文本检索”而是为不同问题增加结构化的检索路径。具体查询方式可参考微软的 GraphRAG Query Engine 文档。GraphRAG 的代价同样明显实体和关系抽取需要额外模型调用社区摘要必须随数据更新错误关系还可能沿图传播。微软在 Dynamic Community Selection 的实验中报告在 AP News 数据集的 50 个全局问题上限定相同搜索深度时平均 Token 成本相对静态 Global Search 下降约 77%回答质量相近但搜索到更深层级时总成本也可能反而上升。因此这个数字应理解为特定实验条件下的结果而不是通用承诺。详见微软研究博客。5. RAPTOR给长文档建立“语义目录树”GraphRAG 强调实体和关系RAPTORRecursive Abstractive Processing for Tree-Organized Retrieval则强调不同抽象层级的语义。它会对原始 Chunk 递归执行嵌入、聚类和摘要最终形成一棵树全局摘要 / \ 主题摘要 A 主题摘要 B / \ / \ 章节块 章节块 章节块 章节块查询时系统既能检索底层原文也能命中高层摘要因此更适合长报告、书籍、论文集等需要跨章节理解的内容。RAPTOR 论文在 ICLR 2024 发表方法细节见论文页面。可以这样区分两者关心“谁与谁有什么关系”优先考虑 GraphRAG关心“长文档在不同粒度上讲了什么”优先考虑 RAPTOR两者都依赖生成式摘要因此最终答案仍应回溯到原始证据而不是只引用摘要。6. Self-RAG 与 CRAG不要盲目信任检索结果传统流水线通常默认“检索到的内容可以直接使用”。现实中Top-K 结果可能无关、过期或相互矛盾如果模型仍然被要求回答就会基于错误上下文生成一个看似可信的结论。Self-RAG 和 CRAG 都试图处理这个问题但它们不是同一种方案。6.1 Self-RAG把检索与反思教给模型Self-RAG训练模型生成特殊的 Reflection Tokens使其能够学习当前步骤是否需要检索检索到的段落是否相关生成内容是否得到证据支持当前回答整体上是否有用。它的关键点是经过训练的模型使用反思标记控制检索和生成。在普通工作流中增加一句“请检查答案”可以实现类似的产品行为但严格来说并不等同于 Self-RAG 原论文的方法。6.2 CRAG在流水线中加入纠错分支CRAGCorrective Retrieval-Augmented Generation更像一个可插入现有 RAG 的工程模块Query → Retrieve → Retrieval Evaluator │ ┌───────────┼───────────┐ ↓ ↓ ↓ Correct Ambiguous Incorrect │ │ │ 精炼内容 组合或补充 改写查询 / │ 检索结果 Web Search └───────────┴───────────┘ ↓ GenerateCRAG 论文使用轻量级检索评估器判断文档质量并在本地语料不足时引入 Web Search同时通过“分解—重组”过滤文档中的无关片段。两者的差异可以简化为Self-RAG重点在模型如何学习“按需检索和自我批判”CRAG重点在系统如何评估检索质量并触发纠正动作。它们能提高系统的鲁棒性但不能自动保证事实正确。尤其在医疗、金融和法律等高风险场景中仍需要可靠数据源、引用核验、权限控制和人工复核。7. Adaptive RAG不是每个问题都值得走最重的流程“公司的报销截止日是哪天”可能只需要一次检索“比较三份合同的责任条款并指出冲突”则可能需要拆解问题和多轮搜索。Adaptive RAG 会先判断问题复杂度再选择不同策略简单问题 → 不检索或直接回答 事实问题 → 单次检索 复杂问题 → 多步 / 迭代检索Adaptive-RAG使用分类器在不检索、单步检索和迭代检索之间动态路由。实际系统不一定需要训练专门分类器也可以从规则或小模型路由器开始。它的价值在于控制平均延迟和成本风险则是路由器一旦把复杂问题误判为简单问题后续流程可能连检索机会都没有。因此路由本身也需要独立评测并为低置信度结果设置回退策略。8. Agentic RAG把 RAG 变成 Agent 的一项能力传统 RAG 的流程主要由开发者预先固定Agentic RAG 则让 Agent 根据目标决定去哪里查、查几次以及下一步做什么。用户目标 → 任务拆解 → 选择数据源或工具 → 检索并评估证据 → 信息不足改写问题并继续检索 → 汇总证据、生成结论与引用例如用户提出“分析最近一个月 iOS 用户流失率上升的原因”Agent 可能执行查询指标数据库定位异常开始的时间检索 Release Notes寻找同期功能变更查询客服工单统计登录失败相关投诉检索 Jira寻找对应缺陷和修复进度交叉验证时间线输出结论、证据和不确定项。此时知识库检索只是 Agent 可以反复调用的工具之一。2025 年的 Agentic RAG 综述将常见能力概括为反思、规划、工具使用和多 Agent 协作。不过多 Agent 并不是 Agentic RAG 的必要条件如果单个 Agent 加确定性的工作流已经够用引入更多 Agent 只会增加协调成本。Agentic RAG 的主要风险包括多轮搜索带来的延迟和 Token 成本循环调用、错误规划和不可预测的停止条件外部网页或文档中的提示注入Agent 越权访问数据或执行工具中间证据链缺乏可观测性导致问题难以复现。因此生产系统需要限制工具权限、迭代次数和预算并完整记录查询、召回结果、工具调用与引用来源。9. Multimodal RAG文档不只有文字真实企业文档中大量信息存在于表格、流程图、截图、页面布局和扫描件中。只做 OCR 再切文本可能会破坏行列关系、图文对应关系和视觉层级。多模态 RAG 常见有两条路线解析后检索分别抽取正文、表格、图片描述和元数据再建立多个索引视觉检索直接对页面图像生成多向量表示召回页面后交给视觉语言模型理解。ColPali是第二条路线的代表工作之一它使用视觉语言模型为文档页面生成多向量表示。对于年报、幻灯片、技术手册和扫描 PDF这类方法能够保留比纯文本管线更多的版面信息但也会增加索引体积、推理成本和权限审查难度。10. 如何选择从问题类型而不是技术热度出发主要问题建议先尝试通用知识库问答召回不准优化解析与 Chunk再做 Hybrid Search Rerank产品编号、错误码、人名经常漏召回BM25 向量混合检索需要跨章节理解一份或少量长文档RAPTOR / Hierarchical RAG需要分析大量文档的主题、实体和关系GraphRAG检索结果质量波动大需要失败回退CRAG 或确定性的检索评估工作流查询难度差异大简单问题不想付出高成本Adaptive RAG任务要跨知识库、数据库、Web 和 APIAgentic RAG答案依赖表格、图片和页面布局Multimodal RAG一条更稳妥的演进路线通常是可靠的文档解析 → 混合召回 → Rerank → 引用与拒答 → 离线评测集 → 根据失败案例引入 Graph / Corrective / Adaptive / Agentic 能力11. 上线前应该评估什么只看“最终回答像不像人话”远远不够。RAG 至少要分层评估检索层RecallK、MRR、nDCG以及关键证据是否被召回生成层答案是否正确、是否忠于上下文、引用能否支持对应结论系统层P95 延迟、Token 成本、索引成本、数据新鲜度、拒答率业务层任务完成率、人工接管率、用户反馈和高风险错误率。RAGAS等框架可以帮助自动化评估上下文相关性、忠实度和回答质量但 LLM 评审本身也会产生偏差。关键场景仍应维护一套由人工审核、覆盖真实问题分布的测试集。结语传统 RAG 解决的是“给 LLM 找几段相关资料”新一代 RAG 进一步回答什么时候需要检索应该去哪里检索应该使用文本、图、表格还是外部工具检索结果是否相关、可信和完整不同证据之间有什么关系信息不足时下一步应该查什么RAG 正逐渐从“向量数据库前面的一个问答流程”演变为 AI 系统中的 Knowledge / Retrieval Layer。真正成熟的方案并不是组件最多的方案而是能够用最简单、可评估、可追溯的架构稳定解决目标问题。参考资料Lewis et al., Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks, NeurIPS 2020.Gao et al., Retrieval-Augmented Generation for Large Language Models: A Survey.Microsoft, GraphRAG Documentation.Sarthi et al., RAPTOR: Recursive Abstractive Processing for Tree-Organized Retrieval, ICLR 2024.Asai et al., Self-RAG: Learning to Retrieve, Generate, and Critique through Self-Reflection, ICLR 2024.Yan et al., Corrective Retrieval Augmented Generation, 2024.Jeong et al., Adaptive-RAG: Learning to Adapt Retrieval-Augmented Large Language Models through Question Complexity, NAACL 2024.Faysse et al., ColPali: Efficient Document Retrieval with Vision Language Models, ICLR 2025.Singh et al., Agentic Retrieval-Augmented Generation: A Survey on Agentic RAG, 2025.Es et al., RAGAS: Automated Evaluation of Retrieval Augmented Generation, EACL 2024.