AI产品评测集怎么做？可下载字段模板

30 秒答案：按 7 步设计 AI 产品评测集

步骤	先回答什么	最小关键字段	本步产物
1. 定义对象	谁在什么环境用哪一版系统完成什么任务？	systemUnderTest、userTask、context	可复现的评测范围
2. 收集样例	正常、边界、对抗和失败恢复场景是否都有真实代表？	caseId、input、dataProvenance、sliceTags	带来源和切片的样例集
3. 写明预期	什么行为必须出现，什么行为绝不能出现？	expectedBehaviors、prohibitedBehaviors、severity	可观察的通过与失败条件
4. 固定指标	用什么方法测量，方向和阈值是什么？	metricDefinitions、metricIds、humanReview	运行前冻结的评分规则
5. 运行评测	实际输出对应哪版模型、提示、检索、工具和数据？	actualOutput、系统与数据版本、逐指标结果	可追溯的单次运行记录
6. 分析失败	哪类失败集中在哪些场景和切片？	failureCategory、切片结果、证据位置	可分派的修复清单
7. 决定发布	严重失败、切片门槛和已知限制是否允许上线？	caseDecision、suiteGateRules、发布决定	上线、阻断、豁免或回滚记录

如果只做最小可用版本，也不要只保存“问题—答案”两列。至少保留任务与输入、上下文、预期与禁止行为、严重度、切片、指标、实际输出、失败类别和版本信息；否则结果很难复测，也无法判断总体平均分是否掩盖关键场景失败。

先把评测对象写清楚

评测集不是一批随手收集的提示词。第一步应记录产品帮助谁完成什么任务、在什么环境运行、调用哪些数据或工具、哪些用途明确排除，以及失败后由谁处理。相同模型放在不同权限、数据和人工流程中，风险与验收条件可能不同。

NIST AI RMF 把场景映射、测量和管理连接成持续过程，并要求记录测试集、指标、工具、部署条件和局限。本文把这些原则转成一个可编辑模板，但它不是标准或认证。

一个评测套件及其样例至少包含什么

层级	字段	要回答的问题
套件	systemUnderTest	本次结果对应哪一版模型、提示、应用、检索语料、嵌入模型、向量索引、工具、策略和配置？
套件	evaluationDataset	评测数据集的版本和内容哈希是什么？
套件	metricDefinitions	指标如何测量、比较和聚合，适用于哪些切片，最低样本量与缺失结果规则是什么？
套件	sliceDefinitions	哪些切片必须覆盖，如何纳入样例，最低覆盖数是多少？
套件	suiteGateRules	样例、切片和严重失败如何共同决定是否阻断发布？
样例	caseId	这条样例如何稳定引用和回归复测？
样例	userTask	用户真正要完成什么任务？
样例	input 与 context	系统会看到哪些输入、权限、资料和环境条件？
样例	expectedBehaviors	输出必须出现哪些可观察行为？
样例	prohibitedBehaviors	哪些行为一旦出现就算失败？
样例	severity	失败影响等级、默认是否阻断以及能否受控豁免是什么？
样例	sliceTags	它属于哪种语言、渠道、任务、用户或风险切片？
样例	dataProvenance	样例来自哪里、如何生成？
样例	consentOrLicense	使用数据的同意或许可依据是什么？
样例	metricIds	用哪些预先定义的指标判定？
样例	humanReview	谁按哪版量表何时复核，分歧如何裁决？
样例	caseDecision	固定规则计算的结果、阻断原因和受控豁免记录是什么？
样例	failureCategory	失败如何归类，以便统计和修复？

AI 产品评测集 JSON 模板包含空白结构、字段中文解释、常见平台字段映射和三条完全虚构的客服摘要样例。JSON Schema 校验文件用于检查填好的评测套件是否保留了必需结构；它只能检查结构和数据类型，不能证明样例、指标或门槛本身合理。

input、reference_output、actual_output、context 怎么放

不同平台使用的列名不完全相同，但常见交换表可以先用这一行 CSV 表头：

case_id,input,reference_output,actual_output,context,metadata_json,rubric_json,severity,slice_tags,failure_category

常见字段	本模板位置	使用判断
input	cases[].input	被测系统实际接收的输入；约束条件不能只写在测试说明里。
reference_output	cases[].referenceOutput	答案较确定时可保存参考答案；开放任务可以留空，改用 expectedBehaviors 保存可观察行为，不伪造唯一标准答案。
actual_output	cases[].actualOutput	每次运行产生的真实输出，不应提前写入评测题目。
context	cases[].context	RAG 文档片段、工具返回或其他允许使用的上下文；用于判断回答是否脱离依据。
metadata	sliceTags、dataProvenance、consentOrLicense	保存切片、来源与许可，不要把这些信息塞进自然语言输入后丢失结构。
rubric	metricDefinitions、metricIds、humanReview.rubricVersion	量表需要版本、测量方法、方向、阈值和适用范围，不能只有“好/不好”。

