大模型输出的畸形 JSON 怎么修：25 条样本 6 种策略实测，100% 能解析却有 24% 把值改坏了

摘要让大模型输出 JSON再在下游解析——这是 Agent 工具调用、结构化抽取、分类路由里最普遍的一条链路。几乎所有教程都会教你加一层容错解析剥掉 markdown 围栏、去掉注释和尾逗号、括号不配平就补全。我把 25 条手工构造的畸形 JSON 样本覆盖 9 类真实畸形形态交给 6 种修复策略跑分别统计解析成功率和语义正确率结论和直觉相反最能修好的那套组合管线做到了 100% 可解析但其中 24% 的样本值被改坏或被发明而单引号类样本被修复后直接返回空对象{}——业务代码看到的是一个合法但全空的记录不会报错只会静默丢数据。本文给出完整可运行的实验代码、实测数据、以及一条哪些损坏连 Schema 校验都拦不住的判定路径。一、为什么解析成功是个错误的指标先看一条真实的实验输出本机 Windows Python 3.11.5下同输入: {k: v, n: 1} # 模型用 Python 字面量风格输出全单引号 策略: 回退式括号栈补全 输出: {} # 解析成功不抛异常 期望: {k: v, n: 1}json.loads没报错函数正常返回下游拿到一个空字典。如果这段 JSON 是要写进数据库的一条工单结果就是插入了一条空记录如果它是 Agent 的工具参数结果就是用默认值调了一次工具。整条链路上没有任何一处会报警。这就是我为什么把实验指标拆成两个parse_ok能不能 loads 开sem_ok解析出来的对象是否等价于模型本想给出的那个值每条样本我都写了expected所以可判定。只看parse_ok一个把数据全吞掉的修复器是满分选手。二、实验设计语料是 25 条本地构造的样本覆盖 9 类畸形形态。必须说清口径这些样本不是从真实模型输出里采集的不代表真实错误分布它们是按经验清单构造的每类形态的最难那一档。本文所有数字都来自这份固定语料换语料结论的相对排序我认为不变绝对百分比会变。类别条数典型样本fencedmarkdown 围栏3 json\n{…}\nchatter前后缀客套话3好的下面是结果{...}trailing_comma尾逗号3{a: 1, b: 2,}single_quote单引号2{k: v}comment注释3{a: 1, // 说明value_trap值内含易误伤字符2{note: items: a, b, }}truncatedmax_tokens 截断3{title: x, author:raw_control值内裸换行/制表符2{desc: 第一行 裸换行fullwidth全角标点4{“a”1“b”2}6 种策略defs1_direct(s):# S1 什么都不做returnjson.loads(s)defs2_balanced(s):# S2 括号配平截取字符串感知地fragbalanced_extract(s)# 找第一个 { 到它的配对 }切出来再 loadsiffragisNone:raiseValueError(no balanced fragment)returnjson.loads(frag)defs3_clean(s):# S3 正则清洗剥围栏 - 截取 - 去注释 - 去尾逗号tdrop_trailing_commas(strip_comments(clean_slice(s)))returnjson.loads(t)defs4_stack(s):# S4 回退式栈补全从末尾逐字符回删最多 48 步returnstack_repair(s)# 每删一次就扫描括号栈补上 ] }取第一个能 loads 的前缀defs5_pipeline(s):# S5 组合管线S3 的各阶段逐个尝试 loads...# 仍失败才降级到 S4最后一步才做全角-半角映射defs6_naive_fullwidth(s):# S6 全局全角归一网传先统一替换标点再解析returnjson.loads(to_ascii_punct(s))S4 的发明 null这一步是关键设计也是后面所有麻烦的来源defclose_open(body):给一个残缺前缀补出可解析的候选串。in_str,stack_scan(body)ifin_str:body# 裸字符串没闭合 - 补右引号bodybody.rstrip()mDANGLING_KEY_RE.search(body)# 结尾是个残缺键名 tag - 整个丢掉这个键ifm:bodybody[:m.start(1)1]whilebody.endswith(,):bodybody[:-1].rstrip()ifbody.endswith(:):body null# 键在、值被截断 - 补一个 null 占位tail[}ifch{else]forchinreversed(stack)]returnbody.join(tail)每策略跑 5 轮耗时取 min~max。三、实测结果策略解析成功率语义正确率静默损坏单样本耗时S1 直接 loads20%20%0%2.1~3.5 µsS2 括号配平截取40%40%0%3.2~4.1 µsS3 正则清洗56%48%8%3.8~5.3 µsS4 回退栈补全80%44%36%45.4~62.2 µsS5 组合管线100%76%24%24.9~27.3 µsS6 全局全角归一24%20%4%3.7~4.5 µs三个反直觉的点解析成功率和语义正确率的差只在强修复策略上出现。S1/S2 不做任何值改写所以两个数字完全相等S4 把差距拉到 36 个百分点——它修好的 36% 样本里值是被它自己编出来的。S5 比 S4 更快24.9~27.3 µs vs 45.4~62.2 µs。因为组合管线把最贵的回退式补全放在最后多数样本在前面的廉价阶段就返回了。整条 S5 管线在全语料上的单样本分布是 min 5.3 / 中位 12.2 / max 134.8 µs——最坏情况出现在客套话里嵌套花括号那条样本它把回退补全的 48 步全部耗尽。S5 在本语料上 0/25 解析失败看起来完美但它的代价藏在第二列76% 语义正确率。四、静默损坏长什么样完整清单5 轮结果完全一致这是确定性过程[S3 正则清洗] 值内含逗号右花括号 期望: {note: items: a, b, }, n: 1} 得到: {note: items: a, b}, n: 1} # 正则 ,\s*([}\]]) 吃进了字符串内部 [S3 正则清洗] 值内含逗号右方括号 期望: {arr_hint: seen [1, 2, ]} 得到: {arr_hint: seen [1, 2]} [S4 回退栈补全] 块注释 期望: {a: 1} 得到: {a: None} # 值被发明成 null [S4 回退栈补全] 值中间截断 期望: {title: 开源推理框架, author: 张三} 得到: {title: 开源推理框架, author: None} # 字段在值没了 [S4 回退栈补全] 值内裸换行 期望: {desc: 第一行\n第二行} 得到: {desc: 第一行} # 后半段内容直接蒸发 [S4/S5] 全单引号、全角标点包键 得到: {} # 最危险的一种合法空对象 [S6 全局全角归一] 合法 JSON 但值内含全角逗号 期望: {steps: 第一步第二步第三步} 得到: {steps: 第一步,第二步,第三步} # 本来就是合法 JSON被修坏了最后一条 S6 值得单独说输入本身是完全合法的 JSONS1 到 S5 全部原样正确解析。只有那个先把全角标点统一换成半角的建议把一个正确结果改错了。任何全局字符替换都必须限定作用域在字符串字面量之外否则它对合法输入是纯破坏。五、加上字段校验能不能兜住我用三层递增校验重测了这 18 条损坏样本V1 只查键是否齐全V2 查键齐全 类型一致V3 再加值契约字符串非空、URL 形状、整数范围。策略损坏条数V1 漏V2 漏V3 漏S3 正则清洗2222S4 回退栈补全9422S5 组合管线6100S6 全局全角归一1111合计18855分两种情况看这张表才有意义损坏形态是缺字段 / 空对象 / null 发明时校验很有效S5 的 6 条损坏被 V2 全数拦下漏 0。损坏形态是字符串值被删了字符 / 被换了标点时三道校验全漏S3 的 2 条和 S6 的 1 条键在、类型是 str、长度非空、URL 形状也还是 URL——V3 比 V2 一条都没多拦住合计 5 vs 5。所以加个 Schema 校验就安全这句话成立条件是修复器的破坏方式是删字段。它要是删字符你的校验就是摆设。六、我建议的判定顺序是否是否单引号/全角包键截断/裸控制字符是否模型原文 rawjson.loads 直接成功?进入字段校验剥围栏 配平截取只删字符串外噪声loads 成功?失败原因可判别?重试或降级:不做字符替换补全只用于展示类字段禁止写库/禁止执行工具调用键齐全 类型一致 枚举/长度/正则值契约?放行重试一次并把校验错误回传模型关键约束是 H 那条补全出来的结果不进写路径。截断样本补全后一定缺信息区别只在于你让它缺得可见报错还是缺得无声author: None落库。七、避坑指南不要用正则去尾逗号。re.sub(r,\s*([}\]]), r\1, s)是全网流传的写法它不看字符串边界实测把items: a, b, }吃成items: a, b}且解析照样成功。要删尾逗号必须走括号栈/字符串态感知。不要用正则删注释。同一条管线在处理{img: https://cdn.example.com/a.png}时//被当注释起点整条样本解析失败实测 S3 在该样本 0/1。失败还算好的值短一点就是静默截断。不要做全局全角→半角替换。实测它让一条完全合法的 JSON 值被改坏第四节 S6 例子。要做也只对字符串字面量之外的字符做。补全器返回{}必须当失败处理。判据很简单解析出的对象为空、而期望结构非空。修复器永远想要解析成功它会把你最想保留的字段先丢掉。null和字段缺失在数据库里是两回事。截断补全出的author: None会覆盖掉一份已有的正确作者名。补全后应把可疑字段单独打标记别让它参与 upsert。别把能解析当成验收指标。这条链路的正确验收指标是解析后语义等价或校验通过本项目一开始就踩过只看 parse_ok 的话 S4 是 80 分的策略看 sem_ok 它只有 44 分。重试预算要按损坏形状估不能按解析失败率估。S5 在本语料里解析失败 0/25看起来一次重试都不用但按校验口径它的 6 条损坏里只做键检查只能发现 5 条第 6 条author被发明成null、键却齐全要靠类型校验才揪出来。而 S3/S6 那 3 条改值型损坏键、类型、值契约三道全漏——按解析失败率配重试预算会配出 0 次重试。源头约束优先于事后修复。用 JSON Schema 在解码阶段做硬约束、或直接让分类任务不输出文本是把这条路绕开的唯一办法。这一条我没有实测数据本机没有可跑的约束解码推理服务只是给结论定位但本文所有修复层数字都在说明同一件事事后修复改不掉值本身错了的问题。八、结论事后修复层能把解析成功率从20% 抬到 100%同一份 25 条语料本机实测这是它真实存在的价值。代价是24% 的样本值被改坏或被发明其中空对象{}和null发明这两类会被字段校验拦下而字符串被删字符/被换标点这一类三道校验合计漏 5 条、一条没拦住。因此修复层只该用于展示类降级不该出现在写库和工具调用的路径上写路径要么靠解码阶段的 Schema 硬约束要么解析失败就直接重试不要在中间加聪明的正则。若要加校验类型一致的键校验是必须的实测拦掉 S5 全部 6 条损坏但别指望值契约有额外收益本语料里 V3 相对 V2 零增量。复现方式demos/json_repair_strategies.pyPYTHONIOENCODINGutf-8 python json_repair_strategies.py运行留档demos/json_repair_strategies.transcript.txtWindows Python 3.11.5。