一份 PDF 扔进 LLM，出来的是乱糟糟的文本还是结构清晰的 JSON，在 2026 年已经成为一条分水岭。左侧是还在手写正则解析发票的团队，右侧是已经用开源模型一夜处理完上万份合同的公司。
过去两年里，PDF 结构化提取的开源生态完成了三次并行的技术筑基。Datalab 在 2026 年 6 月发布的 lift 9B 用 90.2% 的字段级准确率证明了端到端视觉提取模型可以匹敌商业 API。IBM 的 Granite-Docling-258M 证明了 2.58 亿参数的小模型也能完成完整的文档结构理解。XGrammar 则用近乎零开销的约束解码为整个生态提供了默认的 JSON 输出担保。这三条线正在走向交汇，交汇的结果是开源方案在 PDF 提取这个赛道上，第一次有了让商业 API 感到压力的筹码。
范式迁移：从“猜内容”到“保证结构”
PDF 的问题在于它是一个页面描述语言，而不是数据结构。它告诉渲染引擎在哪里画线、在哪里摆字，但不告诉你“这行字是一个发票号码”。传统流水线的做法是 OCR 提文本、正则做解析，每一层都在丢失信息，每一次解析都是概率游戏。
2025 年中至今，端到端视觉模型的出现从根上改变了这个困局。
Datalab 在 2026 年 6 月发布的 lift，是一个 9B 参数的开源权重视觉模型，直接接受 JSON Schema 作为输入，返回符合该 Schema 的 JSON。在 Datalab 的 225 份文档基准测试中（每份 6 到 64 页，共约 11,000 个标注字段），lift 的字段级准确率达到 90.2%，中位数延迟 9.5 秒每份文档。
判断这个数字的重量，需要放在完整的参照系中看。在 Datalab 的同一套评测中，Datalab 商业 API 的字段级准确率是 95.9%（延迟 30.8 秒），Google Gemini Flash 3.5 是 91.3%（28.1 秒）。lift 用不到三分之一的延迟，把与 Gemini 的差距控制在了约 1 个百分点。完全文档级准确率，也就是每个字段都必须正确，对所有模型都是噩梦：lift 为 20.9%，Gemini Flash 3.5 为 40.0%，Datalab API 为 44.4%。
几条底线必须说清楚：这些数字来自 Datalab 自己的评测，应视为厂商数据而非独立审计。低全文档准确率反映了长文档一次性提取的真实难度，没有一个模型能稳定做到“全部正确”。lift 之所以在开源模型中领先（NuExtract3 4B 为 81.5%，Qwen3.5-9B 为 76.3%），核心差异在于 schema-constrained decoding 和训练了模型“弃权”。当模型无法确定某字段值时，输出 null 而不是编造一个值。lift 的代码以 Apache 2.0 发布，权重采用修改版 OpenRAIL-M 许可，对研究、个人用途以及融资或收入低于 500 万美元的初创公司免费。
IBM 的反直觉选择：用 2.58 亿参数颠覆市场
如果 lift 代表了“更大模型加更复杂训练”的路线，IBM 的 Granite-Docling-258M 走了一条截然相反的路。
2.58 亿参数，这个体量大约是 lift 的 35 分之一。但它是一个完整的视觉语言模型，能端到端地将 PDF、扫描件和图片转换为带完整布局保留的结构化输出。表格、公式、代码、列表、页码、阅读顺序，全部在一个 shot 中完成。
Granite-Docling-258M 于 2025 年 9 月由 IBM 发布，是实验性模型 SmolDocling-256M-preview 的产品级进化版。语言骨干从 SmolLM-2 替换为 Granite 3 架构，视觉编码器从 SigLIP 升级为 SigLIP2。IBM 为此付出了昂贵的训练代价：通过大量数据集过滤和清洗来消除 SmolDocling 中存在的循环令牌生成等不稳定性。对希望部署在规模化生产环境中的企业用户来说，这种不稳定性是致命的。
模型的核心创新是 DocTags，IBM Research 开发的通用标记格式。与 HTML 或 Markdown 这种为人类阅读设计的标记语言不同，DocTags 专为图像到序列任务设计，能精确描述页面元素的类型（图表、表格、表单、代码、公式、脚注、标题等）及其空间关系和阅读顺序。设计决定了输出非常简洁，大幅降低令牌消耗，同时保留了普通格式无法承载的布局语义。
Docling 开源库本身由 IBM 于 2024 年启动，2025 年 4 月被捐赠给 LF AI & Data Foundation（Linux 基金会旗下）。截至 2026 年 7 月，该项目在 GitHub 上已收获超过 62,000 颗星，成为全球增长最快的文档提取工具之一。Docling 与 LlamaIndex、LangChain 等框架原生集成，支持 PDF、DOCX、PPTX、XLSX、HTML、图片乃至音频格式。Granite-Docling 以 Apache 2.0 许可证发布，提供 Transformers、ONNX、vLLM、MLX 等多种推理格式，覆盖了从本地实验到生产部署的全路径。
此外，Granite-Docling 的实验性多语言能力覆盖阿拉伯语、中文和日语。IBM 坦诚这些能力尚处于早期阶段且未经验证为企业级，但其方向明确，让文档理解不再局限于拉丁语系。
约束解码：让 LLM“别无选择”地输出正确 JSON
lift 的 schema-constrained decoding 和 Granite-Docling 的 DocTags 输出，背后共享同一项关键技术：约束解码。
传统的做法是让 LLM 输出任意文本、再尝试解析出 JSON。这是一个靠“期望模型恰好输出正确格式”的概率游戏。当 schema 嵌套复杂时，失败率非线性上升。无论如何 prompt、如何做 few-shot、如何做后处理 validation，模型仍然会在语法边界上犯错。
约束解码的思路更根本：在令牌生成阶段就屏蔽所有非法路径。模型每预测一个 token，解码引擎就计算当前上下文下合法的 token 集合（根据目标 JSON Schema），只允许模型从该集合中选择。这相当于在解码层加了一个“语法筛子”，模型物理上不可能输出不合规的 JSON。
2025 年，XGrammar 成为这个领域的分水岭。通过词汇表分区和自适应令牌掩码缓存，XGrammar 在 JSON Schema 约束下的解码速度比早期方法（如 Outlines）快了两个数量级。单令牌开销被压缩到 40 微秒以下，在实际部署中几乎不计。到 2025 年底，XGrammar 已成为 vLLM、SGLang 和 TensorRT-LLM 的默认结构化生成后端。三巨头同时采用，实际上确立了行业标准。
同赛道中并存着 llguidance（OpenAI 在 2025 年 5 月专门致谢其为基础工作做出贡献）和 lm-format-enforcer。但 XGrammar 凭借与主流推理引擎的深度集成，已经锁定了生态位。对最终开发者来说，如果你在使用 vLLM 或 SGLang 部署自托管模型，你已经在使用 XGrammar 了，不管你知不知道。
在应用层，Instructor 和 BAML 各守一端。Instructor（Python，超过 11,000 个 GitHub 星，月下载量超过 300 万）通过 Pydantic schema 提供统一的验证加自动重试层，针对 15 个字段以内的简单 schema，重试恢复率在实践中超过 95%。BAML 则面向多语言团队，用自定义 DSL 定义 schema 后生成 Python、TypeScript、Rust、Go 等语言的类型安全客户端，其 Schema-Aligned Parsing 能处理 LLM 输出的各种脏活，包括包裹在 Markdown 里的 JSON、带 CoT 推理再输出结构化结果、多余逗号等。
一个诚实的提醒：这些结构化输出库的复杂程度可能超出你的实际需求。如果你的场景是单一供应商，schema 扁平且简单，不需要重试逻辑和流式解析，那原生 SDK 的 .parse() 就足够了。零额外依赖。
2026 年开源 PDF 提取工具决策地图
把视线从模型层拉到工具层，2026 年的开源 PDF 提取工具箱已经分化出清晰的功能分组。
Marker（datalab-to/marker，GitHub 约 32,000 星）是综合能力最广的“瑞士军刀”。它支持 PDF、DOCX、PPTX、XLSX、HTML、EPUB 等多种格式，使用 Surya OCR 做文本识别，可选 --use_llm 标志在精度敏感文档上叠加 LLM 增强。在 H100 上批量模式达到约 25 页/秒的吞吐量，结构化 JSON 提取支持自定义 schema。如果你的团队只想装一个工具处理所有格式，Marker 是最安全的选择。
Docling（docling-project/docling，超过 62,000 星）是面向企业级 RAG 流水线的专业选手。它输出的 DoclingDocument 对象保留了语义层次，不只是文本，还有文档结构的“意义”。与 LlamaIndex、LangChain 的原生集成使得它成为 RAG 系统的默认预处理选项。IBM Research 的持续投入和 Linux 基金会的中立治理为长期维护提供了保证。
MinerU（opendatalab/MinerU，超过 73,000 星）由上海 AI 实验室的 OpenDataLab 团队开发，在中日韩文档的布局检测上无可匹敌。它使用 PaddleOCR 和自定义布局检测模型，支持 NVIDIA、AMD 以及超过十种国产加速芯片（昇腾、昆仑芯、寒武纪等）。对于处理中文科技论文和学术文献的团队来说，MinerU 是唯一正确选择。
PyMuPDF4LLM（2,000 多星）是所有场景中最轻的选项，不需要任何 ML 模型，仅依赖 PyMuPDF 的布局引擎提取原生 PDF 文本，速度最快但无法处理扫描文档。pdf-craft（约 4,600 星）专为扫描书籍数字化打造，v1.0 之后完全移除 LLM 文本校正，纯 OCR 方案更快更可预测，自动生成 EPUB 目录。
所有这些工具在开源许可下免费可用。作为对比，商业 API 的价格区间是：Mistral OCR（每千页 2 美元，Batch API 每千页 1 美元），AWS Textract（每千页 1.5 美元纯文本，每千页 15 美元含表格和表单），Unstructured Serverless（每千页 1 美元起）。开源工具的成本仅在于计算资源，一套 GPU 服务器的折旧和电费。
定价坍塌的前夜
2026 年中期，三条技术路线的交汇已经清晰可见。端到端视觉模型（Lift）、轻量级结构理解（Granite-Docling）、约束解码引擎（XGrammar）正在形成一个完整的开源提取栈。lift 和 Granite-Docling 代表了不同的模型哲学，大而专对比小而精，但 XGrammar 级的约束解码可以同时加持两者，让任意模型的输出都是 Schema 合规的。
在一端，Datalab 的整个产品矩阵（marker、surya、chandra、lift）形成了一个从 PDF 解析到 Schema 提取的垂直闭环。在另一端，IBM 的开源策略更彻底：Docling 被捐赠给 Linux 基金会，Granite-Docling 以 Apache 2.0 发布，整个工具链不附加任何商业许可限制。
两种路线谁会胜出并不重要。重要的是价格信号已经出现。当开源模型在字段级准确率上与 Gemini API 差距仅 1 个百分点、延迟只有对方三分之一时，商业 API 的价值护城河就只靠全文档准确率的领先优势（40% 对 20.9%）和托管服务的运维便利来支撑。
这个差距对大规模部署的决策影响极大。如果你的流水线要求每份文档全部字段都精确无误，比如发票自动入账、合规审查，商业 API 的真实价值就在这里。但如果你只需要字段级高准确率配合人工抽检，比如合同摘要提取、研究报告分类，开源方案的成本优势会变得不可拒绝。尤其是当 lift 能在 9.5 秒内完成一篇文档时。
PDF 提取的商业 API 市场正在面临一场定价坍塌。当开源模型在关键指标上日益逼近、而成本只有几十分之一时，供应商的护城河只能是全文档准确率加上托管便利。但这个护城河正在一天天变窄。
被 PDF 困了三十年的数据，终于有了开源的出口。
快报