那个平台团队搭建却无人更新的模型注册表

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

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

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

这篇文章讨论了为什么会发生这种情况。这不是一个关于糟糕工具或懒惰评审者的故事。这是一个关于当你在一套未随之更新的激励结构之上构建治理界面时会发生什么的故事——以及为什么模型注册中心，尤其是，已经成为了这种失败模式的典型案例。

从未存在过的对称性

我见过的每个模型注册中心都会附带一张图表。图表显示了两个角色。左边是生产者（producer）：负责训练、评估并提交晋升候选方案的模型所有者。右边是评审者（reviewer）：负责阅读模型卡片、检查评估差异（eval delta）并批准或拒绝的管家。

这张图暗示了一种对称性。生产者干活；评审者检查工作；注册中心在中间协调。晋升设有门禁，因此质量得到了强制执行。这就是注册中心对自己讲述的故事。这也是注册中心必须讲述的故事，因为如果这种对称性不是真实的，整个前提就会崩塌。

这种对称性是不真实的，其原因在于结构而非个人。生产者有交付日期。他们的绩效考评取决于模型是否在本季度上线。他们的任务单是可见的。他们的经理可以计算他们的晋升次数。

评审者则没有这些。模型评审不在他们的路线图中。它是被别人的截止日期强行插入他们这一周的成本中心。批准模型不会影响他们的绩效考评；只有严重阻碍模型发布才会受到影响。他们的下行风险是真实的，上行收益几乎为零，而且对于任何能够调整人员编制的人来说，他们的排队深度都是不可见的。

因此，一方有时钟压力。另一方充其量只有模糊的义务。评审者的周转时间没有 SLA，因为没人能就“你是否真的阅读了评估集”的 SLA 达成一致。然而，却存在一种非常明确的文化 SLA：“不要成为那个因为动作慢而阻碍发布的人”。结果正如你所预料：审批按照生产者的进度进行，而不是评审者的进度，评审深度被压缩，以适应生产者愿意等待的时间。

“审批”如何退化为“橡皮图章”

这不是任何单个评审者的失败模式。这是一个在没有被赋予相应扩展资源的情况下，被要求进行规模化扩展的监管角色的失败模式。

关于人机协同（human-in-the-loop）系统中橡皮图章行为的文献现在已经非常明确且令人沮丧：当评审者被繁重的任务量淹没、缺乏所见内容的上下文、或面临必须批准的文化压力时，监管就变成了机械性的。他们点击通过。他们开发出一些匹配无关特征的启发式方法——生产者的名字看起来是否眼熟，评估差异是否看起来“方向性正确”，描述是否写得好——并以毫秒级速度应用这些启发式方法，因为他们的队列中还有 30 多个条目。

在模型注册中心里，具体表现如下：

• 评审者需要阅读的“证据”是一个包含 12 个图表的仪表盘，以及由生产者编写的一段 Markdown 文本，而生产者有充分的动力去美化模型。
• 评审者没有独立运行评估集的方法；他们信任生产者 CI 报告的分数。
• 模型卡片模板只在初次填写，之后几乎从未更新。因此到了第三次评审时，评审者只是在略读一份他们已经读过的文档。
• 评审者的名字记录在审批后的审计日志中，但审计日志从未用于绩效考评——它只在发生事故后使用，而那时评审者会被要求为自己六个月前采取的行动辩护。

2025 年 NACD 的一项调查发现，只有 36% 的企业董事会实施了正式的 AI 治理框架，只有 6% 拥有与 AI 相关的管理报告指标。这种差距也体现在工程层面上。组织拥有注册中心，但没有一个有效的衡量标准来判断注册中心的门禁是否发挥了作用。仪表盘显示“100% 的生产模型都经过了注册中心批准”。它并没有说明这种批准到底价值几何。

工具完全按照要求完成了任务

看到这种情况，人们很容易认为平台团队构建了错误的产品。但事实并非如此。他们构建的是执行发起人（executive sponsor）要求的东西。晋升工作流（promotion workflow）存在，血缘关系（lineage）已被捕获，审计日志（audit log）可供查询。如果监管机构介入并询问“你们是否有包含记录在案的审批流程的模型注册中心”，答案是肯定的，而且该注册中心能够完美地通过书面审计。

平台团队的错误（如果算得上错误的话），与每个内部平台团队在采纳是被强制推行而非自愿赚取时所犯的错误如出一辙。他们针对治理审查将要检查的产物进行了优化，即那些证明审批已经发生的产物。他们并没有针对那些能让审批变得有意义的产物进行优化，因为那需要明确审查者究竟负责什么，并为他们提供相应的工具，使其能够在被要求的规模下履行职责。

审查者的规模化（Reviewer scale）是没人计算过成本的部分。构建注册中心的平台团队会非常详细地向你介绍生产者的体验——他们会演示 CLI、评估 CI 集成以及 Backstage 组件。但如果你问他们审查者的日常工作流是什么样的，审查者有哪些工具可以并排比较两个模型版本，或者当审查者队列中有 15 个待办事项而该周只有 1 小时预算时会发生什么，你通常只会得到一个耸肩。答案是：审查者使用注册中心的用户界面（UI），这套 UI 和其他人使用的一样，然后由他们自己想办法解决。

于是，生产者得到了一条铺平的道路（paved road）。审查者得到了一个工单队列。架构预示了结果。

激励设计专家早已知晓的事情

