普通 RAG 擅长找到“哪一段写了答案”，GraphRAG 更擅长回答“这些实体之间如何关联”。但图谱提取、索引和维护都有成本；如果问题只需要精确事实，换成 GraphRAG 可能只是把系统变复杂。
读完你可以：
- 根据问题类型判断是否需要图谱
- 理解 LightRAG 五种查询模式的边界
- 用同一套问题集比较质量、成本和延迟
01. 先判断是不是图谱问题
下面三类问题值得尝试 GraphRAG：跨文档实体关系、沿关系链追溯原因、对某个主题做全局归纳。例如“哪类故障会同时影响供电和通信模块”“某条维护规范改变后涉及哪些设备”。
如果问题是“设备 A 的额定电压是多少”，普通向量检索通常更便宜、更直接。一个实用判断是：答案是否需要拼接两条以上独立关系？如果不需要，先保留简单方案。
02. LightRAG 在索引阶段做什么
LightRAG 不只保存文本向量，还会从文档中提取实体和关系，并将它们连接到原始片段。构建过程可以拆成五步：文档清洗、语义切分、实体关系提取、去重合并、向量与图索引持久化。
入库前先统一同义词和标识符。例如“UPS”“不间断电源”和设备编号可能指向同一实体。若命名没有治理，图里会出现多个孤立节点，查询阶段再强的模型也难以补救。
03. 五种模式分别解决什么
当前 LightRAG 提供 naive、local、global、hybrid 和 mix 模式：
| 模式 | 主要检索对象 | 适合问题 |
|---|---|---|
| naive | 文本块向量 | 明确事实、快速基线 |
| local | 实体邻域和细粒度关系 | 某设备、人物或概念的局部问题 |
| global | 高层关系与主题信息 | 全局趋势、跨文档总结 |
| hybrid | local 与 global 合并 | 同时需要细节与全局视角 |
| mix | 图信息与向量片段融合 | 不确定问题类型时的稳健默认值 |
模式不是质量等级。global 处理一个精确数字，可能不如 naive；local 回答全局趋势，也可能只看到局部邻域。LightRAG 当前 README 将 mix 作为默认查询模式，实际项目仍应通过评测选择，详见官方仓库。
04. 做一次公平对比
使用完全相同的文档、生成模型和问题集，只切换查询模式。问题至少分为四组：精确事实、单实体关系、多跳因果、全局归纳。每组准备有标准答案的问题，并加入“资料中没有答案”的负样本。
记录五项指标：
- 检索证据是否覆盖标准答案。
- 回答中的每个关键结论能否追溯到证据。
- 实体和关系是否被错误合并。
- 首次索引与增量更新的耗时、调用量。
- 单次查询的延迟与上下文长度。
不要只给最终回答打分。GraphRAG 最危险的错误是“关系链看起来合理，但其中一条边并不存在”。验收时应抽查路径上的每个实体和关系是否能回到原文。
05. 常见失败与回退策略
实体碎片化时，先处理别名和编号规则；关系过多时，收紧实体类型和关系白名单；查询为空时，检查索引是否持久化、Embedding 维度是否一致；答案过于发散时，限制跳数、Top K 和上下文预算。
保留普通向量检索作为基线和回退路径。一个成熟系统可以先做问题分类：事实题走 naive，实体关系题走 local，全局题走 global，不确定时再用 mix。这样比让最昂贵的模式接管所有请求更容易解释和控制成本。
当答案依赖“关系”而不只是“相似片段”时，GraphRAG 才真正开始发挥价值。