增量更新与知识时效：让索引跟上文档
本文基于模型知识整理（生成时未联网核对），关键结论建议对照经典文献复核。
一句话定义
文档会被新增、修改、删除，索引必须按文档粒度增量同步：以稳定文档 ID + 内容哈希检测变更，只重嵌入受影响块，删除时按 provenance 反向清理（向量块与图三元组都要清），否则系统会"一本正经地引用已废止的政策"。
为什么重要
知识时效是 RAG 生产事故的高发区：旧版手册没下架、离职员工权限文档残留、政策更新后新旧版本同时命中。这些问题在 demo 期不存在（全量重建很方便），上线后爆发——增量更新机制必须在首版索引设计时就定好（kp-006 的元数据契约）。
前置知识
kp-006（稳定 ID 与元数据）、kp-023（图的 provenance）。
核心概念
- 变更检测：文档级哈希（内容变了才处理）+ 块级哈希（哪几块变了只重嵌入哪几块）。
- 增量索引：新块 upsert、变更块替换（同 ID 覆盖）、消失块删除；向量库与图库双写一致性。
- 反向清理（provenance-based deletion）：删除文档时，按出处记录找到它贡献的所有块与图三元组并移除——图的清理比向量难（实体可能被多文档共享，删除策略要定义"无引用才删节点"）。
- 版本与生效期：政策类文档带 effective/expired 元数据（kp-006），检索默认过滤已失效版本而非物理删除（留档审计）。
- 新鲜度 SLA：文档变更到可检索的时间预算（如 10 分钟），由队列与 worker 容量保障。
原理与机制
双库一致性是难点：向量库与图库是两个存储，文档更新后两边都要同步。常见策略：以"变更事件"驱动两路消费者（各自幂等处理），并配对账任务（定期比对两侧的文档 ID 集合与哈希）兜底漏处理。分布式事务不现实，最终一致 + 对账是工程正解。
图增量比向量增量难：向量块天然按文档隔离，删文档即删块；图中同一实体（"华为"节点）与关系被多份文档共同支撑——删除文档只能删"该文档贡献的三元组"，实体节点要等引用计数归零才删；实体对齐信息（别名映射）也要回滚评估。这是 GraphRAG 类系统的真实维护成本，选型时要计入（kp-026 四问之二）。
新旧版本共存的检索策略：默认查询"只看现行版"（effective ≤ now < expired 过滤）；用户显式问历史时放开过滤并标注版本。比物理删除更稳（审计可回溯），代价是索引更大。
图示
文档变更事件 ─► 哈希比对
├─ 新增 ─► 解析→分块→嵌入→upsert + 图抽取(挂 provenance)
├─ 修改 ─► 受影响块替换; 图: 旧三元组按出处删→新抽取入图
└─ 删除 ─► 向量块删除; 图: 三元组反向清理, 实体引用归零才删节点
旁路: 每日对账(两侧文档集与哈希比对) + 新鲜度SLA监控实例或案例
- HR 政策更新事故：新旧"年假天数"两块同时命中，模型随机取其一——修复：版本元数据 + 默认过滤失效版。
- 图谱删除坑：删除供应商文档后其"供应"边仍在，多跳查询继续引用幽灵供应商——根因是没有 provenance 反向清理。
常见误区
- 误区一："定期全量重建就安全"。数据量大后重建窗口以天计，期间新鲜度崩塌且成本高；增量为主、全量为兜底。
- 误区二："图增量等于向量增量的翻版"。实体被多文档共享，删除与更新要按"贡献"粒度处理；没有 provenance 的图无法安全增量。
- 误区三："新鲜度不用监控"。队列堆积、worker 挂掉都会让更新静默滞后；新鲜度 SLA 要作为一等监控指标（kp-031 思想）。
与其他知识点的关系
自测题
- 变更检测为什么要两级哈希？
答：文档级哈希免处理未变文档，块级哈希把重嵌入范围缩到真正变化的块——省算力且缩短新鲜度延迟。
- 图中删除一份文档的完整动作？
答：按 provenance 删除该文档贡献的所有三元组；实体/别名等待引用计数归零再删；对齐映射评估回滚——比向量块删除复杂得多。
- 为什么政策类文档倾向"过滤失效版"而非物理删除？
答：保留审计与历史查询能力（用户可能显式问旧规），物理删除不可回溯；默认过滤保证现行版优先。
延伸阅读
- 各向量库 upsert/delete 语义文档（Qdrant/Milvus/Pinecone）。
- Microsoft GraphRAG 文档中的增量索引章节。
- 数据工程经典：incremental processing 与 Lambda/Kappa 架构的取舍讨论。