如何为业务AI系统构建场景化评测集

构建场景化评测集，应先锁定一个边界清晰的业务流程和评测要支持的决策，再把真实工作重建为可复现、可评分、能暴露边界的案例。设想一套采购申请助手收到看似完整的申请：供应商编号前后冲突，当前政策检索失败，报价附件还夹带了要求助手绕过规则的指令。几条措辞漂亮的示例提示无法回答真正的问题——系统会不会说明证据不足、拒绝越权、保留待审批状态，并把问题交给正确的人。只有把普通工作、关键边界、已知故障和禁止行为共同纳入覆盖图，平均分才不至于掩盖重要失败。

场景化评测集究竟应该覆盖什么？

它应该以一张工作流覆盖图为骨架：按可信的实际工作构成覆盖日常任务，同时有意加入关键边界、经确认的历史故障和明确禁止的行为。第一步不是罗列“通用助手能力”，而是写清被测系统版本、允许使用者、输入范围、知识库、工具、权限、上下游状态，以及结果将服务于提示词迭代、候选方案比较还是发布决定。评测切片、禁止行为门槛和决策规则也要在生成或查看输出前确定，避免团队看到有利结果后才挑选计分标准。

对采购申请助手而言，普通案例可以是字段一致、材料齐全且当前政策可访问的申请；边界案例则包括缺少必要附件、金额或供应商编号冲突、决定下一步所需事实不在授权证据中，以及政策工具返回过期或互相矛盾的内容。禁止行为应覆盖要求助手自行批准、绕过人工关口、泄露其他申请人或供应商信息，以及附件中的指令试图改变系统规则。历史故障只有在事实和预期行为核实后才进入回归集；真实材料还要经过授权审查和必要的数据最小化。这里的采购规则仅为组织特定的示例，不能照搬为通用政策。

每个评测场景怎样记录，别人才能复现？

每个场景都应成为一条能被另一名评测者重建的案例记录，而不是只有提示词和“理想答案”的孤立样本。记录首先要有稳定案例编号、负责人、状态、版本历史、覆盖类别、任务类别、切片标签、后果等级、来源类别、授权记录和预定数据集归属。随后再还原执行条件：角色与目标、初始流程状态、申请内容和附件、相关历史、系统指令、可访问知识、工具、权限、预置工具结果及环境条件。这样，系统失败与测试环境缺件才不会被混为一谈。

• 身份与来源：案例编号、所有者、变更历史、任务和覆盖类别、切片、后果、来源类别、授权依据及开发集或受保护发布测试归属。
• 测试设置：参与者角色、目标、初始业务状态、请求与文件、对话历史、系统约束，以及当次可用的知识、工具、权限和工具返回结果。
• 结果约束：必须出现的事实或状态变化、可接受的替代措辞或路径，以及证据不足时应当澄清、暂缓、拒绝或升级的条件。
• 评测操作：禁止输出、披露、工具调用和状态变化，评分器类型、量规与门槛、参考解、多次试验及汇总规则，还有模型、提示词、知识库、工具、策略和评测框架版本。

开放式任务通常不应被压缩成一段唯一标准话术。采购助手可以用不同措辞指出缺少报价文件，只要引用的事实正确、没有假装完成审批，并把申请留在正确状态；如果存在多条获准路径，案例应逐项写出可接受替代方案。已知可行的参考解可以证明任务能完成，也能帮助发现评分器遗漏，但它不是排斥其他合法答案的模板。对具有随机性或多步骤执行的系统，如需重复试验，应在查看结果前写明试验次数和汇总规则，同时保存评审者资格、校准版本、裁决路径及未解决分歧。

好案例不只是提出一道难题，而是重建一段有边界的工作，让成功、合理差异和禁止行为都能被检查。

ModelFold编辑部

怎样评分，才不会奖励错误行为？

应为每个场景选择能够有效区分成功与失败的最窄评分方法，并把明确禁止的动作放在不可补偿的独立门槛中。客观可验证的字段、计算、结构、工具参数、记录状态或越权调用，优先采用确定性检查；但检查本身也可能遗漏条件，因此要用已知可行的执行结果证明案例确实可解，并检查失败输出有没有利用评分漏洞。若任务允许多种措辞或步骤，评分重点应落在最终事实、必要状态和实质约束，而不是偶然的文字表面或唯一轨迹。

• 确定性检查适合答案、结构、计算、工具参数、业务状态和禁止动作均可客观验证的场景，但仍要审查检查项是否完整。
• 参考事实或参考解适合证据和终态有边界、表达与路径可以变化的任务；参考内容用于证明可解并列出必要要素。
• 带可观察锚点的分维量规适合有真实开放性的质量，如完整性、可用性、依据充分程度和解释清晰度；不同维度应分别描述。
• 合格专家判断适合需要领域解释或后果无法由自动检查有效处理的任务；受监管决定仍须留给具备资格和授权的角色。

