10-知识库动态更新：增量索引、版本切换、权限和回滚

上一篇讲 RAG 评测体系时，重点是如何证明系统变好了。评测解决的是“当前效果是否可靠”，这一篇继续往生产系统推进：知识库本身会不断变化。

很多 RAG demo 会把文档导入一次，切 chunk、算 embedding、写入向量库，然后开始问答。这个流程适合验证概念，却没有覆盖生产环境最难的一部分。真实知识库一直处在变化中：文档会新增、修改、删除，权限会变化，产品版本会迭代，embedding 模型可能升级，chunk 策略可能调整，索引可能构建失败，错误版本可能需要回滚。

只要知识库进入生产，RAG 就从一次性构建变成持续运行的知识系统。它需要像搜索引擎、数据仓库和线上服务一样管理版本、增量、权限、灰度、审计和成本。

这一篇的核心判断可以先放在前面：

生产级 RAG 的知识库不能只关注**“能不能检索”，还要关注“知识变化后能不能正确更新、权限变化后能不能立即生效、索引失败后能不能恢复、策略升级后能不能灰度和回滚”**。

知识库是持续变化的系统

RAG 使用外部知识来增强生成能力，这意味着外部知识的状态会直接影响答案质量。文档过期，答案就可能过期；权限错误，答案就可能泄露；索引残留，答案就可能引用已删除内容；版本混乱，答案就可能把旧规则和新规则合并。

知识库变化通常有几类。第一类是内容变化，文档新增、修改、删除、标题调整、章节迁移、附件替换。第二类是结构变化，文档格式、表格、代码块、图片 OCR、父子章节关系发生变化。第三类是业务变化，产品版本、适用范围、发布时间、失效时间、权限范围更新。第四类是策略变化，chunk 参数、embedding 模型、索引结构、metadata 字段、Rerank 策略发生调整。

变化类型	典型例子	主要风险
内容变化	新增、修改、删除、附件替换	新知识不生效、旧知识残留
结构变化	表格、代码块、OCR、标题层级变化	chunk 边界失效、证据结构丢失
业务变化	产品版本、适用范围、权限、失效时间	过期答案、权限越界
策略变化	chunk 参数、embedding 模型、索引结构	新旧索引混用、评测不可比

这些变化都会影响在线回答。新增文档如果没有及时入库，系统会继续拒答或回答旧知识。修改后的文档如果没有删除旧 chunk，系统可能同时召回新旧内容。删除文档如果只在业务系统里删除，没有从索引里清理，RAG 仍然可能引用它。权限从公开改成内部可见，如果检索索引没有同步，模型可能看到用户无权访问的内容。

因此，动态更新属于 RAG 生产化的基础能力。知识库的每一次变化，都应该能被检测、解析、重建、发布、回滚和审计。

文档更新要先识别变化范围

动态更新的第一步，是知道什么变了。

最简单的方式是全量重建。每次文档变化后，把所有文档重新解析、切分、embedding、写入索引。这个方式逻辑清楚，但成本很高。文档规模变大以后，全量重建会带来大量计算开销，也会拉长知识更新延迟。

更常见的生产做法是增量更新。系统通过文档 ID、更新时间、内容 hash、版本号或事件消息判断变化范围。没有变化的文档不重复处理，发生变化的文档重新解析和索引，被删除的文档清理对应 chunk 和向量。

内容 hash 很有用。单纯依赖更新时间并不可靠，有些系统会因为同步或权限变更更新 updated_at，但正文没有变化。内容 hash 可以帮助系统判断是否真的需要重新 embedding。对于大文档，还可以进一步做段落级或章节级 hash，只重建变化部分。

变化识别还要考虑附件和结构。PDF 里的表格更新、图片 OCR 结果变化、Markdown 标题层级调整、网页正文抽取规则变化，都可能影响 chunk。系统不能只看文件名和时间戳，而要把解析后的规范化内容作为判断依据。

识别变化范围越准确，更新成本越低，知识生效越快，线上风险也越容易控制。

变化识别方式	适合用途	注意点
更新时间	快速发现候选变化	可能被同步或权限变化误触发
内容 hash	判断正文是否真的变化	需要基于规范化内容计算
段落 / 章节 hash	只重建变化部分	实现复杂度更高
事件消息	快速触发增量任务	依赖上游事件可靠性

