怎么考「LightRAG 相比微软 GraphRAG 轻在哪？」

没有社区摘要，全局性问题它怎么答？

期望

靠全局关键词那一层——从 query 抽出高层概念，在图上找相关的主题簇和高频实体，把这些及其邻域内容送给模型归纳。本质是把「预先归纳」改成「查询时归纳」，省了索引成本但把负担转移到了查询时，且覆盖面不如预生成的摘要完整。

信号

能说出「预先归纳 vs 查询时归纳」这个转移关系的，理解到了设计权衡层面。

增量更新真的完全没问题吗？

期望

也不是零成本——新实体仍需和已有实体做消歧对齐（同一实体的不同表述要合并），否则图里会出现重复实体、关系断裂；长期增量后图的质量可能漂移，仍需定期做整体校验或重建。它是「大幅缓解」而非「彻底解决」。

信号

能指出「消歧仍然是难点」的，说明不是照搬宣传材料。

除了 LightRAG，还有别的轻量路线吗？

期望

可以答几种思路——只对高价值文档建图、其余走普通 RAG（混合架构）；用规则/NER 模型代替 LLM 做实体抽取（大幅降本，代价是关系抽取质量下降）；只建实体索引不建完整关系图（用元数据关联代替边）。关键是展示「图能力可以按需分级」的思路，而不只是背方案名。

信号

能自己推出降本路径的，比只记得一个产品名强得多。

怎么验证 LightRAG 在你的场景里够不够用？

期望

建评测集时单独分一个「跨文档关联」桶和一个「全局归纳」桶，两种方案各跑一遍对比。如果全局归纳那桶的问题在你的业务里占比很低，LightRAG 的短板就无关紧要。用业务问题分布来选方案，而不是用方案能力表。

信号

能把选型问题转化为评测问题的，方法论成熟。

如果我说这两个我们都不打算上，你有什么建议？

期望

完全合理——先确认 badcase 是否真的集中在跨文档关联；如果不是，投入应该回到分块、混合检索、rerank 这些性价比更高的地方。即使确实有关联类需求，也可以先用低成本替代：结构化元数据（把实体作为 chunk 的标签）+ 元数据过滤检索，能覆盖一部分简单关联查询。不上图不等于没办法。

信号

能给出「不上图的替代方案」的，说明思考的是问题而不是技术。