一、高级 RAG 不是堆名词，而是让流程会决策

很多人第一次做 RAG，流程都差不多：文档切块、向量化、存进向量库，用户提问后召回 Top-K，再把上下文塞给大模型。这个 Demo 很快能跑起来，但到了生产环境，问题马上出现。

用户问法可能很口语，向量检索不一定召得准；知识库可能没有覆盖这个问题；复杂问题可能要查多次才能拼出完整答案；有些问题甚至根本不需要检索。朴素 RAG 最大的问题不是“技术不够多”，而是“流程太死”：不管什么问题，都走同一条流水线。

所以，高级 RAG 范式真正要解决的是流程决策问题：什么时候检索，检索结果能不能信，检索不到怎么办，是否需要从关系网络里找答案，是否要让系统多轮检索。理解了这个主线，再看 Self-RAG、CRAG、GraphRAG、Agentic RAG 就不会乱。

二、三代 RAG 演进：Naive、Advanced、Modular

RAG 的发展可以先拆成三层底座。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 typing import Literal
LOW_SCORE = 0.35
MID_SCORE = 0.65
MAX_STEPS = 4
def answer(query: str) -> str:
route = router.classify(query)
if route == "no_retrieval":
return llm.answer(query)
if route == "graph":
context = graphrag.search(query, mode="auto")
return llm.answer_with_citations(query, context)
context = []
current_query = query
for step in range(MAX_STEPS):
docs = hybrid_retriever.search(current_query, top_k=20)
score = retrieval_evaluator.score(current_query, docs)
if score < LOW_SCORE:
docs = web_search.search(current_query, site_whitelist=True)
elif score < MID_SCORE:
docs = merge(docs, web_search.search(current_query, site_whitelist=True))
else:
docs = reranker.top_n(current_query, docs, n=6)
context.extend(docs)
if agent_judge.enough(query, context):
break
current_query = query_rewriter.rewrite(query, context)
if not evidence_checker.supported(query, context):
return "目前证据不足，不能给出可靠结论。"
return llm.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 走向生产的关键。