增量索引要处理新增、修改和删除

增量更新不只是把新文档写进去。它要同时处理新增、修改和删除三种状态。

新增文档相对简单。系统解析文档，生成 chunk，写入 metadata，计算 embedding，再把向量和文本写入索引。关键是要保证文档来源、版本、权限、发布时间、失效时间和质量状态一起入库。否则新增内容虽然能被检索到，却缺少业务边界。

修改文档更复杂。文档一旦变化，旧 chunk 是否还能复用，要看 chunk 边界是否稳定。如果只是一个段落内部改了几个词，可以更新对应 chunk。若标题层级、段落顺序或表格结构发生变化，旧 chunk 边界可能已经失效，需要重建整篇文档的 chunk。

删除文档最容易被忽略。业务系统里删除了文档，索引里必须删除对应 chunk、向量和缓存。否则用户仍然可能从 RAG 答案里看到已删除内容。对于软删除文档，metadata 里应该有状态字段，检索时默认过滤失效内容；对于硬删除，还要清理向量库、全文索引、对象存储和缓存里的残留。

增量索引还要处理失败重试。某篇文档解析失败、embedding 调用超时、向量库写入失败，都不能让系统处在半更新状态。生产系统需要记录每个文档的处理状态、失败原因、重试次数和当前索引版本。失败样本要进入监控和告警，不能静默跳过。

更新状态	需要做什么
新增	解析、chunk、补 metadata、embedding、写入索引
修改	判断 chunk 是否可复用，必要时重建整篇文档
删除	清理 chunk、向量、全文索引、缓存和引用入口
失败	记录状态、失败原因、重试次数和索引版本

chunk 策略变化可能触发重建

chunk 策略看起来是离线处理细节，实际会影响整个索引版本。

如果只是调整在线 topK 或 Rerank 参数，通常不需要重建索引。但如果改了 chunk size、overlap、标题合并方式、表格处理方式、父子 chunk 结构，原来的索引就不再代表新的切分策略。旧 chunk 和新 chunk 混在一起，会导致召回结果不可解释，也会让评测对比失去意义。

比如，旧策略按固定 500 字切分，新策略按标题层级切分。两套策略产生的 chunk ID、文本边界、metadata 和 embedding 都不同。此时继续在同一个索引里增量写入新 chunk，会让同一篇文档出现两种切分版本。在线检索可能同时召回旧片段和新片段，答案会变得不稳定。

所以，chunk 策略应该有版本号。chunk_version 需要进入 metadata，也需要和索引版本绑定。当策略发生结构性变化时，更稳的方式是构建新索引，跑离线评测，通过后再灰度切换。

这也说明，chunk 策略需要持续管理。随着业务文档类型增加，系统可能需要对 FAQ、长 PDF、表格、代码、制度文档采用不同切分策略。策略越多，版本管理越重要。

embedding 模型升级要重视向量空间

embedding 模型升级是 RAG 系统里很敏感的变化。不同 embedding 模型生成的向量通常位于不同语义空间，新旧向量直接混用会让相似度计算失去一致性。

即使两个模型维度相同，向量分布也未必兼容。一个模型更擅长中文业务文档，另一个模型更擅长英文技术语料；一个模型对短 query 表现好，另一个模型对长段落更稳。把它们生成的向量放在同一个索引里，用同一种相似度计算排序，结果可能非常混乱。

因此，embedding_model_version 应该成为索引的重要元数据。模型升级时，更稳的流程是用新模型构建一套新索引，对同一批 Golden Set 做检索评测，比较 Hit@K、MRR、Recall@K、延迟和成本。确认收益后再灰度切换，直接覆盖旧向量风险很高。

策略变化	是否通常需要新索引	原因
调整 topK / Rerank 参数	不一定	在线策略变化，索引数据不变
改 chunk size / overlap / 父子结构	通常需要	chunk 边界、ID、metadata 和 embedding 都会变化
升级 embedding 模型	通常需要	新旧向量空间不能直接混用
调整 metadata 字段规则	视情况而定	影响过滤和权限时需要重建或补全

模型升级还会影响存储和性能。向量维度可能变高，索引大小会变大；推理速度可能变慢，入库成本会上升；新模型支持的最大输入长度不同，也会反过来影响 chunk 策略。embedding 和切分、索引、评测、成本都绑定在一起，不能孤立看待。

