Benchmarking LLM Structured Data Extraction

把一封邮件，变成一个可信的 JSON。

这篇论文提出 LLMStructBench：一个用于评估 LLM 从自然语言文本抽取结构化字段、并一次性生成合法 JSON 的 benchmark。最关键的发现是： 模型大小不是决定性因素，prompt 与 schema 约束如何配合，往往更重要。

开始阅读 复现实验设置
995 tests
22 open-weight models
5 prompting strategies
0.74Gemma3-27B 与 GPT-4o 并列最高 P-score
18PJ+ 全模型聚合 parsing failure 数
11/22P strategy 成为最多模型的最佳策略
WVWrong Value 是最大瓶颈
{
  "task": "email -> schema-valid JSON",
  "central_tradeoff": "structure validity vs semantic fidelity",
  "best_default": "P for aligned models, PJ+ for fragile models",
  "reviewer_note": "需要真实数据与更强统计检验"
}

先给结论

LLMStructBench 的研究对象不是传统 IE 里的“字段识别准确率”那么简单，而是更贴近工程现场的要求：给定一段自然语言、一份 JSON Schema 和一个示例，模型能否在第一次响应中返回一个 schema-valid、字段值也正确的 JSON object。论文的核心洞见是，\(F1_{\mathrm{micro}}\) 这类字段级指标与 \(DOC_{\mathrm{micro}}\) 这类文档级完全正确指标会出现明显分裂：prompt 约束越强，JSON 越容易 parse，但语义值不一定更准。

一句话 这篇论文在测“LLM 能不能靠谱填表”。

输入是一封邮件，输出必须是符合 schema 的 JSON，而且字段值要真的从邮件里抽对。

最反直觉 更强的 JSON 约束不一定让答案更正确。

PJ+ 几乎不再失败解析，但很多错误会变成 Wrong Value，也就是字段在、格式对、值错了。

怎么用 先按模型族选 prompt，再做语义校验。

P 往往综合最好；PJ+ 更适合先保住结构。真正上线还需要 validation 或人工兜底。

如果你只想快速读懂，按这个顺序看

1. 任务是什么先理解“邮件 + schema → JSON”的评估设置。 2. 指标怎么看记住两个分数：字段级对不对，整份 JSON 是否一次全对。 3. 结果怎么读重点看 P vs PJ+，以及 WV 为什么压不下去。 4. 这工作靠谱吗最后看我对数据、复现性和改进方向的评价。

背景：为什么结构化输出这件事还没解决

先把场景想简单一点

你可以把这篇论文想成一个“自动填表”测试：员工发来一封邮件，系统需要把姓名、日期、设备、数量、严重程度等信息填进固定表格。问题是，LLM 很会写解释，但业务系统只认严格 JSON。括号少一个、日期格式错一个、字段值编错一个，自动化流程都可能坏。

在 HR、财务、IT support、物流、电商等流程中，大量业务数据先以邮件、工单、申请说明等自由文本出现。自动化系统真正想要的不是一段回答，而是一个能被程序消费的对象，例如： 

{
  "EmployeeName": "Aiko Tanaka",
  "EmployeeID": "XY729B",
  "IssueSeverity": "High",
  "ReportDate": "05.10.2023"
}

对下游 ETL 或 workflow engine 而言，“大概对”通常不够。少一个 key、日期格式错、返回 markdown code fence、把数值写成解释性文本，都可能让 pipeline 在第一步失败。

本文发现的现实缺口

  • 已有研究常看 schema compliance 或抽取准确率，但二者很少被同一套任务系统性拆开评估。
  • LLM 的 JSON 输出质量不是单调随参数规模变好；同一模型族对不同 prompt 约束的反应差异很大。
  • 结构正确性提升可能把错误从 Missing Key 转移到 Wrong Value，而不是消灭错误。
  • 隐私场景中，很多团队不能把业务邮件送到闭源 API，因此 open-weight model 的本地部署表现很关键。

术语小词典

