7. EvalCase 与 Dataset 设计

核心工程 · 3～5 小时

学习目标

设计高价值 EvalCase
建立 Golden、Edge、Failure、Adversarial 数据层
让生产失败持续进入回归集

前置知识

第 6 章

本章产物： 创建第一个 50 Case 的 EvalDataset 和覆盖矩阵。

7.1 好的 EvalCase 不是“随机问题”

Case 应来自明确质量风险。

推荐六类来源：

Golden：最典型业务。
Edge：边界值、缺失字段、特殊格式。
Failure：历史线上失败。
Adversarial：注入、越权、恶意数据。
Long-tail：真实用户罕见输入。
Synthetic：为了补覆盖自动生成。

7.2 EvalCase Schema

id: refund-partial-001
category: refund
difficulty: medium

input:
  user_message: "取消其中一件商品"

initial_state:
  fixture: retail-v12

expected:
  required_effects:
    - item_2.status == cancelled
  forbidden_effects:
    - item_1.status != cancelled

policy:
  confirmation_required: false

limits:
  max_turns: 12
  max_tool_calls: 15
  timeout_seconds: 60

tags:
  - partial-refund
  - state-based

7.3 Coverage Matrix

不要只追求 Case 数量。

能力	Normal	Edge	Failure	Safety
Search order	10	3	2	1
Cancel	10	6	6	4
Refund	10	8	10	6
Permission	4	5	7	12

覆盖风险比“有 1000 个 Case”更重要。

7.4 Production Replay

线上 Trace 转 EvalCase 前要：

脱敏；
去除客户 secret；
固化外部依赖；
明确真实 expected outcome；
检查是否存在未授权再分发数据。

7.5 Synthetic Data 的正确角色

Synthetic Case 很适合：

参数组合；
边界枚举；
安全变体；
同义改写。

但不应完全替代真实用户行为。生成器本身的偏差会进入 Dataset。

7.6 Case Review

每个 Case 发布前至少问：

Task 是否可执行？
Success 是否可判定？
Environment 是否稳定？
Case 是否重复？
是否包含泄漏信息？
是否错误依赖某一条固定轨迹？

7.7 验收问题

为什么历史失败 Case 往往比随机合成 Case 更有价值？
如何判断 Dataset 是“多”还是“覆盖好”？
Production Replay 为什么需要环境固化？

本章依据

原理性结论优先来自原始论文和官方文档。论文中的实验数字只属于论文声明的模型、数据、环境和评测设置，不能直接外推为你的生产结论。