如果必须长期保留多套 embedding 模型，就要明确在线查询走哪套索引。query 向量必须和 document 向量来自同一模型版本。新旧模型并行时，日志里也要记录本次请求使用的 embedding 版本，便于排查和回滚。

索引版本让发布和回滚可控

动态更新最终要落到索引发布。没有索引版本，RAG 很难做到可控上线。

一个索引版本可以理解为某一时刻知识库、chunk 策略、embedding 模型、metadata 规则和索引参数的组合。它不只是向量库里的一批数据，还代表一套可复现的知识状态。

索引版本包含什么	为什么重要
知识库快照	说明当时有哪些文档和内容
chunk 策略版本	解释证据边界如何产生
embedding 模型版本	保证 query 和 document 向量空间一致
metadata 规则	影响权限、版本、时间和业务过滤
索引参数	影响召回、延迟和成本

生产系统里，索引构建和在线服务最好解耦。后台构建新索引，完成解析、切分、embedding、写入、校验和离线评测。评测通过后，再把在线查询流量切到新索引。这样可以避免用户请求命中正在构建中的半成品。

索引切换可以采用蓝绿发布或灰度发布。蓝绿发布准备两套索引，当前线上用 blue，新版本构建在 green，验证通过后切流。灰度发布则让一小部分用户或一小部分问题先走新索引，观察质量、延迟、错误率和用户反馈，再逐步扩大。

回滚同样重要。新索引上线后，如果发现召回质量下降、权限过滤异常、延迟升高或答案引用错误，系统应该能快速切回旧索引。回滚依赖旧版本保留、配置可切换、日志可识别。没有版本管理，回滚就会变成临时抢修。

索引版本还方便审计。某个用户在某个时间看到的答案，应该能追溯到当时使用的知识库版本、索引版本、模型版本和 Prompt 版本。这样才能解释答案为什么出现，也方便定位历史问题。

权限过滤要在检索阶段生效

RAG 的权限治理不能只靠前端隐藏文档。只要无权内容进入模型上下文，就已经存在泄露风险。即使答案没有展示原文，模型也可能把其中的信息加工成自然语言输出。

所以权限过滤必须在检索阶段生效。用户发起请求时，系统要把用户身份、租户、角色、组织、空间、文档权限、数据域和时间范围转成检索约束。向量检索、关键词检索、结构化检索都要遵守同一套权限规则。

权限过滤有两种常见位置。一种是在检索前过滤候选范围，只在用户可见文档集合中检索。另一种是在检索后过滤结果，把无权 chunk 剔除。前者安全性和效率通常更好，但对索引和权限表达能力要求更高。后者实现简单一些，但如果底层检索已经访问了无权数据，仍然要谨慎处理日志和中间结果。

多租户场景下，tenant_id 应该成为强过滤条件。企业内部知识库里，部门、项目、空间、密级也应该进入 metadata。权限变化时，索引侧需要及时同步。一个用户被移出项目后，旧权限缓存不能继续让他检索到项目文档。

权限还会影响引用。答案里给出的 source_id 和链接，必须指向用户有权访问的来源。不能出现模型回答看似合规，但引用链接打开后无权限，或者引用标题泄露敏感文档名的情况。

权限控制点	要避免的问题
检索前过滤	无权文档进入候选范围
检索后过滤	中间结果、日志或缓存残留无权内容
多租户强过滤	不同租户的数据互相召回
引用权限校验	答案引用到用户打不开或不该看到的来源

删除和权限变更要考虑残留

动态更新里更危险的是删除和权限收紧。

新增文档延迟入库，通常只是回答不够新。删除文档没有清理干净，可能继续暴露失效或敏感内容。权限从公开变成受限，如果索引和缓存没有同步，用户可能继续看到旧内容。

残留可能出现在多个地方。向量库里有旧向量，全文索引里有旧文本，缓存里有旧检索结果，Rerank 缓存里有旧候选，答案缓存里有旧回答，日志里有敏感上下文。动态更新不能只更新主索引，还要考虑这些衍生存储。

删除策略要有明确语义。软删除适合需要审计和恢复的场景，但检索必须默认排除。硬删除适合隐私和合规要求更高的内容，相关向量、文本和缓存都要清理。对于带有保留期要求的数据，还要配合数据生命周期策略。

