一、高级 RAG 不是堆名词而是让流程会决策很多人第一次做 RAG流程都差不多文档切块、向量化、存进向量库用户提问后召回 Top-K再把上下文塞给大模型。这个 Demo 很快能跑起来但到了生产环境问题马上出现。用户问法可能很口语向量检索不一定召得准知识库可能没有覆盖这个问题复杂问题可能要查多次才能拼出完整答案有些问题甚至根本不需要检索。朴素 RAG 最大的问题不是“技术不够多”而是“流程太死”不管什么问题都走同一条流水线。所以高级 RAG 范式真正要解决的是流程决策问题什么时候检索检索结果能不能信检索不到怎么办是否需要从关系网络里找答案是否要让系统多轮检索。理解了这个主线再看 Self-RAG、CRAG、GraphRAG、Agentic RAG 就不会乱。二、三代 RAG 演进Naive、Advanced、ModularRAG 的发展可以先拆成三层底座。Naive RAG 是最基础的“检索 生成”Advanced RAG 在检索前后加增强比如 Query 改写、混合检索、Rerank、上下文压缩Modular RAG 则把整个流程拆成可组合的模块通过路由、分支、循环、融合等方式组装不同工作流。Modular RAG 的意义很大。它不再默认“所有问题都走一条链”而是把 RAG 做成乐高某类问题走图检索某类问题走本地知识库某类问题用网络搜索兜底某类问题交给 Agent 多轮完成。Self-RAG、CRAG、GraphRAG、Agentic RAG 都可以放在这个模块化思想下理解。三、Self-RAG让模型自己判断“要不要检索”普通 RAG 的默认动作是只要用户提问就去知识库检索。但这并不总是合理。比如用户说“你好”根本不需要查库用户问一个知识库没有覆盖的问题检索出来的内容可能完全不相关用户问复杂事实时检索内容有没有支撑答案也需要判断。Self-RAG 就是为了解决这个问题。Self-RAG 的核心思路是让模型在生成过程中学会自我反思。它不只是生成答案还会输出一些反思信号用来判断是否需要检索、检索内容是否相关、答案是否被证据支撑、最终回答是否有用。可以把它理解成给 RAG 加了一个“自检大脑”。Self-RAG 的执行流程第一步判断当前问题是否需要外部知识。如果不需要就直接回答避免无意义检索。第二步如果需要检索对召回片段逐条判断相关性不相关内容不能直接塞进上下文。第三步基于相关证据生成候选答案并检查答案是否被证据支撑。第四步评估答案对用户是否有用最后选择质量更高的结果输出。这里要注意论文里的 Self-RAG 不是简单写一个 Prompt 就能完整复刻它通常需要模型学习特殊的 reflection tokens。实际工程里如果你没有训练模型的条件可以先用“Router LLM 评估器 Rerank 分数”模拟这套决策机制。效果未必等同于论文版但落地成本低。什么时候用 Self-RAG适合问题类型非常杂的系统比如智能客服、企业知识助手、个人助理。它的价值是减少无效检索并避免模型拿不相关上下文硬答。但如果你的业务问题非常单一每次都必须查库那 Self-RAG 的收益就没那么明显。四、CRAG检索质量差时系统要会纠错Self-RAG 关注“要不要检索”CRAG 关注“检索了但结果很差怎么办”。这在生产里很常见知识库缺文档、文档过期、切块不合理、用户问法偏离业务术语都会让检索结果不靠谱。朴素 RAG 最危险的地方是它不会承认检索失败而是继续把低质量内容交给模型生成。CRAG 的做法是在检索后增加一个质量评估器。这个评估器判断召回结果和用户问题之间的匹配程度然后走不同分支高相关就正常生成低相关就切换到网络搜索或外部工具中间状态则把本地结果和外部结果合并再做过滤与重组。CRAG 的工程关键点评估器要轻量。可以用 Cross-Encoder、Rerank 分数、LLM Judge也可以训练一个小分类器。阈值要按业务调。不要照搬固定分数应该用真实问答集标注“可回答、需兜底、应拒答”。网络搜索要有白名单。金融、医疗、法律等场景不能随便抓网页需要来源可信度和时间戳。最后要保留检索证据。用户看到的不只是答案还要能追溯答案来自本地文档还是来自外部搜索。CRAG 最适合知识库覆盖不完整的场景。比如技术客服问到最新版本变更内部知识库还没更新这时系统可以临时走官网文档或搜索结果兜底。它的价值不是让系统“什么都回答”而是让系统知道什么时候本地知识不够并采取更稳的动作。五、GraphRAG向量检索找片段图检索找关系普通向量检索擅长找“和问题语义最像的片段”。如果用户问的是一个局部事实比如“某个字段是什么意思”向量检索通常够用。但如果用户问的是全局问题比如“这批投诉的核心矛盾是什么”“A 公司和 B 公司之间有什么业务关系”“近三年营收下滑和哪些事件相关”只找几个相似 chunk 就不够了。GraphRAG 的思路是先把文档里的实体、关系、事件抽出来构建知识图谱再通过社区发现把相关实体聚成社区并为每个社区生成摘要。查询时系统可以做局部实体检索也可以基于社区摘要做全局总结。GraphRAG 解决什么问题它解决的是“局部片段无法拼出全局理解”的问题。向量检索像在图书馆里按相似度找几页纸GraphRAG 像先整理出人物关系图、事件脉络图、主题社区再按问题去查局部或全局。企业知识分析组织、项目、系统、负责人之间的关系。金融研究串联公司、供应链、公告、行业事件、监管处罚。医疗知识关联疾病、症状、药物、指南、禁忌。长文档总结不是简单摘要而是按主题社区做层次化总结。GraphRAG 的代价也很明显离线构建成本高实体抽取、关系抽取、社区摘要都会消耗大量 LLM 调用图谱质量也依赖抽取质量。它不适合所有项目一上来就做但非常适合关系密集、跨文档推理明显的业务。六、Agentic RAG让 RAG 进入“计划—行动—观察—反思”循环如果 Self-RAG 是让系统会判断CRAG 是让系统会纠错GraphRAG 是让系统会看关系那么 Agentic RAG 就是让系统会行动。它把检索当作 Agent 的一个工具而不是固定流程中的一个步骤。模型可以根据当前上下文决定下一步查什么、用哪个工具、是否继续检索、什么时候生成最终答案。Agentic RAG 适合什么问题它适合多步骤问题。比如“帮我分析 A 公司最近三年的财报找出营收增速放缓的根本原因并验证公告和研报里有没有矛盾”。这个问题至少要查财报、公告、行业数据、历史新闻还要做对比和验证。一次 Top-K 检索通常不够。Agentic RAG 的关键不是“让模型随便想”而是给它受控工具向量检索、关键词检索、SQL 查询、图谱检索、网页搜索、内部 API。每次工具调用都要被记录每轮都要判断信息是否足够超过步数或成本就必须退出。代码示例一个 CRAG Agentic RAG 的路由骨架from typingimportLiteral LOW_SCORE0.35MID_SCORE0.65MAX_STEPS4def answer(query: str)-str: routerouter.classify(query)ifrouteno_retrieval:returnllm.answer(query)ifroutegraph:contextgraphrag.search(query,modeauto)returnllm.answer_with_citations(query, context)context[]current_queryqueryforstepinrange(MAX_STEPS): docshybrid_retriever.search(current_query,top_k20)scoreretrieval_evaluator.score(current_query, docs)ifscoreLOW_SCORE: docsweb_search.search(current_query,site_whitelistTrue)elifscoreMID_SCORE: docsmerge(docs, web_search.search(current_query,site_whitelistTrue))else: docsreranker.top_n(current_query, docs,n6)context.extend(docs)ifagent_judge.enough(query, context):breakcurrent_queryquery_rewriter.rewrite(query, context)ifnot evidence_checker.supported(query, context):return目前证据不足不能给出可靠结论。returnllm.answer_with_citations(query, context)这段代码的重点不是某个框架而是把决策点显性化是否需要检索、是否走图谱、检索质量是否足够、是否需要外部兜底、是否已经有足够证据、是否应该拒答。只要这些点清楚换成 LangGraph、LlamaIndex Workflow、Java 编排服务都可以。七、五种范式怎么选先看问题复杂在哪里技术选型不要看名字高级不高级要看业务的主要矛盾。如果只是检索召回一般先做 Advanced RAG如果本地知识库经常答不上来优先做 CRAG如果用户问的是关系和全局总结考虑 GraphRAG如果问题天然需要多轮检索和工具调用再做 Agentic RAG。八、生产级落地比范式更重要的是治理闭环高级 RAG 一旦进入生产复杂度会明显上升。你不仅要关心答案准不准还要关心检索链路是否可回放、Agent 是否会死循环、外部搜索是否可信、用户有没有权限访问某些文档、低置信度时是否会拒答。上线前必须想清楚的 6 件事第一证据优先。答案里最好带引用至少内部日志要能追溯到 chunk、文档、版本和来源。第二低置信度不要硬答。可以追问、拒答、转人工不能为了完整性编答案。第三Agent 要有边界。最大步数、最大 token、最大工具调用次数、工具白名单都要配置。第四外部搜索要治理。要限制来源、记录时间、去重、过滤广告页和低质量内容。第五图谱要有更新机制。实体关系会变化旧图谱不更新会制造新的错误。第六要分层评测。不要只看最终答案检索层、上下文层、生成层、Agent 层都要有指标。九、面试或方案汇报怎么讲可以这样回答RAG 从 Naive 到 Advanced再到 Modular本质是从固定流程走向动态编排。Advanced RAG 解决的是检索质量和上下文质量Self-RAG 解决的是要不要检索以及答案是否有证据支撑CRAG 解决的是检索质量差时如何纠错和兜底GraphRAG 解决的是跨文档关系和全局理解Agentic RAG 解决的是复杂问题需要多轮计划、检索和工具调用。真正落地时不建议一开始就把所有范式堆上去。更稳的路线是先把 Advanced RAG 做扎实建立评测集和日志再加检索质量评估器做 CRAG如果业务确实有实体关系和全局总结再建设 GraphRAG最后再把复杂任务交给 Agentic RAG并用权限、预算、步数和人工兜底控制风险。总结一句话高级 RAG 的目标不是让架构图更复杂而是让系统面对复杂问题时更稳、更可控、更有证据。能判断、能纠错、能看关系、能多轮行动这才是 RAG 从 Demo 走向生产的关键。
高级 RAG 范式：Self-RAG、CRAG、GraphRAG、Agentic RAG 到底解决什么问题？
一、高级 RAG 不是堆名词而是让流程会决策很多人第一次做 RAG流程都差不多文档切块、向量化、存进向量库用户提问后召回 Top-K再把上下文塞给大模型。这个 Demo 很快能跑起来但到了生产环境问题马上出现。用户问法可能很口语向量检索不一定召得准知识库可能没有覆盖这个问题复杂问题可能要查多次才能拼出完整答案有些问题甚至根本不需要检索。朴素 RAG 最大的问题不是“技术不够多”而是“流程太死”不管什么问题都走同一条流水线。所以高级 RAG 范式真正要解决的是流程决策问题什么时候检索检索结果能不能信检索不到怎么办是否需要从关系网络里找答案是否要让系统多轮检索。理解了这个主线再看 Self-RAG、CRAG、GraphRAG、Agentic RAG 就不会乱。二、三代 RAG 演进Naive、Advanced、ModularRAG 的发展可以先拆成三层底座。Naive RAG 是最基础的“检索 生成”Advanced RAG 在检索前后加增强比如 Query 改写、混合检索、Rerank、上下文压缩Modular RAG 则把整个流程拆成可组合的模块通过路由、分支、循环、融合等方式组装不同工作流。Modular RAG 的意义很大。它不再默认“所有问题都走一条链”而是把 RAG 做成乐高某类问题走图检索某类问题走本地知识库某类问题用网络搜索兜底某类问题交给 Agent 多轮完成。Self-RAG、CRAG、GraphRAG、Agentic RAG 都可以放在这个模块化思想下理解。三、Self-RAG让模型自己判断“要不要检索”普通 RAG 的默认动作是只要用户提问就去知识库检索。但这并不总是合理。比如用户说“你好”根本不需要查库用户问一个知识库没有覆盖的问题检索出来的内容可能完全不相关用户问复杂事实时检索内容有没有支撑答案也需要判断。Self-RAG 就是为了解决这个问题。Self-RAG 的核心思路是让模型在生成过程中学会自我反思。它不只是生成答案还会输出一些反思信号用来判断是否需要检索、检索内容是否相关、答案是否被证据支撑、最终回答是否有用。可以把它理解成给 RAG 加了一个“自检大脑”。Self-RAG 的执行流程第一步判断当前问题是否需要外部知识。如果不需要就直接回答避免无意义检索。第二步如果需要检索对召回片段逐条判断相关性不相关内容不能直接塞进上下文。第三步基于相关证据生成候选答案并检查答案是否被证据支撑。第四步评估答案对用户是否有用最后选择质量更高的结果输出。这里要注意论文里的 Self-RAG 不是简单写一个 Prompt 就能完整复刻它通常需要模型学习特殊的 reflection tokens。实际工程里如果你没有训练模型的条件可以先用“Router LLM 评估器 Rerank 分数”模拟这套决策机制。效果未必等同于论文版但落地成本低。什么时候用 Self-RAG适合问题类型非常杂的系统比如智能客服、企业知识助手、个人助理。它的价值是减少无效检索并避免模型拿不相关上下文硬答。但如果你的业务问题非常单一每次都必须查库那 Self-RAG 的收益就没那么明显。四、CRAG检索质量差时系统要会纠错Self-RAG 关注“要不要检索”CRAG 关注“检索了但结果很差怎么办”。这在生产里很常见知识库缺文档、文档过期、切块不合理、用户问法偏离业务术语都会让检索结果不靠谱。朴素 RAG 最危险的地方是它不会承认检索失败而是继续把低质量内容交给模型生成。CRAG 的做法是在检索后增加一个质量评估器。这个评估器判断召回结果和用户问题之间的匹配程度然后走不同分支高相关就正常生成低相关就切换到网络搜索或外部工具中间状态则把本地结果和外部结果合并再做过滤与重组。CRAG 的工程关键点评估器要轻量。可以用 Cross-Encoder、Rerank 分数、LLM Judge也可以训练一个小分类器。阈值要按业务调。不要照搬固定分数应该用真实问答集标注“可回答、需兜底、应拒答”。网络搜索要有白名单。金融、医疗、法律等场景不能随便抓网页需要来源可信度和时间戳。最后要保留检索证据。用户看到的不只是答案还要能追溯答案来自本地文档还是来自外部搜索。CRAG 最适合知识库覆盖不完整的场景。比如技术客服问到最新版本变更内部知识库还没更新这时系统可以临时走官网文档或搜索结果兜底。它的价值不是让系统“什么都回答”而是让系统知道什么时候本地知识不够并采取更稳的动作。五、GraphRAG向量检索找片段图检索找关系普通向量检索擅长找“和问题语义最像的片段”。如果用户问的是一个局部事实比如“某个字段是什么意思”向量检索通常够用。但如果用户问的是全局问题比如“这批投诉的核心矛盾是什么”“A 公司和 B 公司之间有什么业务关系”“近三年营收下滑和哪些事件相关”只找几个相似 chunk 就不够了。GraphRAG 的思路是先把文档里的实体、关系、事件抽出来构建知识图谱再通过社区发现把相关实体聚成社区并为每个社区生成摘要。查询时系统可以做局部实体检索也可以基于社区摘要做全局总结。GraphRAG 解决什么问题它解决的是“局部片段无法拼出全局理解”的问题。向量检索像在图书馆里按相似度找几页纸GraphRAG 像先整理出人物关系图、事件脉络图、主题社区再按问题去查局部或全局。企业知识分析组织、项目、系统、负责人之间的关系。金融研究串联公司、供应链、公告、行业事件、监管处罚。医疗知识关联疾病、症状、药物、指南、禁忌。长文档总结不是简单摘要而是按主题社区做层次化总结。GraphRAG 的代价也很明显离线构建成本高实体抽取、关系抽取、社区摘要都会消耗大量 LLM 调用图谱质量也依赖抽取质量。它不适合所有项目一上来就做但非常适合关系密集、跨文档推理明显的业务。六、Agentic RAG让 RAG 进入“计划—行动—观察—反思”循环如果 Self-RAG 是让系统会判断CRAG 是让系统会纠错GraphRAG 是让系统会看关系那么 Agentic RAG 就是让系统会行动。它把检索当作 Agent 的一个工具而不是固定流程中的一个步骤。模型可以根据当前上下文决定下一步查什么、用哪个工具、是否继续检索、什么时候生成最终答案。Agentic RAG 适合什么问题它适合多步骤问题。比如“帮我分析 A 公司最近三年的财报找出营收增速放缓的根本原因并验证公告和研报里有没有矛盾”。这个问题至少要查财报、公告、行业数据、历史新闻还要做对比和验证。一次 Top-K 检索通常不够。Agentic RAG 的关键不是“让模型随便想”而是给它受控工具向量检索、关键词检索、SQL 查询、图谱检索、网页搜索、内部 API。每次工具调用都要被记录每轮都要判断信息是否足够超过步数或成本就必须退出。代码示例一个 CRAG Agentic RAG 的路由骨架from typingimportLiteral LOW_SCORE0.35MID_SCORE0.65MAX_STEPS4def answer(query: str)-str: routerouter.classify(query)ifrouteno_retrieval:returnllm.answer(query)ifroutegraph:contextgraphrag.search(query,modeauto)returnllm.answer_with_citations(query, context)context[]current_queryqueryforstepinrange(MAX_STEPS): docshybrid_retriever.search(current_query,top_k20)scoreretrieval_evaluator.score(current_query, docs)ifscoreLOW_SCORE: docsweb_search.search(current_query,site_whitelistTrue)elifscoreMID_SCORE: docsmerge(docs, web_search.search(current_query,site_whitelistTrue))else: docsreranker.top_n(current_query, docs,n6)context.extend(docs)ifagent_judge.enough(query, context):breakcurrent_queryquery_rewriter.rewrite(query, context)ifnot evidence_checker.supported(query, context):return目前证据不足不能给出可靠结论。returnllm.answer_with_citations(query, context)这段代码的重点不是某个框架而是把决策点显性化是否需要检索、是否走图谱、检索质量是否足够、是否需要外部兜底、是否已经有足够证据、是否应该拒答。只要这些点清楚换成 LangGraph、LlamaIndex Workflow、Java 编排服务都可以。七、五种范式怎么选先看问题复杂在哪里技术选型不要看名字高级不高级要看业务的主要矛盾。如果只是检索召回一般先做 Advanced RAG如果本地知识库经常答不上来优先做 CRAG如果用户问的是关系和全局总结考虑 GraphRAG如果问题天然需要多轮检索和工具调用再做 Agentic RAG。八、生产级落地比范式更重要的是治理闭环高级 RAG 一旦进入生产复杂度会明显上升。你不仅要关心答案准不准还要关心检索链路是否可回放、Agent 是否会死循环、外部搜索是否可信、用户有没有权限访问某些文档、低置信度时是否会拒答。上线前必须想清楚的 6 件事第一证据优先。答案里最好带引用至少内部日志要能追溯到 chunk、文档、版本和来源。第二低置信度不要硬答。可以追问、拒答、转人工不能为了完整性编答案。第三Agent 要有边界。最大步数、最大 token、最大工具调用次数、工具白名单都要配置。第四外部搜索要治理。要限制来源、记录时间、去重、过滤广告页和低质量内容。第五图谱要有更新机制。实体关系会变化旧图谱不更新会制造新的错误。第六要分层评测。不要只看最终答案检索层、上下文层、生成层、Agent 层都要有指标。九、面试或方案汇报怎么讲可以这样回答RAG 从 Naive 到 Advanced再到 Modular本质是从固定流程走向动态编排。Advanced RAG 解决的是检索质量和上下文质量Self-RAG 解决的是要不要检索以及答案是否有证据支撑CRAG 解决的是检索质量差时如何纠错和兜底GraphRAG 解决的是跨文档关系和全局理解Agentic RAG 解决的是复杂问题需要多轮计划、检索和工具调用。真正落地时不建议一开始就把所有范式堆上去。更稳的路线是先把 Advanced RAG 做扎实建立评测集和日志再加检索质量评估器做 CRAG如果业务确实有实体关系和全局总结再建设 GraphRAG最后再把复杂任务交给 Agentic RAG并用权限、预算、步数和人工兜底控制风险。总结一句话高级 RAG 的目标不是让架构图更复杂而是让系统面对复杂问题时更稳、更可控、更有证据。能判断、能纠错、能看关系、能多轮行动这才是 RAG 从 Demo 走向生产的关键。
