LightRAG 相比微软 GraphRAG 轻在哪？
谁在问：进阶加分题；关注开源生态的面试官、图谱方向团队
口语化问法
- 除了微软那套 GraphRAG，还了解别的图谱 RAG 方案吗？
- LightRAG 的 light 体现在哪？
- 预算有限但想要图关系能力，怎么选？
考察意图
这是进阶加分题，答不上来不致命，但答得好能显著加分。它验证的不是记忆力，而是你是否关注开源生态的实际演进——以及能否从「成本痛点 → 简化设计 → 能力取舍」这条线理解一个方案为什么被设计成那样。
参考答案
60 分答案（及格线）
LightRAG 是针对 GraphRAG 成本痛点的轻量化方案。主要差异：放弃了昂贵的社区检测和层级摘要生成，改用「实体图 + 向量检索」的双层检索；支持增量更新，新文档进来只需增量抽取并接入图，不必大规模重建索引。结果是索引成本和查询成本都显著下降，代价是全局摘要类问题的能力弱于完整 GraphRAG。
90 分答案（有生产经验的回答）
把三点差异讲透：
① 索引阶段砍掉了什么：微软 GraphRAG 的重头戏是社区检测 + 为每个社区逐层生成摘要——这一步要大量 LLM 调用，也是成本的主要来源之一。LightRAG 只保留实体关系抽取和图构建，不做社区层级摘要。
② 检索方式换成双层：局部关键词找具体实体及其邻居（回答「X 的参数是什么」这类具体问题），全局关键词找主题层面的关联（回答偏概括性的问题）。这是用检索策略的分层，替代了预先生成的社区摘要层级。
③ 增量更新是最实在的改进：这是实际运维中最痛的点。完整 GraphRAG 因为社区结构和摘要依赖全局，新文档进来严格说需要重做社区检测；LightRAG 的设计让新实体和边可以直接挂进已有图。知识库每天更新的场景，这个差别决定了方案能不能长期跑下去。
一句话答法（面试可直接用）：「GraphRAG 强在全局摘要，但索引昂贵、更新困难；LightRAG 砍掉社区摘要那套重构建，换来低成本和增量更新，适合预算有限又想要图关系能力的场景。代价是纯全局归纳类问题会弱一些。」
再补一个选型判断：如果你的核心需求是「跨实体的具体关联查询」，LightRAG 基本够用；如果核心需求是「给我总结整个知识库的宏观趋势」，那社区摘要那套是刚需，省不掉。
追问链
没有社区摘要，全局性问题它怎么答？
期望靠全局关键词那一层：从 query 抽高层概念 → 在图上找相关主题簇与高频实体 → 把它们的邻域内容送给模型归纳。本质是把「预先归纳」改成「查询时归纳」 —— 省了索引成本，负担转移到查询时，覆盖面不如预生成摘要完整信号说得出「预先归纳 vs 查询时归纳」这个转移 → 理解到了设计权衡层面增量更新真的完全没问题吗？
期望不是零成本：新实体仍要和已有实体消歧对齐，否则图里出现重复实体、关系断裂；长期增量后图质量会漂移，仍需定期整体校验或重建。它是「大幅缓解」不是「彻底解决」信号能指出「消歧仍然是难点」→ 不是照搬宣传材料除了 LightRAG，还有别的轻量路线吗？
期望三条降本路线：只对高价值文档建图、其余走普通 RAG（混合架构）；用规则/NER 模型替代 LLM 做实体抽取（大幅降本，关系抽取质量下降）；只建实体索引不建完整关系图（元数据关联代替边）。关键是「图能力按需分级」这个思路，不是背方案名信号能自己推出降本路径 → 比只记得一个产品名强得多怎么验证 LightRAG 在你的场景里够不够用？
期望建评测集时单独分「跨文档关联」桶和「全局归纳」桶，两个方案各跑一遍对比；全局归纳那桶在业务里占比很低，LightRAG 的短板就无关紧要。用业务问题分布选方案，不是用方案能力表信号能把选型问题转化成评测问题 → 方法论成熟这两个我们都不打算上，你有什么建议？
期望完全合理 —— 先确认 badcase 是否真集中在跨文档关联 → 不是的话，投入回到分块、混合检索、rerank 这些性价比更高的地方 → 确有关联需求也先走低成本替代：结构化元数据（实体作为 chunk 的标签）+ 元数据过滤检索，能覆盖一部分简单关联查询。不上图不等于没办法信号能给出「不上图的替代方案」→ 思考的是问题而不是技术
评分要点
- 知道 LightRAG 的核心是砍掉社区检测与层级摘要
- 能说出双层检索（局部实体 / 全局主题）的机制
- 能说出增量更新是最实在的改进
- 能说出代价（全局归纳类问题能力弱）
- 加分：能指出增量更新仍面临实体消歧问题
- 加分：能自己推出其他降本路线
- 加分：能把选型问题转化为「按业务问题分布做评测对比」