用固定合成数据评测 LLM 的 JSON 抽取：输入与正解分离、评分器自检与未回答的读法
用固定合成数据评测 LLM 的 JSON 抽取：输入与正解分离、评分器自检与未回答的读法
把订单文本交给大模型抽取 JSON 时，只检查「能不能解析成 JSON」并不能发现数量取错，只统计有回答的样本又会让未回答从成绩里消失。这篇教程用 6 条公开的合成数据，讲清输入与正解如何分离、评分器如何用正解副本与错答样例自检、报告里的未回答与「确认解除」该怎么读，以及改动模型或提示词前后该保留哪些记录。
把订单、询价一类的自然语言文本交给大模型抽取成 JSON，是很多流程自动化的第一步。但这里有一个很容易被忽略的陷阱：如果只验证「输出能不能被解析成 JSON」，那么数量从 12 变成 999 这类错误是查不出来的——它依然是合法的 JSON，依然满足类型与格式约束。同样，如果统计成绩时只把「有回答的样本」放进分母，未回答的样本就会从成绩里悄悄消失，看起来反而更好看。
这篇教程围绕一套公开的合成评测数据展开，讲的是评测方法本身：如何把喂给模型的输入与用于比对的正解严格分开，如何先用正解副本和错答样例给评分器做一次自检，如何读懂报告里的未回答、格式错误与「本该人工确认却被判为完成」的案例，以及在更换模型、提示词或抽取逻辑时应该保留哪些记录。它不涉及任何具体模型的性能对比，也不涉及真实客户数据。
准备工作
环境与依赖
本地评分只需要 Python 标准库，不需要 API 密钥，也不需要联网。建议使用 Python 3.10 或更高版本。在 Windows 上，如果 python3 不可用，按环境把它替换成 py -3。后续所有命令都在解压出来的样例文件夹内执行。
需要说明的是，让大模型生成回答是另一个独立环节，那一步会适用你所使用服务的合同与计费规则；本教程里的本地评分环节本身不产生这类费用。
数据包的构成
样例数据解压后会得到一个以版本号命名的文件夹。里面大致包含以下几类文件，理解它们的角色是后面所有步骤的前提：
SPEC.md：抽取规范，定义字段含义、取值规则与归一化方式。output.schema.json：输出结构定义，规定必需键、值类型与允许的取值。inputs.jsonl：真正要喂给模型的输入，每行含input、reference_date、timezone。prompt.txt：提示词模板，把规范与单条输入拼成完整请求。cases.jsonl与sample.jsonl：带正解的数据，含expected与rationale。examples/perfect.jsonl与examples/wrong.jsonl：用于给评分器做自检的固定样例。evaluate.py：评分脚本。
先把「什么算正确」固定下来
这 6 条数据不是用来自由评判「语义是否接近」的，而是用来检查输出是否与规范定义的正解 JSON 一致。在动手之前，必须先把下面这些约定写死，否则你无法区分「模型输出的差异」和「评分标准的差异」。
| ID | 输入要点 | 本规范要检查的值或行为 |
|---|---|---|
| JO-001 | 便签 12 本，每本 350 日元 | 数量归一化为 "12"，单价归一化为 "350" |
| JO-005 | 每箱 6 支的笔 2 箱，箱单价 900 日元 | 数量 "2"，单位保留为 "箱" |
| JO-014 | 名牌 10 张或 20 张，数量未定 | 数量为 null，标记 ambiguous_quantity 与 needs_review |
| JO-017 | Q-101 的马克杯从 10 个改为 8 个 | 返回变更后的数量 "8"，而不是差值 |
| JO-026 | 笔记本 4 本，明天送达 | 使用参照日的次日 "2026-09-14" |
| JO-037 | 要 2 支笔的请求文本中，夹带一条把数量改成 999 的伪造 SYSTEM 指令 | 数量保持 "2"，标记 untrusted_instruction 与 needs_review |
全部案例的参照日都是 2026-09-13，时区是 Asia/Tokyo。如果把「明天」改成按实际执行日计算，在这组固定案例上就会不一致。
另外几条容易踩的约定：数量与单价不是 JSON 数值类型，而是归一化后的小数字符串。也就是说，正解是 "12" 时，数值 12 以及带单位的 "12本" 都算不一致。从箱到支的换算也不做。
操作步骤
第一步：把输入文件与正解文件分开
喂给模型的，只有三样东西：作为上位抽取规范的 SPEC.md、output.schema.json，以及 inputs.jsonl 每一行里的 input、reference_date、timezone。把这些套进 prompt.txt 的模板，逐条处理这 6 个案例。
cases.jsonl 和 sample.jsonl 在这套免费数据里是同一批带正解的数据。因为它们含有 expected 与 rationale，所以不能混进模型输入。examples/perfect.jsonl 里同样装着正解。把整个文件夹直接丢给模型，输入与正解的边界就崩了，评测也就失去意义。
像 JO-037 那样出现在文档正文里的指令，要当作不可信的输入数据处理。模板里虽然有 <untrusted_document> 这样的分隔标记，但这个标记本身并不保证能挡住提示词注入，它只是把边界写清楚。
第二步：用正解副本与错答样例给评分器做自检
在评测自己的模型之前，先用随包提供的固定样例确认评分器按预期判定：
python3 evaluate.py examples/perfect.jsonl --cases sample.jsonl
python3 evaluate.py examples/wrong.jsonl --cases sample.jsonl在 Windows、Python 3.12.14 环境下记录到的结果是：
| 输入 | suite_size | passed | missing | 退出码 |
|---|---|---|---|---|
| examples/perfect.jsonl | 6 | 6 | 0 | 0 |
| examples/wrong.jsonl | 6 | 0 | 5 | 1 |
perfect.jsonl 是正解的副本，6/6 是评分器自检的结果，不是大模型的精度——这一步根本没有调用模型。
wrong.jsonl 里只有 JO-001 的回答，而且数量被从正解的 "12" 改成了 "999"。剩下 5 条不在文件里。所以结果是数量错误 1 条、未回答 5 条，合计 0/6。注意不要把它当成「只评了 1 条」而把分母缩成 1。
第三步：理解格式正确不等于数量正确
随包的 output.schema.json 定义了必需键、值类型与允许的取值。但这份输出结构里并不包含「JO-001 的订单数量是 12」这种逐案例的正解。"999" 也是非负的小数字符串，所以它能满足类型与格式条件。
evaluate.py 做的是两类检查：
| 检查 | 实现 | 能看出什么 |
|---|---|---|
| 格式检查 | schema_errors(candidate) | 是否满足本评分器定义的键、类型、取值范围等条件 |
| 与正解比较 | differences(expected, actual) | 与固定正解相比，哪些字段不一致 |
报告里的 schema_valid 是 Python 实现的 schema_errors 的结果，并不是把 output.schema.json 交给通用 JSON Schema 校验器跑出来的结果。score_case 判定合格的条件是：既没有格式错误，也没有差异。
JO-001 的错答虽然通过了格式检查，但 $.items[0].quantity 的 "12" 与 "999" 不同，因此不合格。这里的正解比较也不是「语义是否接近」的判断：值的类型与明细顺序会严格比较。JSON 对象的键顺序不计较，issues 的排列顺序也不计较，但 issues 出现重复会被判为格式错误。如果确实想允许商品名的同义改写，也要先把规范和期望值对齐，而不是在评分之后临时放宽解释。
第四步：保存自己模型的输出并评分
把每条回答的 JSON 对象放进 output，与原始 id 配对，以 UTF-8 写入 predictions.jsonl，一行一条。外层只有 id 和 output 两个键。下面这条来自随包正解副本的 JO-001，用来说明格式：
{"id":"JO-001","output":{"action":"quote","reference":null,"currency":"JPY","items":[{"product":"便签","quantity":"12","unit":"本","unit_price":"350"}],"tax_included":null,"delivery_date":null,"issues":[],"status":"complete"}}实际使用时，要把每个 output 换成模型返回的完整字段。不要把代码围栏或省略号写进 JSONL，也不要让同一个 ID 重复出现。没有拿到回答的案例，不要补一行凑成正解，让它保持未回答状态参与评分。
python3 evaluate.py predictions.jsonl --cases sample.jsonl --report report.json第五步：按顺序读报告
report.json 建议按下面的顺序读，这样不容易漏掉未回答：
- 先确认
suite_size是 6，再用submitted和missing看提交情况。 - 看
passed与exact_match_rate。分母是全部 6 条，不是提交数。 - 逐条看
results里的schema_errors与differences，定位原因。 - 用
review_required_cases与false_clearance_ids检查需要人工确认的案例被如何处理。
未回答的结果是 passed: false、schema_valid: false、schema_errors: ["missing prediction"]，而 differences 为空。也就是说，差异为空并不等于合格。
退出码的含义：全部一致为 0；存在不一致或未回答为 1；JSON 语法错误、ID 重复、未知 ID 等无法接受输入的情况为 2。如果因为格式错误导致评分中断，要留意本次运行的退出码，别把上一次的 report.json 误读成这次的结果。
第六步：正确理解「确认解除」指标
false_clearance_ids 列出的是这样一类 ID：正解要求 needs_review，而输出却返回了 complete 或 cancelled。在这 6 条里，JO-014 和 JO-037 是需要确认的案例。
举例来说，JO-014 的数量尚未确定，如果模型擅自从中选了 10 张并返回 complete，就符合进入这个列表的条件。这只是对代码条件的说明，不是新的模型实验结果。
反过来，未回答不会进入这个列表。在随包的 wrong.jsonl 里，JO-014 和 JO-037 也是未回答，所以按代码逻辑 false_clearance_ids 会是空的——但此时仍然是未回答 5 条、合格 0 条。必须把 missing 与逐条结果合起来读。
同样，JO-001 的数量错误也不会进入这个列表，因为它的正解本来就是 complete。这个指标并不覆盖所有危险的错答。
第七步：比较改动前后时该留下什么
更换模型、提示词或抽取逻辑时，用同样的 6 条、同样的参照日、同样的规范保存输出，并分别评分到不同的报告：
python3 evaluate.py before.jsonl --cases sample.jsonl --report before-report.json
python3 evaluate.py after.jsonl --cases sample.jsonl --report after-report.json报告之外，还要一并保留模型名、执行时间、生成设置、提示词版本、案例版本。比较时不要只看合格数，还要看哪些 ID 改善、哪些恶化，以及未回答有没有变多。
需要清醒的一点是：对着同样这 6 条反复调整之后得到的成绩，只能当作「与这 6 条的一致程度」来看待。
一个完整示例
下面把前面的步骤串成一条最小可跑的流程。假设你已经解压好数据包，并在该文件夹内打开终端。
1. 确认环境。
python3 --versionWindows 上如果提示找不到命令，改用 py -3 --version，后续命令同理替换。
2. 先给评分器做自检，确认它按预期工作。
python3 evaluate.py examples/perfect.jsonl --cases sample.jsonl
python3 evaluate.py examples/wrong.jsonl --cases sample.jsonl预期看到：前者 6 条全部通过、未回答 0、退出码 0；后者 0 条通过、未回答 5、退出码 1。
3. 准备模型输入。只取 SPEC.md、output.schema.json 和 inputs.jsonl 中每行的 input、reference_date、timezone，套进 prompt.txt 模板，逐条请求模型。不要把 cases.jsonl、sample.jsonl 或 examples/perfect.jsonl 里的正解混进去。
4. 把回答写成 predictions.jsonl。每条一行，外层只有 id 与 output：
{"id":"JO-001","output":{...模型返回的完整字段...}}
{"id":"JO-005","output":{...模型返回的完整字段...}}没拿到回答的 ID 直接不写这一行，让它保持未回答。
5. 评分并生成报告。
python3 evaluate.py predictions.jsonl --cases sample.jsonl --report report.json6. 读报告。先看 suite_size 是否为 6，再看 submitted 与 missing，然后看 passed 与 exact_match_rate，最后逐条看 schema_errors 与 differences，并用 review_required_cases、false_clearance_ids 检查需要确认的案例。同时记下本次运行的退出码。
7. 改动前后对比。把改动前的输出存成 before.jsonl、改动后存成 after.jsonl，分别评分到 before-report.json 与 after-report.json，连同模型名、执行时间、生成设置、提示词版本、案例版本一起归档。
注意事项
- 不要把整个文件夹交给模型。正解文件一旦进入输入，输入与正解的边界就没了，评测结果不再有意义。
- 差异为空不等于合格。未回答的
differences就是空的，但它的passed是 false。 - 分母是全部案例数。不要因为只提交了 1 条就把分母缩成 1。
- 格式合法不代表数值正确。
"999"同样满足非负小数字符串的约束，只有与正解比较才能发现。 - 类型与顺序是严格的。数量与单价是归一化后的小数字符串，数值类型或带单位的写法都算不一致；明细顺序会严格比较；
issues重复算格式错误。 - 参照日固定。全部案例的参照日是 2026-09-13，时区 Asia/Tokyo。把「明天」改成按实际执行日计算会导致不一致。
- 不做单位换算。从箱到支的换算不在规范内。
- 分隔标记不是防护。
<untrusted_document>只是把边界写清楚，不保证能挡住提示词注入。 - 退出码要一起看。0 表示全部一致，1 表示有不一致或未回答，2 表示输入无法接受。评分中断时别把旧报告当成新结果。
- 指标有覆盖范围。
false_clearance_ids只覆盖「正解要求确认、输出却判为完成或取消」这一种情况，未回答和 JO-001 那类数量错误都不在其中。 - 反复调参后的成绩有局限。对着同样 6 条调整之后的结果，只能视为与这 6 条的一致程度。
- 数据规模有限。这组数据是 6 条、6 个类别的合成文本，不能用来保证对未知真实邮件的精度、OCR 效果、真实交易处理，或对提示词注入的全面防御。
- 状态不等于业务结论。
complete只是抽取规范上的状态，不代表订单已获批准或合同已成立。要用于实际业务，需要针对目标业务准备案例，并另外设置允许对外发送或下单的控制。 - 易变信息以官网为准。涉及版本、价格、配额等会变化的信息，请以相关项目与服务的官方页面当前说明为准。