2 篇博文 含有标签「ai-evals」

每个构建 AI 产品的团队都会得出同样安逸的结论：“我们每天都在用它，效果非常好。”这句话听起来像是证据。但它不是。它是房间里最具误导性的信号，而且你的团队越优秀，这个信号就越强烈——更具说服力，也更错误。

“吃狗粮”（Dogfooding）只能告诉你产品在运行。它不能告诉你产品是否奏效。这是两个不同的命题，而它们之间的差距正是你产品发布出问题的地方。从统计学上讲，构建系统的人是所有可能用户中最糟糕的样本。他们共享系统的心理模型，知道它的薄弱环节，并且已经花了几个月时间训练自己，用模型喜欢的方式来组织请求。这根本不是测试人群。这是你从未开展过的一项研究的对照组。

一个自托管 LLM 团队将生产模型从 fp16 量化为 int4。内存占用降低了 4 倍，吞吐量几乎翻倍，GPU 账单大幅缩减，团队重新运行了曾用于 fp16 发布把关的同一套评估组件。MMLU-Pro 保留了基准测试的 98.1%。综合质量看起来不错。他们发布了。

六周后，一名支持工程师注意到数学辅导功能悄悄变差了。合规团队标记了在对抗性提示下违反政策的补全次数有所增加。结构化输出的重试率从 1.4% 攀升至 6.8%。这些都没有出现在评估仪表盘上，因为评估仪表盘是为了验证另一个模型而构建的——那个虽然共享相同权重文件，但每个激活值背后都有四倍比特位的模型。

这就是量化漂移（quantization slippage）。成本分析只计算了内存和延迟方面的收益，却没有计算这次替换在无形中要求的评估重新锚定。而针对 fp16 分布进行校准的评估套件，现在正用错误的准则对错误的模型进行评分。