GraphRAG 解决什么问题？什么场景值得付出数倍索引成本？
谁在问：二面·架构向；简历写了 GraphRAG 必被追问「为什么用它」
口语化问法
- GraphRAG 和普通 RAG 差在哪？
- 你们上 GraphRAG 了吗？为什么（不）上？
- 知识图谱这套东西成本不低吧，怎么判断值不值？
考察意图
这题的核心考点是「适用边界」，不是「是什么」。 面试官最想听到的其实是一句反向判断：大部分场景不需要它。能说出「什么时候不该用」的候选人，比能背出社区检测算法的候选人评价更高。因为简历上写 GraphRAG 的人不少，能说清为什么用的很少。
参考答案
60 分答案（及格线）
普通 RAG 是把文档切块向量化，检索时找语义相似的片段。它有两类结构性盲区：跨文档实体关联（「这个供应商同时出现在我们哪几份合同里」——答案散落在十几份文档中，向量检索只会返回互不相干的片段）和全局归纳（「公司的技术栈演进趋势是什么」——答案不在任何单篇文档里）。
GraphRAG 在索引阶段用 LLM 从文档抽取实体-关系-属性三元组构建知识图谱，检索时沿关系边走，或用预生成的社区摘要回答全局问题。适合实体密集、关系复杂的领域：法务、医疗、金融、供应链。
90 分答案（有生产经验的回答）
补三层：
说清社区检测这一步：图建好后用社区检测算法自动识别隐藏的聚簇（比如「某车企-供应链-电池厂商」自然聚成一簇），并为每个社区预生成摘要。这正是它能回答全局性问题的机制——全局问题不靠检索，靠预先归纳好的社区摘要。
明确说出代价（本题核心）：索引成本约为普通 RAG 的 5–10 倍，因为要用 LLM 逐段抽取实体关系。而且文档更新时图的维护麻烦得多——完整 GraphRAG 的增量更新是个实打实的工程难题。
给出反向判断（最加分）：除非场景确实是「实体密集 + 需要跨文档推理 + 需要全局洞察」三者同时成立，否则 Advanced RAG 就够了。 业界有个流传很广的经验：约 80% 的常规问答，好的文档解析 + 朴素 RAG 就能覆盖。GraphRAG 的思想是对的（预先建立关联、降低检索时的认知负担），但当前实现方式偏重。
给判断流程：先看 badcase 类型——如果失败集中在单跳问答的召回不准，那是分块/检索的问题，上 GraphRAG 完全跑偏；只有当失败集中在「需要串联多个文档的实体」时才考虑。
追问链
索引成本高 5–10 倍，具体高在哪？
期望每个 chunk 都要过一次 LLM 做实体关系抽取（主要开销）→ 实体消歧/对齐 → 构图 → 社区检测 → 逐社区生成摘要，后面几步也可能调 LLM；成本随文档量线性放大，百万级文档的初始建图是天级作业加可观账单信号指出「实体抽取是主要开销」→ 真估算过；只说「因为要建图所以贵」→ 泛泛而谈文档更新了，图怎么维护？
期望GraphRAG 最大的工程痛点：新文档要抽实体 → 与已有实体消歧对齐（同一实体的不同表述要合并）→ 更新关系边；社区结构可能变，严格说要重做社区检测和摘要 —— 完整 GraphRAG 往往得大规模重建，这正是 LightRAG 的主要卖点信号说得出「实体消歧」这个具体难点 → 做过图谱相关工作怎么保证抽取出来的实体关系是对的？
期望实体抽取质量决定 GraphRAG 的上限，抽取模型太小整张图不可用。手段：用足够强的模型抽取、给明确的实体类型schema而非开放抽取、抽完抽样人工校验、高频实体做别名归一化词典。图错了下游全错，且很难从答案倒推出是图的问题信号意识到「图的质量就是系统上限」→ 理解了系统性风险「我们数据量不大但关系复杂」，你怎么建议？
期望数据量不大恰是 GraphRAG 的甜点区：索引成本绝对值可控，关系复杂正中强项。路径：先用 Advanced RAG 跑通拿 badcase → 确认失败真集中在跨实体关联 → 再上图；预算紧先上 LightRAG。别跳过基线直接上图，否则不知道图的增量有多少信号能给「先基线后升级」路径 → 有工程节制；直接说「那就上 GraphRAG」→ 缺验证意识你简历写了 GraphRAG，如果当时不用它，效果会差多少？
期望简历深挖的杀招。要给具体对比：哪一类 query 靠 Advanced RAG 答不了 → 这类占比多少 → 上图后这类的准确率变化。当时没做过这个对比就坦诚承认，补一句「现在回头看应该先建基线做 A/B」—— 比强行编数字可信得多信号答不出任何对比数据、只能说「效果更好」→ 基本坐实「为了简历好看而上」
评分要点
- 能说出普通 RAG 的两类结构性盲区（跨文档关联、全局归纳）
- 能描述索引阶段的实体关系抽取与建图
- 能明确说出索引成本量级（约 5–10 倍）
- 能说出适用领域（实体密集、关系复杂）
- 能给出反向判断：多数场景不需要它
- 加分：知道社区检测与摘要是全局问题的解法机制
- 加分：知道增量更新与实体消歧是主要工程痛点
- 加分：主张先建 Advanced RAG 基线再决定是否升级