以 Token 数量而非结果驱动的 A/B 测试

我曾合作过的一个团队发布了一次 prompt 变更，将输出 token 减少了 22%。实验仪表盘上一片绿意——方差极小，p 值非常清晰，外推后的成本节省每年高达六位数。两周后，一位研究转化漏斗的产品分析师指出，在同一时间段内，下游任务完成率下降了 11%。较短的输出省略了一个澄清步骤，而用户一直默默依赖该步骤来了解下一步该点击哪里。

实验平台没有撒谎。它报告的正是团队配置的核心指标，而且该指标确实朝着正确的方向移动了。问题在于，该指标衡量的是团队实际上并不关心的东西。Token 统计成本低，实验基础设施对其有现成的集成，而衡量结果却很难——因此团队选择了平台提供的便捷方案。结果是仪表盘上的完胜，却是产品层面的退化。

这种模式在 AI 驱动的功能中屡见不鲜，就像十年前虚荣指标（vanity-metric）的 A/B 测试在互联网其他领域盛行一样。其机制是完全相同的：当易于衡量的代理指标（proxy）与难以衡量的实际结果不完全相关时，实验基础设施将倾向于优化那个容易发布的指标。那些没有强迫自己去衡量实际结果的团队，正在发布一些他们无法与退化区分开来的局部最优解。

代理指标替换陷阱

这种替换几乎是在无人察觉的情况下发生的。团队最初在结果层提出问题——“这次 prompt 变更是否让助手更有用了？”——最后却在代理层配置实验——“这次 prompt 变更是否减少了平均输出 token？”这种转化在逻辑向下推演时看起来很合理，因为 token 与成本相关，成本与利润率相关，而在足够抽象的意义上，利润率又与“有用”相关。但每一步都在丢弃信号，等到仪表盘建成时，正在回答的问题与最初提出的问题已经相去甚远。

古德哈特定律（Goodhart's Law）抽象地描述了这种动态：当一个衡量指标变成目标时，它就不再是一个好的指标了。关于它的文献非常晦涩，但工程领域的解释却很简单。一旦你的实验晋级标准依赖于代理指标，你的团队就会开始产生一些只能驱动该指标、而无法推动其背后真正目标的变更。这并非出于恶意，而是优化的本质使然。强化学习研究对此有详尽的记录，该领域甚至为其专门命名——奖励破解（reward hacking）——而同样的效果也发生在运行 prompt 实验的人类团队中。

这种倾向之所以难以抵制，是因为代理指标作为次要信号确实有用。Token 计数能反映真实的成本。延迟能反映真实的用户体验。错误不在于衡量它们，而在于让它们承担了设计之初并未预设的核心指标重任。一个将 token 削减作为护栏指标（guardrail）以确保成本不会激增的团队，其做法是正确的。但一个仅仅因为 token 减少就发布变更的团队，其做法是错误的，而仪表盘无法分辨这二者的区别。

为什么 LLM 功能特别容易陷入此境地

LLM 驱动功能的三个特性使得这种失败模式比传统产品实验更为严重。

首先是输出的高维性（high-dimensional）。传统的 A/B 测试衡量按钮是否被点击，点击就是结果。而 LLM 的 A/B 测试衡量是否生成了回复，而回复是由上千个 token 组成的具有内部结构的整体，它以实验框架无法察觉的方式映射到用户行为。最自然的核心指标——“这个回复好吗”——是无法直接观察到的。因此团队退而求其次，选择任何可观察到的东西，而可观察的是回复的表面属性：token 数量、延迟、拒绝率、格式合规性。这些都不是最终结果。

其次是成本压力是持续且可见的。Token 支出是 CFO 会询问的项目。而任务完成率则是产品团队必须构建基础设施才能衡量的指标。组织关注点的不对称意味着 token 相关指标最先被工具化，仪表盘最先被建立，OKR 最先与之挂钩。等有人问起“用户真的得到了他们想要的吗”时，实验文化已经围绕着那些容易衡量的事情僵化了。

第三点是，从输出质量到用户结果的路径比传统功能经过了更长的链路。更短的输出可能会导致用户提出追问而不是完成任务，这增加了对话长度，进而增加了单次会话成本，抵消了原始 prompt 变更节省的费用——但这一切都不会出现在范围局限于首条回复 token 计数的单轮 A/B 测试中。在测试衡量的层面上，成本优势是真实的；而在用户体验的层面上，成本损失也是真实的，但实验平台只报告前者。

强制性的指标分类法

第一个具体的改进方案是将代理指标 (proxy) 与结果指标 (outcome) 的区分从文化层面提升到结构层面。文化规则（例如“记得也要关注用户影响”）在季度回顾面前往往不堪一击。而结构性规则（例如“如果不明确分类主指标，实验平台就不允许你将该实验标记为可发布状态”）则能发挥作用。

这种行之有效的分类法包含三个层级：

• 结果指标 (Outcome metrics)：衡量用户是否得到了他们想要的东西。任务完成率、代码编辑接受率、未升级服务工单的解决率、点击并达到满意停留时间的搜索结果。这些指标的埋点成本高且衡量速度慢，但它们是唯一能宣告实验成功的指标。
• 代理指标 (Proxy metrics)：成本低、反馈快、与结果相关但本身并非结果的技术性测量值。Token 数量、延迟、响应长度、格式合规性、拒绝率。这些指标对于调试和理解成功机制很有用，但仅凭这些指标的提升不足以支撑发布决策。
• 护栏指标 (Guardrail metrics)：衡量变更不得造成的损害。单个已解决任务的成本、p95 延迟、留出集评估 (held-out eval) 上的幻觉率、用户反馈的负面评价。这些指标的检测阈值较松，因为它们的作用是捕获重大的回退，而不是驱动发布决策。

只有在实验平台强制执行该分类法时，它才能发挥作用——如果只有代理指标变动而“推广”按钮呈灰色，只有当用户结果层级变绿时才能点击。那些在幻灯片中对指标进行分类、却未能在工具层强制执行的团队，最终只是换汤不换药地重蹈覆辙。分类法的重点在于消除意外发布仅有代理指标提升的变更的可能性，而不仅仅是提醒人们可以这么做。

这也迫使人们就给定功能的结果指标展开有益的讨论。代码补全产品的结果是“被接受并保留”的编辑，而非“显示的编辑建议”。搜索产品的结果是“满意的查询”，而非“结果点击”。AI 客服的结果是“未升级服务工单的解决”，而非“结束对话的回复”。不同的产品有不同的结果，分类工作本质上就是精准命名这些结果的过程。

作为决策锚点的慢速对照组

AI 功能的 A/B 测试往往周期很短，因为 AI 功能本身迭代很快。对于每周发布提示词 (prompt) 变更的团队来说，两周的实验周期已经算很慷慨了。问题在于，你真正关心的结果指标的反馈周期往往比实验支持的周期更长。

一个在周二收到略差回复的用户可能当时没察觉；他们可能会发起一个后续追问，而仪表盘将其计为另一个独立的会话；他们可能在三周后流失，而实验永远无法将此归因于那个提示词。两周的时间窗口太短，无法检测到群组效应 (cohort effect)，而 A/B 平台却被设置为无论如何都要在窗口结束时给出结论。

加载中…