JSON 输出:能解析 ≠ 能用

三种方式,各跑 30 次

三个结论,逐条讲:

① 现代模型的"格式合法性"已经不是问题了。 三种方式的解析成功率都是 100%——别再为"它会不会返回带 markdown 包裹的 JSON"焦虑(至少在这个模型这个任务上)。老教程里那些"用正则抠 JSON"的技巧,收益已经很小(但兜底逻辑仍建议留着,见下)。

② 真正的杀手是字段漂移:0/30。 不指定 schema 时,模型每次自由发挥字段名:person/人物/姓名,amount/金额/价格,item/商品/物品——ap0.2 那个"5 次 4 种结构"的现场,在这里被量化成了零通过率。

③ 写死 schema 就够了(至少这个任务):30/30。 方式 ② 只是在提示词里明确写出字段名和类型,一致率就到了 100%;方式 ③ 再叠加 API 的 json 模式,没有额外提升。先用 ②,不够再上 ③。

所以正确的写法长这样

P_SCHEMA = """从这句话提取信息。严格输出 JSON,字段固定为:
{"person": "人名或null", "amount": 数字或null, "item": "物品或null", "date": "日期原文或null"}
只输出 JSON,不要任何其他文字、不要 markdown 代码块。"""

四个要点:字段名写死(英文短名,避免中英混用)、类型写清、允许 null(比强行编造好)、明确禁止额外文字。

关于 API 的 json 模式(response_format={"type":"json_object"}):它保证输出是合法 JSON,但不保证字段符合你的 schema——所以它替代不了写死 schema,只是多一道保险。(部分服务商支持传入完整 JSON Schema 做强约束,支持度以各家文档为准。)

但别以为这样就万无一失

本次实测是理想条件:输入干净、字段简单、temperature=0。真实世界里还会遇到:

• 输入是脏的(乱码、超长、包含引号和括号)→ 输出可能崩;
• 字段变复杂(嵌套对象、数组、枚举)→ 漂移概率回升;
• 模型换版本/换服务商 → 行为可能变。

所以下一节要建校验 + 自动修复:不是因为"提示词不行",而是因为任何靠概率的东西都需要一道兜底。你的产品要面对的是一万次调用,不是三十次。

🔧 动手做:测你自己任务的字段一致率(12 分钟)

1. 跑本节代码 json_modes.py,看你自己的三行数字。
2. 换成你的 schema:把 P_SCHEMA 换成你毕业方向真正要提取的字段(至少 5 个字段,含一个可选字段)。
3. 加大难度:把 TEXTS 换成你的真实输入,故意混进 1-2 条脏数据(超长、带乱码、信息不全的)——字段一致率掉了吗?
4. 试试嵌套:把 schema 改成带嵌套对象或数组的(比如 items: [{name, count}]),重跑——一致率变化多大?这就是"复杂 schema 更难约束"的实证。
5. 记下你的基线:当前 schema 下,我的字段一致率是 __/30。下一节要把它推到更高。

✅ 做到这里你应该有:你自己 schema 的字段一致率基线,以及一次"复杂 schema 掉分"的观察。

为什么:这一节把 ap0.2 的第一座山量化了。有了"字段一致率"这个指标,下一节的校验修复才有得比——先量化问题,再解决问题,这是这门课的固定套路。

我要从【什么文本】中提取信息用于【什么用途,比如入库/统计】。请帮我:1) 设计一个稳定的 JSON schema(字段名用英文短名、写清类型、标注哪些可为 null);2) 写出对应的提示词片段(含禁止额外文字的表述);3) 指出我这个 schema 里哪些字段最容易被模型漂移或编造。