现场是这样的。抽取接口要求 score 是整数，模型返回 "score": "85"，pydantic v2 抛 Input should be a valid integer，两千条里约 7% 失败，整批任务被卡住。
中间走过弯路，把「解析层没开宽松模式 严格按类型比对」当成主因，改完现象没变。
这类报错背后常见的原因有几处，逐个排除就行。schema 写了 integer 但模型把数字当字符串；模型从原文照抄带引号的数字；重试时提示词没说明类型 问题照旧。
第一件事是统计失败样本的字段类型分布
python -c "import json;from collections import Counter;print(Counter(type(json.loads(l)['score']).__name__ for l in open('bad.jsonl')))"然后用 field_validator 做字符串到整数的转换
python -c "from pydantic import field_validator;print('validator ready')"schema 描述里写清不要加引号
python patch_desc.py --field score --desc 输出 JSON 数字 不加引号剩下的就是重跑失败批次并按原值比对
python rerun.py --input bad.jsonl --out fixed.jsonl同一份数据我导出了两份，一份留底，一份拿来试。
恢复的判定其实很直接。两千条全部通过校验，score 的数值分布与修复前一致，没有出现被截断的取值。
模型对类型的理解依赖字段描述，只写类型不写示例，字符串和数字经常混。拖得越久，排查成本越高，因为现场状态会被后续操作覆盖。