评测（evals）是什么，怎么开始

它是什么

评测是把「模型输出好不好」变成可重复判断的一套流程：定义任务，写清判定标准，再用一批固定样本反复跑。它不是发论文用的排行榜，而是产品自己的体检表。

评测的对象可以是整条链路，也可以只测中间一步。对多数团队来说，先测最终答案是否解决了用户问题，比纠结某个内部环节的分数更实际。

怎么工作

第一步，定任务与判定标准。标准要能落到具体句子，例如「回答引用了给定材料里的条款，且没有编造材料外的规定」，而不是「回答得好」。标准模糊，后面所有分数都没有意义。

第二步，攒小样本金标。从真实请求里挑一批有代表性的输入，人工写好期望输出或通过条件，覆盖常见请求、边界情况与已知失败类型。样本小但贴业务，比大而泛的公开数据集有用。

第三步，选评分器。代码判定适合有唯一答案的场景：格式是否合法、字段是否齐全、计算是否正确。模型当裁判适合开放性回答，但必须校准。人工评分最贵，用来抽查前两者。

第四步，建立回归习惯。每次改提示词、换模型、调检索，都跑同一套样本，对比通过率与失败项的变化，而不是凭一次手工试用下结论。

离线回归与线上抽样要配合。离线保证改动不倒退，线上看真实流量里有没有新的失败模式。线上抽到的坏例子应当补进评测集，让它下次能被自动抓到。

怎么开始

从最小可用开始：先写一小批样本与通过条件，用代码评分器跑通流程，再逐步扩充。样本要保存输入、期望与判定理由，方便后面复盘。

常见误解

• 「平均分高就没问题」：平均分会掩盖分布。错的那部分如果都落在高风险场景，平均分再好看也不能上线。要看失败的是哪一类。
• 「评测集建一次就够」：产品在变，用户请求也在变。评测集不更新，就会慢慢测不到真正的问题。
• 「评分器越复杂越好」：能用代码判定的就不要上模型。规则清楚、可解释的评分器更容易维护。
• 「评测只是上线前的一道手续」：它的价值在持续回归，一次性验收只是其中一小部分。

想动手可以把评测接进日常流程，参考评估一次改动。分析失败分布时，先分清幻觉这类具体错误形态。