[ExtractBench] LLM 的滑铁卢：当企业级复杂 Schema 撞上 PDF 提取

TL;DR

尽管 GPT-5、Gemini-3 等顶级模型在各类基准上刷榜，但在处理真实的、具有数百个字段的 JSON 提取任务时，它们却集体“破防”。最新提出的 ExtractBench 揭示了一个残酷的现实：当 Schema 宽度达到企业级规模（如 300+ 字段）时，现有模型的有效输出率竟然跌至 0%。本文将深入解析为何复杂的结构化提取依然是 LLM 进入千行百业的“最后一公里”。

背景定位：从“玩具”任务到企业级挑战

在学术研究中，结构化提取往往被简化为单页收据或简单表单的 key-value 对。但在真实的金融、法律场景（如 SEC 财报、动辄 200 页的信贷协议）中，Schema 不是几个字段，而是逻辑嵌套深度达 6 层、字段多达数百个的复杂结构。

ExtractBench 就在这个坐标系中填补了空白：它不关注简单的 VQA 问答，而是考察模型是否能从原始 PDF 完整、准确地填充一个符合规范的长 JSON。

痛点深挖：为什么现有的评估方法失效了？

作者指出，目前的结构化提取面临两个致命 gap：

1. 维度错位：现有的测评（如 F1 Score）对所有字段“一视同仁”。但在工业界，提取出的 协议ID 错一个字母就是零分，而 借款人名称 这种自由文本只要语义一致即可。
2. 解析困境：在大规模 Schema 下，模型极易产生语法错误（如少一个括号或多了逗号）。这种“格式崩溃”往往掩盖了模型背后真实的提取能力。

方法论核心：Schema 即规范 (Schema-as-Specification)

ExtractBench 引入了一种驱动式评估框架。在这种机制下，JSON Schema 不仅仅是输出模板，更是评价标准：

• AST 遍历打分：框架解析 JSON Schema 的 AST，并在每个节点绑定对应的 Metric（如 number_tolerance 或 string_fuzzy）。
• 语义数组对齐 (Semantic Array Matching)：处理数组时，不再按位置死磕，而是利用 LLM 裁判先将模型输出项与黄金标准项进行语义对齐，再计算准确率。
• 精确识别“三态”：区分字段是“提取正确”、“显式填空（Null）”还是“彻底漏填（Missing）”，从而为模型诊断提供线索（针对性解决幻觉 vs 遗漏）。

上表展示了 ExtractBench 针对不同字段类型预设的打分策略

实验发现：Frontier Models 的“集体翻车”

实验对 GPT-5.2、Gemini-3 Flash/Pro 以及 Claude 4.5 进行了实测。结果令人震惊：

1. 宽度的诅咒：在 SEC 10-K/Q（369 个字段）任务中，所有模型全军覆没，输出的 Valid JSON 比例为 0%。
2. 产出量是瓶颈：模型能否成功的关键不是文档有多长（Input），而是要生成的 JSON 有多重（Output）。研究通过 Python 脚本计算发现，输出体积越大，模型的“语法纪律”越容易崩溃。
3. 受限解码的悖论：强制执行 JSON 约束（Structured Output Mode）有时反而会降低性能。因为复杂的约束增加了推理开销，导致模型在处理内容逻辑时“CPU 过载”。

左图展示了不同领域的文档压缩率，发现输出量大的任务（如论文引用提取）对模型挑战更大。

深度洞察：这对未来意味着什么？

• 走出单一 Prompt 的幻觉：靠一个 Over-complex 的 Prompt 完成数百个字段提取是不可能的。我们需要“分治法”（Map-Reduce）式的提取架构。
• 基础设施进化：ExtractBench 的价值不仅在于数据集，更在于其开源的评估框架。它允许开发者像写代码注释一样在 Schema 中定义如何评价这个字段。
• 局限性：目前基准仍集中在英语和金融法律领域。跨语言、跨行业的复杂提取将是下一个爆发点。

总结

ExtractBench 撕开了 LLM 在处理极高性能需求任务时的遮羞布。它告诉我们，AI 距离真正取代资深分析师去自动处理那些数百页的金融合同，还有相当长一段路要走。而精准、多维、基于 Schema 的评估，正是指引这条路的灯塔。