3 篇博文 含有标签「ai-evaluation」

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

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

你的评估套件通过了。质量仪表板显示为绿色。一周后，用户正在悄悄流失，没人能解释原因。评估集并没有通过犯错来撒谎——它的谎言在于它是一面镜子。你用来评分的标签，可以追溯到正是由你试图评估的那个模型家族生成或过滤的。通过这项评估并不是质量的证明。它证明了你的模型与其过去的输出是一致的。

这是成熟 LLM 流水线中一种隐蔽的失败模式：通过生产泄漏导致的评估集污染。这不同于著名的基准测试污染（即在 GSM8K 上训练的模型又在 GSM8K 上进行评分）——那个故事已经被讲烂了。更微妙的一种发生在下游。你的黄金标签来自用户反馈、来自先看到模型草稿的人类标注员、来自 RLHF 奖励追踪、来自 LLM-as-judge（模型即评委）的偏好数据。这些流水线中的每一个都将当前模型习语的指纹带回到了你的“基准真值”中。几个季度下来，测试集悄悄地记住了你模型的偏好，评估变成了一个自我表扬的循环。

一家加拿大航空公司的支持聊天机器人凭空捏造了一项根本不存在的丧亲票价政策。该机器人表现得非常自信、格式规范且彬彬有礼。乘客们相信了它。法院随后判定航空公司应对这一虚假政策负责。与此同时，该聊天机器人的满意度评分可能还相当不错。

这就是隐式反馈陷阱。大多数团队用来衡量 AI 质量的信号——点赞评级、点击率、满意度评分——不仅充满噪点。它们还在衡量错误目标方面存在系统性偏见。而针对这些信号进行优化，只会让你的 AI 变得更糟。