一家连锁服务企业的客服助手，在公司把无理由退换的期限从三十天调整为十五天之后的一周里，仍在按旧规则答复客户。质检抽查时发现问题，同一个退换货问题在不同坐席那里得到了两种答复，一部分按新规，一部分按旧规。运维去查后台，新的制度文件确实在上周一就上传到位了。

团队遇到这类现象，反应通常是检索没做好、模型没读进去，于是调低相似度阈值、增加切片数量、在提示词里反复强调以最新规定为准。这些动作做完，问题依旧间歇性出现。症结不在检索的准确度，而在于一次制度更新需要在几个位置同时生效，只改其中一处，旧版本就仍然留着被调用的通道。

制度状态至少可能存在于源文件、派生切片与检索索引、答复缓存，以及历史会话上下文或会话摘要中。知识版本变化后，旧会话再次涉及该制度时，应重新校验当前问题对应的有效版本，不能直接沿用历史上下文中的旧结论。上传新文件只更新了源文件；索引要等重建完成才会变化，重建期间旧索引仍在承接查询；答复缓存按问题特征保存，各有存活时长，与知识是否更新没有天然联系。任一处滞后，回答就会落在旧规则上。另一个常被忽略的情况是旧文件没有下架，同一主题同时存在两个版本，检索按相似度打分选出的未必是最新生效的那一份。

制度类条目本身应当携带时间信息。每条知识在登记时写明发布日期、生效日期、失效日期与替代关系，把发布时间与生效时间分开记录，版本号与生效时间一并进入索引。新版本发布时，旧版本不直接删除，而是标记为已被替代并设定停用时间。这样既能让查询命中当时有效的版本，也留下了变更痕迹，事后能还原某一天系统是按哪一版答复的。

索引更新不宜就地覆盖。一种可用的做法是先重建一份新索引，等它装载完成、抽检通过，再把查询流量切过去，旧索引在过渡期内保留只读，用于比对与回退。这里要分清：旧索引的“回退”是重建出现问题时恢复上一份正在运行的索引、保证服务不中断的操作安全措施，它不等于允许用一份已经废止或本应停用的版本去答复用户；版本选择仍由下面的仲裁规则按生效时间决定。还要考虑一种现实情形：若新制度已生效且只存在于新索引，而新索引发生故障、系统回退到旧索引，旧索引里可能根本没有当前应当生效的版本，此时按生效时间仲裁也选不出来。遇到这种情况，系统不能退而用旧制度作为当前依据，应对受影响主题暂停自动回答、直接查询权威源或转人工处理，直到当前有效版本恢复可用。切换动作要能回滚，否则一次有问题的重建会让整个知识库停摆，此时连回退到上一版索引的机会都没有。

答复缓存需要与知识版本建立关联。缓存条目在保存时记录它依据的是哪一版知识，知识版本发生变化时，关联的缓存条目立即失效，而不是等它自然过期。对于提问口径没变、依据却已经变化的场景，这一环正是让旧答案停止出现的关键，仅靠提示词叮嘱无法解决。

检索阶段若同时召回多个版本，仲裁规则要事先写明。先按适用范围筛选，把不适用于当前客户或当前区域的版本排除；再根据问题对应的业务目标时间匹配当时有效的版本——问当前规则就用当前生效版本，问历史事实则允许返回当时有效的旧版本并明确标注版本与有效期；最后才参考检索分数。注意这里取的是“当时有效”，不是简单“最新”：一份九月发布、十月生效的新版，在九月下旬回答当前政策时仍应命中旧版；而对“今年七月退换货期限是多少”这类历史问题，即使新版已生效，也应返回七月当时有效的旧版本。把时间与范围放在分数之前，是为了避免一份措辞更贴近提问的旧文件压过新文件，也避免用尚未生效或已经失效的版本答复。规则一旦确定，就应当统一执行，而不是每次由执行者临时判断。

需要说明的是，通用模型或Agent平台通常都提供文档上传与索引重建的接口，但生效时间如何登记、索引切换由谁操作、缓存失效如何与知识版本挂钩，仍需结合企业自身的内容管理流程来确定。

在青山不语AI工作室的企业AI Agent定制方案中，制度类知识按发布、生效与失效时间登记，索引更新走重建后切流的过渡方式，答复缓存与知识版本联动失效，检索遇到多版本并存时按适用范围与业务目标时间仲裁，区分最新发布与当前生效。

这套机制的边界也要讲清楚。它能确保系统按目标时间读到当时有效的版本，它却无法判断该版本的内容本身是否正确。制度条款的修订、解释与废止属于业务部门的职责，助手这一侧负责版本识别、生效判断、缓存失效与变更留痕。业务口径本身存在分歧时，系统只能把两个版本同时呈现，不能替业务做裁定。

验收可以用一次真实的更新来完成。选一条正在被频繁查询的制度，发布一个新版本，随后用同一个问题分别在新会话与历史会话中提问，观察回答是否一致地切换到新版本；再检查旧版本停止查询之后，历史答案有没有标注依据已经变更。两次测试的结果，基本能说明版本管理有没有形成闭环。

我的看法是，知识更新的难点不在上传一个新文件，而在让新旧交替在源文件、索引、缓存与会话上下文等多处同时发生。企业评估AI定制服务时，与其问知识库能装多少份文档，不如问一句：制度生效之后，多久能确定所有“当前规则”查询都不再把旧版本当成现行依据，同时历史查询仍能正确定位当时有效版本。这个问题能被清楚地回答，知识库才算真正接上了业务。