JSON Schema规定 JSON 里有哪些字段、字段是什么类型、能不能嵌套、日期要长什么样。
Ground Truth (GT)人工确认过的标准答案 JSON，用来和模型输出逐字段比较。
Parseable JSON模型输出至少能被程序读成 JSON；但能 parse 不代表值一定对。
Schema-valid JSON不仅能 parse，而且字段结构和类型满足 schema。
Wrong Value (WV)字段存在、结构也可能对，但值错了。这是本文发现的最大瓶颈。
Document-level correct整份 JSON 完全正确。现实中很多 pipeline 要的就是这个。

要解决什么问题

论文要回答一个工程味很浓的问题：当我们要求 LLM 从自然语言消息中抽取所有必要字段，并输出符合指定 JSON Schema 的单个对象时，什么模型、什么 prompt 策略最可靠？

01
输入文本

邮件、申请、提醒、工单等自然语言文本。

02
Schema

固定 key、类型、嵌套深度、日期 pattern。

03
示例对

一个 example text + reference JSON。

04
LLM 输出

要求只返回单个 JSON object。

05
评估

同时比较 parseability、schema validity、字段值语义正确性。

Figure 1: LLMStructBench inference-time setup
Figure 1. LLMStructBench inference-time setup?dataset use-case?natural language text?example pair?JSON schema ???? LLM????????? JSON ?? Ground Truth ?????

目前的方法版图

Schema-constrained decoding

代表工作 JSONSchemaBench 关注 constrained decoding engine 能否覆盖 JSON Schema 特性、提升生成效率和合规性。优势是结构强；不足是更偏 decoder/framework 层，不直接衡量端到端 IE 里的语义字段是否正确。

Prompting workflow

Generate & Organize 这类两阶段方法先抽内容，再组织成结构，动机是拆开“理解文本”和“格式化输出”。本文实验支持这个思路：结构约束与语义正确性确实会互相拉扯。

Schema-driven prompting

在 prompt 中显式提供 schema 或 example object，让模型模仿目标结构。本文把这种策略和 Ollama API 的 format 参数组合起来，形成五种可比较条件。

LLMStructBench 的定位是补上一个中间层：不只问“能不能生成合法 JSON”，也不只问“字段值像不像”，而是用同一组邮件式任务观察模型族、规模、prompt 约束之间的 error redistribution。

本文方法：数据集、任务与创新点

Dataset 设计

数据集包含 5 个 use-case，每个 use-case 有 199 个手工验证样本，共 995 tests。每个 scenario 固定一份 JSON Schema，样本由自然语言消息和 schema-conform ground truth object 组成。论文强调数据虽由 GPT-4o 合成，但经过人工检查，删除或修复 text 与 JSON 不一致的样本。

合成流程是先生成 fully populated JSON object，再用 email generation prompt 转成自然语言邮件。为了制造 lexical diversity，prompt 要求随机化人名、日期、数值和场景字段。

创新点

  • 开放 benchmark：995 个手工验证样本，任务明确面向 JSON structured extraction。
  • 指标设计：同时给出 character/token-ish field 级 accuracy 和 document-level validity。
  • prompt 策略实验：系统比较 5 种 JSON prompting configuration。
  • 模型覆盖：22 个 open-weight variants + GPT-4o reference，覆盖 0.6B 到 70B。
  • 错误画像：把 MK、MV、WV 的 overlap 拆开看，指出 WV 是长期瓶颈。

Table I：五类任务复杂度

Use case描述CountKeysLeavesDepth
Support ticketsIT support ticket requests199552
Sick leaveSick-leave requests199753
Project extensionProject extension requests199963
Conference registrationConference registration requests199973
Loan requestEquipment loan requests，含 object array19910.04*9.04*4

* Loan request 的 key/leaves 是平均值，因为结构包含对象数组。

Appendix B 的两个示例

Easy: Support Ticket

文本包含员工姓名、ID、问题描述、严重程度、报告日期。目标是扁平 key-value JSON。

{
  "EmployeeName": "Aiko Tanaka",
  "EmployeeID": "XY729B",
  "IssueDescription": "Unable to access shared drives due to permission error.",
  "IssueSeverity": "High",
  "ReportDate": "05.10.2023"
}

Harder: Loan Request

