冷启动评估：如何在零生产环境追踪的情况下发布 AI 功能

每个 AI 功能上线前都有一个同样的静默时刻：在第一个用户看到它之前，团队中的某个人会问“我们怎么知道这个东西好不好？”，而诚实的回答是“我们现在还不知道”。你没有追踪记录 (traces)，因为你还没有用户。你没有用户，因为你还没有发布。这是一个真实的死循环，而它产生的两种失败模式都是致命的——要么盲目发布，让第一周的线上问题 (escalations) 成为你的评估数据集；要么等待“真实数据”，眼睁睁地看着产品路线图推迟一个季度，而竞争对手却发布了演示视频。

摆脱困境的方法不是假装冷启动评估与发布后的评估是同一个问题（只是样本量较小）。事实并非如此。你不是在对分布进行采样，而是在构建先验 (prior)。上线首日的每一个信号都是你所做选择的产物——关于衡量什么、模拟谁的行为以及关注哪些失败的选择。能够出色发布 AI 功能的团队会将发布前的评估栈 (eval stack) 视为一等交付物——它不是在准入审查前一晚匆忙拼凑的电子表格，而是一个由内部试用 (dogfooding)、模拟、专家标注和对抗性探测 (adversarial probes) 组成的层级化系统，每一层都提供不同类型的信号，并伴随着关于它能告诉你什么以及不能告诉你什么的明确说明。

这篇文章介绍了我如果在下个月必须发布产品时会构建的评估栈，以及我在第一天会分配的权重和我会警惕的陷阱。

为什么“等待真实追踪记录”是错误的答案

“等到有生产数据再说”的最强论据 (steelman) 是：合成评估受编写者偏见的影响，而没有什么能比真实用户的混乱现实更具说服力。这个论据关于偏见的部分是正确的，但结论是错误的。真实追踪也不是免费的——它们来自通常付了费的用户，他们的投诉是公开的，而他们的流失是你无法挽回的。从生产追踪中发现失败模式的代价是：用户经历了这个失败，以及所有你尚未捕捉到的下游失败。合成评估是有噪声的，而生产发现是昂贵的。你是在用精确度交换影响范围 (blast radius)。

第二个问题是，前几周的生产追踪几乎总是存在自选偏差。你的早期采用者不是你的中位数用户。他们会找到聪明的方法来使用该功能，容忍粗糙的边缘，并在你的 Slack 频道中写下看似信号、实则只是某个超级用户偏好被放大的文字反馈。将他们的追踪记录视为黄金标准 (ground truth) 会将这种偏差根植于随后的每一次迭代中。等你意识到评估循环一直在针对一小群人进行优化时，你已经拥有了一个为 10 个用户调优而让其他 1 万个用户感到困惑的模型。

第三个问题是潜伏的，也是最糟糕的。在没有评估栈的情况下发布产品的团队往往会回溯性地构建一个，且是构建在他们已经根据内部直觉优化过的模型之上。由此产生的评估是模型当前行为的下游产物——它们编码的是“不要从这里退化”，而不是“达到我们真正关心的门槛”。冷启动评估是你唯一一次在成品扭曲标准之前制定评分准则的机会。

冷启动评估栈的四个层级

这个栈有四个层级，每一层都回答一个不同的问题。混淆它们——或者只依赖其中一个——就是团队最终得到的评估看起来很全面，却仍然错过关键失败的原因。

带有结构化任务的员工内部试用 (dogfooding)。 内部试用几乎总是存在，但也几乎总是运行得很糟糕。解决方法是增加结构。一个结构化的内部试用小组并不意味着“使用这个功能并告诉我们你的想法”。它意味着一份预先写好的固定任务列表，每个参与者都会尝试这些任务，并根据评分准则进行报告。任务应涵盖黄金路径 (golden path) 以及至少两类你怀疑会难倒模型的边缘情况。输出结果进入一个共享的电子表格，带有二进制的通过/失败标签和关于失败模式的一行简记。你不是在尝试给模型打分——你是在尝试梳理出失败分类学 (failure taxonomy)，这是接下来的三个层级的输入。

基于场景且具备画像多样性的模拟。 一旦你知道要寻找哪些类型的失败，你就需要量。这就是合成画像 (personas) 发挥作用的地方。画像是一个可重复的个人资料——用户属性、历史、目标、先前的上下文——你可以根据需求实例化并输入到功能中。WHOOP 团队发布了一个记忆智能体，使用的是诸如“一个拥有 15 次 80% 以上绿色恢复的 IN_THE_GREEN 成员”之类的画像；Algolia 在租户没有搜索日志时，从客户记录中生成合成查询。这两种模式之所以有效，是因为画像是一种廉价的方法，可以在改变提示词 (prompt) 时保持用户状态不变，反之亦然。一个拥有 20 个画像且每个画像有 50 个场景的模拟器可以产生 1,000 次评估运行，每次提示词更改时你都可以重新生成——这是内部试用无法提供的主要功能。

