129 篇博文 含有标签「mlops」

一个发布团队在百分比旗标（percentage flag）的保护下发布了一个新模型。分桶计算公式为 hash(user_id) % 100，金丝雀（canary）测试覆盖 0–4 桶。在两周内，人均参与度的提升显著且稳定，于是团队将比例提升到 20%，随后是 50%，最后推向全球。在 50% 到全量发布的某个阶段，这种提升突然消失了。事后复盘（post-mortem）发现问题出在金丝雀人群（canary cohort）。实验变量并没有真正改变指标。金丝雀组的样本是一个特殊的群体。

团队以为自己是在对用户进行采样，实际上它是在对 ID 进行采样。

事件时间线清晰可见。9:02，你的平台团队将 prompt-template@v38 推送到了配置服务。11:14，你的仪表板显示一切正常。16:51，支持团队有人标记了升级件数的激增。17:03，你打开了评估套件，发现回归分数为 0.34，于是进行了回滚。复盘报告称：“在 8 小时内捕获，除了 0.04% 看到该问题的客户外，未造成进一步损害。”工程领导层对响应速度表示赞赏。

但这是错的。回归在 0 小时内就被捕获了。17:03 运行的评估套件与 09:03 运行的是同一个。它一直指向的是 v37。评估框架在进程启动时从配置服务加载了模板，将渲染后的 Prompt 以 Python 对象的形式缓存到了模块级作用域中，并且从未重新读取源文件。你的线上流量在上午 9 点切换到了 v38。而你的评估直到 17:03 有人重启了 Worker 池来“重新运行回归”时才发生变化。在长达 8 小时的时间里，客户交互是基于从未经过评估打分的 Prompt 进行的，而评估系统却一直在给生产环境中根本没人在用的 Prompt 打分。

一个微调（fine-tune）不仅是一个文件。它是训练集上流水线的闭包（closure），如果一个团队在交付文件时没有提供这种闭包，那么他们就构建了一个生产依赖，其源代码其实只存在于某个人的脑子里。当那个人带着两周的离职通知和一份整洁的交接文档离开的那天，你某个收入相关特性的巴士系数（bus factor）就降到了零，而且没人会察觉，因为权重依然在注册表中，注册表标签依然稳定，模型也依然在处理流量。清算会在以后出现，比如在一次常规的基座模型迁移中，原本应该只需要一个 sprint 的工作却耗费了一个季度。

在我观察到陷入此困境的团队中，这种模式是一致的。一名 ML 工程师花了六个月时间迭代一个微调模型——包括数据策展（data curation）、超参数搜索、以及根据感觉在留存集上评估的行为补丁（behavioral patches）。最终的适配器（adapter）权重被推送到模型注册表并打上标签。而产出这些权重的训练流水线，只是该工程师笔记本电脑里的一个 Notebook，里面充斥着硬编码路径和浮动依赖，这些依赖指向的是每个单元格最后一次执行当天的最新版本。团队理所当然地接受了交接，因为权重有效、评估分数不错，且注册表标签很稳定。18 个月后，该工程师离职了。又过了 6 个月，一次基座模型迁移需要针对更新后的基座重新生成适配器。此时 Notebook 运行后生成的权重分数降低了 3 分，并且在最困难的客户细分领域出现了明显的性能退化，团队花了 4 个月时间尝试复现原始产物，但最终以失败告终。

我认识的一个平台团队花了两个季度构建了一个模型注册中心（model registry）。它拥有组织架构要求的一切：从 dev 到 staging 再到 prod 的晋升工作流、CODEOWNERS 风格的审批矩阵、血缘追踪、评估分数门禁、包含 30 天窗口期的弃用政策，以及一个展示每个模型版本在哪个服务中运行的 Backstage 磁贴。他们发布了上线公告，举办了技术分享会，并在合规活页夹中增加了相关条目。

六个月后，公司流量最高的智能体（agent）运行在一个模型卡片上，其“所有者”字段仍指向一个已经离职的人，评估分数来自团队早已弃用的基准测试，而“批准人”姓名是平台技术主管——他从未用过那个智能体，从未读过其评估集，并在周四晚上 11:43 点击了批准，因为生产者在私信（DM）中对他说，明天就要发布了。