文本中列出多件设备和数量，目标 JSON 含 Equipment 数组，每个 item 有类型和数量。

{
  "BorrowerName": "Hiroshi Yamamoto",
  "BorrowerID": null,
  "Equipment": [
    {"EquipmentType": "tablet", "EquipmentQuantity": 1},
    {"EquipmentType": "VR headset", "EquipmentQuantity": 2},
    {"EquipmentType": "digital camera", "EquipmentQuantity": 1}
  ],
  "ReturnDate": "23.11.2023"
}

数学表示与建模

先别急着看公式：作者其实在问两件事

第一，模型抽出来的每个字段值有多接近标准答案？这对应 \(F1_{\mathrm{micro}}\)。第二，整份 JSON 有没有一次性完全正确？这对应 \(DOC_{\mathrm{micro}}\)。前者像“考试按小题给分”，后者像“表单只要一格错就退回”。

论文把输出错误递归拆成 Missing Key (MK)、Missing Value (MV)、Wrong Value (WV)。WV 又分为 string deviation、same-type value error、coercible mismatch、hard type error。最终指标不是单一 accuracy，而是字段级 \(F1_{\mathrm{micro}}\) 与文档级 \(DOC_{\mathrm{micro}}\) 的组合。

MK: Missing Key标准答案有这个字段，模型输出里没有。例如少了 ReturnDate。
MV: Missing Value字段在，但值缺失或是 null。例如 "EmployeeID": null。
WV: Wrong Value字段和值都看起来存在，但值与 GT 不一致。例如数量 2 写成 1。
Failed输出完全无法作为 JSON 使用，或有致命 schema violation。

字段级 score

\[ F1_{\mathrm{micro}}=\lambda F1_{\mathrm{keys}}+(1-\lambda)F1_{\mathrm{values}},\qquad \lambda=0.25 \] \[ F1_{\mathrm{keys}}=\frac{2P_{\mathrm{keys}}R_{\mathrm{keys}}}{P_{\mathrm{keys}}+R_{\mathrm{keys}}},\qquad F1_{\mathrm{values}}=\frac{2P_{\mathrm{values}}R_{\mathrm{values}}}{P_{\mathrm{values}}+R_{\mathrm{values}}} \]

这里 key 只占 25%，原因是作者认为 value 错误对下游系统更危险。一个 missing key 也会在 value 层再被罚一次，所以降低 key 权重避免重复惩罚过重。

读法：\(F1_{\mathrm{micro}}\) 高，说明模型大体能把字段抽对；但它允许“部分正确”。所以它适合比较抽取能力，不适合作为上线前唯一指标。

值级 fuzzy credit

\[ TP_{v}=N_{v}-\left(E_{\mathrm{type}}+E_{\mathrm{value}}+E_{\mathrm{coerce}}+E_{\mathrm{dev}}\right) +\sum_{i=1}^{N_{\mathrm{lev}}}D(d_i)+\gamma E_{\mathrm{coerce}},\qquad \gamma=0.2 \] \[ D(d)= \begin{cases} 1, & d \le \tau_{\mathrm{good}}\\ \alpha(1-d), & \tau_{\mathrm{good}} < d < \tau_{\mathrm{bad}}\\ \rho_{\mathrm{bad}}, & d \ge \tau_{\mathrm{bad}} \end{cases} \]

论文给出的参数是 \(\alpha=0.5\)、\(\tau_{\mathrm{good}}=0.1\)、\(\tau_{\mathrm{bad}}=2.0\)，并对严重错误字符串施加负惩罚 \(\rho_{\mathrm{bad}}=-1\)。这一设计让“42” vs 42 或轻微拼写差异获得部分 credit，但硬类型错误和荒谬字符串不会被温柔放过。

文档级 correctness

