# 中文模型任务测试材料 v1

这是一套虚构输入、人工参考答案和离线验收材料，不是模型成绩单。2026-10-09 本批没有调用任何模型。已有 27 次同档主力短任务实测在 https://www.apizt.com/examples/model-task-benchmark ，与这里的 20 个新用例分开。

## 内容

- `cases.json`：4 个中文事实抽取、4 个长文引用、5 个表格抽取、5 个工具选择和 2 个代码修复任务。`expected` 是人工编写答案，不能填入模型结果。
- `long-document.txt`：120 个稳定片段 ID 的虚构书展资料，包含无答案、未决矛盾与跨段组合。字符数由 `cases.json` 记录；不是按 Token 定长，不对应某个厂商的上下文上限。
- `grader.py`：本地检查四类结构化答案，不联网、不调用模型、不执行工具。缺答为待验收，不自动失败，也不自动成功。代码任务始终要求单独人工审查与测试。
- `code/baseline/`：两个有已知错误的作者编写文件，分别是数量字符串解析和重试间隔纯计算。
- `code/reference/`：作者编写的参考实现，仅用于检查离线测试本身；不是模型交付。
- `code/test_contracts.py`：12 个独立行为测试。测试预期直接来自文字合同，不根据候选实现生成。它导入候选 Python 文件，因此先人工审查，再在无密钥、无网络、无业务数据的隔离环境运行。
- `record-template.json`：分析器 schemaVersion=1、kind=benchmark-attempts 的 JSON 对象，包含 configs 和 records。60 行计划占位（20 用例 × 3 型号 × 1 轮）。`status=unknown`、`passed/elapsedMs/billedUsd=null` 表示未实测、未核对。不要把这些行当成已提交请求或通过结果；分析前移除未执行行。
- `record-template.csv`：同一批尝试的填写表，空格表示未知。它不携带完整 configs；转换成 JSON 时必须附上已核对的配置定义，不能直接导入分析器。
- `config-template.json`：先填写实际参数、超时、输出上限和缓存条件；它不会发送请求。每款型号使用独立 configId，协议是计划预设，预算与推理字段为 null，budgetMappingVerified=false。核对真实请求后再更新。

## 离线核对参考答案

把人工审查过的可见 JSON 回答存为本地 `answers.json`，格式为 `{ "summary-negation-01": { ... }, "citation-no-answer-02": { ... } }`。不要把 expected 复制进正式成绩表。

```bash
python3 grader.py --answers /absolute/path/answers.json
python3 code/test_contracts.py --candidate-dir code/reference
```

第一条只验收文件中的答案。第二条只验证作者参考实现满足合同；不能报告为模型通过。也可以对作者 baseline 运行同一套测试，确认已知错误确实会失败。

## 代码修复任务

给每个模型相同的 `prompt` 与对应 baseline。只允许交付 `quantity.py` 或 `retry.py`，不给参考实现。保留原始响应，先审查 diff，禁止修改测试和导入额外依赖。人工确认后，将两个交付文件放到单独候选目录，再在隔离环境运行：

```bash
python3 code/test_contracts.py --candidate-dir /absolute/path/reviewed-candidate
```

测试脚本不会自动隔离网络或文件系统；隔离由你的执行环境提供。它不运行 shell 命令，也不自动执行模型给出的安装指令。只修复一项时可指定 `QuantityContractTests` 或 `RetryContractTests`。

## 记录实际试验

1. 先固定数据集、型号、轮次和参数。https://www.apizt.com/tools/benchmark-plan-builder 目前使用自己的 9 份固定短任务，不能自动导入本包的 20 个新任务；本包用 cases.json 与 config-template.json 单独建立计划，不能混用数据集 ID 或成绩。
2. 均衡组可参考 `gpt-6.1-sol`、`claude-sonnet-5-5`、`gemini-3.8-flash`，先确认当前账号可用 ID。相同的 `medium` 不代表相同算力。原生协议的参数需要分别核实。
3. 每次实际请求记录独立 trialId；重试也新建一行。未提交占位行在分析前移除，或者单独作为计划表保存。
4. 有完整结束状态且已验收才填 `completed`；截断填 `truncated`；明确 HTTP 错误填 `http-error`；超时后无法确定提交或完成情况填 `unknown`。先核对再决定是否重发。completed 必须有 passed=true/false；未完成状态的 passed 必须为 null。尚待人工审查的完成响应先留在自己的待审表，不作为已验收 completed 导入。
5. 按合同验收后才填 passed。HTTP 200、合法 JSON 或出现工具名都不是通过。使用记录中的 sampleId 对应 case ID，保留完整请求与答案在自己的安全存储中；分析器只收元数据。
6. billedUsd 仅填可以对应到这次请求的实际扣费。公开报价、usage 和估算不能填进实扣字段；没有证据就保留 null。公开展示最低报价时，输入和输出必须来自同一个计费方案，其他价格在模型广场查看。
7. 用 https://www.apizt.com/tools/benchmark-result-analyzer 导入标准 JSON。比较时须用相同 datasetId 与对齐的 sampleId；每款型号配置可以有独立 configId，是否具备横比条件取决于协议、参数、预算与映射证据，不取决于 ID 名字相同。只有少量合成任务时，不做综合能力排名。工具统计的是独立请求尝试，不能直接代替按业务任务聚合后的成功成本。

## 验收口径

- Summary：所有事实、否定、未知及支持片段必须一致。缺失不能变成 false 或 0。
- Citation：片段 ID 必须实际支持结论；无答案输出 unknown，未决矛盾输出 conflicting。ID 顺序不计分，重复 ID 不通过。
- Table：按输入顺序保留全部行；ID 和金额是字符串，数量是精确整数。缺失为 null，不能等于零。不得额外增加总计行。
- Tool：只验收提案选择、参数与澄清，既不执行工具，也不构成完整 Agent 循环的测试。
- Code：功能、类型、边界和只改允许文件分别验收。单元测试通过不意味着可以直接上线。

材料无 API Key，无真人隐私与实际交易数据。任何结果都应注明模型版本、日期、请求参数、结束状态和本次任务范围。