针对小型但多样化的种子集进行专家标注。 内部试用和模拟都依赖于你的团队对“好”是什么样子的直觉。这种直觉在特定方面是错误的，只有当领域专家阅读输出时，这些错误才会显现。一个由 50-100 个精心挑选的输入组成的种子集，由一两个专家根据明确的准则进行审查，为其他每个层级提供了一个高信号的锚点。种子集是评分准则本身得到精炼的地方——你会发现你的通过/失败标准在面对真实的边缘情况时经不起推敲，而你会因此修正它们。Eugene Yan 的三步指南收敛到这个数字是有原因的：它足够小，可以进行彻底审查；足够大，可以捕捉大多数系统性失败；且足够便宜，可以在准则演变时重新执行。

从公共基准借用的对抗性探测库。 你的用户在第一天可能不是对抗性的，但你的产品表面从拥有输入框的那一刻起就是对抗性的。提示词注入、越狱、违反政策的请求、跨租户的上下文泄漏——这些都不需要恶意用户就会产生影响，因为良性输入经常会意外触发它们。好消息是，你不需要从头开始编写这些探测工具。HarmBench、JailbreakBench、AdvBench 和 Promptfoo 红队语料库都是公开的、经过策划且有人维护的。拉取与你的部署界面匹配的子集，将其作为不可逾越的准入门槛运行，并在每次提示词更改时重新运行。其成本很低，而它强制执行的底线是实实在在的。

对首日决策进行加权，避免被嗓门最大的用户左右

几乎每个团队都会掉进这个陷阱。CEO 试用了某个功能，发现了一个让他烦恼的点，在 Slack 发了条消息，紧接着 Prompt 的顶部就多了一个针对该特定情况的变通方案（workaround）——而且对于不在那次对话中的人来说，这段方案完全没有任何上下文。内部试用（dogfooding）层的评估分数上升了，但种子集（seed set）的分数却下降了，只是那个星期没人去看种子集，因为 CEO 满意了。这种情况重复三周，你的 Prompt 就会变成由高层烦恼堆积而成的疤痕组织，而你的场景模拟（scenario sim）也会在不知不觉中偏离产品愿景。

防止这种情况的机制是显式加权，并制定一套关于当各层意见不一致时哪一层胜出的书面规则。一套可行的默认设置是：专家种子集是准确性的基准真相（ground truth），场景模拟是覆盖范围的基准真相，对抗性探测（adversarial probes）是带有通过阈值的硬性关卡，dogfooding 是定性的并用于完善失败分类法（failure taxonomy），但不决定数值评分。当 dogfooding 层与专家种子集不一致时，种子集胜出，而 dogfooding 的观察结果成为种子集的待选添加项——有待专家评审。当专家种子集与场景模拟不一致时，则通过调整反映专家关注点的角色设定（persona）来重新生成模拟。

第二个机制是公开权重。将它们放在与评估工具（eval harness）相同的代码库中，并以与评审 Prompt 相同的节奏对它们进行评审。跳过这一步的团队最终会产生非正式的权重，这些权重往往会跟着最近投诉的人走。而执行这一步的团队则被迫进行关于“什么是好”的实质性讨论，这种讨论才是冷启动评估计划真正的产出。

当第一批真实的 Trace 到达时，不要丢掉合成数据栈

一旦生产环境的流量开始流入，人们的直觉是将整个评估计划转向真实 trace，因为“终于有真实数据了”。请抵制这种冲动。你在第一周获得的 trace 往往偏向于早期采用者，而忽略了那些试用一次、碰到困难就再也不回来的用户。合成数据栈仍然是你对抗这种偏差的最佳防线，因为它被显式设计用于覆盖那些流量分布中权重不足的场景。

行之有效的集成模式是增量式的。从 trace 中挖掘新的角色和新场景，将它们喂给模拟器，让模拟器的规模持续增长。为种子集采样 trace，让专家进行标注，扩大种子集。将对抗性探测与你观察到的实际畸形输入进行交叉比对，将新颖的输入添加到探测库中。合成层会随着时间的推移变得更加丰富，而不是被取代。你砍掉它们的那一天，就是你的评估质量开始悄悄跟随流量构成（traffic mix）而非产品意图的那一天。

具有前瞻性的做法是：将你的评估栈视为一项数据资产，其权重与你的 Prompt 或检索索引（retrieval index）大致相当。评估栈会产生复利，它为发布把关，它让你能够回答“新模型是否更好”，而无需每次都重新讨论整个评估标准。冷启动只是拥有它的第一天。

如果只有一周时间，先交付什么

如果时间紧迫，你在发布前只能构建一层，那就构建一个包含 50 个案例和一份书面评分准则（rubric）的专家种子集。它是成本最低、信号最强的产出物，并且能为你以后添加的所有内容打下基础。如果你有两周时间，加入对抗性探测库——从 HarmBench 或 Promptfoo 红队语料库中提取一个子集，将其作为发布前的关卡，这就大功告成了。如果你有三周时间，加入带有书面任务清单的结构化 dogfooding。带有角色设定的场景模拟器是长期收益最高但构建正确所需时间最长的层，因此在压缩的进度表中它排在最后，但在正规的进度表中它排在最前。

核心观点是，冷启动评估并不是发布后评估的缩减版。它决定了发布后的评估是否有可供对比的有用基准。在需要之前就建立好评估栈，显式地为各层分配权重，并拒绝让第一周的客户投诉成为你的评估数据集。做对这一点的团队发布速度更快，而不是更慢，因为发布后的每一次迭代都有一个为产品定制的衡量标尺，而不是随波逐流于碰巧出现的流量。