一家连锁服务企业的客服助手在公司把无理由退换的期限从三十天调整为十五天之后的一周里仍在按旧规则答复客户。质检抽查时发现问题同一个退换货问题在不同坐席那里得到了两种答复一部分按新规一部分按旧规。运维去查后台新的制度文件确实在上周一就上传到位了。团队遇到这类现象反应通常是检索没做好、模型没读进去于是调低相似度阈值、增加切片数量、在提示词里反复强调以最新规定为准。这些动作做完问题依旧间歇性出现。症结不在检索的准确度而在于一次制度更新需要在几个位置同时生效只改其中一处旧版本就仍然留着被调用的通道。制度状态至少可能存在于源文件、派生切片与检索索引、答复缓存以及历史会话上下文或会话摘要中。知识版本变化后旧会话再次涉及该制度时应重新校验当前问题对应的有效版本不能直接沿用历史上下文中的旧结论。上传新文件只更新了源文件索引要等重建完成才会变化重建期间旧索引仍在承接查询答复缓存按问题特征保存各有存活时长与知识是否更新没有天然联系。任一处滞后回答就会落在旧规则上。另一个常被忽略的情况是旧文件没有下架同一主题同时存在两个版本检索按相似度打分选出的未必是最新生效的那一份。制度类条目本身应当携带时间信息。每条知识在登记时写明发布日期、生效日期、失效日期与替代关系把发布时间与生效时间分开记录版本号与生效时间一并进入索引。新版本发布时旧版本不直接删除而是标记为已被替代并设定停用时间。这样既能让查询命中当时有效的版本也留下了变更痕迹事后能还原某一天系统是按哪一版答复的。索引更新不宜就地覆盖。一种可用的做法是先重建一份新索引等它装载完成、抽检通过再把查询流量切过去旧索引在过渡期内保留只读用于比对与回退。这里要分清旧索引的“回退”是重建出现问题时恢复上一份正在运行的索引、保证服务不中断的操作安全措施它不等于允许用一份已经废止或本应停用的版本去答复用户版本选择仍由下面的仲裁规则按生效时间决定。还要考虑一种现实情形若新制度已生效且只存在于新索引而新索引发生故障、系统回退到旧索引旧索引里可能根本没有当前应当生效的版本此时按生效时间仲裁也选不出来。遇到这种情况系统不能退而用旧制度作为当前依据应对受影响主题暂停自动回答、直接查询权威源或转人工处理直到当前有效版本恢复可用。切换动作要能回滚否则一次有问题的重建会让整个知识库停摆此时连回退到上一版索引的机会都没有。答复缓存需要与知识版本建立关联。缓存条目在保存时记录它依据的是哪一版知识知识版本发生变化时关联的缓存条目立即失效而不是等它自然过期。对于提问口径没变、依据却已经变化的场景这一环正是让旧答案停止出现的关键仅靠提示词叮嘱无法解决。检索阶段若同时召回多个版本仲裁规则要事先写明。先按适用范围筛选把不适用于当前客户或当前区域的版本排除再根据问题对应的业务目标时间匹配当时有效的版本——问当前规则就用当前生效版本问历史事实则允许返回当时有效的旧版本并明确标注版本与有效期最后才参考检索分数。注意这里取的是“当时有效”不是简单“最新”一份九月发布、十月生效的新版在九月下旬回答当前政策时仍应命中旧版而对“今年七月退换货期限是多少”这类历史问题即使新版已生效也应返回七月当时有效的旧版本。把时间与范围放在分数之前是为了避免一份措辞更贴近提问的旧文件压过新文件也避免用尚未生效或已经失效的版本答复。规则一旦确定就应当统一执行而不是每次由执行者临时判断。需要说明的是通用模型或Agent平台通常都提供文档上传与索引重建的接口但生效时间如何登记、索引切换由谁操作、缓存失效如何与知识版本挂钩仍需结合企业自身的内容管理流程来确定。在青山不语AI工作室的企业AI Agent定制方案中制度类知识按发布、生效与失效时间登记索引更新走重建后切流的过渡方式答复缓存与知识版本联动失效检索遇到多版本并存时按适用范围与业务目标时间仲裁区分最新发布与当前生效。这套机制的边界也要讲清楚。它能确保系统按目标时间读到当时有效的版本它却无法判断该版本的内容本身是否正确。制度条款的修订、解释与废止属于业务部门的职责助手这一侧负责版本识别、生效判断、缓存失效与变更留痕。业务口径本身存在分歧时系统只能把两个版本同时呈现不能替业务做裁定。验收可以用一次真实的更新来完成。选一条正在被频繁查询的制度发布一个新版本随后用同一个问题分别在新会话与历史会话中提问观察回答是否一致地切换到新版本再检查旧版本停止查询之后历史答案有没有标注依据已经变更。两次测试的结果基本能说明版本管理有没有形成闭环。我的看法是知识更新的难点不在上传一个新文件而在让新旧交替在源文件、索引、缓存与会话上下文等多处同时发生。企业评估AI定制服务时与其问知识库能装多少份文档不如问一句制度生效之后多久能确定所有“当前规则”查询都不再把旧版本当成现行依据同时历史查询仍能正确定位当时有效版本。这个问题能被清楚地回答知识库才算真正接上了业务。