\[ DOC_{\mathrm{micro}}=\frac{\#\mathrm{Correct}}{\#\mathrm{Tests}} \left(1-\frac{\#\mathrm{Failed}}{\#\mathrm{Tests}}\right) \] \[ Score=(1-\eta)F1_{\mathrm{micro}}+\eta DOC_{\mathrm{micro}},\qquad \eta=0.5 \]

这一步非常关键：一个模型可以字段级分数很高，但每个文档都错一个小字段，对严格 ETL 来说仍然不可用。\(DOC_{\mathrm{micro}}\) 逼迫模型在 document-level 上达到“整份 JSON 完全正确”。

一个小例子

假设一份 JSON 有 10 个字段，模型每次都抽对 9 个、错 1 个。字段级分数看起来很高，但如果业务系统要求整份表单完全正确，那么 100 份输出里可能 0 份能直接进入数据库。这就是论文为什么要同时看 \(F1_{\mathrm{micro}}\) 和 \(DOC_{\mathrm{micro}}\)。

实验方法与可复现设计

实验其实是在比较两种“管住模型”的方式

第一种是在 prompt 里反复告诉模型“按这个 schema 输出 JSON”，这就是 P。第二种是用 API 的 format 参数硬性要求 JSON 或 JSON Schema，这就是 J/J+。PJ+ 则是两者都用：prompt 里说清楚，API 层也约束。

模型池

Open-weight 模型共 22 个 variants，来自 Qwen3、Phi、Gemma3、Deepseek-R1、Llama3。规模覆盖 0.6B 到 70B。

额外加入 GPT-4o 作为 closed-weight upper-bound reference，但不纳入参数规模相关分析。

运行接口

论文使用 Ollama API 风格的 format 参数做 JSON 约束实验：有时传 literal string "json"，有时传完整 JSON Schema object，也有完全不设 API format 的条件。

论文没有充分报告 temperature、top-p、seed、max tokens、硬件和具体 Ollama/version，这是复现层面的明显缺口。

Table II：五种 prompting strategy

读表口诀：P 看 prompt，J 看 API format，+ 看是否把完整 JSON Schema 交给 API。 所以 PJ+ 是“prompt 说清楚 + API 也用 schema 管住”。
Tag描述format 参数System/User prompt 中是否含 schema/example
J只设置 API format 为 JSON"json"不显式提结构
Pprompt 要求返回 JSON，并给 schema 与 example object不设置包含 JSON schema 和 example object
PJAPI 设置 "json"，prompt 也要求 JSON"json"包含 JSON schema 和 example object
J+把 JSON Schema object 放进 API formatJSON-Schema object不显式提结构
PJ+API format 使用 JSON Schema，同时 prompt 给 schema/exampleJSON-Schema object包含 JSON schema 和 example JSON object

Prompt 策略选择的早期 scoring

作者先不急着比较所有模型的最终综合分，而是粗略数一数：哪个策略更常产出完美 JSON，哪个策略更容易失败。这个 early scoring 的作用是筛出 P 和 PJ+ 两个主角。

作者先用一个粗粒度策略分数挑出最值得深挖的 prompting technique。每个 test-case 或 error occurrence 的权重如下：

  • Correct：每个 flawless generation 加 10 分。
  • Mistakes：value deviation 或 extra keys 每次扣 1 分。
  • Errors：missing values 或 missing keys 每次扣 2 分。
  • Failures：无法返回可解析 JSON 每个 test-case 扣 15 分。
Figure 2: Phi3-3.8B parsing success across prompting strategies
Figure 2. Phi3-3.8B ??? prompting strategy ?? parsing success / extracted / failure ???
Figure 3: Phi3-3.8B JSON error distribution
Figure 3. Phi3-3.8B ? correct?mistake?error?failure ???? Phi ? P/PJ+ ????????

实验数据结构化清单

复现项论文提供的信息复现时需要补足/固定
数据5 scenarios × 199 = 995 validated tests；每个 scenario 固定 schema。公开仓库路径、样本划分、schema 文件版本。
输入natural-language message + schema + example pair。exact system prompt/user prompt/template 拼接顺序。
模型Qwen3、Phi、Gemma3、Deepseek-R1、Llama3 共 22 个 open variants；GPT-4o reference。模型 checkpoint hash、quantization、Ollama tag。
生成参数围绕 Ollama format 参数做五种条件。temperature、top_p、top_k、max_tokens、seed、stop tokens。
解析若模型输出 JSON 外包裹文本，尝试 regex 抽取 JSON substring。regex 具体实现，多个 JSON block 时的选择规则。
评估递归比较 GT 与输出，统计 MK/MV/WV，计算 \(F1_{\mathrm{micro}}\)、\(DOC_{\mathrm{micro}}\)、Score。字符串 normalization、日期/大小写/空白处理规则。

实验结果与核心结论

先抓住一条主线

这部分所有表和图都在证明同一件事：结构正确和语义正确不是一回事。强约束可以让模型更像 JSON，但不一定让字段值更可信。读结果时不要只看 Correct，也要看 Failed 和 WV。

1. Prompt strategy 比想象中更重要

这张表的读法：Correct 越高越好，Failed 越低越好；Mistakes/Errors 是还需要后处理或人工修的输出。P 的 Correct 最高，但 Failed 也最高；PJ+ 的 Failed 几乎归零，但 Mistakes 更多。
StrategyCorrectMistakesErrorsFailed解读
J2,27145,95128,797726只靠 API JSON mode 不够，语义错误和结构错误都多。
P7,79114,1712,8791,597正确数最高、mistakes 最少，但对 Phi 等模型可能 catastrophic failure。
PJ6,80015,79213,506445比 J 好，但 errors 高。
J+6,12928,9031,242135schema-level format 降低 structural errors，但 semantic mistakes 多。
PJ+7,64620,6521,16918最稳 parse，几乎消灭 failure；代价是 Wrong Value 更多。
P
11 wins
PJ+
8 wins
PJ
3 wins
J/J+
0 wins

Table IV 显示 P 在 11 个模型上是最优，PJ+ 在 8 个模型上最优。作者后续集中比较 P 和 PJ+。

Figure 6: Deepseek-R1 F1micro and DOCmicro distribution under P prompting
Figure 6. Deepseek-R1 在 P strategy 下的 \(F1_{\mathrm{micro}}\) 与 \(DOC_{\mathrm{micro}}\) 分布。
Figure 5: Gemma3 F1micro and DOCmicro by model size
Figure 5. Gemma3 ? \(F1_{\mathrm{micro}}\) ? \(DOC_{\mathrm{micro}}\)?1B ? document-level ???????
Figure 7: Deepseek-R1 F1micro and DOCmicro distribution under PJ+ prompting
Figure 7. 切换到 PJ+ 后，Deepseek-R1 的 document-level 方差显著收窄，但 semantic WV 更集中。

2. 模型规模有帮助，但不是单调决定因素

排行榜不要只看第一列模型名。重点看两个分数的差距：很多模型 \(F1_{\mathrm{micro}}\) 很高，但 \(DOC_{\mathrm{micro}}\) 低得多，说明“字段常常接近正确，但整份 JSON 经常不能一次全对”。
ModelSize\(F1_{\mathrm{micro}}\)\(DOC_{\mathrm{micro}}\)Score
GPT-4oapprox. 1.8T*0.960.520.74
Gemma327B0.960.520.74
Llama3.170B0.950.510.73
Gemma312B0.950.490.72
Deepseek-R170B0.950.450.70
Llama3.370B0.950.450.70
Qwen314B0.950.440.69
Deepseek-R114B0.950.430.69
Qwen31.7B0.940.400.67
Deepseek-R17B0.940.390.67
Qwen332B0.940.390.67
Deepseek-R18B0.940.380.66
Phi314B0.940.380.66
Phi4-mini3.8B0.950.380.66
Phi414B0.940.380.66
Qwen34B0.930.370.65
Qwen38B0.930.360.65
Deepseek-R132B0.940.330.63
Qwen30.6B0.920.300.61
Deepseek-R11.5B0.900.160.53
Gemma31B0.890.100.49
Phi3.53.8B0.950.030.49
Phi33.8B0.950.010.48

* GPT-4o 参数量是论文中的近似值，作者也注明没有有效公开信息。

最重要的结果读法

Gemma3-27B 与 GPT-4o 并列最高，Gemma3-12B 甚至超过多款 70B 模型。Qwen3-1.7B 进入中游，Deepseek-R1-32B 反而落后于更小模型。这说明 structured extraction 的可靠性更像是 instruction tuning、数据质量、架构和 prompt compatibility 的共同产物，而不是单纯参数规模的函数。

3. 错误从“结构失败”转向“语义值错误”

这里是全文最关键 insight：PJ+ 把 MK/MV 压得很低，但 WV 接近 100%。也就是说模型越来越会“填满表格”，但还是会把表格内容填错。
Deepseek-R1PPJ+
\(N_{\mathrm{err}}\)MK%MV%WV%\(N_{\mathrm{err}}\)MK%MV%WV%
1.5B79036.818.976.76050.00.399.7
7B6011.216.091.56160.01.6100.0
8B6110.05.797.26580.00.0100.0
14B5610.27.796.46310.00.5100.0
32B6660.34.898.37330.00.0100.0
70B5380.26.797.85780.00.0100.0

Table VI 是全文最有洞见的表之一。PJ+ 几乎消灭 MK/MV，特别是小模型 1.5B 的 MK 从 36.8% 降到 0%。但剩余错误几乎全变成 WV。换句话说，强 schema 约束保证“盒子形状对了”，却没有保证“盒子里放的东西对了”。

4. 顶尖模型也绕不开 WV

Top modelPPJ+
\(N_{\mathrm{err}}\)MK%MV%WV%\(N_{\mathrm{err}}\)MK%MV%WV%
GPT-4o4730.09.396.45550.05.098.0
Gemma3-27B4780.06.797.35590.00.0100.0

Table VII 说明，即使是 GPT-4o 和 Gemma3-27B，错误池中也几乎被 WV 主导。PJ+ 对 Gemma3-27B 可以把 MV 降到 0，但 WV 占比变成 100%。这再次证明：schema enforcement 解决的是“形状”，不是“事实”。

Figure 10: Venn diagrams for Deepseek-R1 errors under P prompting
Figure 10. Deepseek-R1 在 P strategy 下 MK、MV、WV 的 Venn overlap。随着规模增加，MK 几乎消失，但 WV 持续存在。
Figure 11: Venn diagrams for Deepseek-R1 errors under PJ+ prompting
Figure 11. Deepseek-R1 在 PJ+ strategy 下的错误 overlap。结构类错误被压缩后，剩余错误几乎都表现为 WV。

5. Table VIII 的模型族级总结

模型族最佳/推荐策略主要模式论文观察
Gemma31B 更偏 PJ+；12B/27B 用 P1B 有 MK/MV，12B 后以 WV 为主12B 是巨大跃升，27B 只有边际提升；27B 与 GPT-4o 并列最高。
Llama3 70BPWV整体准确率高，但 \(DOC_{\mathrm{micro}}\) 仍有波动。
Qwen30.6B 可用 PJ+，多数规模用 P小模型有 MK/WV，中大模型 WV1.7B 中游表现亮眼；32B 不一定优于小模型。
Deepseek-R11.5B 用 PJ+；7B-70B 多数用 P规模上来后 MK 消失，WV 持续32B 是反常低点；PJ+ 让结构稳定但 WV 更集中。
Phi3.8B 系列更适合 PJ+；14B/Phi4-mini 可用 PWV，且小 Phi 的 P failure 明显Phi3/Phi3.5 3.8B 的 \(DOC_{\mathrm{micro}}\) 极低，Phi4-mini 是正向异常点。
Figure 4: Gemma3 raw performance by size under P prompting
Figure 4. Gemma3 ? P strategy ????????? correct / mistake / error / failed ???
Figure 8: F1micro and DOCmicro vs log parameter size under P prompting
Figure 8. P strategy ??\(F1_{\mathrm{micro}}\) ??????????? \(DOC_{\mathrm{micro}}\) ?????
Figure 9: F1micro and DOCmicro vs log parameter size under PJ+ prompting
Figure 9. PJ+ strategy ??document-level reliability ???? prompt-model interaction ?????

核心结论压缩版

实践建议

  • 如果模型族与 prompt 对齐良好，P 策略通常是最高综合分选择。
  • 如果模型容易输出不可解析内容，PJ+ 是更安全的起点，因为 failure 极少。
  • 对业务 pipeline，不能只看 JSON parse rate；必须单独评估 Wrong Value。
  • 小模型不一定不可用，Qwen3-1.7B、Gemma3-12B 展示了强性价比。
  • 扩大模型规模对 value accuracy 有帮助，但对 document-level 完全正确率没有稳定保证。

论文自己的结论

  • GPT-4o 没有明显压过最好的开源模型，Gemma3-27B 达到同等 score。
  • PJ+ 提升结构有效性，但会增加 semantic errors。
  • WV 是几乎所有配置下的主导错误。
  • 最佳方案是按模型族匹配 prompting strategy，而不是盲目选大模型。
  • 未来需要 post-generation semantic validation 或 fine-tuning，而不只是更强 schema。

我的 reviewer 评价

我对这篇论文的总判断

这是一篇很有工程价值的 benchmark paper：它不一定把 structured extraction 研究推进到理论新高度，但把很多团队在线上踩过的坑量化出来了。它最适合作为“选模型和 prompt 策略前的基准读物”，不适合作为“证明某模型可直接上线”的最终证据。

优点：这篇工作抓住了真问题

我喜欢这篇论文的地方在于，它没有沉迷“模型能不能输出漂亮 JSON”这种表层问题，而是把 production extraction 的两个硬指标拆开：字段值对不对，以及整份文档能不能一次过。\(DOC_{\mathrm{micro}}\) 的引入很实用，因为它代表了自动化系统最残酷的验收标准。

另一个强点是错误分析。Table VI/VII 很清楚地说明 schema 约束不是免费午餐：它会把 structural error 压下去，但把不确定性挤到 Wrong Value。这个 insight 对做 LLM ETL 的人很有价值，因为它直接决定后续要投 validation、human-in-loop、retrieval grounding 还是 fine-tuning。

不足：benchmark 有用，但还不够硬

最大问题是数据生成。虽然作者做了人工验证，但主体数据仍由 GPT-4o 合成，且 use-case 主要是模板化邮件场景。这会低估真实业务文本中的歧义、缺省信息、噪声、附件引用、多轮上下文和 schema/text 不一致问题。它更像“clean room extraction benchmark”，还不是完整的 real-world ETL benchmark。

第二个问题是复现细节不够。模型 tag、quantization、decoding hyperparameters、prompt exact text、regex extraction rule、normalization policy 都会显著影响 JSON 任务结果。论文想服务 practitioner，但 appendix 没把这些钉牢，导致可复现性打折。

我会怎么改进

下一版应该加入真实邮件/工单脱敏子集，报告严格 seed 与 decoding 参数，并做统计显著性检验。更重要的是，我会增加三类 baseline：constrained decoding engine、function/tool calling style output、以及 post-hoc repair + validation loop。否则“P vs PJ+”的结论容易被更强的 decoding/repair pipeline 改写。

指标上也可以更业务化：对字段设置 criticality weight，例如日期、金额、ID 的 WV 远比称呼大小写严重。现在 Levenshtein fuzzy credit 对字符串友好，但对 business semantics 仍偏浅。

落地建议

  • 先用 P 和 PJ+ 都跑一遍自己的业务样本，不要直接照搬论文的全局最优。
  • 把评估拆成三层：能否 parse、是否 schema-valid、字段值是否语义正确。
  • 对金额、日期、ID、数量这类 critical field 单独算错误率，不要让平均分掩盖风险。
  • 上线前加入 post-hoc validator：日期格式、枚举值、数量范围、ID lookup、跨字段一致性都应该程序化检查。

One More Thing

这篇论文最值得带走的不是某个 leaderboard 名次，而是一种评估观：结构化输出不是“格式约束问题”，而是“格式、语义、模型习惯、解码策略和下游容错边界”的联合系统问题。

P

更适合已经听话的模型，综合分常更高。

PJ+

更适合脆弱模型，先保住 parseability。

WV

最终瓶颈是字段值真实性，不是 JSON 括号。

单文件论文解读页：基于 LLMStructBench.pdf 内容整理。公式通过 MathJax 渲染；表格数值来自论文 Table I-VIII。