学习如何构建黄金数据集、选择有用的指标、评估模型行为、运行回归测试，并通过评测在生产级 AI 中赢得信任。
作者：The Forward Deployed 编辑团队（已审核）
如果在生产（Production）章节你只能学一件事，那就学这一件。评测（evals）是你判断一个概率性系统是否真正可用的方法，而“先建评测”这一习惯，正是能交付演示的工程师与能在生产环境中赢得客户信任的工程师之间最清晰的一条分界线。它是这个角色技术信号的核心。
为什么这就是工作本身，而不是杂务
每一次 FDE 项目都会遇到这样的模式：模型在演示中表现出色。你把它放到客户的真实数据上运行——几十年来不一致的记录、无人记录过的边缘案例、监管机构必须能够签字确认的问题——然后它就崩溃了。弥合这个差距就是部署工作本身，而你无法弥合一个你无法度量的差距。
在继续阅读之前：客户问：“我怎么知道这个助手是准确的？”你可以说“我们测试过，看起来不错”。为什么这个回答不合格？一位资深 FDE 会怎么回答？
“看起来不错”之所以不合格，是因为它经不起下一个问题：在什么上准确？如何度量？如果明天它变差了，你怎么知道？资深的回答会给出一个基于数据集的数字：“我们在一组固定的代表性问题上对它评分，由领域专家和自动化裁判打分；它目前处于已知的准确率水平，而且我们每天重新运行整套评测，因此回归问题能在一天内暴露出来。”这一句话包含了数据集、评分者、数字，以及让这一切保持可信的执行节奏。
三层结构，按顺序构建
评测不是单一的东西。你要分层构建，每一层都在回答上一层无法回答的问题。
- 离线评测——它到底能不能用？
先构建一个固定的输入数据集，并配上“正确答案”的概念，在任何东西上线之前运行它。这就是你的回归测试套件。对于一个检索助手来说，就是一组真实问题，以及它们应该检索到的段落或答案。离线评测的关键在于可重复性：同一套测试，在每次变更时运行，这样你才能判断新的提示词或模型到底是变好了还是变差了。没有它，每一次“改进”都只是猜测。
- 在线评测——它在真实环境中能用吗？
离线数据永远无法覆盖真实用户行为的完整分布。在线评测度量的是线上系统：采样真实流量、记录输出、追踪点赞/点踩、升级转人工和任务完成情况。你的离线分数与在线分数之间的差距本身就是一种信号。差距过大意味着你的测试集不像真实情况，需要修复的是你的测试集。
- LLM 即裁判——如何大规模地为“好”打分？
大多数 FDE 的产出并非对错之分，而是好坏之别——一段摘要、一个答案、一封邮件草稿。你不可能对每一个都进行人工评分。标准做法是用一个强大的模型作为裁判：给它输入、输出和评分标准，让它打分。这种方式成本低且可扩展，但有两种失效模式需要警惕：裁判存在偏差（偏好更长的答案、偏好自己的风格），而且会漂移。因此，你要用人工评分对裁判进行校准，并在高风险环节保持人工参与。裁判是对人类判断的规模化，而非替代。
校准是一套流程，而且短到可以背诵：从系统中抽取真实输出，让人类——最好是客户的领域专家——按照裁判使用的同一评分标准打分，然后统计裁判与人类意见一致的频率。当两者出现分歧时，分歧本身就是诊断依据：模糊的评分标准要重写，有偏差的裁判要换提示词或换模型，而如果人类彼此之间意见不一，说明评分标准对人类来说也不够明确。需要记住的基准数据：Zheng 等人对这一问题进行了系统研究，发现像 GPT-4 这样的强大 LLM 裁判可以“达到超过 80% 的一致性，与人类之间的一致性水平相当”——这使得人与人之间的一致性成为天然的标杆，因为接近这一水平的裁判，其评分稳定性与你的专家相差无几。同一篇论文还记录了你在校准时需要对抗的裁判偏差：位置偏差、冗长偏差和自我偏好偏差。
赢得信任的纪律：每天运行
一次性的上线前评测，在语料库或模型发生变化的瞬间就会过时。在受监管的环境中，“上线时是准确的”并不能作为辩护理由。真正能赢得采纳的做法，是一套常设的回归测试套件，在每次变更时和按固定计划运行，让漂移在一天之内暴露出来，而不是在客户会议上才被发现。Morgan Stanley 的项目就是现成的例子：团队每天针对固定的问题集进行回归测试，最终顾问的采纳率接近全员普及。资料来源将这两个事实并列呈现；把前者解读为赢得后者的原因，是本课程基于项目页面的论证。信任不是一次上线事件，而是一个客户能看见的、始终在运行的流程。
差 / 良 / 优——“你如何评估这个系统？”
差——“我试了一堆提示词，输出看起来是对的。”这是轶事，不是测量。它无法检测回归，无法向监管机构辩护，还会告诉面试官你从未运行过真实的东西。
良——“我构建了一个代表性案例的测试集，并在上线前测量了准确率。”这是一次真正的离线评测，属于扎实的中级水平工作。与“优”的差距在于：它只是一个快照，没有考虑线上真实分布，也没有说明你将如何发现系统在变差。
很好——“每次变更都跑离线回归套件，在线指标监控真实流量，用经过专家评分校准的 LLM 评审来处理主观部分，再加上每日运行以便漂移能尽快浮现。客户的合规标准被编码进了评审的评分细则里。”分层、持续，并与客户对“好”的实际定义挂钩——这是一个真实的受监管部署所采用的结构。
这个变化是真实的吗？
一个常设套件会产生一连串的分数，而一连串的分数会引出一个上面各层都无法回答的问题。昨天套件读数是百分之八十二；你改了提示词；今天读数是百分之八十四。是提升还是噪声？在有限案例集上的评测分数，是对系统在整个分布上表现的估计，而任何估计都带有抽样噪声。案例集越小，噪声区间越宽——小于该区间的差值，就是一个戴着百分比面具的抛硬币。
区间的宽度来自比例的标准误，算式只需几行：
Standard error of a proportion: SE = sqrt(p × (1 − p) / n)
At a score of p = 0.8 on n = 200 cases:
0.8 × 0.2 = 0.16
0.16 / 200 = 0.0008
sqrt(0.0008) ≈ 0.028 → one SE ≈ 2.8 points
So an 82% → 84% move is a two-point delta, well inside one SE.
Growing the set shrinks the band:
0.16 / 1000 = 0.00016
sqrt(0.00016) ≈ 0.013 → at n = 1,000, one SE ≈ 1.3 points从这些算术中可以得出三条操作规则。第一，评测集的规模要与你需要检测的差值相匹配：小差值需要大案例集，如果你能负担的案例集很小，那就只能读出大幅变动——在构建套件时就要决定哪些差值是重要的。第二，优先在同一批案例上做配对比较：让新旧两个版本跑完全相同的套件，把两者结论一致的案例全部搁置，只从两者不一致的案例中读取结果。如果新版本赢得了大多数不一致案例，说明这个变更确实起了作用；如果不一致案例大致对半分，那你看到的就是噪声。共享案例会在比较中相互抵消，这使得配对比较能分辨出比两个独立抽样分数更小的差异。第三，当发布门禁取决于这个数字时，在分数旁边标注噪声区间——“八十四，上下浮动三”能让签字的人确切知道这个数字能承载多少分量。
上面的评审校准流程遵循同样的逻辑：评审与专家之间的一致率同样是在有限样本上测得的比例，因此带有同样的区间，而仅用少数案例校准的评审，其校准只是徒有其名。
一个最小化的评测框架
你不需要框架就能起步。下面的骨架就是全部思想：一个数据集、一个评分器、一个聚合器。（示例代码。）
# eval_harness.py — the smallest thing that is a real eval
import json
def load_cases(path):
# each case: {"input": ..., "expected": ...(optional), "rubric": ...}
return [json.loads(line) for line in open(path)]
def score(case, output, judge):
"""Return a 0..1 score. Swap in exact-match, retrieval-hit, or LLM-judge."""
if "expected" in case:
return float(case["expected"].lower() in output.lower()) # cheap offline check
return judge(case["input"], output, case["rubric"]) # subjective -> judge
def run(cases, system, judge):
results = [(c, system(c["input"])) for c in cases]
scores = [score(c, out, judge) for c, out in results]
return {
"n": len(scores),
"mean": sum(scores) / len(scores),
"fails": [c["input"] for (c, _), s in zip(results, scores) if s < 0.5],
}
# Run it on every change. Check `mean` against last run; investigate `fails`.``` 有三个特性使它成为真正的评测而非演示：可重复（每次运行使用相同的用例）、可聚合（得到一个可以随时间追踪的数字）、能暴露失败（给出需要你去修复的列表）。其余的一切——更好的数据集、经过校准的评审、在线采样——都只是在这条主干上的精雕细琢。
面试中应带走的东西
在 AI 系统设计环节中，当题目涉及任何准确性、安全性或合规性要求时，不要一上来就谈模型或向量存储。而要先谈你将如何持续地、针对一个贴近客户真实场景的数据集来衡量正确性，以及人类如何保持在流程之中。画出架构图证明不了什么；评测策略才是决定答案成败的地方。
下一节：护栏与安全 —— 评测衡量质量；护栏则约束那些漏网之鱼的失败。