注册中心没有坏。晋升门禁触发了。审计日志是完整的。发布公告承诺的一切都是真的。然而，该组织对生产环境模型的实际监管，反而比 18 个月前更少了。当时同样的决策是由一名 ML 工程师在将模型 URI 粘贴进配置文件之前，手动阅读评估输出后做出的。

一个 RAG 流水线在发布时设置了 0.4 的重排序器（reranker）分数阈值。任何低于该分数的片段都会从提示词（prompt）中被剔除。半年后，一次常规的索引重建将嵌入模型（embedding model）更换为同系列的一个更新版本——变更日志称这是一次透明的升级。两天后，回答的相关性下降了 6%。团队将责任归咎于 LLM，进行了模型对比测试（bake-off），却发现没有任何候选模型能挽回损失，结果花了一个季度去追踪一个根本不存在于他们所对比模型中的回归问题。

回归问题就出在门控（gate）环节。重排序器——未做变动，相同的模型版本（checkpoint），相同的权重——现在正在对一组不同的候选集进行评分。新的嵌入模型将不同的数据块（chunks）拉入前 50 名，重排序器根据自身的校准对它们给出了更低的分数，而 0.4 的门控剔除的候选者比前一周增加了 37%。0.4 这个数字没变，但 0.4 所代表的含义变了。

“点赞”按钮是你所能埋点的最廉价信号。它也是最危险的信号之一，因为没有任何迹象表明它正在重塑你的评估集本应代表的分布。这个按钮作为正向信号被收集——策展流水线将其解读为高质量——而六个月后，评估集就被一群不包含最可能流失的客户的用户所选择的案例占据了。

这种失败很少表现为回归。它表现为一种偏离：每周评估趋势向好，企业级用户的 NPS 下滑，而团队只有在一个流失的账户指出了其团队一直遇到错误回答的具体问题类型时，才会诊断出这种差距。评估集中根本没有这种类型的案例。你正在优化的信号是真实的。它只是测量了错误的分布。

一个客户支持工单在周二送达。客户附上了一张你的产品在 6 周前生成的输出截图。他们声称该输出是错误的、不安全的，或者根本不符合预期，并要求修复。你的支持工程师将提示词粘贴回同一个 API 终端，得到了一个清晰、合理的回答。就系统目前的状态而言，这个 Bug 并不存在。

Bug 是存在的，但产生这张截图的模型已经不在了。自从客户提交工单以来，你的 v1-chat 终端背后的权重已经更换了两次——一次是为了提升质量，一次是为了优化成本——而原始的检查点（checkpoint）已无法访问。客户的“这东西坏了”现在成了一个针对变动目标的无法证伪的断言，支持团队既无法确认它，也无法关闭它。

这不是一个古怪的边缘案例。这是将模型版本控制视为内部 MLOps 问题，而非客户可见的产品合约的必然结果。终端 URL 是稳定的，但它背后的产物（artifact）却不是。在你的支持流程、保留策略和客户合约承认这一差距之前，每一个针对已轮换检查点的 Bug 报告都会掉进同一个分类真空区。

审计员的问题听起来很简单。她翻开你的申诉日志，指着八个月前的一行，询问是哪个模型决定了那个案例。你的工程师调出了 Schema：有一个 model 列，审计窗口内的每一条决策都显示为 v1。接着，平台团队的一位成员随口提到，在审计期间，v1 背后的别名（alias）轮换了四次——一次基础模型升级、一次微调刷新、一次供应商侧的容量迁移，以及一次在事故期间持续了六个小时的回滚。诚实的回答是，你无法确定是哪一个 Checkpoint 产出了那个决策。审计员记录下了一些内容。那个回答不是监管机构能接受的答案，而你刚刚意识到，你交付的系统未能满足一项它从未被设计去满足的审计要求。

这里的差距不在于缺失了一行日志，而在于对“模型”含义的两种不同理解。对于交付系统的工程师来说，v1 是一个 Endpoint——一个稳定的契约，调用者可以指向它，而其背后的东西则可以免费升级。对于审计员来说，“产生此决策的模型”是一个特定的 Artifact：一个权重 Checkpoint、一个哈希值，一个原则上你可以在相同的输入上重新运行并获得具有辩护一致性输出的东西。Endpoint 别名是为了向调用者隐藏 Checkpoint 的轮换而发明的。而审计级的溯源要求恰恰相反——每一项决策都必须能追溯到产出它的确切 Checkpoint。这两个想法从一开始就处于碰撞轨道上；审计只是它们相遇的地方。

