GraphRAG、LightRAG 与 Agentic RAG

T2-9模块 2 · RAG 工程化面试权重 高更新于 2026-08
前置T2-1T2-7
关联题目Q2-19Q2-20Q2-21

这篇学完你能回答什么

  • 「什么是 Agentic RAG？和固定管线比强在哪、贵在哪？」
  • 「GraphRAG 解决什么问题？什么场景值得付出数倍索引成本？」
  • 「LightRAG 相比微软 GraphRAG 轻在哪？」

这三个是 2026 年 RAG 面试的新增高频考点——问的不是「你知不知道」，而是**「你知不知道什么时候不该用」**。

从两类答不出的问题讲起

你的标准 RAG（Advanced RAG：语义分块 + 混合检索 + rerank）已经跑得不错了。但总有两类问题它答不了：

第一类：需要跨文档串联。 「这家供应商同时出现在我们哪几份合同里？」——答案不在任何单一 chunk 里，它散落在十几份文档中，需要把实体关系拼起来才能回答。向量检索只会返回十几段互不相干的片段。

第二类：需要多步推理。 「我们上一代产品的主要投诉点，在新版本里解决了吗？」——这需要先查上一代的投诉，再查新版本的改动，然后比对。固定管线只检索一次就交给模型，中间那步「根据第一次结果决定第二次查什么」没人做。

两类问题分别催生了两条技术路线：GraphRAG 解决知识的结构化，Agentic RAG 解决检索的自主决策。

一类缺结构，一类缺决策
标准 RAG 已经跑得不错了，这两类问题却是它的结构性盲区
「这家供应商在我们哪几份合同里」

答案不在任何单一 chunk 里

散落在十几份文档中，要把实体关系拼起来才答得了

对应
GraphRAG · 知识的结构化

LLM 抽实体-关系-属性三元组建图

检索时沿关系边走，或直接用社区摘要回答全局问题

实体抽取社区检测社区摘要
「上一代的投诉点，新版解决了吗」

得先查投诉，再查改动，然后比对

固定管线只检索一次，中间那步决策没人做

对应
Agentic RAG · 检索的自主决策

把检索变成 Agent 的一个工具

由模型自己决定要不要再查、换什么角度查

Router多 RetrieverMemoryReAct 循环
第一类问题上，向量检索只会返回十几段互不相干的片段；第二类问题上，固定管线检索一次就交给模型，中间那步「根据第一次结果决定第二次查什么」没人做。

一、Agentic RAG：让检索变成一个循环

决策权交给模型，账也跟着涨
判断要不要查 → 调用检索工具 → 观察够不够 → 不够就换个角度再来一轮
用户问题
Agent 循环 · 判断
要不要检索？查什么Router 先判断 query 类型
调用检索工具
向量库 / BM25本地知识库
SQL / 图谱结构化与关系数据
Web 搜索库外信息
观察结果
够回答了吗结果不相关就自我修正
两个出口
不够 · 换角度或换数据源再检索一轮必须设最大轮次
够了生成答案退出循环
同一个问题，两种管线的账
项目固定管线Agentic 循环
LLM 调用检索一次后生成一次每次决策都要调一次
整体成本基准可能是数倍
首字延迟几百毫秒数秒
失控形态—反复检索同一个东西

一个很加分的中间方案：不必每次都让 LLM 深度思考 —— 预定义几种检索策略，用轻量分类器选择，只在复杂 query 上启用完整 Agent 循环，既拿到大部分收益又避免成本失控。

稳定性仍是短板：模型会「明明该检索却直接答」，也会「反复检索同一个东西」，所以最大轮次和总 token 预算是必设项，评测也要看轨迹而不只看最终答案。

贵在每一次决策都要多调一次 LLM。首字延迟从几百毫秒涨到数秒，对话式产品要慎重；不设最大轮次和 token 预算，遇到答不了的问题它会疯狂循环烧钱。

核心变化

传统 RAG 是一条固定流水线：检索一次 → 生成。Agentic RAG 把检索变成 Agent 的一个工具，由模型自己决策：

原文示意
用户问题
   ↓
【Agent 循环】
   判断：这个问题需要检索吗？需要检索什么？
   → 调用检索工具（可以是向量库、SQL、图谱、Web 搜索）
   → 观察结果：够回答了吗？
       ├─ 不够 → 换个角度 / 换个数据源，再检索一轮
       └─ 够了 → 生成答案

关键组件通常包括：Router（判断 query 类型，路由到合适的数据源）、多个 Retriever、Memory（维护对话历史支持上下文感知检索）、ReAct 循环（思考-行动-观察，迭代到答案完整）。

