第 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 | 样本所属数据集版本 |
| Run 依赖版本 | 本次执行实际使用的知识库、工具 Schema、模型和环境版本 |
例如，退款政策更新后，如果样本输入不变但期望行为变化，应更新 case_version；如果只是把同一批 Case 重新编组，则更新 dataset_version；某次执行实际使用的知识库和工具版本由 Run 记录。三者不能压缩成一个含义不明的 version。
12.3 通用 Eval Case Schema
不同评测对象的 Case 字段会有差异，但可以先定义一套通用骨架。
通用骨架包含五组信息：身份与分类（case_id、场景、能力、风险、难度、来源），执行输入（input、context、environment），评判契约（期望行为、禁止行为、Rubric、Evaluator 配置），治理信息（版本、Owner、审核状态），以及专项对象的增量字段。完整类型和必填性统一放在 12.10，避免正文与交付物维护两份逐字段表。
可以用 YAML 表示一条通用 Case：
case_id: refund_eligibility_001
case_version: v3
dataset_id: refund_regression_set
dataset_version: v8
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_base: refund_policy
effective_at: 2026-07-08
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:
dataset_role: regression
tags:
- refund
- quality_issue
owner: ai_eval_team
review_status: approved
usage_rights_status: approved_for_evaluation
这不是唯一格式，但它展示了 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、usage_rights_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、case_version、dataset_id、dataset_version、metadata.owner、metadata.dataset_role 等字段。如果这些字段不完整，版本报告只能展示总分，无法说明问题来自哪个场景、能力或风险。治理流程还要读取 metadata.usage_rights_status，避免把来源可追溯误当作用途已经获得授权。
| 使用方 | 依赖字段 | 字段缺失后果 |
|---|---|---|
| 执行器 | input、context、environment、tools | 无法自动运行或无法复现 |
| Evaluator | expected_behavior、negative_behavior、Rubric | 无法稳定判定结果 |
| 报告系统 | scenario、ability_tags、risk_level | 无法分层展示和支持决策 |
| 归因系统 | trace_requirement、evidence、versions | 无法定位失败来源 |
| 治理流程 | source、owner、review_status、usage_rights_status | 样本不可维护、不可审计或用途越界 |
一条 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 定义期望证据和评判要求，一次执行的 Case Result 保存实际证据链。两者通过 case_id、case_version 和 run_id 关联，但不能写进同一个对象；否则下一次运行会覆盖上一次事实。
典型字段：
| 字段 | 说明 |
|---|---|
| input | 用户问题或检索任务输入 |
| gold_evidence | 期望召回的证据片段 |
| environment_requirements.corpus_version | Case 成立所需的知识语料版本 |
| context_policy | 上下文拼接策略 |
| expected_behavior | 期望回答与证据使用行为 |
| citation_requirement | 是否必须引用证据 |
| evaluation_metrics | 本 Case 要计算的召回、忠实度、引用准确率等指标 |
示例：
case_id: rag_refund_policy_014
case_version: v1
dataset_id: refund_rag_core_set
dataset_version: v3
scenario: 退款政策问答
input: "耳机拆封后还能七天无理由退吗？"
environment_requirements:
corpus_version: refund_policy_2026_07
effective_at: 2026-07-08
gold_evidence:
- doc_id: refund_policy_audio_003
passage_id: p12
required: true
expected_behavior:
- 说明拆封后影响二次销售通常不适用七天无理由。
- 如果存在质量问题，应进入售后质检流程。
context_policy: 优先使用当前生效政策；冲突时保留来源和生效时间
citation_requirement: 最终结论必须引用直接支持该结论的政策片段
evaluation_metrics:
- evidence_recall_at_5
- faithfulness
- citation_accuracy
执行后，实际召回片段、组装上下文、回答、引用和指标值进入 Case Result 与 Evaluation Result。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 契约的语义权威；配套《Eval Case Schema 工作表》是它的可填写实现，字段需与本节保持一致。若二者冲突，应修正工作表，不得形成第二套契约。第 7、8、14 章的专项 Case 只定义对应评测对象的增量字段。
| 字段 | 类型 | 必需 | 说明 |
|---|---|---|---|
| case_id | string | 是 | 全局唯一 |
| case_version | string | 是 | 当前 Case 契约版本 |
| dataset_id | string | 是 | 所属 Dataset 标识 |
| dataset_version | string | 是 | 所属 Dataset 版本 |
| 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 | string / object | 是 | 用户输入或结构化任务目标 |
| context | object | 否 | 对话、证据、业务状态 |
| environment | object | 否 | 工具、权限、知识库和沙箱的逻辑依赖或约束 |
| expected_behavior | list | 是 | 应该发生什么 |
| negative_behavior | list | 建议 | 不允许发生什么 |
| rubric | string / object | 是 | Rubric 标识或内联规则 |
| evaluator_config | object | 是 | 评估器配置 |
| metadata | object | 是 | 标签、Owner、审核状态和使用权状态 |
metadata 至少包含 dataset_role、tags、owner、review_status 和 usage_rights_status。其中 dataset_role 表示 Golden、Regression、Hard Case 或 Red Team 等用途；usage_rights_status 记录允许用途、访问范围、保留期限和审核状态，与第 11 章评测数据资产的权威元数据字段一致。case_version、dataset_id 和 dataset_version 使用独立字段，不再藏在 metadata.version 中。
environment 描述 Case 成立所需的逻辑依赖、权限和时间边界，不记录某次执行实际解析到的模型、知识库、索引、工具或环境版本。实际版本由 Run 血缘保存，Case Result 再通过 run_id 关联。
12.11 交付物二：专项 Case Schema
| Case 类型 | 必备扩展字段 |
|---|---|
| LLM Case | reference、constraints、generation_config |
| RAG Case | corpus_version、gold_evidence、context_policy、citation_requirement、evaluation_metrics |
| 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 和人工各适合评判什么。