权限收紧也要触发缓存失效。一个答案缓存如果只按问题文本缓存，没有把用户身份和权限版本纳入 key，就可能把其他用户有权看到的答案返回给无权用户。RAG 的缓存设计必须把权限边界当成核心维度。

这些问题在 demo 阶段很少出现，在生产阶段却是高风险点。RAG 只要连接企业内部知识库，就必须把删除、权限和缓存残留一起设计。

残留位置	可能风险
向量库 / 全文索引	已删除或收紧权限的内容仍被召回
检索缓存 / Rerank 缓存	旧候选继续进入上下文
答案缓存	无权用户拿到其他权限下生成的答案
日志和 trace	敏感上下文被长期保留

GraphRAG 的更新和权限更复杂

普通 RAG 主要处理文档和 chunk。GraphRAG 还会处理实体、关系边、社区摘要、路径检索和图结构推理。知识更新和权限治理在这里会更复杂。

文档更新后，不只是 chunk 要重建，实体抽取结果、实体属性、关系边、社区划分和摘要也可能变化。删除一篇文档后，它贡献的实体关系是否还有效，需要根据其他来源判断。某条关系如果只来自被删除文档，就应该被删除或降权。社区摘要如果包含了被删除或过期信息，也需要重新生成。

权限问题也更敏感。即使某个用户无权访问原文，他可能通过关系边、邻居节点或社区摘要间接推断出敏感信息。比如某个项目成员关系、客户名称、未公开产品计划，如果被抽成图结构后进入全局摘要，就可能越过原始文档权限。

因此，GraphRAG 的权限不能只控制文档读取。实体、关系边、社区摘要、路径检索结果都需要携带来源和权限范围。检索和推理时要保证用户只看到由其有权来源支撑的图信息。全局摘要也要分权限域构建，避免把不同权限范围的信息混在一个摘要里。

GraphRAG 的更新成本通常更高，也更需要版本管理。图谱构建、社区检测、摘要生成和向量索引之间要保持一致，否则系统可能用新文档 chunk 搭配旧关系边，产生难以排查的答案。

GraphRAG 对象	更新和权限关注点
实体	来源文档删除后，实体属性是否仍可信
关系边	关系是否只由已删除或无权来源支撑
社区摘要	是否包含过期、删除或跨权限信息
路径检索结果	推理路径是否全部来自用户有权证据

构建流程要可观测

动态更新系统需要完整的可观测性。否则索引是否真的更新、哪些文档失败、失败影响多少问题，都很难判断。

构建流程至少要记录文档数量、变化数量、解析成功率、chunk 数量、embedding 调用量、向量写入量、删除数量、失败数量、重试次数、构建耗时和索引大小。每篇文档最好有处理状态：待处理、解析中、embedding 中、写入中、成功、失败、已删除。

质量监控也很重要。一次更新后 chunk 数量突然下降，可能是解析规则坏了。某类文档 embedding 失败率升高，可能是输入长度超限。索引大小异常增长，可能是删除旧 chunk 失败。检索延迟突然变高，可能是索引参数或数据规模变化。

上线前还应该跑一批自动校验。比如抽样检查文档是否能按 source_id 回到原文，metadata 是否完整，权限字段是否存在，旧版本是否被过滤，Golden Set 上的关键指标是否退化。通过这些检查后，再把索引发布到线上。

动态更新的可观测性也要服务于业务。知识管理员需要知道哪些文档入库失败，研发需要知道哪个阶段失败，产品需要知道新知识多久生效，安全团队需要知道权限变更是否同步。不同角色看到的仪表盘可以不同，但底层 trace 要一致。

监控项	能暴露什么问题
解析成功率、chunk 数量	解析规则异常、结构丢失
embedding 调用量、失败率	输入超限、模型服务异常、成本异常
写入量、删除量、索引大小	旧 chunk 未清理、索引异常膨胀
Golden Set 回归指标	新索引质量退化
权限字段完整率	权限过滤可能失效

更新频率要结合业务取舍

并非所有知识都需要实时更新。更新频率应该结合业务风险、文档类型和成本来设计。

客服知识、故障公告、线上配置、权限变更、合规政策这类内容时效性高，需要更快同步。产品手册、历史方案、内部培训材料可以接受分钟级或小时级延迟。归档文档甚至可以走低频批处理。

