先保证能解析，再谈对不对
结构化输出任务要把「能不能解析」当作独立指标：解析成功率、字段缺失率、类型错误率分开统计，然后再看内容正确率。顺序不能颠倒——解析都失败时，内容正确率无从谈起，而把解析失败的样本直接剔除会让真实失败率被隐藏。常用做法是给可解析率设一个门槛（如 99.5%），跌破就回滚。
基本信息
| 检查顺序 | 可解析 → 必填键齐全 → 类型正确 → 内容正确 |
|---|---|
| 统计口径 | 分开报解析成功率、字段缺失率、类型错误率 |
| 门槛 | 可解析率设阈值（如 99.5%），跌破回滚 |
| 口径区分 | 首次成功率与最终成功率（含重试）要分开写 |
典型使用场景
- 抽取流水线上线前：跑解析链路检查点，确认各环节失败率
- 版本对比：新版提示可解析率是否下降
- 重试策略评估：衡量重试带来的收益与额外成本
- 异常定位：按检查点分桶，区分是结构问题还是截断问题
- 线上监控：持续统计解析失败率，设阈值告警
解析链路检查点
解析链路检查点
checks = [
("json_loadable", lambda raw: json.loads(raw) is not None),
("required_keys", lambda obj: set(KEYS) <= set(obj)),
("types_ok", lambda obj: all(isinstance(obj[k], T[k]) for k in KEYS)),
]
# 按检查点分桶统计：失败率高的环节优先修
# 截断导致的解析失败与结构错误要分开看
# 失败样本必须留存原文，便于定位是提示问题还是长度问题
# 重试成功也算一次失败，统计时区分首次与最终成功率检查点与处置
| 检查点 | 含义 | 失败时的常见原因 |
|---|---|---|
| json_loadable | 整体能否被解析 | 输出被截断、混入解释文字 |
| required_keys | 必填键是否齐全 | 提示未列全字段、模型自行省略 |
| types_ok | 字段类型是否正确 | 数字写成字符串、空值写成 "" |
| 内容正确 | 取值是否与原文一致 | 抽取偏差，与格式无关 |
把解析失败的样本直接剔除再算准确率，会把问题藏起来；失败率必须单列，并保留失败原文用于定位。
重试成功也算一次失败：统计口径要写清是首次成功率还是最终成功率，两者差值反映重试收益。