知识库上线之后：谁来维护，多久更一次

知识库项目的验收通常很顺利：导入文档、跑通问答、答得不错。问题出现在半年后 —— 制度改过一版、价格调整过、某个流程已经取消，而知识库仍在用旧内容回答，而且答得同样自信。

内容腐坏的三种形态

1. 过期：规定变了但旧文档还在库里。最危险的一种，因为答案形式完全正常；
2. 冲突：新旧两版同时存在，模型可能检索到任一版，答案在两次提问之间不一致；
3. 缺失：业务新增了内容但没有同步进来，表现为「这个问题它答不上来」，相对容易发现。

三者里只有第三种会主动暴露，前两种需要专门去查。这就是为什么维护不能靠「有人发现问题再改」。

责任要落到文档而不是系统

常见的做法是把知识库交给 IT 部门维护，但 IT 不知道某条制度是否已经作废。有效的做法是每一份源文档指定一个业务侧责任人 —— 通常就是该文档的出具部门 —— 由他们负责在内容变更时同步。

系统侧要做的是让这件事足够容易：有一个明确的提交入口、变更后能看到生效状态、以及旧版本自动下线而不是并存。如果更新一份文档需要走工单、等排期，那它就不会被更新。

一个可执行的节奏

• 变更即同步：制度与价格类文档在发布新版时同步更新，这是硬要求；
• 季度复核：按责任人清单逐份确认是否仍然有效，确认本身要留记录；
• 每月看一次答不上来的问题列表：它直接指向内容缺失，是最便宜的选题来源；
• 每月抽查若干条线上答案，重点核对是否引用了已失效的内容。

版本与生效日期

每份文档都应当带版本号和生效日期，检索时默认只召回当前有效版本。历史版本可以保留但要明确标记，并且不参与默认检索 —— 否则就会出现前面说的冲突情况。

有了生效日期还能做一件有用的事：定期列出超过一定时间未更新的文档，提醒责任人确认。这比等出错再查主动得多。

把维护成本写进预算

知识库是持续投入的资产，不是一次性交付物。项目立项时就应当明确维护投入由谁承担、占多少工时，否则上线半年后它会悄悄失效，而失效的知识库比没有知识库更有害 —— 人们已经开始依赖它了。相关安排见企业知识库解决方案与合作流程。