非对称评估经济学：为什么一个测试用例的成本比它测试的功能还要高

这是一个尴尬的事实，大多数 AI 团队在发现时往往已经晚了半年：一个精心设计的评估（eval）用例所耗费的工程精力通常比它要测试的功能本身还要多。修改一次提示词（prompt）只需要一个下午。而让你确信这次修改没有破坏原有功能的评估用例，则需要领域专家进行为期两天的标注，一个与裁判提示词（judge prompt）的校准循环，以及一场关于“正确”在当前用户界面下究竟意味着什么的讨论。功能可以在一个 Sprint 内交付，而让你能够安全交付后续十个功能的评估体系则需要一个季度才能成熟。

这种不对称性并非缺陷。它是评估工作的结构性形态。标注、边缘情况的策划、裁判校准和评分标准设计都是前置的固定成本，它们不随你交付功能的多少而扩展，而是随你想要验证的不同行为（behaviors）数量而扩展。与此同时，功能开发端不断产生看似廉价的边际输出：“又一次提示词迭代”、“为智能体增加了一个工具”、“更换模型”。每一个改动看起来都很微小。但每一个改动都在无声无息地增加评估集必须覆盖的范围。

这与软件组织多年来在基础设施上犯的会计错误如出一辙。容量、可观测性和可靠性曾被视为每个功能的额外开销——即每个 Sprint 计划底部的税项——而实际上，它们是跨越多年产品发布持续产生价值的资本支出（capex）。那些最早意识到这一点的团队建立了如今被所有人效仿的平台组织。而那些没有意识到的团队，最终只能把同一个负载均衡器重造六遍。

评估正朝着同样的路径发展，而大多数团队仍站在错误的一边。

成本是集中的，价值是分散的

评估在经济学上令人困惑的地方在于，其成本和价值出现在不同的账本上。

构建一个包含 200 个真实生产故障案例的黄金数据集，由了解该领域的专家进行标注，并配有一个与人工评审达成 85–90% 一致性的校准裁判——这对于一名工程师来说确实是几周的工作量，还需要投入大量的领域专家时间。这些努力都不会产生任何可以演示的功能。它产生的是一种测量工具。

但一旦这种工具存在，其价值便无处不在。从 Claude 4.6 到 4.7 的每一次模型更换都要经过它。每一次提示词修改都受它门禁。每一次能力的发布——添加工具、扩展上下文窗口、开启视觉功能——都依赖它来进行发布与否的决策。工具本身不交付任何东西，但它降低了其他所有交付项的风险。

粗略估算一下：如果一个经过校准的 200 例评估集需要投入约 5,000 美元的工程和标注时间来构建，每年再投入 5,000 美元进行维护，并且在它的生命周期内让你安全地执行三次模型迁移和二十次提示词迭代——而如果没有它，每当生产环境出现问题时，这些迭代都将变成持续 1 到 2 周的全员停工调查——那么这个评估集每年就产生了超过 50,000 美元的“避免返工”价值。ROI 是真实的，只是会计核算方式将其掩盖了。

这正是财务团队几十年来一直在争论的资本支出（capex）与运营支出（opex）的区别。构建成本是集中且不均衡的；而价值则分摊到未来的每一次使用中。如果你将构建成本记为当前功能的运营支出，该功能看起来就会无利可图并被削减。如果你将其记为评估资产的资本支出，它看起来就像是一项具有多年回报周期的明智投资。经济逻辑没有变，变的是视角。

为什么边际成本框架会导致团队投入不足

在大多数工程组织内部，预算单位是功能、Sprint 或 OKR。这些都不是评估集的正确核算单位。

当 AI 产品团队负责人询问“交付摘要功能需要多少成本？”时，他们得到的答案是“一名工程师两周的时间”。这个答案忽略了以下成本：确认摘要功能是否优良的成本、提示词更改时发生回退的成本、在下一次模型迁移中生存下来的成本，以及在用户输入分布发生漂移时不产生无声降级的成本。所有这些工作（其中大部分就是评估集）被稀释到许多功能中，不专门向任何人收费，因此也就没有专门的资金支持。

失败模式是可预见的。每个产品团队都在理性地选择将评估工作推迟到“以后”，或推给“评估团队”，或推给“平台”。评估团队（如果存在的话）的规模被设定得好像只承担了 20% 的实际工作，因为可见的产出很小。与此同时，保持评估套件有用所需的实际劳动——当模型获得新能力时对旧案例重新评分、调试不稳定的裁判、淘汰过时的案例、生成对抗性用例——作为无声的债务积累在某处。

加载中…