模型、提示词和知识库不断变化，AI工作流怎样进行版本控制？

Geoffrey Chen

《AI进入工作之后》· 第二季“从个人工具到组织能力”· 第十一篇

一个AI助手上周还能正确解释退款政策，本周却开始遗漏一个例外。团队检查提示词，没有变化；知识库也似乎正常。后来才发现，供应商更新了模型，同时政策库加入一份新指南，检索排序发生改变。系统的“名称”没变，真正运行的组合已经变了。

传统软件通常能指出发布版本和代码提交。AI工作流的行为却由模型、指令、数据、检索、工具、参数和外部服务共同形成。只记录“使用某某AI”不足以复现一次结果，也不足以安全回退。

版本对象不是模型，而是完整配置

一次AI运行至少依赖：模型及供应商版本、系统提示与模板、知识库快照和索引方式、工具定义与权限、参数、后处理规则以及人工步骤。

其中任何一项改变都可能改变输出。修改一个文件看似内容维护，却可能使检索结果重新排序；增加工具可能让代理选择新的路径；供应商后台更新可能在组织没有改代码时改变行为。

所以，组织需要为“工作流配置”生成一个可识别版本，把各组件引用固定在一起。模型无法固定时，也要记录供应商标识、调用日期和可获得的版本信息。

先区分内容更新、技术更新和目的变更

不是所有变化都需要同样审批。

修正政策中的拼写属于低风险内容更新；更换嵌入模型或检索算法是技术更新；让原本只草拟的系统自动发送信件，则是目的和权限的重大变化。

变化分类应决定测试与批准强度。内容更新要检查受影响回答；技术更新要重跑基线和失败案例；目的、数据或行动权限变化需要重新进行影响与风险评估。

如果所有改变都走同一缓慢流程，团队会绕过制度；如果所有改变都被当作普通维护，重大扩权可能悄悄发生。

每个版本需要一张可读的配置卡

配置卡应记录：预期用途和禁止用途；组件版本；权威数据与更新时间；主要评测结果；已知限制；批准人；上线日期；监控指标；回退版本。

模型卡研究提出记录模型的预期用途、评测条件和限制。Google Research：Model Cards for Model Reporting 数据说明书则记录数据来源、构成、收集过程和建议用途。Microsoft Research：Datasheets for Datasets

组织的配置卡应把这两类思想扩展到完整工作流。它不是给开发者看的长篇技术档案，而是让业务负责人和审计者知道当前系统究竟是什么。

测试结果必须绑定版本

“系统准确率达到95%”只有在说明用哪个配置、哪个测试集和什么时间时才有意义。新版本不能继承旧版本的合格结论。

每次发布应重跑关键基线：普通任务、历史严重错误、边缘群体、权限测试、工具失败和停止条件。变化范围较小时可以使用影响分析减少测试，但必须说明为什么未测试的部分不受影响。

测试集本身也要版本化。新增案例可能使分数下降，这不一定表示系统变差，而可能表示评测变得更严格。组织需要同时保存旧基线和新标准。

生产监控要能发现渐变和突变

并非所有变化发生在正式发布。用户问题、客户群、外部资料和攻击方式会漂移。系统在相同配置下也可能面对不同世界。

NCSC安全运行与维护指南要求监控模型和系统行为、输入、数据漂移和异常，并建议为模型变化提供预览与版本化接口。NCSC：Secure operation and maintenance

监控不应只看服务是否在线。还应看拒答率、人工推翻、错误类型、群体差异、检索来源和投诉。达到阈值时，组织要能暂停或回到已知良好版本。

回退必须包括数据和权限

如果只把模型切回旧版，却保留新的知识索引和工具权限，系统并没有真正回退。

一个可恢复版本应包括组件清单、配置、数据快照或可重建索引，以及与之匹配的权限。对于不断更新的客户数据，不可能冻结全部内容，但可以保留结构、来源和变更记录，使当时结果可解释。

NCSC安全开发指南要求追踪、验证和版本控制AI资产，并能在遭受破坏时恢复到已知良好状态。NCSC：Secure development

回退决定还要有人负责。事故发生时，如果业务、技术和供应商互相等待，备份存在也没有恢复能力。

变更日志要面向受到影响的人

内部日志记录技术细节，使用者则需要知道行为变化：哪些任务受影响，输出格式是否改变，旧结果是否需要重查，人工审核是否暂时增加。

对外影响较大的系统，重大变化还可能需要更新透明度说明、通知合作方或重新培训员工。版本控制不是隐藏变化，而是让变化获得合适的可见性。

NIST AI RMF把监控、反馈和持续改进视为生命周期活动。NIST AI RMF Core 只有版本与责任相连，持续改进才不会变成持续不可预测。

紧急变更和退役也属于版本控制

安全事件或严重错误发生时，团队可能必须在完整评测前关闭工具、撤回权限或替换资料。组织应预先定义紧急变更程序：谁可以立即行动、怎样限制范围、何时补做测试，以及谁负责通知业务与受影响者。

临时修复必须有到期时间。否则，一次事故中加入的绕过规则会永久留在系统，逐渐形成无人理解的技术债务。恢复正常流程时，要确认临时数据、权限和缓存已经清除。

退役同样需要版本。组织应记录何时停止使用、哪些记录必须保留、下游流程怎样迁移、旧接口何时关闭，以及仍未解决的案件由谁处理。只停止付费并不等于系统已经退出；复制的提示、导出的资料和依赖它的工作仍可能继续存在。

完整生命周期从第一次试验延伸到最后一个依赖被安全移除。能上线却不能退役的AI系统，也不是组织真正拥有的能力。

版本边界还应包括运行环境。权限设置、检索参数、安全过滤、接口超时和外部工具版本即使没有改变模型，也可能改变最终行为。发布记录若只写模型名称，就无法重建当时的实际系统。完整配置必须把这些依赖与业务规则一同固定，并在任何关键依赖变化时触发相称的回归测试。

结论：能够改变的系统必须能够说明自己怎样改变

AI工作流不应因为依赖动态模型而放弃版本控制。相反，组件越多、更新越快，越需要把某一时点的完整配置固定为可识别对象。

最低原则是：

每个生产AI用例都必须能够回答当前运行什么、与上一版有何差异、通过了哪些测试、谁批准、出现问题怎样回退，以及哪些历史结果需要复查。

版本控制的目标不是让AI永远不变，而是让变化不破坏解释、审计和恢复。组织只有在能够安全改变系统时，才真正拥有系统。

主要资料

继续阅读：浏览《AI进入工作之后》系列文章

了解 Geoffrey Chen 的更多信息

订阅后即可通过电子邮件收到最新文章。