最佳实践：什么时候上图，怎么上图

本章是把前八章压缩成可执行判断的速查：何时值得引入图检索，以及引入后每一步的推荐做法。

9.1 什么时候上图：决策清单

按优先级回答四个问题：

1. 查询日志里有没有多跳问题？ 典型形态："A 的 B 技术被谁借鉴了"、"X 团队的工作与 Y 故障有什么关系"。若没有，图检索的理论优势用不上。
2. 有没有语料级概览需求？ 管理层摘要、领域地图、全库趋势分析——这类问题向量 RAG 结构性无法回答，是 GraphRAG 的独占价值。
3. 实体是否值得链接？ 语料有稳定的核心实体集（产品、机构、人物、概念）才值得建图；实体极度发散的长尾文本（如闲聊日志），图的收益有限。
4. 更新频率与团队资源是否匹配？ 日更以上选 LightRAG 路线；周更级批处理可选 GraphRAG；没有图数据库运维经验的团队优先"PG + 向量扩展"或托管方案起步。

四条里命中两条以上，值得做判别实验；只命中第 4 条或一条都没有，先把向量 RAG 调优（chunking、rerank、混合检索）。

9.2 抽取质量的十个抓手

按投入产出比排序：

1. 先审计再调优：抽 100 个文本单元人工核对，区分"漏抽"（补 gleaning）与"抽错"（改 prompt 示例）两类错误分别处理。
2. gleaning 至少 1 轮：官方经验中性价比最高的单点改进。
3. 谓词归一化表：上线前把同义谓词（"开发/创建/构建/提出"）映射到规范集，边数立刻收敛。
4. 实体类型枚举收紧：开放式类型（几十种 type）会让社区碎片化；控制在 5-10 类。
5. 给抽取模型"领域样例"：prompt 里放 2-3 个 gold 抽取样例，比换更大的模型有效。
6. 高价值语料人工预标注：对核心文档（如产品手册）人工抽 50 条边，作为抽取器的 few-shot 与回归测试集。
7. 描述字段控制长度：实体/关系的 description 是下游摘要的输入，单条控制在 1-2 句。
8. 跨语言统一处理：中英混排语料指定抽取输出语言（通常统一为中文或英文），避免同一实体双语节点。
9. 记录抽取置信度：让 LLM 自评置信度入边属性，低置信边在检索排序中降权。
10. 定期抽样回归：语料或模型变化时重跑审计集，防抽取质量漂移。

9.3 查询路由与混合检索

• 路由信号：问题中实体链接成功数、问题是否含概览词（"整体/所有/趋势/对比"）、预期跳数（可由问题抽取的三元组链长估计）。
• 默认混合：即使问题走了图检索，也用向量结果做 RRF 补充——图检索漏抽的边，向量检索常能兜住。
• 多跳深度设限：PPR 的 α 与路径深度按语料直径调，2-3 跳是收益甜点；更深的跳数噪声大于信号。
• 全局查询进缓存：社区摘要的查询结果按（问题嵌入 + 报告版本）缓存，全局问题天然重复度高。

9.4 成本控制红线

• 抽取模型单价设上限（小模型优先），只有审计发现漏抽不可接受才升级。
• 单篇文档的抽取预算设硬上限（token 数），超限文档进人工队列——通常是解析坏的 PDF。
• 社区报告总量设预算：报告数 × 平均报告 token 不应超过抽取环节 token 的 1/3，否则先调社区粒度。
• 查询侧的 global 模式加配额与降级：配额内走完整 map-reduce，超配额降级到 Lazy 按需摘要。

9.5 常见反模式

反模式	后果	替代做法
用 GraphRAG 替换向量库	开放语义问题全面回退，成本翻倍	图 + 向量 + BM25 混合
不做实体解析直接上社区检测	图碎裂，社区报告读不成句	先跑名称归并 + 相似度合并
社区粒度默认不调	全局报告要么太碎要么太粗	用 20-50 个全局问题反向调分辨率
全局查询不问层级	查询 token 爆炸	先 Level 1 再按需下钻
索引跑完不审计中间表	问题暴露在使用阶段才发现	把 Parquet 中间表检查做成发布门禁
删除文档只删向量	图与摘要悄悄失真	级联删除 + 引用计数（见第 8 章）
一套 prompt 打所有语料	领域术语抽取全军覆没	按语料域做 prompt 变体 + 自动调优

小结

• 上图的门槛是"查询日志里真的有多跳或全局问题"，四条决策清单命中两条以上再做投入。
• 抽取质量是系统上限：审计先行、gleaning 兜底、谓词归一、置信度入图。
• 生产默认是混合：图管连接与概览，向量管语义，RRF 管合并，路由管调度。