把评测理解成反馈系统，而不是发布前的一张成绩单

很多团队第一次做 LLM 评测，会整理几十条问题，运行新旧提示词，然后比较一个总分。这个动作比凭感觉上线好得多，却很容易停在“发布前考试”：样本长期不变，分数没有对应产品风险，线上出现的新失败也回不到评测集。

更有用的理解是把评测当成反馈系统。它持续接收真实使用中的信号，把模糊的不满意转成可讨论的失败类型，再影响下一轮数据、提示词、模型或交互设计。

一个样本需要哪些信息

只有输入和理想输出的样本往往不够。我们至少还需要任务来源、风险级别、判断标准和失败标签。这样一次分数变化才能被解释，而不是只剩下平均值上下浮动。

{
  "id": "support-017",
  "input": "用户要求取消已经发货的订单",
  "expected": {
    "mustMention": ["无法直接取消", "退货流程"],
    "mustNotDo": ["承诺即时退款"]
  },
  "risk": "high",
  "source": "anonymized-production",
  "failureTags": ["policy", "overpromise"]
}

这里的期望不是唯一标准答案，而是可检验的行为边界。开放式任务尤其适合拆成“必须包含”“不得包含”和“允许变化”三部分。

不要让平均分隐藏风险

如果九十个低风险问答全部正确，十个高风险任务全部失败，总分仍可能看起来不错。因此报告需要按场景和风险分层。常见的观察面包括：

关键规则通过率，例如是否泄露不该出现的信息；
任务完成率，例如工具链是否真正抵达目标状态；
人工偏好与修改量，例如答案需要多大幅度的编辑；
成本和延迟，避免质量提升来自不可接受的资源投入。

评分器也有边界。确定性的格式、关键词和状态检查应优先使用代码；只有语义质量难以规则化时，才使用模型评分，并用人工抽检校准评分器本身。

让线上失败回流

每次投诉、人工接管或异常重试都可能成为新样本，但不能原样复制敏感数据。合理流程是先脱敏，再归入失败类型，最后挑选能代表问题的最小案例。修复完成后，这个案例应留在回归集中，防止相同错误在下一次优化时回来。

当评测可以明确告诉我们“哪类用户、哪种任务、哪个风险边界发生了变化”，它才真正参与工程决策。分数只是反馈系统的一种压缩表达，不是系统本身。

（示例内容，用于站点骨架验证）