my-vault/01_Projects/Personal-Tech/LLM_Evaluation/03-Practice/_template/02-case-design.md

type, status

type	status
project	active

02 · Case 设计

权威分布表：20-case 配比见 01-LLM-Evaluation-Roadmap Day 1；10-case 结构见 02-First-Week-Worksheet 第 2 节。第一版 10-20 个即可。

输入上下文（冻结快照）

每个 case 的输入 = question + context。context 就是下面这段原文（文档片段 / 工具定义 / 代码片段）。判"文档能否完整回答"、盲评判"有据性"都以它为界。建数据集时，这段原文原样搬入每个 case 的 input.context。

• 来源：＿＿＿＿（URL）／ 抓取日期：＿＿＿＿
• 许可：＿＿＿＿ ／ PII：＿＿＿＿
• 边界说明：＿＿＿＿（例如：本片段仅含文档的 X 节，凡未覆盖内容一律视为"资料不足"）

原文（粘贴处）

<粘贴输入上下文原文，保留原始措辞与格式>

Case 列表（对应工作表第 2 节）

编号	类别	问题	文档能否完整回答	预期系统行为	case 状态
01	正常路径		是		candidate
02	正常路径		是
03	正常路径		是
04	资料不足		否
05	资料不足		否
06	部分支持		部分
07	多证据		是
08	幻觉诱发		否 / 部分
09	格式约束		是
10	边界条件		视情况

case 状态流转：candidate → reviewed → accepted → regression → deprecated（定义见 01-LLM-Evaluation-Roadmap 第五节）。

资料不足的写法：不要写完全无关的问题，写"只差一小块信息就能回答"的问题（如文档讲了字段但没有默认值），才能测出模型会不会补全空白。

JSONL 结构（稳定测试定义）

字段与示例见 01-LLM-Evaluation-Roadmap 第五节。每个 case 至少包含：id / input / expected / metadata（category、difficulty、risk、split、case_status）/ rubric_version / dataset_version。测试定义与运行记录分开保存。

注意：input.context = 顶部"输入上下文（冻结快照）"的原文；运行记录不复制全文，只存 case_id + 版本号（见 01-LLM-Evaluation-Roadmap 第五节）。

{
  "id": "rag-0001",
  "input": { "question": "", "context": [] },
  "expected": { "behavior": "", "must_include": [], "must_not_include": [] },
  "metadata": { "category": "", "difficulty": "", "risk": "", "split": "dev", "case_status": "candidate" },
  "rubric_version": "0.1",
  "dataset_version": "0.1"
}

---

返回 01_Projects/Personal-Tech/LLM_Evaluation/03-Practice/README。