LLM 评测的两个噪声来源与处理方法

与传统单元测试不同，大模型的评测结果天然带有概率性波动：同一份提示词模板仅改动一个词，得分可能从 84% 跳到 81%，回滚后再跑又变成 87%。文章作者认为，单一分数并不能反映模型真实能力，它只是一个估计值。要建立可信赖的评测体系，必须先把噪声的两类来源分清楚，才能对症下药。

噪声的两类来源

第一类是输入端的不确定性，即统计学中的「偶然不确定性」。当用户回复一个孤立的单词（例如「Stop」），短信机器人可能解读为退订，而客服场景可能只是暂停会话。脱离上下文后，两种解释都说得通，连人类标注员也会分歧。这种噪声是任务本身内禀的，再优化评测模型也无济于事。

第二类是评测端的不确定性，即「认知不确定性」。即便提示词干净、模型输出正确，LLM 裁判仍可能在两次相同调用中给出 3 分与 5 分的差异。作者把这种噪声归为三个常见成因：托管模型的非确定性（即使 temperature 为 0，后端更新或负载均衡也可能改变输出）、评分标准过于模糊（如笼统要求「有用」「helpful」）、以及模型自身的偏好偏差（倾向长答案、倾向列表中的第一项等）。

如何清洗输入

• 在构建用例时附带最近三轮对话历史，弥补单轮对话缺失的上下文。
• 停止使用合成测试用例，改用真实生产会话并脱敏后作为固定样本。
• 对一条输入标注多个「合法回复」，避免裁判因答案措辞不同而误扣分。

如何稳定裁判

• 用多模型集成评测（文中提到 Claude、GPT-4、Gemini），并在三者分歧过大时标记该次结果。
• 同一套题连续运行三遍，计算基线标准差，把结果写成「84% ± 3%」而非单一数字。
• 把主观评分改成二元、客观维度：是否回答了问题？是否出现幻觉？语气是否礼貌？

重新理解评测目标

文章最后强调，LLM 评测更接近性能基准或 A/B 测试：它不证明正确性，只估计置信度。一旦把波动当成系统属性而非 bug 来对待，就不再执着于跑出 100% 的绿灯，转而积累足够的统计置信度再决定上线。