华为云 AgentArts 的官方文档用 input、reference_output 和运行时产生的 actual_output 说明基础比较关系，并在 RAG 防编造场景增加 context；文档也提醒字段应随评估器和评估目的变化。上述映射是本模板的互操作建议，不代表这些列名是跨平台统一标准。

样本量先按场景起步，再用失败分布修正

华为云 AgentArts 文档给出的平台实践起点是：每个业务场景先准备 30–50 条典型数据，同时覆盖正常、边界和对抗用例；上线后再把 Trace 中的真实 BadCase 回流到评测集。这里的 30–50 条不是通用统计结论，也不能替代功效分析、置信区间或高风险场景所需的更大样本。团队仍应按风险、切片数量、期望检测到的差异和可接受误差确定最终样本量。

用场景矩阵覆盖“会成功”和“会失败”

一个小型起步集可以至少覆盖：

1. 正常场景：典型输入能否完成核心任务；
2. 边界场景：输入缺失、冲突、模糊、过长或超出知识范围时是否保留不确定性；
3. 对抗场景：提示注入、越权请求或诱导性输入是否改变系统边界；
4. 失败恢复：工具超时、检索为空或格式错误时，能否安全失败并交给人工；
5. 重要切片：与真实部署相关的语言、渠道、用户群体、任务类型和风险等级。

Google PAIR 强调输入和训练数据应接近真实世界条件，不应只保留过度干净的数据，并说明测试集用于评估模型。本文据此建议产品评测集覆盖真实部署中的噪声与差异。哪些切片重要取决于具体产品；模板不会替团队决定总体代表性或法律要求。

在看到结果前固定指标和阈值

先写指标定义、测量方法、方向、单位和通过阈值，再运行模型。这样可以减少“看到结果后改口径”的空间。产品评测通常需要组合多类信号：

• 任务结果：必要事实、步骤或结构是否完成；
• 依据与真实性：关键陈述能否追溯到允许使用的输入或来源；
• 风险行为：是否出现禁止内容、越权动作、隐私泄露或无依据承诺；
• 人工评分：主观质量由什么量表、哪些复核人和怎样的一致性规则判断；
• 运行指标：延迟、失败率、工具成功率和单位任务成本；
• 切片结果：总体平均值是否掩盖某些场景的严重失败。

不同指标不能随意压成一个平均分。严重安全或权限失败可以作为独立阻断条件，即使总体任务成功率较高也不应被抵消。

把一次测试变成可复测记录

每次运行至少绑定模型、系统、提示、检索、工具和数据版本，保存实际输出、逐指标结果、人工判断、失败类别和证据位置。修改任何关键组件后，重新运行同一组核心样例，才能判断修复是否带来回归。

一个可核查的公开实例是 DragonAI 的千问、Kimi、Gemini RAG 与微调引用来源基准：它固定问题与重复次数，保留逐次运行来源 URL，并把失败、零引用和不可比较结果留在原分母中。这个实例展示的是如何保存评测证据，不代表发布评测集、页面被抓取或等待时间本身已经带来无品牌搜索可见性或 GEO 成功。

NIST AI RMF 的 Measure 部分强调客观、可重复或可扩展的测试、评估、验证与确认过程，并要求记录指标、方法和结果。生成式 AI Profile 进一步说明，组织可以根据系统或用例特征、风险容忍度、风险严重性和可用资源调整评测与风险管理方式。

发布决策不能只写“平均分通过”

模板把发布决定单独记录，至少包括：

• 阻断失败是否为零；
• 已知限制是否在界面和操作流程中被控制；
• 哪些结果必须人工确认；
• 上线后监测哪些信号；
• 什么条件触发降级、停用或回滚；
• 谁对当前版本作出批准，批准何时到期、何时复查。

Google 的负责任 AI 指导把公平、问责、安全和隐私列为需要结合产品实现考虑的维度。具体控制措施取决于部署环境，不能由一份通用模板自动给出。

最小执行顺序

1. 写清产品场景、用户、部署条件和排除用途；
2. 列出严重失败，再反推禁止行为和阻断规则；
3. 编写正常、边界、对抗、恢复和关键切片样例；
4. 在运行前固定指标、阈值与人工复核规则；
5. 绑定系统版本并运行，保存输出与证据；
6. 按失败类别修复并做回归测试；
7. 记录发布决定、已知限制、监测计划与回滚条件。

使用边界

公开模板只是起点。三条样例完全虚构，不包含真实客户数据，也不能证明任何模型达到上线标准。高影响场景还需要相应领域专家、隐私、安全、法律和受影响群体参与；通过有限测试集不等于系统在所有条件下都可靠。