第 12 章：Eval Case Schema 与样本设计
第 12 章：Eval Case Schema 与样本设计
12.1 Case 不是一个问题
同一句用户输入，在不同上下文中可能有完全不同的正确行为。
用户说：“帮我改一下退款账户。”
如果用户已经完成身份校验，订单属于本人，退款流程允许修改账户，那么 Agent 可以引导用户进入账户修改流程。
如果用户没有通过身份校验，Agent 必须先验证身份。
如果用户试图修改他人订单的退款账户，Agent 必须拒绝。
如果订单已经退款完成，Agent 应解释当前状态，而不是继续调用修改工具。
如果系统没有账户修改工具，Agent 应转人工或说明限制。
因此，Eval Case 不是一个简单的 query。它是评测执行的最小结构化单元，必须包含输入、上下文、环境、可用工具、期望行为、评分规则和风险约束。
没有结构化 Case，就无法自动化执行、无法复现、无法归因，也无法把线上 Bad Case 沉淀为长期资产。
12.2 一个好 Case 的基本要求
一条可用的 Eval Case 至少要满足六个条件。
| 条件 | 说明 |
|---|---|
| 可执行 | 系统能根据 Case 自动构造输入、环境和工具配置 |
| 可评判 | 有明确期望行为、Rubric 或可执行校验器 |
| 可复现 | 记录模型、数据、工具、知识库和环境版本依赖 |
| 可归因 | 保存中间证据、工具返回、Trace 或状态变化 |
| 可维护 | 有版本、Owner、审核状态和变更记录 |
| 可决策 | 标注风险等级、指标归属和门禁影响 |
只包含“用户问题”和“参考答案”的样本，最多适合做简单问答评测。对于企业级 LLM / RAG / Agent 应用，它远远不够。
12.2.1 Case ID 和版本规范
Case 一旦进入评测体系，就应具备稳定标识。稳定标识不是为了形式整齐，而是为了支持回归、归因、报告和审计。
推荐的 case_id 可以包含业务域、能力域、场景和序号：
refund_rag_member_points_001
refund_tool_partial_amount_003
privacy_redteam_order_lookup_002
命名中不要放模型版本、Prompt 版本或临时实验名称。Case 描述的是业务评测对象，而不是某次运行。
版本字段应区分三层：
| 版本 | 说明 |
|---|---|
| case_version | 样本自身字段、期望行为或 Rubric 变化 |
| dataset_version | 样本所属数据集版本 |
| dependency_version | 知识库、工具 Schema、环境等外部依赖版本 |
例如，退款政策更新后，如果样本输入不变但期望行为变化，应更新 case_version，并记录关联知识库版本。否则历史分数变化无法解释。
12.3 通用 Eval Case Schema
不同评测对象的 Case 字段会有差异，但可以先定义一套通用骨架。
| 字段 | 说明 |
|---|---|
| case_id | 样本唯一标识 |
| title | 简短标题 |
| scenario | 业务场景 |
| user_task | 用户任务 |
| ability_tags | 能力标签 |
| risk_level | 风险等级 |
| difficulty | 难度 |
| source | 样本来源 |
| input | 用户输入或任务目标 |
| context | 对话历史、业务状态、外部证据 |
| environment | 工具、权限、知识库、沙箱等环境配置 |
| expected_behavior | 期望行为 |
| negative_behavior | 不允许出现的行为 |
| Rubric | 评分规则 |
| evaluator_config | Evaluator 配置 |
| metadata | 版本、Owner、审核状态等 |
可以用 YAML 表示一条通用 Case：
case_id: refund_eligibility_001
title: 签收超过 7 天但用户声称质量问题
scenario: 退款申请
user_task: 判断退款资格
ability_tags:
- 意图理解
- RAG
- 工具调用
- 业务规则
risk_level: P1
difficulty: Medium
source: 线上日志改写
input: "我这个耳机签收十天了，但有质量问题，能不能退？"
context:
order_status: "signed"
signed_days: 10
category: "耳机"
user_authenticated: true
environment:
knowledge_version: refund_policy_2026_07
tools:
- order_lookup
- refund_eligibility_check
expected_behavior:
- 识别用户不是普通 7 天无理由退货，而是质量问题售后。
- 查询订单和退款资格。
- 基于政策说明可能需要质检或人工审核。
- 不直接承诺立即退款。
negative_behavior:
- 直接拒绝退款并只引用 7 天无理由规则。
- 未查询订单就承诺退款。
- 跳过质检或人工审核。
rubric: refund_policy_faithfulness_v1
evaluator_config:
rule_checks:
- no_privacy_leak
judge:
rubric: refund_policy_faithfulness_v1
metadata:
owner: ai_eval_team
version: 1.0.0
review_status: approved
这不是唯一格式，但它展示了 Case 应该具备的结构深度。
12.3.1 字段分层：执行字段、评判字段、治理字段
Case 字段可以分为三类。
| 字段类型 | 作用 | 示例 |
|---|---|---|
| 执行字段 | 让系统能运行样本 | input、context、environment、available_tools |
| 评判字段 | 让 Evaluator 能判断结果 | expected_behavior、negative_behavior、Rubric、evaluator_config |
| 治理字段 | 让样本可维护、可审计 | source、risk_level、version、owner、review_status |
很多样本只包含执行字段，导致评测后无法判断结果。也有些样本有参考答案，却没有环境和工具配置，导致无法复现。企业级 Case 必须同时具备这三类字段。
对于客服 Agent，environment 尤其重要。用户是否已通过身份验证、订单是否属于本人、知识库版本是什么、退款工具是否可用，这些条件都会改变正确行为。
12.3.2 Case 是执行器、Evaluator 和报告之间的契约
Case Schema 的价值不只是让样本字段更整齐。它实际上定义了三方契约。
第一，执行器需要知道如何运行 Case。它依赖 input、context、environment、available_tools、initial_state 等字段。如果这些字段缺失，评测只能退化成人工复制问题。
第二，Evaluator 需要知道如何判断 Case。它依赖 expected_behavior、negative_behavior、rubric、evaluator_config、risk_level 等字段。如果这些字段含糊，Judge、脚本和人工会用不同标准评判。
第三，报告和归因系统需要知道如何解释 Case。它依赖 scenario、ability_tags、source、version、owner、dataset_split 等字段。如果这些字段不完整，版本报告只能展示总分，无法说明问题来自哪个场景、能力或风险。
| 使用方 | 依赖字段 | 字段缺失后果 |
|---|---|---|
| 执行器 | input、context、environment、tools | 无法自动运行或无法复现 |
| Evaluator | expected_behavior、negative_behavior、Rubric | 无法稳定判定结果 |
| 报告系统 | scenario、ability_tags、risk_level | 无法分层展示和支持决策 |
| 归因系统 | trace_requirement、evidence、versions | 无法定位失败来源 |
| 治理流程 | source、owner、review_status | 样本不可维护、不可审计 |
因此，一条 Case 写得是否完整，决定了后续自动化、归因、门禁和回流能否成立。Case 不是数据表字段集合，而是评测系统协作的最小协议。
12.4 LLM 能力 Case
LLM 能力 Case 用于评估基础模型或 Prompt 在给定输入下的输出质量。
典型字段：
| 字段 | 说明 |
|---|---|
| input | 用户输入或任务指令 |
| context | 参考上下文，可为空 |
| reference | 参考答案或期望要点 |
| constraints | 格式、语气、长度、安全边界 |
| Rubric | 评分维度 |
| generation_config | Temperature、Top-p、最大长度等 |
示例：
case_id: llm_instruction_001
scenario: 政策解释
input: "请用三句话解释什么情况下不能 7 天无理由退货。"
context:
policy_excerpt: "拆封后影响二次销售的商品不适用七天无理由退货..."
constraints:
format: "三句话以内"
must_include:
- "拆封影响二次销售"
- "定制商品"
- "超过时效"
rubric:
- 政策正确性
- 表达清晰度
- 格式遵循
LLM Case 的关键是控制输入和期望输出边界。它适合评估模型能力，但不适合单独证明业务系统可上线。
12.5 RAG Case
RAG Case 必须保存证据链。否则答案错了时，无法判断是检索错、证据错、上下文错，还是生成错。
典型字段：
| 字段 | 说明 |
|---|---|
| query | 用户问题 |
| gold_evidence | 期望召回的证据片段 |
| corpus_version | 知识库版本 |
| retrieved_chunks | 实际召回结果 |
| context_policy | 上下文拼接策略 |
| expected_answer | 期望回答要点 |
| citation_requirement | 是否必须引用证据 |
| metrics | 召回、忠实度、引用准确率等 |
示例：
case_id: rag_refund_policy_014
scenario: 退款政策问答
query: "耳机拆封后还能七天无理由退吗？"
corpus_version: refund_policy_2026_07
gold_evidence:
- doc_id: refund_policy_audio_003
passage_id: p12
required: true
expected_answer:
- 说明拆封后影响二次销售通常不适用七天无理由。
- 如果存在质量问题，应进入售后质检流程。
metrics:
- evidence_recall_at_5
- faithfulness
- citation_accuracy
RAG Case 的重点不是只看最终回答，而是把证据召回、证据使用和最终生成分开评。
12.6 Tool Case
Tool Case 用于评估模型是否在正确时机选择正确工具，并生成正确参数。
典型字段：
| 字段 | 说明 |
|---|---|
| user_goal | 用户目标 |
| available_tools | 可用工具列表 |
| tool_schema | 工具参数定义 |
| state | 当前业务状态 |
| expected_tool | 期望工具 |
| expected_args | 期望参数 |
| expected_result_usage | 工具返回结果应如何被使用 |
| side_effect_policy | 是否允许副作用 |
示例：
case_id: tool_refund_check_008
scenario: 退款资格校验
user_goal: "帮我看看这个订单能不能退"
state:
user_authenticated: true
order_id: "ORDER_123"
available_tools:
- order_lookup
- refund_eligibility_check
- refund_submit
expected_tool_sequence:
- order_lookup
- refund_eligibility_check
expected_args:
order_lookup:
order_id: "ORDER_123"
refund_eligibility_check:
order_id: "ORDER_123"
negative_behavior:
- 未校验资格直接调用 refund_submit
- 使用空订单号或错误订单号
Tool Case 的评判应尽量使用脚本和状态校验，而不是只依赖 Judge 主观判断。
12.6.1 副作用工具的 Case 要更严格
查询类工具和提交类工具不能用同一套 Case 要求。提交退款、创建投诉工单、修改账户、取消订单等工具会改变真实业务状态，Case 必须增加副作用约束。
副作用工具 Case 应包含：
| 字段 | 说明 |
|---|---|
| precondition | 调用前必须满足的条件 |
| confirmation_required | 是否需要用户二次确认 |
| idempotency_key | 幂等键或去重机制 |
| allowed_state_transition | 允许的状态变化 |
| forbidden_state_transition | 禁止的状态变化 |
| audit_requirement | 审计记录要求 |
示例：
side_effect_policy:
tool: refund_submit
precondition:
- user_authenticated: true
- refund_eligibility: approved
- user_confirmed: true
confirmation_required: true
idempotency_key: order_id + item_id + refund_request_id
allowed_state_transition:
from: refund_not_started
to: refund_submitted
forbidden_state_transition:
- submit_without_identity
- submit_duplicate_refund
audit_requirement:
- operator
- timestamp
- tool_args
- user_confirmation
这类字段决定 Tool Case 是否具备发布门禁价值。
12.7 Agent Case
Agent Case 是最复杂的 Case，因为它要描述目标、环境、工具、初始状态、过程要求和终态标准。
典型字段：
| 字段 | 说明 |
|---|---|
| goal | 用户最终目标 |
| initial_state | 初始业务状态 |
| environment | 可用工具、权限、知识库、沙箱 |
| interaction | 单轮或多轮用户输入 |
| trace_requirement | 需要记录哪些轨迹字段 |
| success_criteria | 成功标准 |
| failure_criteria | 失败标准 |
| safety_constraints | 安全和权限边界 |
| final_state_check | 终态校验方式 |
示例：
case_id: agent_refund_account_change_002
scenario: 退款账户修改
goal: "用户要求查询退款进度并修改收款账户"
initial_state:
user_authenticated: false
order_owner: current_user
refund_status: processing
environment:
tools:
- identity_verify
- refund_status_lookup
- account_change_request
permissions:
account_change_requires_identity: true
interaction:
- role: user
content: "我退款还没到账，顺便帮我把收款账户改成这个新的。"
success_criteria:
- 先要求并完成身份校验。
- 查询退款进度。
- 说明账户修改条件。
- 仅在满足权限条件后发起账户修改请求。
failure_criteria:
- 未校验身份就调用账户修改工具。
- 泄露账户敏感信息。
- 承诺无法保证的到账时间。
trace_requirement:
required_fields:
- action
- tool_call
- observation
- state_change
- final_state
Agent Case 的重点是过程和终态。最终回答看起来正确，不代表 Case 通过。
12.7.1 Agent Case 的环境保真度
Agent Case 的难点不只是输入复杂，而是环境会影响行为。一个在模拟环境中通过的 Agent，可能因为真实工具返回、权限策略、缓存或延迟不同而失败。
环境保真度至少要检查：
| 环境项 | 检查问题 |
|---|---|
| 工具返回 | 是否模拟真实错误码、空值、超时和边界值 |
| 权限策略 | 是否与线上身份核验和角色权限一致 |
| 业务状态 | 订单、退款、积分等状态是否真实可变 |
| 知识版本 | 是否绑定具体文档和索引版本 |
| 延迟与失败 | 是否模拟工具慢响应和失败重试 |
| 审计日志 | 是否保留工具调用和状态变更记录 |
客服 Agent 的退款工具如果在评测中总是返回成功，就无法覆盖真实线上常见的“订单状态不满足退款条件”“工具超时”“优惠券规则无法计算”等情况。这样的 Case 会高估 Agent 能力。
12.8 业务应用 Case
业务应用 Case 更接近真实验收。它不仅看 Agent 的行为，还看业务结果和用户旅程。
典型字段：
| 字段 | 说明 |
|---|---|
| business_scenario | 业务场景 |
| user_journey | 用户完整路径 |
| sop | 业务流程要求 |
| policy_constraints | 政策和权限约束 |
| service_level | 响应时效和体验要求 |
| business_success | 业务成功标准 |
| audit_requirement | 审计和合规留痕 |
业务应用 Case 适合用于发布门禁、灰度验收和高价值端到端回归。
客服 Agent 的业务应用 Case 可能要求：
- 用户问题在三轮内得到可执行结论。
- 如需工具操作，必须先完成身份校验。
- 如遇政策例外，必须解释原因并提供下一步。
- 涉及投诉升级时，必须按 SOP 转人工。
- 全程不得泄露他人订单和隐私信息。
- 最终 Trace 必须可审计。
12.9 Case 设计中的常见反模式
12.9.1 只有问题，没有上下文
没有上下文的 Case 很容易误判。用户说“这个还能退吗”，如果不知道商品、签收时间、拆封状态和质量问题，就无法判断正确答案。
12.9.2 只有参考答案，没有期望行为
Agent 应用不只生成答案，还可能调用工具、改变状态、转人工或拒绝。只写参考答案，无法覆盖过程行为。
12.9.3 只写正向行为，不写禁止行为
高风险 Case 必须写 negative_behavior。比如“不得跳过身份校验”“不得承诺一定到账”“不得查询他人订单”。
12.9.4 Case 和 Evaluator 脱节
如果 Case 没有标明评估方式，后续很容易被错误评估器处理。工具参数应由脚本校验，开放解释可由 Judge 评估，高风险样本应人工复核。
12.9.5 Case 无版本
业务规则变化后，旧 Case 需要修正。如果没有版本，历史分数就无法解释。
12.9.6 Case 无审查流程
Case 不是写完就能进入核心评测集。尤其是高风险样本，需要经过审查：
- 业务语义是否真实。
- 上下文是否足够支持判断。
- 期望行为是否唯一或边界清楚。
- 禁止行为是否覆盖关键风险。
- Evaluator 是否能可靠判断。
- 版本和 Owner 是否完整。
审查流程可以避免两类问题：一类是样本本身不清楚，导致模型、Judge 和人工都难以判断；另一类是样本看似合理，但实际业务规则已经变化。
审查结论也要结构化记录。至少包括：
| 字段 | 说明 |
|---|---|
| reviewer | 审查人或审查角色 |
| review_result | approved / rejected / needs_revision |
| issue_type | 上下文不足、Rubric 不清、政策过期、Evaluator 不可靠等 |
| required_fix | 需要补充或修改的内容 |
| approved_for | 可进入 Golden、Regression、Hard Case、Red Team 或仅人工复核 |
这让 Case 审查从口头确认变成可追踪流程。高风险 Case 尤其需要这种记录，因为它们会进入发布门禁和合规证据链。
12.9.7 Case 过度依赖标准答案
开放式回答不适合只用标准答案。客服 Agent 可以用不同表达完成同一任务。更稳妥的方式是定义期望行为和禁止行为。
例如，会员部分退款场景的期望不是背诵固定话术，而是：
- 识别为金额权益高风险问题。
- 说明需要结合订单明细、优惠券和积分规则。
- 调用退款规则工具或转人工。
- 不承诺具体退款金额和积分结果。
这样 Case 可以允许不同表达，同时保持质量边界。
12.10 交付物一：通用 Eval Case Schema
| 字段 | 类型 | 必需 | 说明 |
|---|---|---|---|
| case_id | string | 是 | 全局唯一 |
| title | string | 是 | 简短标题 |
| scenario | string | 是 | 业务场景 |
| user_task | string | 是 | 用户任务 |
| ability_tags | list | 是 | 能力标签 |
| risk_level | enum | 是 | P0 / P1 / P2 / P3 |
| difficulty | enum | 是 | Easy / Medium / Hard / Hard Negative / Adversarial |
| source | string | 是 | 来源 |
| input | object | 是 | 用户输入或任务目标 |
| context | object | 否 | 对话、证据、业务状态 |
| environment | object | 否 | 工具、权限、知识库、沙箱 |
| expected_behavior | list | 是 | 应该发生什么 |
| negative_behavior | list | 建议 | 不允许发生什么 |
| Rubric | string | 是 | 评分规则 |
| evaluator_config | object | 是 | 评估器配置 |
| metadata | object | 是 | 版本、Owner、审核状态 |
12.11 交付物二：专项 Case Schema
| Case 类型 | 必备扩展字段 |
|---|---|
| LLM Case | reference、constraints、generation_config |
| RAG Case | corpus_version、gold_evidence、retrieved_chunks、citation_requirement |
| Tool Case | available_tools、tool_schema、expected_tool_sequence、expected_args |
| Agent Case | initial_state、trace_requirement、success_criteria、failure_criteria、final_state_check |
| 业务应用 Case | user_journey、sop、policy_constraints、business_success、audit_requirement |
专项 Schema 不是互相排斥的。一个复杂业务 Case 可能同时包含 RAG、Tool 和 Agent 字段。
12.12 本章小结
Eval Case 是评测执行的最小结构化单元。它不是一个问题，也不是一条参考答案，而是一组足以支持执行、评判、复现、归因和维护的信息。
本章给出的 Schema 解决三个问题：
- 让样本可以被自动化执行。
- 让评测结果可以被解释和归因。
- 让线上 Bad Case 可以沉淀为长期资产。
有了评测样本，下一章我们来解决"怎么判"的问题——Evaluator 如何设计，规则、脚本、Judge 和人工各适合评判什么。