更新越实时，系统复杂度越高。实时解析、实时 embedding、实时索引写入、实时权限同步都会增加资源压力。批处理更容易控制成本，也更容易做完整校验，但知识生效会有延迟。

更稳的做法，是分层更新。高优先级文档走事件驱动的快速链路，普通文档走定时增量任务，低优先级文档走批量重建。索引发布也可以分层，紧急修复先小范围生效，再进入完整索引版本。

更新频率还要和评测结合。越频繁的更新，越需要自动化校验和快速回滚。否则知识更新速度提高了，线上答案风险也会提高。

文档类型	更新策略倾向
故障公告、权限变更、合规政策	事件驱动，快速同步
产品手册、客服知识、配置说明	定时增量，配合自动校验
培训材料、历史方案、归档文档	低频批处理或定期重建

成本治理也是动态更新的一部分

知识库动态更新会带来持续成本。解析、OCR、embedding、向量存储、全文索引、Rerank、评测、备份和多版本保留都会消耗资源。

内容 hash、增量更新和去重可以减少重复 embedding。文档分层可以让低价值内容使用低频更新策略。索引版本保留也要有生命周期，不能无限保存所有历史版本。向量维度、索引类型、压缩策略和冷热数据分层都会影响成本。

成本治理不能简单压缩质量。比如降低 embedding 模型成本可能损害召回，减少 Rerank 候选可能损害排序，缩短索引保留可能影响回滚。更合理的方式，是把成本指标纳入评测报告，和质量、延迟一起看。

动态更新阶段还要关注失败成本。一次全量重建失败，如果没有旧索引可用，会影响线上服务。一次错误权限同步，如果没有审计和回滚，会带来安全风险。生产 RAG 的成本不只包括计算账单，也包括故障恢复和风险控制成本。

成本项	常见治理方式
重复 embedding	内容 hash、增量更新、去重
向量存储	生命周期管理、冷热分层、压缩策略
多版本索引	保留可回滚版本，清理过期版本
评测和后校验	按风险分层触发，避免全量高成本调用

动态更新方案怎么组织

设计 RAG 知识库更新方案时，可以先把它从一次性导入提升到生产链路。

可以说，知识库更新要覆盖新增、修改、删除和权限变化。系统会用文档 ID、内容 hash、更新时间和事件消息识别变化，对变化文档做增量解析、chunk、embedding 和索引写入；对删除文档清理向量、全文索引和缓存；对失败任务做重试、告警和状态记录。

接着说明版本意识。chunk 策略、embedding 模型、索引参数和 metadata 规则都要有版本。embedding 模型升级通常需要新建索引，因为新旧向量空间不能混用。chunk 策略变化也可能触发全量重建。新索引要经过 Golden Set 评测，再通过灰度或蓝绿发布切换，发现问题可以回滚到旧索引。

然后强调权限。权限过滤必须在检索阶段生效，用户身份、租户、角色、文档权限和数据域都要成为检索约束。删除和权限收紧要同步清理索引和缓存，避免旧内容残留。GraphRAG 还要控制实体、关系边、社区摘要和路径检索的权限，防止间接泄露。

最后补充可观测性和成本。构建流程要记录解析成功率、chunk 数、embedding 量、写入失败、删除数量、索引版本和评测结果。动态更新要在质量、延迟、成本和安全之间做取舍。

这种组织方式能体现 RAG 的生产意识：知识库导入只是开始，真正难的是持续变化时仍然保持答案正确、安全、可回滚。

小结

知识库动态更新把 RAG 从 demo 推向生产系统。文档会新增、修改、删除，权限会变化，chunk 和 embedding 策略会升级，索引需要发布、灰度、回滚和审计。

增量索引解决变化成本，内容 hash 帮助识别真实变更，删除清理避免旧知识残留，chunk_version 和 embedding_model_version 保证索引可解释，索引版本让发布和回滚可控，权限过滤让模型看不到无权证据，可观测性让构建失败和质量退化能被及时发现。

理解动态更新以后，RAG 的工程边界会更清楚。前面几篇关注的是如何把一次请求答好，这一篇关注的是知识不断变化时，系统如何长期答对、答新、答得安全。下一篇进入 GraphRAG、Self-RAG、CRAG 和 Agentic RAG，把普通 RAG 的短板和高级范式的补位关系收束起来。