它强在哪

  • 动态多轮检索：根据中间结果决定要不要再查、查什么。
  • 工具多样化：向量库、BM25、Web 搜索、数据库按需组合。
  • 自我修正：检索结果不相关时能换个角度重来，而不是硬着头皮拿噪音作答。

到 2026 年，Agentic RAG 已被广泛视为企业复杂问答落地的事实标准。

它贵在哪（面试必答的另一半）

  • 成本：每次决策都要调一次 LLM，整体成本可能是传统 RAG 的数倍。
  • 延迟：多轮循环让首字延迟从几百毫秒涨到数秒，对话式产品要慎重。
  • 稳定性：模型的决策能力仍不够可靠，会出现「明明该检索却直接答」「反复检索同一个东西」的情况，需要设最大轮次和兜底。

一个务实的中间方案（很加分）：不必每次都让 LLM 深度思考——预定义几种检索策略，用轻量分类器选择，只在复杂 query 上启用完整 Agent 循环。既拿到大部分收益，又避免成本失控。

二、GraphRAG：把知识变成图

核心机制

索引阶段用 LLM 从文档里抽取实体-关系-属性三元组，构建知识图谱；再用社区检测算法把图划分成若干「社区」（比如「特斯拉-供应链-电池厂商」自然聚成一簇），并为每个社区预生成摘要。

检索时不只捞相似片段，而是沿着图的关系边走，或直接用社区摘要回答全局性问题。

它擅长什么

  • 多跳推理：「A 的供应商的竞争对手是谁」这种需要跨实体串联的问题。
  • 全局洞察：「公司的技术栈演进趋势是什么」——答案不在任何单篇文档里，需要把全库归纳起来，这是向量检索的结构性盲区。
  • 实体密集领域：法务、医疗、金融、供应链。

它的代价（这是考点）

索引成本约为普通 RAG 的 5–10 倍——因为要用 LLM 逐段抽取实体关系。而且文档更新时图的维护也麻烦得多。

所以标准回答是：除非你的场景确实是「实体密集 + 需要跨文档推理 + 需要全局洞察」，否则 Advanced RAG 就够了。 有个流传很广的判断：约 80% 的常规问答场景，好的文档解析 + 朴素 RAG 就能覆盖。

LightRAG 轻在哪（Q2-21）

LightRAG 是针对 GraphRAG 成本痛点的轻量化方案，核心差异：

  • 放弃了昂贵的社区检测与层级摘要生成，改用「实体图 + 向量检索」的双层检索（局部关键词找具体实体，全局关键词找主题关联）。
  • 支持增量更新：新文档进来只需增量抽取并接入图，不必像微软 GraphRAG 那样大规模重建索引——这是实际运维中最实在的改进。
  • 结果是索引成本和查询成本都显著下降，代价是全局摘要类问题的能力弱于完整 GraphRAG。

一句话答法：「GraphRAG 强在全局摘要但索引昂贵、更新困难；LightRAG 砍掉社区摘要那套重构建，换来低成本和增量更新，适合预算有限又想要图关系能力的场景。」

三、它们不是互斥的

2026 年的成熟架构通常是混合的：

Advanced RAG 作基座（分块 + 混合检索 + rerank）
      +
Agentic 作调度层（决定检不检、检哪、够不够）
      +
GraphRAG / SQL / Web 作为可选检索源之一

也就是说：Agentic RAG 是「决策层」，GraphRAG 是「数据层」，前者可以把后者当作工具之一来调用。把这层关系讲清楚，比单独介绍两个名词专业得多。

同样值得提一句的是 Multimodal RAG：图表、PDF 截图直接以图像形式建索引检索（ColPali 一类思路），适合报表、图纸密集的场景，属于 2026 年的另一个新方向。

工程实践（截至 2026-08）

什么时候升级（简版，完整决策树见 T2-10）：

原文示意
你的 badcase 主要是哪类？
  ├─ 单跳问答召回不准        → 别升级，回去优化分块/混合检索/rerank
  ├─ 需要多步推理、多源对比   → Agentic RAG
  ├─ 需要跨文档实体关系/全局洞察 → GraphRAG（预算够）/ LightRAG（预算紧）
  └─ 图表、扫描图纸为主       → Multimodal RAG

避坑：

  • 不要为了简历上好看而上 GraphRAG。面试官很爱追问「你为什么用它、不用会怎样」，答不出适用边界反而扣分。
  • Agentic RAG 一定要设最大检索轮次和总 token 预算，否则遇到答不了的问题会疯狂循环烧钱。
  • Agentic 系统的评测和传统 RAG 不同：要看轨迹（检索了几轮、路由对不对）而不只看最终答案（详见 T5-1）。
  • 实体抽取质量决定 GraphRAG 上限，抽取用的模型太小会让整张图不可用。
