“这个答案不错”不是评估。“准确率 92%”也未必是评估——如果测试集不代表真实任务、评分器没有校准、失败切片被平均数掩盖，数字只会让错误更有权威感。

深度重写版约 16 分钟含网站案例含 Eval Spec
我的定义是：Evaluation = 把产品承诺写成可重复运行、能区分改进与退化的证据系统。它不是上线前一次考试，而是需求、开发和生产之间的共同语言。

一套 Eval 至少包含五个对象

Task真实用户要完成的工作
Trial输入、环境与一次运行轨迹
Grader确定性、模型或人工评分
Outcome最终状态与副作用

对 Agent 还要保存 Transcript（轨迹）：调用了哪些工具、花了多少步、在哪里失败。只看最终答案，会漏掉越权、浪费和偶然成功。概率系统还需要多次 Trial；一次通过不能代表稳定。

六种评估幻觉

FAILURE 01

单一总分

平均数很好，却掩盖高风险用户或关键任务持续失败。

FAILURE 02

考试泄题

开发者和模型反复看到测试集，优化的是题库而非能力。

FAILURE 03

评分器污染

用与被测系统相同偏好的模型评分，错误互相强化。

FAILURE 04

没有基线

只看新方案绝对分，不知道是否优于简单 Prompt 或人工流程。

FAILURE 05

单次运行

忽略随机性，把幸运样本当成稳定能力。

FAILURE 06

指标投机

系统学会讨好评分规则，却伤害真实用户价值。

完整案例：怎样评估一篇 AI Lab 文章

公开项目：目标是建立专业可信度，而不是把文章写长评估对象同时包含内容、来源、可用性、风格与隐私。

先建立最简单基线：旧版三章节短文。新版不以字数取胜，而要在五条证据上显著改善。

Depth有明确论点、最强反方和边界
Grounding概念归属准确，关键事实有官方来源
Usefulness包含完整案例、协议与测试
Voice有 Alex 的判断，不假装原创
Safety无客户泄露、虚构案例明确标注

确定性检查负责链接、章节、重复 ID 与敏感词；模型评分负责论证连贯性和反方强度；人类负责真实性、品牌语气和是否值得署名。三种 Grader 互补，而不是互相替代。

Eval Spec：从失败开始设计，而不是从分数开始

EVAL SPEC / REUSABLEv1.0
产品承诺：[用户能完成什么]
评估单位：[一次回答 / 一条轨迹 / 一个最终状态]
任务分布：[常见、关键、边界、对抗、历史事故]
基线：[人工 / 简单 Prompt / 现有版本]
评分维度：[定义、权重、硬性失败]
Grader：[规则 / 模型 / 人工；各自负责什么]
重复次数：[概率任务至少多次运行]
切片：[用户、语言、风险、工具、任务难度]
通过门槛：[总体 + 关键切片 + 零容忍项]
失败分类：[原因而非表面症状]
回归策略：[每次改动运行哪些固定集合]
生产反馈：[哪些真实失败进入评估集]

评分器也要被评估

模型 Grader 可扩大覆盖面，但必须与专家样本校准。先让多人独立评分一批代表样本，讨论分歧并写清 rubric（评分标准）；再测模型评分与共识的吻合度。遇到高风险或价值判断，不要把自动评分当最终裁决。

Grader擅长主要风险
确定性规则格式、字符串、执行结果只检查可见表面
模型评分语义、完整性、开放式质量偏好、漂移、自洽性偏差
人工专家真实性、高风险判断、产品价值昂贵、慢、评分不一致
最强反对意见：评估会让创造性工作被指标绑架

这条反对意见值得权衡。Eval 应守住底线和产品承诺，不应把所有优秀答案压成同一模板。把“不可接受”自动化，把“真正优秀”保留给人判断。

最终闭环：真实失败不断更新测试世界

开发集用于快速迭代，保留集用于防止自我欺骗，生产失败用于扩充新的切片。每次修复都要把对应失败变成回归样本，否则同类问题迟早回来。

Eval 的最高价值不是证明系统已经很好，而是让团队更快知道哪里不好、为什么不好，以及下一次改动究竟有没有变好。