关于这一点，我见过的最有效的视角来自平台工程关于黄金路径（golden paths）的文献。该社区最强有力的主张是：强制采纳是行不通的——80% 的自愿采纳才是目标；一旦某条路径被强制执行，你就会制造怨恨和影子 IT，并且你会失去原本可以改进该路径的反馈闭环。

模型注册中心通常是强制性的。生产者必须使用注册中心，因为监管要求、法律团队或首席技术官（CTO）的备忘录是这么说的。审查者必须配备人员处理队列，因为同一份备忘录规定必须有人这么做。双方都没有选择这一工作流。双方都没有权利投票决定它是否有效。当平台团队报告采用率指标时，他们统计的是合规性——即进入生产环境的模型通过该工作流的百分比——而不是大家真正关心的东西，即拦截了百分之多少的劣质模型。

如果你想设计一个审批具有实际价值的注册中心，平台工程的策略手册对于你应该做什么给出了明确的指导：

• 使审查者的付出可见。 追踪队列等待时间、决策时间以及每位审查者每周审查的项目数量。公开这些数据。把它们放在审查者的经理会真正查看的仪表板上。否则，审查者的时间就是未被计算的，而未被计算的时间会被其他事务排挤掉。
• 为审查者提供与生产者截然不同的产物。 由生产者编写的模型卡片（model card）不是证据，而是宣传。注册中心应该在提交时运行一个独立的评估套件，针对生产者不可见的留存集进行测试，并向审查者展示该增量，以及生产者训练时使用的源数据集血缘。审查者的工作是阅读独立证据，而不是批改课后作业。
• 将 SLA 与激励机制匹配。 如果为了保持生产者持续交付而必须在 24 小时内完成审批，那么审查者必须配备能够实现 24 小时周转的人力。如果人力不足，24 小时的 SLA 就会通过“不读即批”的方式来达成，每一次都会如此。要么是 SLA 错了，要么是人力配置错了；其中之一必须做出让步。
• 追踪审批的事后准确性。 每个进入生产环境并发生事故的模型都应该产生一个事实：“该模型于某日由某审查者在看到这些证据后批准”。汇总、发布，并将其作为审查者的实际评分卡。如果没有这一点，审查者的评分标准就只有速度，而你实际上是在告诉他们要针对速度进行优化。

这些都不是工具，而是政策。注册中心可以支持它们——大多数现代注册中心已经捕获了这些数据——但正是这些政策将“审批”从一个签名转变为一种判断。

生产者看到了什么，以及为什么这很重要

生产者侧也存在一种不对称性，而这正是导致模型在未经严格审查的情况下发布的真实原因。

生产者看不到审查者的队列。他们看到的是一个写着“请求晋升（request promotion）”的按钮。他们看到的是一个显示为“待定（pending）”的状态。他们看到的是一个自提交以来的计时器，如果他们赶时间，可以通过走到审查者的办公桌前或在 Slack 上发私信（DM）来缩短这个时间。从生产者的局部激励结构来看，每一个捷径都是理性的。发布就在明天。审查者在线。模型没问题。私信很管用。

平台团队往往意识不到组织中实际的审批带宽有多少已经转移到了私信中，因为私信不会出现在注册中心的仪表板上。注册中心看到了审批时间戳，却看不见产生该时间戳的社交压力。审计日志记录了行为却丢失了上下文，这意味着关于系统运行状况最深刻的信号——即隐藏在“Mike 在 Aisha 发送 Slack 消息告知明天就要发布的两分钟后批准了该请求”中的信号——恰恰是没人收集的信号。

这不是生产者的错。生产者正在做世界各地生产者都在做的事情：消除关键路径上的摩擦。这是一个领导力问题。必须有人决定注册中心的权威是真实的，这意味着要接受当审查者不可用时某些发布将会推迟，这意味着要放弃组织想要的东西，以换取组织声称更想要的监管属性。

这种权衡在每一次被提出时都不受欢迎。这就是为什么，在注册中心发布六个月后，这项权衡便不再存在了。

该如何应对

如果你拥有一个模型注册中心，但不确定其中的审批是否真实有效，以下三个诊断性问题可以在一个下午内给你答案。

首先，请你的评审人凭记忆数一数，他们在上个季度驳回了多少个模型。如果答案是零，那么你拥有的不是评审机制，而是一个走过场的文书流程。

其次，查看最近十个生产模型的审批记录，检查提交与决策之间的时间差。如果中位数少于一小时，说明你的评审人什么都没看——因为实际时长根本不够。如果中位数超过一周，说明你的评审人已经不堪重负，而注册中心正成为瓶颈，导致开发者在私下里绕开它。

第三，找一份过去一年内模型在生产环境中表现异常的事故报告。通过注册中心追溯该模型。询问当时的评审人，他们在审批时看到了什么，以及需要什么信息才能发现该问题。答案几乎总是：“我需要看到 X，但注册中心没有显示 X，而且即使显示了，我也没有时间去处理它。”这个答案就是你下一版注册中心必须实现的功能需求。

工具链是简单的部分。在交付模型注册中心时，没有人是因为工具本身而走投无路。他们之所以陷入困境，是因为没搞清楚评审人应该承担什么责任、考核指标是什么，以及在承担责任时获得了什么支持。这是一个领导力问题，而不是一个 MLOps 问题。如果把它当作后者来处理，你团队构建的注册中心终将变成一个无人更新的摆设。