企业生产实践：成本、增量更新与评估
GraphRAG 上生产的三个决定性问题：成本算不划算、更新跑不跑得动、效果有没有变好。本章按这三条主线展开，并给出落地的检查清单。
8.1 成本：索引是 LLM token 生意
GraphRAG 索引成本由三个乘法构成：
总成本 ≈ 文本单元数 × 抽取轮数（1 + gleaning 轮数）× 单元 token 数 × 模型单价
+ 社区报告数 × 报告生成 token 数 × 模型单价直观量级（官方与社区的口径）：万级文档语料用 GPT-4 级模型跑完整 GraphRAG 索引，成本在千到万美元级——这是"GraphRAG 太贵"吐槽的来源。降本工具箱按性价比排序：
- 抽取/摘要用小模型：抽取是格式转换任务（JSON 输出），当前一代小模型（及便宜的云端档位）已足够好；摘要与回答再用大模型。LightRAG 的四角色 LLM 配置就是把这个思想制度化。
- 延迟摘要（LazyGraphRAG 思路）：索引只抽取，社区摘要按查询触发。官方数据：索引成本降至约 0.1%（千倍量级），全局查询约便宜 700 倍，而全局问题质量在官方基准上与完整 GraphRAG 打平。适用前提：全局查询占比不高、可接受首查延迟。
- 谓词与实体受控：schema 化程度越高（KAG 路线），抽取输出越短、图越干净、摘要越省。通用语料至少做谓词归一化。
- 缓存与增量：verb 级缓存（graphrag v3.x）保证调 prompt 只重算变化部分；LightRAG 式增量避免全量重建。
- 社区粒度调粗：分辨率调小 → 社区变少 → 报告变少；代价是全局概览变粗。按问题粒度反向设计。
成本观测要点：把 token 账单按"抽取 / 报告 / 查询"三个环节归因（graphrag 的 verb 缓存键本身就是归因维度），否则优化无从下手。
8.2 增量更新与删除
生产知识库是活的：新文档进来、旧文档过期、错误要订正。各路线的增量能力对比见第 4 章，落地时的三个工程细节：
- 删除是图上的级联操作：删一篇文档要删它贡献的三元组——但一条边可能来自多篇文档（demo 中的 weight 即为此设计）。只有 weight 归零的边才能物理删除，否则全局摘要会悄悄漂移。LightRAG 2025.08 起官方支持删除文档并重建受影响 KG 子图，自建系统必须实现等价的引用计数。
- 增量后的全局一致性：新文档接入改变了社区结构，预计算报告的"局部失效"需要向上传播——哪些 Level 0 社区受影响 → 哪些 Level 1 报告要重生成。实现上建议维护"文档 → 三元组 → 社区 → 报告"的反向索引。
- 更新风暴隔离：大批量导入时，抽取（LLM 密集）与社区重算（图计算密集）要资源隔离，否则互相饿死。与分布式系统主题中的批量隔离原则是同一件事。
8.3 评估：先回答"图检索在你的任务上有没有用"
GraphRAG 的评估比向量 RAG 更难，因为它服务的是两类异质问题：
局部/多跳问题——用现成多跳基准：
| 基准 | 特点 | 适用 |
|---|---|---|
| HotpotQA | 2 跳为主、 Wikipedia | 通用多跳事实问答 |
| 2WikiMultihopQA | 2-4 跳、关系多样（比较/组合/推理） | 图结构收益最明显的场景 |
| MuSiQue | 2-4 跳、构造式无捷径 | 检验真多跳而非单跳记忆 |
指标用检索侧（recall@k、答案支撑段落命中率）与生成侧（F1/EM）分开报；HippoRAG 系列的官方对比显示，图检索的优势主要体现在 2Wiki/MuSiQue 这类真多跳集合上。
全局问题——GraphRAG 论文的三维 LLM 评审（comprehensiveness 全面性 / diversity 多样性 / empowerment 可行动性）仍是事实标准；微软后续的 BenchmarkQED 工具包提供了可复现的全局评测流程。
2025 年后的冷静期结论必须内化：GraphRAG-Bench（arXiv 2506.05690，v3 于 2026-02 更新）等系统研究的共识是——图检索的收益高度依赖任务（层次化知识检索、深度上下文推理收益大；简单事实检索常常打不过调好的向量 RAG）。上线前的判别实验：从真实查询日志抽 100-200 条，按"实体可链接性 + 跳数 + 全局性"标注分桶，只对图检索有理论优势的桶做 A/B。多数项目的正确结论是混合部署而非全面替换。
防污染纪律：多跳基准进入训练语料已久，自测分数需要按评估主题的方法论做泄漏检查。
8.4 生产案例的共性模式
公开案例（微软研究院博客、Neo4j 与云厂商的方案库、LightRAG 社区部署）中的高频模式：
- 混合部署是默认结局：图检索处理实体关系与全局概览，向量检索处理开放语义，BM25 兜底精确词。路由按 8.3 的分桶结果配置。
- 图谱是人机共建的：自动抽取打底 + 领域专家审核高中心性节点（degree 最高的前几百个实体贡献了大部分多跳路径）。在 WebUI 里提供"节点合并/拆分"操作（LightRAG Server 的运维面思路），把专家知识沉淀回图。
- 引用与可观测是上线门槛：每条答案要给出"来自哪些实体/关系/原文"；查询日志记录路由决策与各环节延迟，用于持续调优。LightRAG 2025.11 集成 RAGAS 与 Langfuse 即为此。
- 图库运维并入现有体系：备份、权限、审计沿用 DBA 体系；大规模图单独评估分片（NebulaGraph 路线）或托管（Neptune 路线）。
8.5 落地检查清单
- [ ] 查询日志分桶：多跳/全局/事实/开放语义各占多少？图检索的理论优势桶占比是否值得投入？
- [ ] 索引成本测算：按"单元数 × 抽取轮数"估抽取 token，按"社区数 × 报告预算"估摘要 token，两环节分开报价。
- [ ] 抽取质量审计：人工抽 100 个文本单元核对抽取结果，算召回率——低于预期先调 prompt/gleaning，不要急着调检索。
- [ ] 实体解析灰区队列：相似度灰区的候选对有人工消费机制。
- [ ] 删除路径演练：删一篇文档，验证图、社区、报告三级的一致性。
- [ ] 评估看板：检索 recall 与生成质量分环节看板，多跳桶单独追踪。
- [ ] 降级预案：图存储故障时检索服务自动退化为纯向量模式（图索引应是增强，不是单点）。
小结
- 成本的主战场在抽取与摘要：小模型抽取、Lazy 式延迟摘要、verb 级缓存是三件最便宜的武器。
- 增量更新的坑集中在删除级联与全局摘要的局部失效传播，反向索引（文档→三元组→社区→报告）是必备数据结构。
- 评估先分桶后 A/B：图检索的收益高度任务相关，"全面替换向量检索"在 2026 年已无依据，混合部署才是默认答案。