Evals 语义扩散现象

语义扩散（semantic diffusion，借 Martin Fowler 2000s 的术语）

同一个词至少在指四件不同的事，谁都没错但互相说不通：

• 数据标注公司说"专家在写 evals" → 实际指 error analysis / 专家批注什么是对的；
• "PM 应该写 evals，evals 是新 PRD" → 不意味着 PM 要写生产级 LLM judge；
• "我们做了 evals：查了 LM Arena / Artificial Analysis 排行" → 那是 model evals（选模型），不是应用评估；
• "evals 是整个反馈回路" → 那是评估过程。实践者对"要不要给 AI 产品建可行动的反馈回路"全体同意，分歧只在措辞。

评估指标 vs 生产监控：假两难

• 评估数据集/指标 = 把你信任的产品判断编码成数据集，保护已知关键行为（"无论怎么改，这 10 个问题不能错"），防回归；
• 生产监控 = 用显式信号（点赞/点踩）+ 隐式信号（用户点"重新生成"= 对首答不满）在真实流量里发现未知失败。高吞吐产品不可能人工看全部 trace，监控的作用是告诉你该看哪些 trace；
• 闭环：监控圈出 trace → 归纳失败模式 → 只为"你在乎且反复出现"的失败建评估数据集 → 改完部署 → 新版本仍可能以新方式失败 → 继续监控。评估指标只能抓你已知的错误，两者缺一不可。
• LLM judge 的边界：复杂场景涌现模式太多，judge 追着建会失控；此时直接看用户信号、修复、确认无回归、继续走，比堆 judge 更划算。

Codex 团队的实际配比（Kiriti）：有保护核心行为的评估集 + 重度customer 信号监听 + 模型变更必 A/B（错误的 code review 评论会让用户直接关掉产品）+ 盯社交媒体 + 每次新模型全团队人手一份"私藏难题集"当自定义 eval。