知识库建完就过期？说说责任人、版本和下线机制

去年下半年，我们回访一家做建材的客户。他们的知识库上线四个月，后台看着日均查询三百来次，数据挺好看，但销售在群里骂：问“现在返点政策是多少”，AI 答的是前年那一版。问题不在模型，也不在向量库——那份《经销商返利政策》从入库那天起就没人再碰过，文件本身没标失效，系统当然照答。

这类事情我们见得太多了。企业知识库真正的敌人不是技术选型，是资料过期没人管。下面说四件具体的事：责任人、版本管理、有效期标记、下线流程。听着像行政工作，但恰恰决定了知识库半年后还能不能用。

一、先承认：过期资料比没有资料更危险

没有资料的时候，AI 会老实说“我不确定”，员工转身去问人。资料过期的时候，AI 会用很确定的语气给你一个错的数字，前者只是体验差，后者可能直接导致报价报错、合规踩线。

更麻烦的是它很难被发现。员工发现答案不对，往往关掉对话框自己去问同事，不会反馈；管理员看着后台查询量还在涨，以为一切正常。所以不能等出了问题再修，得靠机制在出问题之前把过期内容拦下来。

二、责任人：落到一个具体名字，不是“IT 部门”

“IT 部门负责”等于没人负责。IT 不知道财务制度改没改，业务部门又觉得知识库是 IT 的事。我们通常设三层：

角色	管什么	频次
文档所有者（Owner）	每份文档一个具名的人，通常是这份制度、产品资料或流程的实际负责人；内容变更后 3 个工作日内更新入库	随变更
部门知识官	每个部门 1 人，盘点本部门文档清单，催办到期未确认项	每季度
平台管理员（IT）	管账号权限、入库流程、失效拦截规则，不判断内容对错	每月抽查

关键在第一条。入库时强制填 owner 字段，填不出来，就说明这份文件本来就没有明确负责人，那它多半也不该进知识库。顺带说一句：如果你们选的企业知识库方案在系统层面做不到 owner 必填、做不到按字段过滤，那它在运维上是先天欠缺的，越早调整越省事。

三、版本管理：让每段文字能追溯到人和时间

版本管理不是把 Word 改名成 V1、V2、V3 存到共享盘。知识库里的版本管理，指的是每条入库内容都带一套可查的元数据。我们一般建议至少这几个字段：

字段	说明	示例
doc_id	稳定不重复的文档编号	KB-HR-0142
version	版本号	v2.3
effective_date	生效日期	2025-03-01
expire_date	失效日期，允许为空	2026-02-28
owner	责任人	张××（人力）
source_url	原始出处链接	OA 制度库链接
status	草稿／生效／已废止	生效

这套字段在实际检索时很有用：可以按生效日期过滤，避免命中旧版本；AI 回答时能带上“依据 2025 年 3 月版《××制度》”，用户自己就能判断时效；出了争议也能定位到谁在什么时候改过。

版本切换建议保留旧版本一段时间，而不是直接覆盖。我们踩过的坑是早期图省事直接覆盖，结果历史对话里引用的旧内容无法回溯，客户投诉时说不清当时依据的是哪一版。现在的做法是旧版本置为“已废止”、保留可查，但默认不参与检索。

这件事建议交给流程，别靠人记。比如文档在 OA 里审批通过后自动同步到知识库并写入元数据，用AI 工作流自动化接一下，比让行政每周手动上传可靠得多，也省掉了“以为对方传了”的扯皮。

四、有效期标记：给知识设保质期，分档管理

不是所有文档都该一年一审，一刀切的结果通常是半年后没人再执行。按变化速度分档，管理成本才降得下来：

类型	典型内容	建议有效期	到期动作
高频变动	价格、返点、促销政策、库存口径	1–3 个月	到期自动下架，需重新确认
中频	组织架构、岗位职责、报销标准	6–12 个月	到期提醒 owner 确认
低频	员工手册、安全规范、行业标准	12–24 个月	到期提醒 + 季度巡检
长期	公司简介、企业文化、发展历程	不设或 24 个月	年度确认

到期不等于自动删，而是“降权 + 提醒”。到期未确认的内容，在检索结果里往后排，AI 回答时标注“该信息可能已过期，请向××部门核实”。这里我们踩过一个坑：早期设成到期直接自动下架，赶上一批财务文档集中过期，客服连着三天答不上基础问题——下架前必须有确认窗口，一般给 15 个工作日比较稳妥。

五、下线流程：删比加更需要规矩

新增内容大家都有动力，删除往往没人愿意按按钮。但一条已废止的制度留在库里，危害大于十条缺失。下线至少要包含下面几步：

1. 发起与确认：由 owner 或部门知识官发起，记录下线原因（废止／被替代／内容错误），不能只写“删除”两个字。
2. 替代指向：如果是因为有了新版本，必须把新文档 ID 填进去，让老问题能被引导到新答案，而不是直接查无结果。
3. 软删除 + 冷静期：先从检索索引移除，原文保留 30–90 天，期间可恢复。
4. 影响面检查：查一下最近 30 天有多少次问答引用了这条内容，量大就先通知相关岗位，再下线。
5. 留痕：谁、什么时候、因为什么下线，日志要能查。审计和合规场景下这条经常被追问。

如果知识库是私有化部署在自有服务器上，这些日志和回收站都在自己手里，做审计会方便不少；用 SaaS 方案要提前确认后台能不能导出操作记录，别等要用的时候才发现没有。

六、把四件事压成一个季度节奏

制度写得再细，不排进日历就等于没写。我们现在给客户的默认节奏是：

• 每月：平台管理员跑一次失效扫描，把当月到期清单发给各部门知识官。
• 每季度：知识官盘点本部门文档，重点看高频变动类；人工抽查 10 条问答，判断答案今天是否仍然正确。
• 每半年：更新一次 owner 名单，人员流动是元数据失真的头号原因；清理无人认领的文档。
• 每年：整体评估一次，包括分类体系要不要调、哪些内容该合并。

这套动作走一遍，一个中等规模企业每季度大概占用 1–2 个人天。跟知识库烂掉之后重新梳理一遍的成本比，这个投入相当划算。

下一步可以做什么

如果知识库已经在跑，建议这周先做一件小事：导出全部文档清单，只加两列——owner、最近确认日期，把空着的那几行标出来。通常这一步就能暴露 20%–30% 的孤儿文档，比开三次会都管用。

然后再决定要不要上有效期字段和下线流程。文档量几百份以内，一张表加一个季度会议基本撑得住；上千份、多部门协同的时候，才值得让系统来做这件事。我们做过不少类似梳理，包括知识库跟 OA、企微的对接，需要的话可以联系我们聊聊现状，或者直接拨 400-873-2750。