两个模型都能写出流畅答案，一个在公开知识问答中分数更高，另一个却更擅长公司的客服流程。哪个“效果更好”？如果没有说明用户、任务、数据和成本，这个问题没有完整答案。
生成式AI的输出不是固定标签。摘要可以有多种正确写法，客服回复既要回答问题又要符合业务边界，智能体还要选择工具、填参数并真正完成操作。一个总分很难同时表示这些差异。
有效的评估体系更像软件测试与实验设计的结合：先定义任务成功，再准备有代表性的数据，用不同评分器检查不同层面，保留失败样本，并把离线结果连接到真实用户行为。
## 评估从任务契约开始
“回答准确”过于模糊。以产品问答为例，任务契约应说明允许使用哪些知识、是否必须引用来源、答案最长多少、信息不足时如何回应，以及哪些问题必须转人工。
契约还要定义输入分布。用户可能只问一句短问题，也可能粘贴长日志；可能使用标准产品名，也可能用错别字和内部简称。测试数据若只包含整齐问题，分数无法代表真实使用。
每项要求都应对应可观察结果。事实是否由来源支持、工具参数是否正确、最终状态是否改变、时延是否达标，都可以分别检查。先把成功拆成部件，后续分数才有解释力。
## 为什么公开榜单不能替代自己的测试集
公开基准适合比较通用能力，也能帮助发现模型的知识、推理或语言短板。HELM研究主张在多场景、多指标下评估模型，并公开提示与输出，正是为了避免用单一成绩概括复杂系统。
然而，企业任务的字段、规则和错误代价通常不在公开数据里。一个模型可能擅长考试题，却会混淆公司的两个套餐；也可能在平均分上略低，却在短答案和固定格式任务中更稳定。
因此，评估数据至少应有三层。第一层是日常高频样本，反映主要流量；第二层是边界与对抗样本，包含歧义、信息缺失、长上下文和冲突指令；第三层是近期真实失败，经过去除敏感信息后持续加入回归集。
测试集要锁定版本。题目、参考答案、评分规则或检索知识一旦变化，应产生新版本，不能把不同版本的分数直接画在同一条趋势线上。
*可靠评测先固定输入、配置和评分条件，再比较模型；否则差异可能来自测试环境，而不是模型能力。*
## 先用确定性检查抓住低成本错误
能用程序精确判断的要求，不必全部交给另一个大模型。JSON是否能解析、必填字段是否存在、数值是否在范围内、引用链接是否可访问、工具调用是否成功，都适合确定性检查。
分类、抽取和代码任务也可以使用准确率、F1、执行结果或单元测试。对于可能有多个正确表达的文本，可先检查关键事实与格式，再评价完整性和表达质量。
确定性指标的优点是便宜、快速、可复现，适合每次代码或提示更新时运行。它们不能评价所有开放式质量，却能把大量基础错误从人工审核中移走。
## 开放式回答需要评分量表
让评审者直接打“好或不好”，不同人会使用不同标准。更稳定的方法是写出分维度量表，例如事实一致性、任务完成度、相关性、清晰度和不确定性表达，并为每个等级提供正反例。
比较两个候选时，成对选择通常比独立打绝对分更容易。评审者可以回答“哪一个更符合这条标准”，同时记录平局和两者都失败。
样本顺序应随机，模型名称应隐藏。否则先出现的答案、品牌印象和回复长度都会影响判断。对关键样本可以让两名评审者独立标注，再检查一致率并讨论分歧。
## 模型裁判有用，但不是最终真相
强模型可以按照量表批量评审开放式回答，大幅加快迭代。MT-Bench与Chatbot Arena研究表明，模型裁判在不少场景中能接近人类偏好，同时也存在位置偏差、偏爱冗长回答和自我偏好等问题。
使用模型裁判时，应随机交换候选顺序，要求引用具体证据，并用一组人工标注样本校准。若裁判换版本或提示改变，历史分数不能默认仍可比较。
高影响错误和模型之间分差很小的样本仍需人工复核。模型裁判适合扩大评测覆盖面，不适合把评估责任完全转交给另一个不透明模型。
## RAG必须分开检查检索与生成
检索增强生成系统可能在两个地方失败：没有找到正确资料，或已经找到资料却生成了错误答案。只给最终回复打分，无法知道应该调整索引、重排器还是提示词。
检索层可以检查目标文档是否进入前若干结果、相关片段排序和无关片段比例。生成层则检查答案是否忠于检索上下文、是否覆盖问题、有没有加入来源中不存在的事实。
RAGAS等研究框架正是把上下文相关性、回答忠实度和回答质量拆开评估。自动指标可以用于快速筛选，但重要结论仍应回看原始问题、检索片段与回复三者的对应关系。
知识库更新后要重新运行测试。答案变差可能不是模型退步，而是文档切分、版本标签或索引刷新出了问题。
*分段评测能把“回答不好”变成可行动的故障定位：是资料没找到、模型没用好，还是评分规则不清。*
## 智能体评测要看最终环境状态
智能体可能说“预约已经取消”，但后台记录并未改变。评价这类系统不能只看最后一句自然语言，而要检查它是否选择正确工具、提供正确参数、处理错误返回，并使环境达到预期状态。
一个任务可以拆成规划、工具选择、参数、执行、恢复和最终说明。步骤不必与参考路径完全相同，只要没有越权、成本合理且最终状态正确，就可能是有效方案。
同时要注入故障：接口超时、字段变化、权限不足、工具返回空结果。可靠智能体应停止、重试或请求人工帮助，而不是编造成功。
## 把质量、速度和成本放在同一视图
模型质量提升往往伴随更长上下文、更复杂检索或多次调用。评测如果只看答案分数，可能选出线上无法承担的方案。
每次运行应记录首字延迟、总时延、输入与输出量、模型调用次数、检索次数和失败重试。对智能体，还要记录完成一个任务的总步骤和工具成本。
比较方案时使用“每个成功任务的成本”比单纯的每百万token价格更贴近现实。一个便宜模型若需要多次重试，最终未必更省。
## 分数需要统计不确定性
在一百道题上从82分升到84分，可能只是样本波动。应尽量在相同样本上做配对比较，并报告置信区间或通过重复采样估计不确定性。
生成具有随机性。对关键开放式任务可以用相同配置重复多次，观察平均表现与最差表现。只跑一次，会把一次幸运输出当成稳定能力。
还要按任务类型、语言、长度和难度分组。总体分数上升但长文本任务明显下降，发布风险仍然存在。
## 离线评测与线上反馈各自回答什么
离线测试适合在发布前快速比较模型、提示和检索配置，能够固定变量并复现错误。线上试验则能看到真实用户是否完成任务、是否重复提问、是否转人工和是否放弃。
线上指标也可能被误读。回复更短会降低时延，却可能让用户再次询问；转人工率下降，可能是问题解决得更好，也可能是用户直接离开。指标之间需要成组观察。
上线应从小流量开始，并保留回退版本。新系统产生的失败样本经过审核后加入离线集，形成“线上发现、离线复现、修复回归”的闭环。
## 建立体系的六个步骤
第一步写任务契约，把成功、禁止行为和不确定时的处理方式变成可测试要求。
第二步建立版本化数据集，覆盖高频、边界和近期失败，并隔离真正的最终测试集。
第三步优先实现确定性评分，再为开放式维度设计量表、模型裁判与人工复核。
第四步固定模型、提示、温度、工具、知识库和执行环境，保存原始输入输出，而不只保存汇总分。
第五步设置发布门槛。关键任务不能回退，严重错误数必须为零或低于明确阈值，成本与时延也要在范围内。
第六步连接线上指标，持续把新失败变成测试样本。评估体系不是上线前的一份报告，而是长期质量基础设施。
## 三个常见误区
第一个误区是追求一个总分。总分适合排序，不适合诊断；必须保留分任务结果和具体失败样本。
第二个误区是把模型裁判当作客观标尺。裁判也有版本、提示和偏差，需要人工样本校准。
第三个误区是只测正常输入。真正决定系统可靠性的，往往是歧义、空结果、工具失败和分布变化。
## 结语
生成式AI效果评估的核心不是找到一个神奇指标，而是建立一条证据链：任务要求可以观察，测试数据代表真实使用，评分方法与维度匹配，差异带有统计范围，失败能够定位，线上结果可以回流。
当团队能回答“在哪类样本上改善、为什么改善、付出多少成本、出现什么新错误”，评估才真正帮助决策。一个漂亮的总分只能告诉人们谁排在前面，完整体系则能告诉工程团队下一步应该改哪里。
## 参考资料