在本地文件夹里，一份合同被覆盖后，剩下的就是唯一版本。接入检索增强生成的知识库不是这样：新文件导入并建立索引后，旧版本通常仍留在库中，与新版本一同参与召回。当经营者提问“客户甲的交付周期怎么约定”，系统可能命中的是补充协议签署之前的那一版。版本管理在这里不是归档习惯，而是检索质量问题。

一套可用的版本机制，需要让版本信号出现在三个位置。文件名是第一层，用统一结构把客户名称、项目名称、资料类型、日期和版本号写进去，避免只留一个名为“最终版”的文件。文档正文开头是第二层，注明来源、日期、适用范围和当前版本；解析切分之后，这些字段仍会留在片段里，成为可被检索到的元信息。来源输出是第三层，回答必须能定位到文件名称、相关片段、资料日期和版本信息，否则结论无从核对。

更新时的处理方式决定旧版本会不会继续干扰。通行做法是保留旧版本但标记为“已失效”，给新版本补上生效日期，而不是简单删除——删除会丢掉审计线索，也可能让引用过该文件的其他记录断裂。关键动作是让“已失效”成为检索能够感知的信号，而不是一句写在正文里、模型未必读到的说明。

生成层需要配合。提问模板中应明确要求：只依据知识库中可检索到的资料作答；不同资料存在冲突时分别列出，并说明各自的版本或日期；不要用常识补充合同中没有出现的承诺。这实际上是把版本冲突显性化，交给使用者判断，而不是指望模型自己挑出较新的那一份。

任何版本变更之后，都应拿一个真实问题进行测试，确认系统不再优先引用旧版本。这是少数能证明机制真正生效的手段。入池标准同样要收紧：只有具备复用价值、来源与日期明确、内容经过基本核对，并且会影响报价、交付或客户沟通的资料，才进入核心知识库。

版本管理的成本主要不在技术，而在纪律。定期清理重复件与过期件，控制知识库范围，涉及合同金额、付款条件和客户承诺的结论一律回到原始文件核对。做到这些，知识库才会是一个可检索、可核对的经营资料库，而不是一堆越堆越厚的旧文件。