部分得分可以显示系统完成了哪些有意义的组成部分，例如识别出材料缺失却没有给出正确的下一步，但它不能掩盖禁止披露或未授权操作。具体门槛及其发布后果应由产品和风险责任人结合业务后果预先确定，不能从通用文章中套用。模型评分器也不因在开发样例上与人工一致就自动获得可信度；它需要清晰量规、正反示例，并在相关业务情境中与合格评审者校准。OpenAI对GDPval的说明同样指出，其自动评分器不足以替代有经验的职业评审者。量规版本、门槛逻辑、切片、汇总和决策规则一旦改变，应形成新的评测版本。

怎样让不同评审者稳定地使用同一套标准？

一致评审依赖一份简短但可执行的评审指南，以及正式评分前的校准，而不是只把分值名称发给评审者。展示系统输出前，指南应说明流程目的、角色、当时可用证据、允许行为、产品边界和量规版本。每个分值都要绑定可观察的现象，并提供正例、反例和边界例；如果案例缺少必要材料、工具环境损坏或预期结果尚无业务决定，还要允许评审者选择“证据不足”或“无法评分”，避免被迫给出虚假判断。

1. 先用校准案例讨论标准；任务构成、策略、量规或评审人员发生实质变化后重新校准。
2. 做候选系统比较时，在可行情况下隐藏系统身份并调整输出顺序，减少品牌和顺序线索。
3. 让评审者先独立提交分数与理由，再进入讨论，避免较早发言者替代独立判断。
4. 把分歧分类为案例缺陷、阈值不清、背景缺失、合法多解或尚未完成的产品决定。
5. 指定裁决负责人，并保存原始标签、理由、量规版本和裁决结果，供复盘及评分器再校准。

分歧不是必须消灭的噪声，而是一种诊断证据。两名评审者若因申请材料本身互相冲突而得出不同结论，修复方向可能是补全案例；若两种处置在流程中都合法，就应更新可接受结果，而不是强迫一方改分；若争议来自“何时必须人工升级”尚未确定，则应交还产品或风险责任人作出明确决定。检查输出、执行轨迹和评分理由，可以进一步区分真实系统失败与评分器、案例或环境故障。完整流程是可调整的编辑综合，不代表每项任务都需要相同人数、相同裁决层级或强制共识。

评测集怎样在持续开发和正式发布中保持有用？

要让评测证据长期有用，必须把反复可见的开发集与受保护的发布测试分开，并用版本化登记表管理案例暴露、重复和变更。开发集可以频繁用于调整提示词、检索、工具、策略和工作流，也应容纳快速代表性检查与已知故障回归；但团队已经看过并针对这些案例优化，所以其成绩只能说明开发进展。受保护发布测试应在案例入库、例行运行和输出筛选之前确定归属，严格限制访问，并只在最终比较或发布决定等明确场合审慎使用。

• 跨数据集检查完全重复、近似重复、共同来源记录、改写版本及同一场景模板生成的“兄弟案例”。
• 记录人员和自动化流程对案例正文、参考答案、量规及评测结果的访问，不能只保护输入文件。
• 已用于诊断或修复的确认故障应进入开发或回归证据；发布测试只能用独立创建且未指导修改的同类新案例。
• 受保护案例一旦实质影响系统修改，就将其转入开发或回归集，并通过新版本补充未暴露的替代案例。
• 登记案例负责人、来源、授权、归属、暴露、内容与标签版本、复核历史、变更理由及退役理由。

维护不是机械地按固定周期换题。流程、用户群体、政策、知识库、模型、提示词、工具、权限或运行环境发生实质变化时，应重新审视覆盖图、评分器和发布门槛；经核实的新故障可以在最小化敏感信息后加入评测。结果除了总体摘要，还应按任务类别、覆盖类别、业务切片、后果和门槛分别报告，因为相同平均分可能对应完全不同的失败结构。这里没有通用案例数、切分比例或刷新间隔：规模和构成取决于评测支持的决定、流程差异、重要切片、评分可靠性和可合法获得的证据。

评测集最终是一组可审计的决策证据，而不是安全或上线证书。产品与风险责任人应在查看结果前说明门槛及使用方式，领域专家负责核对流程现实性和预期结果；当案例涉及受治理的数据或判断时，数据、隐私、安全、法务、合规及其他合格职能应按职责参与。法律、医疗、金融、用工、安全、网络安全、隐私等受监管决定必须保留给具备相应资格和授权的人员。一次离线通过也不能单独证明业务价值、安全、公平、合规或生产就绪，还需要结合上线监测、用户研究、事件复盘和与系统后果相称的其他证据。