“这个新提示词感觉好多了”“换了模型之后好像更准了”，如果你的团队经常这样讨论，说明还缺少一个关键工具：评测集。没有评测集，每一次修改提示词、更换模型、调整检索策略，都只能依靠看几个例子的主观印象来判断，很容易顾此失彼。 构建评测集听起来像是大工程，但实际上从几十条样本开始就能发挥作用。

为什么评测集如此重要

  • 客观比较：用同一组数据比较不同方案，结论更可靠；
  • 防止退化：修复一个问题的同时，及时发现是否引入了新问题；
  • 加快迭代：自动化评测让每次修改都能快速得到反馈；
  • 支持决策：选择模型、决定是否上线、评估是否需要微调，都有数据依据；
  • 沟通共识：评测集本身就是团队对“什么是好的输出”的共同定义。

第一步：收集样本

从真实数据出发

最有价值的样本来自真实用户的输入。如果产品已经上线，从日志中抽样；如果尚未上线，可以请目标用户或业务人员写出他们会问的真实问题。避免只用开发人员自己想象出来的问题，它们往往过于规范和简单。

覆盖多种情况

一个好的评测集应包括：

  • 典型情况：最常见的输入类型，占比最高；
  • 困难情况：复杂、模糊、需要多步推理的输入；
  • 边界情况：超出能力范围、应该拒绝或转人工的输入；
  • 对抗情况：试图诱导系统犯错的输入，参见红队测试入门；
  • 历史问题：曾经出过错的真实案例。

从小规模开始

先收集 50 到 100 条样本，覆盖主要的输入类型。不要因为追求完美而迟迟不开始。评测集可以在使用中不断扩充。

第二步：定义标准答案或评分标准

有确定答案的任务

分类、信息抽取、事实问答等任务，可以直接标注标准答案，用程序自动比对。

开放式任务

摘要、写作、对话等任务没有唯一正确答案，需要定义评分标准，例如：

  • 必须包含的要点：回答中应该提到的关键信息；
  • 禁止出现的内容：错误信息、不当承诺、违规内容；
  • 质量维度：准确性、完整性、相关性、简洁性、语气是否恰当，每个维度定义清楚的评分细则。

评分标准越具体，评测结果越稳定。“回答好不好”是一个糟糕的标准；“是否正确引用了退货政策中的时限”是一个好的标准。

由领域专家参与

标准答案和评分标准应该由懂业务的人参与制定，而不仅仅是工程师。

第三步：选择评估方式

规则与程序评估

精确匹配、关键词检查、格式校验、数值比较等，速度快、成本低、结果稳定，适合有确定答案的任务。

大模型辅助评估

用一个大模型根据评分标准对输出进行打分或比较，适合开放式任务的大规模评估。需要注意其中的偏差，并定期与人工评估结果进行校准，详见 LLM-as-a-Judge。

人工评估

最可靠但成本最高。适合用于建立基准、校准自动评估方法和评估关键决策。

实践中通常组合使用：能用规则的用规则，开放式任务用大模型辅助，定期抽样人工复核。

第四步：针对系统的不同环节评测

对于复杂的应用，除了评估最终输出，还要评估中间环节：

  • RAG 系统：检索是否找到了正确的文档、回答是否忠实于检索内容，参见 RAG 评测正在变难；
  • Agent 系统：工具选择是否正确、参数是否正确、任务是否完成，参见 AI Agent 常见故障模式；
  • 多步骤流程：每一步的输出是否符合预期。

分环节评测能帮助快速定位问题所在。

第五步：融入开发流程

  • 每次修改都运行：修改提示词、更换模型、调整参数后，运行评测并与基线比较；
  • 自动化：把评测集成到持续集成中，效果下降时自动报警，参见提示词工程化；
  • 查看具体案例：不仅看总分，还要查看变好和变差的具体案例；
  • 持续扩充：线上发现的新问题、用户反馈的错误案例，修复后加入评测集；
  • 定期更新：业务变化后，及时更新过时的样本和标准答案。

常见误区

  1. 评测集太简单：只包含容易的样本，分数很高但无法反映真实表现；
  2. 在评测集上过度优化：针对评测集反复调整，导致在新数据上表现下降。可以保留一部分样本作为不参与调优的测试集；
  3. 只看平均分：平均分提高了，但某个重要类别的表现可能大幅下降；
  4. 一成不变：业务和用户行为在变化，评测集也需要更新。

小结

评测集是大模型应用从“凭感觉”走向“有数据”的基础。从几十条真实样本开始，覆盖典型、困难、边界和历史问题案例，定义具体的评分标准，组合使用规则、大模型和人工评估，并把评测融入每一次修改的流程中。评测集会随着产品一起成长，成为团队最有价值的资产之一。