多数 badcase 不该用升级来解
先看 badcase 主要是哪一类，再决定要不要为它付出数倍成本
升级决策
badcase 主要是哪类升级到什么代价与边界
单跳问答召回不准别升级 —— 回去优化分块 / 混合检索 / rerank约 80% 的常规问答场景，好的文档解析 + 朴素 RAG 就能覆盖
需要多步推理、多源对比Agentic RAG（Router + 多 Retriever + ReAct 循环）成本可达数倍，首字延迟涨到秒级
跨文档实体关系 / 全局洞察GraphRAG（预算够）索引成本约为普通 RAG 的 5–10 倍，文档更新时图的维护也麻烦
同上，但预算紧LightRAG：实体图 + 向量的双层检索砍掉社区检测与层级摘要换来增量更新，全局摘要类问题弱一档
图表、扫描图纸为主Multimodal RAG（ColPali 一类思路）图表、PDF 截图直接以图像形式建索引
避坑与边界
两者不互斥
Agentic 是决策层，GraphRAG 是数据层 —— 前者可以把后者当作工具之一来调用
成熟架构长这样
Advanced RAG 作基座 + Agentic 作调度层 + GraphRAG / SQL / Web 作可选检索源
Agentic 必设上限
最大检索轮次 + 总 token 预算，否则遇到答不了的问题会疯狂循环烧钱
Agentic 怎么评
看轨迹：检索了几轮、路由对不对，而不只看最终答案（详见 T5-1）
抽取质量是上限
实体抽取用的模型太小，会让整张图不可用
LightRAG 的实惠
新文档只需增量抽取并接入图，不必像微软 GraphRAG 那样大规模重建索引
不要为了简历上好看而上 GraphRAG。面试官很爱追问「你为什么用它、不用会怎样」—— 答不出适用边界，比没用过更扣分。

面试视角

背名词不加分，说边界才加分
每个新架构都用三段式：解决什么 + 代价是什么 + 什么时候不该用
  1. 先说解决什么两类问题标准 RAG 结构上就答不了
  2. 再说代价是什么Agentic 成本数倍，GraphRAG 索引 5–10 倍
  3. 讲清两者关系Agentic 是决策层，GraphRAG 是数据层
  4. 给出反向判断约 80% 的常规问答场景其实不需要 GraphRAG
只读过：这些回答会暴露你
  • 背得出三元组和社区检测，答不出索引成本高多少倍
  • 把 LightRAG 说成「GraphRAG 简化版」，讲不出砍掉了什么
  • 把 GraphRAG 和 Agentic 并列成两个二选一的方案
  • 「我们上了 Agentic RAG」，说不出最大轮次和预算怎么设
  • 被问「不用会怎样」时只能把优点再重复一遍
真做过：这些细节骗不了人
  • 报得出索引成本 5–10 倍，并补一句文档更新时图维护也麻烦
  • 讲得出 LightRAG 砍掉社区摘要、换来增量更新这笔交易
  • 一句话摆清层次：Agentic 调度，GraphRAG 当它的数据源之一
  • Agentic 一定设最大轮次 + token 预算，评测看轨迹
  • 主动给反向判断：约 80% 的场景朴素 RAG 就能覆盖
追问的终点永远是同一句：「你的项目为什么（没）用」。到 2026 年这些概念的知晓率已经很高，稀缺的是判断力。配套题目：Q2-19、Q2-20、Q2-21、Q2-22；综合：Q2-25。

典型追问路径：Agentic RAG 是什么（Q2-19）→ 成本涨多少、怎么控 → GraphRAG 解决什么（Q2-20）→ 索引成本多高、什么时候不值得 → LightRAG 的差异（Q2-21）→ 你的项目为什么（没）用。

答题结构建议：每一个新架构都用「解决什么 + 代价是什么 + 什么时候不该用」三段式回答。 2026 年这些概念的知晓率已经很高，能背名词不构成优势；能说出「80% 场景其实不需要 GraphRAG」这种反向判断的，才是有工程判断力的候选人。

配套题目：Q2-19、Q2-20、Q2-21、Q2-22；综合：Q2-25。

小结与延伸

一句话总结：Agentic RAG 让检索从「一次性流水线」变成「自主循环」，GraphRAG 让知识从「一堆碎片」变成「一张关系网」——两者都不便宜，所以真正的能力是判断什么时候不用它们。

下一篇 T2-10：把这一章所有技术收拢成一张架构选型决策树。

继续深入

本篇归属第 2 章「RAG 工程化」，去做这一章的题。