RAG 进阶：从 Naive RAG 到 GraphRAG 与 Agentic RAG

为什么基础 RAG 会遇到瓶颈

基础 RAG 的流程很短：把问题转成向量，取回 Top-K 片段，再让大模型回答。它易于实现，也足以覆盖大量知识问答任务。

但复杂问题会暴露它的局限。例如“过去一年哪些供应风险反复影响多个项目”需要跨文档汇总；“对比两个方案的依赖与成本”可能要查多个数据源；一个含糊问题还可能需要多轮检索才能定位真正意图。

围绕这些问题，RAG 逐渐演化出 Advanced RAG、Modular RAG、GraphRAG 和 Agentic RAG。它们不是严格递进的产品版本，而是解决不同困难的架构思路。

Naive RAG：先建立可用基线

Naive RAG 通常包含一次向量检索和一次生成：

query_vector = embed(question)
chunks = vector_db.search(query_vector, top_k=5)
answer = llm.generate(prompt(question, chunks))

它的问题包括：查询表达与文档语言不一致；仅靠向量漏掉关键词；Top-K 中存在重复或噪声；长问题的多个子意图没有分别检索。

不过，Naive RAG 仍应作为基线。若基础链路还没有评估集和可观测性，直接叠加复杂模块只会让错误更难定位。

Advanced RAG：在检索前后提高质量

Advanced RAG 通常从三个位置改进。

检索前

系统可以改写查询、拆分子问题、扩展同义词，或先判断应该查询哪个知识库。

原问题：新版本升级后为什么变慢，怎样回退？

子问题 1：新版本已知性能问题有哪些？
子问题 2：当前环境满足哪些回退条件？
子问题 3：标准回退步骤是什么？

检索中

把向量检索与 BM25 等关键词方法结合，并加入元数据过滤。多路结果可用 Reciprocal Rank Fusion 等方式合并。

检索后

对候选片段重排、去重和压缩，再按来源可信度与时间排序。这样送给大模型的不是“最像的几段话”，而是一组更能回答问题的证据。

Modular RAG：把链路拆成可替换组件

当系统同时面对产品文档、工单数据库、网页搜索和实时 API 时，单一检索器不再合适。Modular RAG 将查询理解、路由、检索器、重排器、记忆和生成器拆成独立模块。

route = router.choose(question)

if route == "product_docs":
    evidence = hybrid_retriever.search(question)
elif route == "order_status":
    evidence = order_api.get(question)
elif route == "cross_source":
    evidence = merge(
        hybrid_retriever.search(question),
        order_api.get(question),
    )

模块化的价值不在于节点多，而在于职责清楚、能够独立评估和替换。代价是链路编排、错误处理和监控更复杂。

GraphRAG：当关系比单个片段更重要

向量检索擅长找与问题相似的局部片段，却不天然擅长回答跨文档的整体问题。GraphRAG 会从文档中提取实体、关系和声明，形成图结构，再对社区或子图生成摘要。

[项目 A] --依赖--> [供应商 X]
    |                  |
  使用              交付延迟
    v                  v
[组件 M] <------影响-- [风险事件 R]

面对“供应商 X 影响了哪些项目”时，图上的关系遍历比单纯相似度更自然；面对“所有项目面临的主要风险主题是什么”时，可以利用社区摘要进行全局归纳。

Microsoft 的 GraphRAG 实现会在索引阶段抽取实体、关系和声明，进行社区检测并生成分层摘要；查询侧提供 Local、Global、DRIFT 等模式。当前架构与模式可查看 GraphRAG 官方文档。

一个最小 GraphRAG 试验

官方 CLI 的基本流程是初始化工作区、建立索引，再选择查询方法：

python -m pip install graphrag
graphrag init --root ./ragtest
graphrag index --root ./ragtest
graphrag query --root ./ragtest --method local "实体 A 与事件 B 有什么关系？"

命令与配置可能随版本调整，实际使用前应对照官方快速入门。构建图谱通常会产生多次模型调用，先用小样本估算成本，并人工检查实体合并和关系抽取质量。

GraphRAG 并非通用升级包。若问题主要是“某项制度怎么规定”，普通混合检索通常更直接；若数据中实体关系密集，问题经常跨文档汇总，它才更可能体现价值。

Agentic RAG：让智能体决定下一步

Agentic RAG 把检索看成一种可调用工具。智能体先分析问题，再决定是否检索、查哪个来源、要不要改写问题，以及证据是否足够。

while not done and steps < max_steps:
    plan = agent.decide(question, evidence)

    if plan.action == "search_docs":
        evidence += doc_search(plan.query)
    elif plan.action == "query_database":
        evidence += sql_tool(plan.query)
    elif plan.action == "answer":
        done = True

return agent.compose_answer(question, evidence)

它适合检索路径不固定的研究、排障和多源分析任务。智能体发现结果不足后，可以换关键词、扩大时间范围或调用另一个工具。

与此同时，循环次数会增加成本和延迟；模型可能选错工具或反复检索；同一问题的执行路径也未必完全一致。因此必须设置最大步数、工具权限、超时、预算和停止条件。

单智能体、多智能体与分层协作

一个智能体可以独立完成规划、检索和回答，结构最简单。任务扩大后，也可以按角色拆分：检索智能体负责找证据，分析智能体负责比较，审查智能体检查引用。

协调者
  ├── 文档检索智能体
  ├── 数据查询智能体
  └── 证据审查智能体

多智能体并不会自动提升质量。它会增加消息传递、状态同步和错误归因成本。只有当任务可以按信息源或专业职责清晰拆分，并且每个角色都有独立工具或评估标准时，这种结构才值得使用。

如何选择合适架构

可以按问题复杂度逐级判断：

一次检索能稳定命中？
  是 → 保留 Naive RAG
  否 → 加入查询改写、混合检索和重排

是否存在多个异构数据源？
  是 → 使用 Modular RAG 做路由

是否经常需要跨实体、跨文档归纳？
  是 → 评估 GraphRAG

检索路径是否要根据中间结果动态变化？
  是 → 评估 Agentic RAG

每增加一层能力，都应给出可量化收益：召回率是否提高，复杂问题正确率是否改善，延迟与调用成本增加多少。若无法回答这些问题，复杂架构很可能只是在掩盖基础数据质量问题。

小结

RAG 的进阶方向，本质上是在检索链路中加入更多判断：Advanced RAG 优化检索前后，Modular RAG 路由不同组件，GraphRAG 显式建模实体关系，Agentic RAG 则根据中间结果动态规划。

架构越强，运行和评估成本也越高。先用基础 RAG 建立可靠基线，再只为已经出现的具体问题增加模块，通常比一步搭出最复杂的系统更稳妥。