一、项目背景

这家客户的 RAG 知识库上线半年，前期问答准确率还不错，我们当时挺满意。问题是从第七个月开始，用户陆续反馈"答出来的政策和现在不一样"。查下来发现，源文档这半年改了十几版，RAG 还检索着最早的片段，客服拿着旧条款给用户，用户真去兑现被拒，投诉直接甩到老板群里。我们才意识到，RAG 这东西大家都在讲"怎么把文档灌进去"，没人认真讲"灌进去之后源文档变了怎么办"，而真实企业里文档是活的，版本管理不做，知识库就是个慢性中毒的库。

二、落地场景

我们落地的主线是给每个源文档和每个切片都挂版本指纹，源文档一变就增量更新，失效片段主动回收。第一块是文档版本指纹，源文档入库时算内容哈希，任何修改都会产生新指纹，系统据此判断是新增、更新还是删除。第二块是增量切片同步，只对指纹变化的文档重新切片和向量化，不变化的跳过，同步成本从全量降到增量。第三块是失效片段回收，旧版对应的向量和文本片段标记为失效，检索时不再召回，避免新旧混出。第四块是变更影响面评估，上线前估算这次变更会影响多少问答场景，高风险变更走人工复核。第五块是回溯审计，保留历史版本，出问题能查到某天某片段来自哪个版本。

三、关键技术挑战与解决思路

版本指纹最怕碰撞和误判。我们一开始用整文档哈希，结果客户只是在页脚加了行修订日期，整篇指纹就变了，系统当成大改全量重切，浪费算力还把没变的片段也短暂标记失效。后来改成"正文内容指纹加忽略区配置"，把页脚、修订记录这类易变但无关的区域排除在指纹计算外，误触发大幅减少。失效片段回收有个顺序问题：我们最初先删旧片段再写新片段，中间有几秒窗口新旧都召回不了，问答直接空答。改成"先写新片段、确认索引就绪后再回收旧片段"，空窗消失。

变更影响面评估当时我们做得太粗，只按"改了几个文档"算风险，结果有次客户改了一个高频 FAQ 的退货政策，文档数就一个，但影响面极大，直接上线后投诉爆发。之后评估改成"文档热度乘变更幅度"，高频文档的小改也标红走人工复核，高风险变更再没绕过人。

四、效果数据

增量同步上线后，同步时效从全量的约两小时压到变更文档的约十分钟以内。过期片段残留率（应失效但仍能被召回的比例）从约百分之八降到接近零。问答准确率在源文档频繁变更的那几个月，不降反升，从约八成五回升并稳定在约九成三。回退次数（因同步问题需要回滚）从每月几次降到零。变更影响面评估拦截的高风险单文档变更，每月约三到五起，全部走人工复核后才上线。

案例片段（已脱敏）： 某政策文档 v3 更新为 v4，正文指纹变化，页脚修订日期变更被忽略区排除未触发误判。系统增量重切该文档 12 个片段，新片段写入后索引就绪，回收 v3 对应 12 个旧片段。影响面评估：该文档近 30 日检索热度 top 5%，变更幅度中，综合风险标红，走人工复核 40 分钟后上线。监控记录同步耗时 8 分 12 秒，旧片段残留 0，上线后该场景问答准确率由 0.81 升至 0.94。

切片策略上我们还有一处优化值得提。源文档很多是带表格的政策文件，纯按字数切会把表格从中间劈开，检索召回的片段残缺，问答自然答不准。我们加了"表格感知切片"，遇到表格就把整表作为一个不可拆单元，前后用语义边界切，表格内不再硬断。这个改动让带表文档的问答准确率提了一截。另外增量同步的触发我们起初挂在文件变更事件上，发现客户用协同文档多人编辑，保存动作频繁触发，一天重切几十次，浪费算力。后来改成"指纹变化且间隔大于五分钟才触发"，把协同编辑的抖动过滤掉，同步量降了约七成，时效性没受影响。这两处都是"看着小、实则影响大"的优化，也再次说明 RAG 的质量藏在切片和同步这些不起眼的环节里。

五、可复用经验总结

RAG 不能只管进不管出，这是我们从这次项目里学到最贵的一课，知识库上线只是开始，源文档的版本生命周期才是它能活多久的关键。指纹计算一定要排除易变无关区域，否则全量重切既浪费又制造短暂的不一致窗口，这点在多版本文档场景尤其明显。失效回收的顺序不能反，先写后删这个细节看着小，空窗期答不上来比答错更让用户怀疑系统。我们当时在影响面评估上栽过一次，后来想明白风险不该按"改了多少"算，该按"多少人会撞上"算，热度乘幅度比单纯看变更量靠谱得多。版本追踪这套机制，后来在另一个合规问答项目上直接复用，只是把人工复核改成了合规双签。