你干净利落地运行了实验。两个实验组，一个功能开关，一个明确的指标，统计团队也认可了该设计。十二周后，你上线了胜出的方案，然而提升效果却在一个 Sprint 内悄然消失。复盘（Post-mortem）结果显示代码没问题，功能开关的滚动发布没问题，分析端也没问题。发生变动的是实验清单上没人负责的东西：你检索调用背后的托管嵌入模型（embedding model），在第三周、第七周，以及你开会审阅结果的那个早上，为同一个查询返回了略微不同的向量。你的 A/B 测试是真实的，但它运行的底层基座却不是。

这是每一个运行检索增强生成（RAG）的团队最终都会遇到的失败模式，而且几乎没人针对它进行设计。嵌入端点被视为像 Postgres 一样的稳定基座。但它不是。它是一个模型，其发布节奏由厂商控制，你不会去阅读它的更新日志，它的行为表现面（behavior surface）可能会发生偏移，而无需改变维度数量、SLA 或你签署的 API 合约。你以为实验测量的是功能变化，实际上测量的是检索机制的变迁，而功能开关带来的波动只是其上的噪声。

预发布环境界面（staging UI）里的点踩（thumbs-down）按钮原本只有一个作用：告诉值班工程师哪个回复看起来很糟，以便他们去排查。六个月后，模型团队的某个人把“所有带有修正建议的生产反馈”拉取到一个 Parquet 文件中，并针对它运行了一个微调（SFT）任务。评估集在三个指标上有所提升，却在五个指标上悄悄退步。没人能解释原因，直到有人翻看标签并发现修正列中有一行写着：“这没问题，但我讨厌它的措辞方式。”模型习得了这种观点。然后，它又习得了另外四万个观点。

这种失效模式源于调试界面和标注界面是同一个界面。工程师点击“点踩”可能是因为某个环节坏了，或者看起来很奇怪，或者他们正准备提交一个工单，或者排版让他们不爽，甚至只是为了测试按钮是否好用。从那次点击中流出的信号混合了“这个输出是错误的”、“这个输出是对的但很难看”、“我不喜欢这个”以及“我当时很无聊”。作为单一标签，它什么也证明不了。以此进行训练，它教会模型的是所有这些情绪的并集。

你选择了基础模型，“因为它是更安全的那一个”。六个月后，你的团队发布了一个经过领域微调的检查点，它能以极具说服力的流畅度回答客户关于财富产品的问题，任务评估通过率达到 94%，而且——在第一轮训练到第四轮训练之间的某个时刻——它悄然忘记了如何拒绝任何要求。没人注意到这一点，因为你的发布评估套件从未衡量过微调消除了什么。它被剥离的能力从未出现在你的任务分布中，因此也从未出现在仪表盘上。

这是目前生产环境中 LLM 系统最少被报道的故障模式：训练后的对齐并不是模型家族的固有属性。它是某个特定检查点的属性，而有监督微调（SFT）默认会腐蚀这种属性。进行微调的团队发布的并不是他们评审过的模型的微调版本。他们发布的是一个不同的模型——其模型卡描述的是根本没有在提供服务的权重。

基准测试指标连续四个季度上升。用户满意度却没有。团队中没有人能解释这种差距，直到有人对提示词模板进行了 diff，并注意到 Few-shot 示例正从评估器读取的同一个 CSV 文件中获取。评估集已悄然变成了上下文示例。这个指标不再衡量泛化能力。它衡量的是模型在刚被告知答案的情况下，复制与之最接近问题的能力。

这就是我想命名的失效模式：评估集到提示词的泄露 (eval-to-prompt leakage)。它在结构上与传统机器学习中的测试集污染 (test-set contamination) 完全一致，但它是通过团队刻意构建的后端通道发生的。Few-shot 检索是一个合理的工程举措。评估库是一个合理的工程产物。当两者在没有人划定界限的情况下汇集到同一个存储层时，污染就产生了。