2 篇博文 含有标签「incentives」

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

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

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

FinOps 团队在一年前推出了 AI 内部计费（Chargeback）。仪表盘非常华丽。每个功能团队都能精确到分地看到上个月的推理账单，平台 PM 的幻灯片展示了 SKU 级别的业务线归因。相比一年前，组织拥有了更多的 AI 功能，但 AI 的质量却变差了。目前还没有人将这两个事实联系起来，但它们其实是同一件事。

用一句话概括这种失败模式：内部计费为推理 Token 定价，却悄无声息地忽略了评估 Token 的定价。因此，组织架构中的每一位 PM 都面临着一个奖励模型升级、惩罚评估规范的激励结构。12 个月后，评估覆盖率在萎缩，而账单却在增长——这与 FinOps 项目最初设想的激励效果完全背道而驰。这并不是仪表盘的漏洞，而是内部计费模型在严格执行其设计逻辑，只是在 AI 领域，源自云成本 FinOps 的设计假设已不再适用。