怎么考「GraphRAG 解决什么问题？什么场景值得付出数倍索引成本？」

我要答我要考
Q2-20GraphRAG中高频

谁在问：二面·架构向；简历写了 GraphRAG 必被追问「为什么用它」

开场怎么问

GraphRAG 和普通 RAG 差在哪？

换个问法

  • 你们上 GraphRAG 了吗？为什么（不）上？
  • 知识图谱这套东西成本不低吧，怎么判断值不值？

五层追问链

左边照着问，右边对着听。最后一层是压力面，不必每个候选人都问到。

索引成本高 5–10 倍，具体高在哪？

期望
每个 chunk 都要过一次 LLM 做实体关系抽取（这是主要开销），还要做实体消歧/对齐、构图、社区检测、为每个社区生成摘要——后面几步也都可能调用 LLM。所以成本随文档量线性放大，百万级文档的初始建图可能是天级作业和可观的账单。
信号
能指出「实体抽取是主要开销」的，是真估算过；只说「因为要建图所以贵」的是泛泛而谈。

文档更新了，图怎么维护？

期望
这是 GraphRAG 最大的工程痛点。新文档进来要抽取实体、和已有实体做消歧对齐（同一个实体不同表述要合并）、更新关系边；社区结构可能因此改变，严格来说需要重新做社区检测和摘要生成。完整 GraphRAG 往往要大规模重建，这也是 LightRAG 这类方案的主要卖点（见 Q2-21）。
信号
能说出「实体消歧」这个具体难点的，做过图谱相关工作。

怎么保证抽取出来的实体关系是对的？

期望
实体抽取质量决定 GraphRAG 的上限，抽取用的模型太小会让整张图不可用。手段：用足够强的模型做抽取、给明确的实体类型 schema（而非开放抽取）、抽取后抽样人工校验、对高频实体做别名归一化词典。图错了下游全错，而且很难从答案倒推出是图的问题。
信号
意识到「图的质量是上限」的，理解了系统性风险。

面试官说「我们数据量不大但关系复杂」，你怎么建议？

期望
数据量不大恰恰是 GraphRAG 的甜点区——索引成本的绝对值可控，而关系复杂正是它的强项。建议路径：先用 Advanced RAG 跑通拿 badcase，确认失败确实集中在跨实体关联，再上图；预算紧可先用 LightRAG。别跳过基线直接上图，否则你不知道图带来了多少增量收益。
信号
能给「先基线后升级」路径的，有工程节制；直接说「那就上 GraphRAG」的，缺少验证意识。

你简历写了 GraphRAG，如果当时不用它，效果会差多少？

期望
这是简历深挖的杀招。要能给出具体对比：哪一类 query 靠 Advanced RAG 答不了、占比多少、上图之后这类的准确率变化。如果当时没做这个对比，坦诚承认并说明「现在回头看应该先建基线做 A/B」，比强行编数字可信得多。
信号
答不出任何对比数据、只能说「效果更好」的，基本坐实了「为了简历好看而上」。

危险信号

听到这些话，基本可以判定是背题而不是做过。

只讲「用知识图谱增强检索」，说不出具体解决了哪类问题。
完全不提成本代价，把它当免费升级。
答不出任何不该用它的场景。
简历写了但说不清为什么用、不用会差多少——面试官最反感的一类。
把 GraphRAG 和「用图数据库存向量」混为一谈。

评分卡

  1. 能说出普通 RAG 的两类结构性盲区（跨文档关联、全局归纳）
  2. 能描述索引阶段的实体关系抽取与建图
  3. 能明确说出索引成本量级（约 5–10 倍）
  4. 能说出适用领域（实体密集、关系复杂）
  5. 能给出反向判断：多数场景不需要它
  6. 加分：知道社区检测与摘要是全局问题的解法机制
  7. 加分：知道增量更新与实体消歧是主要工程痛点
  8. 加分：主张先建 Advanced RAG 基线再决定是否升级
参考答案与考察意图面试中途别看这一段

考察意图

这题的核心考点是「适用边界」，不是「是什么」。 面试官最想听到的其实是一句反向判断：大部分场景不需要它。能说出「什么时候不该用」的候选人，比能背出社区检测算法的候选人评价更高。因为简历上写 GraphRAG 的人不少，能说清为什么用的很少。

参考答案

图 2 · 60 分与 90 分差在哪：代价、演进、怎么验证
60

60 分答案（及格线）

普通 RAG 是把文档切块向量化，检索时找语义相似的片段。它有两类结构性盲区：跨文档实体关联（「这个供应商同时出现在我们哪几份合同里」——答案散落在十几份文档中，向量检索只会返回互不相干的片段）和全局归纳（「公司的技术栈演进趋势是什么」——答案不在任何单篇文档里）。

GraphRAG 在索引阶段用 LLM 从文档抽取实体-关系-属性三元组构建知识图谱，检索时沿关系边走，或用预生成的社区摘要回答全局问题。适合实体密集、关系复杂的领域：法务、医疗、金融、供应链。

90

90 分答案（有生产经验的回答）

补三层：

说清社区检测这一步：图建好后用社区检测算法自动识别隐藏的聚簇（比如「某车企-供应链-电池厂商」自然聚成一簇），并为每个社区预生成摘要。这正是它能回答全局性问题的机制——全局问题不靠检索，靠预先归纳好的社区摘要。

明确说出代价（本题核心）：索引成本约为普通 RAG 的 5–10 倍，因为要用 LLM 逐段抽取实体关系。而且文档更新时图的维护麻烦得多——完整 GraphRAG 的增量更新是个实打实的工程难题。

给出反向判断（最加分）：除非场景确实是「实体密集 + 需要跨文档推理 + 需要全局洞察」三者同时成立，否则 Advanced RAG 就够了。 业界有个流传很广的经验：约 80% 的常规问答，好的文档解析 + 朴素 RAG 就能覆盖。GraphRAG 的思想是对的（预先建立关联、降低检索时的认知负担），但当前实现方式偏重。

给判断流程：先看 badcase 类型——如果失败集中在单跳问答的召回不准，那是分块/检索的问题，上 GraphRAG 完全跑偏；只有当失败集中在「需要串联多个文档的实体」时才考虑。

攒够了去组卷页一键生成可打印的面试题单