10.1
将构建查询和维护成本分别计算
图增强系统的成本不能只看一次回答消耗多少模型调用。构建阶段包含解析、抽取、实体消歧、图处理和摘要；查询阶段包含路由、检索、重排、生成与核验；维护阶段还包含更新、纠错、权限变更和人工审核。本报告建议以固定观察周期记录三部分，并明确哪些是一次性支出、哪些随文档增加、哪些随请求增加。只有这样才能判断某种较昂贵索引是否会在大量查询中获得合理摊销。
一个简单的成本模型可以写成周期总成本等于构建成本、更新成本、查询次数乘平均查询成本以及运维成本之和。模型中的每个量都要有单位和测量边界：模型用量、计算时间、存储和人工工时不能未经换算直接相加。若使用货币估算，应记录价格日期与计价来源；本报告不引用易变的外部模型报价，而在演示中使用明确标注的假设成本单位。平均每次查询成本还会随问题类型变化，主题概括可能需要更多报告，精确查询可能只需一个片段。因此成本分析应与任务分布相连，避免用一种复杂查询代表全部请求。
10.2
延迟预算沿查询路径分配
用户感受到的是端到端等待时间，而不是某个检索模块的单独耗时。查询路径中，权限检查、网络传输、图扩展、图片读取和生成都可能成为瓶颈。建议先测量各阶段分布，再决定优化位置。若大部分时间用于生成，优化毫秒级图查询未必改变体验；若少量大图查询导致长尾，平均延迟也会掩盖问题。报告中应同时记录中位数和较高分位，并按任务类型区分。超时后返回部分结果还是明确失败，也应作为服务设计的一部分。
预算可以在执行前分配，也可以随证据发现动态调整。例如，精确编号已经找到一份当前有效记录，就不一定继续扩展整个关系网络；关系问题缺少一个关键连接时，则可把更多预算分配给定向查找。终止规则应依据证据充分性，而不只是固定步数。为防止图扩展无限增长，可以设置候选上限、关系类型白名单和时间范围。预算不足时，系统应说明当前证据覆盖到哪里，而不是把未搜索区域当成不存在。性能优化因此涉及回答范围与可靠性的共同选择，不能只追求更快输出文字。
10.3
缓存必须绑定知识和权限版本
缓存可以减少重复处理，但也可能重复传播过期或越权信息。查询字符串相同并不意味着可复用同一答案，因为用户权限、知识版本和时间条件可能不同。建议缓存键包含规范化问题、资源范围、知识版本、模型配置和权限范围标识。缓存内容还应保存其依赖的证据集合，以便源数据改变时失效。对于全局社区摘要，尤其需要检查它是否混合了不同访问级别的信息；仅在最终回答阶段过滤原文，无法消除摘要中已泄露的内容。
缓存可以分层设置：解析结果按资源内容复用，嵌入按模型与内容版本复用，检索候选按范围复用，最终答案则采用更严格条件。不同层的失效规则不应混成一个统一有效期。资源内容不变但权限收紧时，解析缓存可能继续有效，答案缓存却必须重新检查；模型升级时，旧嵌入可能需要重算，原始资源不必复制。测试应覆盖这些交叉变化。缓存命中率高并不自动意味着系统更好，如果命中的是过时或不完整回答，反而会稳定地产生错误。因此应同时观察缓存正确性、节约成本和失效延迟，而不是只把命中率作为成功指标。
10.4
压缩和剪枝需要保留关键例外
为了减少上下文和存储，可以压缩片段、合并重复观察、剪去低价值边或选择较粗社区层级。风险在于重要性不能只由频率或长度决定。一句很短的例外条件可能改变整段规则，一条低频关系可能是某次事故的唯一证据。压缩前应识别否定、数量、单位、时间和例外，并检查压缩后是否仍能恢复这些约束。对于无法安全概括的内容，可以保留原文并降低其他背景信息的优先级。压缩质量应通过任务结果与证据保留共同评估。
图剪枝也应考虑证据角色。外围节点虽然不参与最短路径，却可能提供反例或解释身份差异；删除它们可能让图看起来更清晰，却让回答变得单向。可区分用于导航的精简图与用于核验的证据图，前者帮助快速定位，后者在需要时补充完整出处。两者通过标识关联，不必把所有信息都放进模型上下文。对大量重复来源，应合并展示但保留来源计数与独立性判断，避免把转载次数当作多个独立证据。有效压缩减少冗余，保留能改变结论的差异，这比单纯追求更少节点或更短提示词更接近实际目标。
10.5
观测质量漂移与运营反馈
上线后，数据和用户问题都会变化。新术语、新拍摄设备或新文档格式可能使抽取和检索质量下降，而模型服务本身仍返回成功。应建立定期抽样与固定哨兵问题，监测实体未链接率、无证据回答、引用失效和模态缺失等信号。指标变化需要结合输入分布解释，不能把所有下降归咎于模型。若用户开始提出更复杂的问题，平均成功率变化可能反映任务变了。监控应能区分数据漂移、任务漂移和系统故障。
反馈入口要允许用户指出具体陈述或证据的问题，而不只是给整个回答点赞。纠错记录应回到知识维护队列，标记是源数据错误、抽取错误、身份合并错误、检索遗漏还是生成越界。高频错误可以形成回归用例，但需要避免把全部用户反馈直接当作正确标签。对于争议性反馈，应保留原始意见与审核结果。运营团队还应观察纠错处理时间和同类错误复发率，因为一个能发现问题却长期不修复的系统仍然不可靠。持续改进的闭环，是从用户看到的错误回到可修改组件，再通过独立检查确认修复生效。
本报告原创设计
10.6
采用门槛应与价值和维护能力匹配
采用GraphRAG不必从全量资料和全部功能开始。可以选择一个边界清楚、问题重复出现、证据可获得的场景，先验证图结构是否减少关键错误或提高查找效率。成功标准应在实验前写明，例如关系问题的必要证据覆盖、审核时间和错误严重性。若只在演示中挑选系统擅长的问题，就无法判断真实价值。试点还需要包含数据更新和纠错过程，因为静态演示最容易遗漏维护负担。能够持续修复一张小图，比一次性生成一张巨大但不可管理的图更接近可用服务。
决策可以分阶段进行：证明数据可组织，证明检索有增量，证明用户任务受益，最后证明持续运营可承担。每一阶段都允许停止或简化。如果向量混合检索已经满足目标，图可以只保留用于解释或特定关系查询；如果视觉信息只对少量问题必要，则可按需调用。团队能力也属于成本的一部分，包括本体维护、数据审核和故障处理。报告建议把退出机制写进试点方案：如何导出证据、替换模型和回到前一流程。可替换性减少长期依赖，使技术选择能够随新证据调整，而不是被早期架构承诺锁定。