三个月前我们公司搭了个RAG智能客服，上线的时候效果特别好——问什么都能从知识库里面找答案。结果呢？两周后客服就来找我投诉了。

客户问你们这个产品新版本有什么功能，AI回答了一堆三个月前的旧功能。客户说你们政策改了吧？AI还在念老版本。

我才意识到：知识库不是搭完就完事了，它每天都在变。

产品更新了、政策调整了、新文档发了，你向量数据库里还是三个月前的旧东西，AI就会一本正经地胡说八道。这个问题比你想的麻烦多了。

最开始我们偷懒，搞了个笨办法。

每天凌晨两点全量重建索引。听起来简单吧？问题是我们知识库有八千多份文档，全量重建要跑四个多小时。这期间搜索不稳定，有时候查东西半天出不来结果。更要命的是很多文档只是改了个错别字，你也得全部重新算一遍Embedding，纯浪费资源。

后来改成了增量同步：只把改过的文档重新入库。但问题又来了——你怎么知道哪些文档改过？

最粗暴的办法是每天扫一遍文件修改时间，变了就重新索引。这个方案简单，大部分小团队这么干就够了。我们当时就是这么做的，每小时跑一次，改了什么就补什么。

但有个坑我们踩了很久：一篇文档更新之后，旧版本的向量你得从库里删掉啊！不然检索的时候新旧内容同时被召回，AI拿着两份互相矛盾的文档给你回答，你说它能对吗？

这个问题我们大概花了两周才发现。有客户投诉说AI给的答案前后不一致，我们排查了半天才搞清楚——旧版本的向量没删干净。

现在我们的方案是这样的：

定时增量加版本号比对。每份文档都存一个hash值，每次改了就重新算hash。检索的时候先对比hash，不一致的就标记需要更新。这个方案不算完美，但对我们这种规模够用了。

说句实在话，RAG上线之后最费精力的根本不是技术，是知识库管理本身。我们公司文档管理本来就乱——同一份政策在三个地方存了三个版本，你说AI该信哪个？

所以我的建议是：搞RAG之前先把你的文档治理好。源数据都是乱的，你索引机制再完美也白搭。

更多科技资讯，请看《听歌识曲是怎么做到的？从Shazam说起》。