只做模型版本管理不够

线上文档助手开始超时。模型版本没动，容器健康检查全绿，发布流水线也没报错。

真正变的是检索配置：它多塞了几段上下文，生成变慢，请求堆在推理服务后面。把应用容器回滚到上一版，没用，因为检索配置根本不在那个容器里。

这是一个假想案例，但它问的问题很真：你们到底发布了什么？

一、发生了什么

Stack Overflow 博客 9 月 28 日发了一篇 MLOps 实操文，核心主张是：对一个 AI 应用来说，模型版本只是答案的一部分。

输入、预处理、提示词、检索、工具契约、服务参数，都能各自改变行为。所以需要的是一个「发布边界」：把必须一起工作的组件打成一个可回滚的整体。

文章给的起点不是买平台，而是三样东西：一份版本化的发布清单、一道有意义的评测门禁、一条真的演练过的回滚路径。

清单里该记什么？应用代码版本、模型快照、提示词版本、检索索引版本、embedding 版本、切片与排序流水线版本、运行时配置（token 上限、批大小、超时、资源放置）、评测集版本、上一个可用版本。调工具的应用，还要把工具 schema 和适配器版本记上。

文章特意提醒：清单不等于逐位可复现。外部服务会变，生成本身有随机性，有些厂商不提供不可变的模型快照。这些限制要写下来，而不是把一个浮动别名伪装成固定版本。

二、跟你有什么关系

做应用的团队。 你至少要知道一次请求是由哪几个版本拼出来的。答不上来，故障就只能靠猜。

做平台的团队。 你的交付物不是「能部署」，而是「能定位、能回滚、能证明回滚后依赖兼容」。

做管理的。 「质量下降」不是一份故障报告。门禁失败至少要留下候选版本、基线版本、数据集版本、失败样例和 trace。

三、怎么用

1. 先写清单，再谈自动化。 从一次真实请求出发，把参与的组件列全，每个都写成可解析的版本引用。密钥只存引用，不存值。
2. 让评测回答产品问题。 服务返回 200 不等于用户拿到了答案。文档助手要有可引用的来源、正确的产品版本、缺证据时敢拒答。把历史故障、模糊提问、越权尝试都放进评测集，并留一份不参与调参的保留集。
3. 用确定性检查兜底。 schema 是否合法、工具参数是否在允许范围、引用标识是否存在、权限有没有被执行，这些不需要模型判断。语义评分可以交给模型，但它的输出只是排序信号，不是标准答案。
4. 压测负载分布，不是压接口。 短问短答和长文长答是两种负载。流式响应要分开看首 token 时间和后续出词速度，还要看排队时间。不要把各阶段的 p95 相加当端到端 p95，它们可能不是同一批请求。
5. 算每个成功任务的成本。 便宜的模型如果触发更多重试和人工兜底，账会反过来。把失败尝试算进分子。
6. 把回滚当路由决策。 候选版本只接一部分流量，会话要稳定分配，别让同一段对话中途换模型。回滚要恢复兼容的依赖：索引、缓存、迁移都要能退。已经在跑的生成长任务要有取消或排空策略；发邮件、写数据库这类副作用，切模型版本是撤不回来的。
7. 演练一次。 在真出事之前，完整走一遍「切回上一个可用版本」。没演练过的回滚路径，等于没有。

四、三个别信的说法

「锁了模型版本就可复现。」 检索、提示词、运行时参数任何一项变了，行为都会变。模型只是其中一个变量。

「评测分数过了就能上。」 分数是在一份有限数据集上算的，它证明不了没有安全漏洞，也证明不了峰值负载下不出问题。门禁要能拦住已知的严重问题，不是给你发合格证。

「回滚就是把镜像切回去。」 如果候选版本已经原地覆盖了索引，切回旧镜像，它读的还是新索引。数据、缓存、迁移都要有可逆设计。

五、一句话结论

AI 应用的版本号不该只贴在模型上；回答「这次到底发布了什么」，比回答「用的哪个模型」难，也更有用。

信息来源

• Why model versioning is not enough for production AI，Stack Overflow Blog，2026 年 9 月 28 日

功能与价格以官方公告为准。本文写于 2026 年 10 月 19 日。