技术知识库 · 工具评测 · · 国科智飞 Gavin
Lift：用 JSON Schema 约束结构化抽取，准确率与速度能不能兼得
Datalab 开源的 9B 视觉模型，按 JSON Schema 从 PDF 抽取结构化 JSON，官方基准上比 Gemini Flash 3.5 快约三倍。
Lift 是 datalab-to 团队开源的结构化抽取模型：9B 参数的视觉 LLM，输入 PDF 或图像页面，输出一份符合你给定 JSON Schema 的 JSON。代码是 Apache-2.0，模型权重走修改版 OpenRAIL-M 许可，2026 年年中上线，目前仍属早期项目。
它要解决的问题很具体：做合同、发票、财报这类文档自动录入时，真正的难点往往不是"模型看不懂"，而是"输出格式不可控"——JSON 语法错、缺字段、类型对不上，下游代码就得写一堆兜底逻辑。Lift 的答案是 schema-constrained decoding：在解码阶段强制模型按 Schema 生成。
能力与亮点
输出合规是硬保证。 约束解码让模型只能生成符合 Schema 的合法 JSON 和正确类型，而不是在 prompt 里"请输出 JSON"然后祈祷。这是结构化抽取能上生产的前提，也是 Lift 最值得借鉴的工程思路——同样的机制可以平移到 Agent 工具调用、数据落库、工作流事件等场景。
多页单次推理。 官方称 26 页合同一次喂入，跨页字段（比如封面的合同号与末页的签字日期）在同一上下文里处理。传统"分页→抽取→拼接→处理跨页引用"的流水线容易丢字段，整文档上下文更贴近真实长文档。
视觉直吃页面图像，不依赖 OCR pipeline。 输入是 PDF 渲染出的页面图像，少了一层 OCR 错误传递。团队本身就是 surya、marker、chandra 等 OCR/文档解析项目的作者，这条护城河有来历。
工具链完整。 lift_extract CLI 支持单文件与整目录批处理，也接受页面范围子集（类似 "0-5,8" 的写法），输出目录里每个文档对应一份结果 JSON 和一份 metadata.json（记录页数、token 数与错误信息，失败时附带原始模型输出，方便调试）；lift_app 是 Streamlit 的 Schema Studio，交互式编写与测试 Schema；推理后端支持 vLLM（默认，含 H100/A100/L40S/A10/L4/4090/3090/T4 等多档批处理预设）和 HuggingFace；有 Python SDK，InferenceManager 可以在进程内复用权重，避免每次调用重新加载模型——批量处理时这点很关键。
官方 benchmark。 测试集为 225 份文档、每份 6–64 页、约 11000 个评分字段，含跨页值、穷举列表、必须为 null 的字段、近似干扰项等对抗样本，exact-match 评分，8 并发。README 给出的中位延迟与字段准确率：Lift 90.2% / 9.5s，Gemini Flash 3.5 91.3% / 28.1s，闭源 Datalab API 95.9% / 30.8s。字段准确率差 1.1 个百分点，速度快约三倍。
怎么读这张表。 同表还有几个参照：Azure Content Understanding 83.4% / 73.7s，NuExtract3（4B）81.5% / 8.3s，基座 Qwen3.5-9B 76.32% / 16.8s。Lift 的位置很清楚：比通用 9B 模型高约 14 个百分点，比最快的 4B 模型慢一秒多但准确率高近 9 个百分点。它不是最准的，也不是最快的，卖点是速度与准确率之间的折中——这个定位对企业批处理场景恰好够用，因为它把最贵的那一段（人工复核）压到了可接受的量级。当然，这是项目方口径，选型时用自家文档复核才有意义。
背后是一整条文档智能工具链。 同组织还有 marker（PDF→Markdown，约 3.6 万 star）、surya（OCR/版面分析，约 2.1 万 star）、chandra（OCR，约 1.1 万 star）、pdftext（文本层提取）以及企业部署与 SDK，合计约 7 万 star，是文档智能赛道最完整的开源家族之一。官方批量服务称每周处理 10 亿页以上——开源做生态、托管卖准确率，这条商业分层也很值得产品团队研究。
Schema 写法有明确边界。 推荐 string/number/integer/boolean/array/object/null，字段含义不明确时写 description，required 只标必须字段，缺失值返回 null。enum、anyOf、oneOf、$ref、additionalProperties 这类约束解码器编译不了、会被跳过，输出保证随之削弱——这不是小细节，很多人第一次用会把 schema 写得跟 OpenAPI 一样复杂，然后发现"保证"没了。
约束解码的思路比模型本身更值得抄。 凡是"模型输出要被程序消费"的场景都适用：Agent 的工具调用参数、写库前的字段校验、工作流的事件结构。比起在 prompt 里写"请只输出 JSON"，用 constrained decoding 从源头消灭格式错误，是更工程化的做法；开源生态里 outlines、guidance、jsonformer 等做的也是同一件事。Lift 的价值在于把这条思路和视觉文档抽取结合了起来。
局限与坑
字段准确率不等于全文档成功。 同一张官方表格里，Lift 的 full-doc accuracy 只有 20.9%，Datalab API 是 44.4%。做合同自动录入这类"错一个字段整份就废"的场景，必须预留人工复核环节，不要用字段准确率去推算直通率。
License 分层要看两层。 代码 Apache-2.0 很宽松；模型权重是修改版 OpenRAIL-M：研究、个人使用，以及融资规模低于 500 万美元的初创公司可免费使用，但不能用于与 Datalab API 竞争的产品，去限制需谈 on-prem 商业授权。选型时让法务看模型许可，而不只是代码许可。
9B 是有上限的。 复杂版面、手写、低质量扫描会退化；相比闭源 API 的 verification 与 citations 能力，开源版没有对应机制。
部署要 GPU。 单卡可跑是优点，但不是一条命令就能用的 SaaS，吞吐、显存和批处理参数需要自己压测；项目还年轻，文档与接口仍在变化。
适用场景
- 合同、发票、财报、病历、运单、简历等"非结构化文档转结构化字段"的批处理；
- 数据不能出内网的场景，单卡本地部署即可满足；
- 与 OCR / PDF 转 Markdown 工具组成流水线：先转页面图像，再抽 JSON；
- 需要"输出 100% 符合 Schema"的下游系统集成，比如直接写库、触发工作流。
选型建议
先明确优先级：追求最高准确率且能接受数据交给第三方，直接评估官方托管 API（带 citations 与 verification）；数据必须留在本地、能接受中等准确率，Lift 是目前开源 9B 方案里值得优先试的。上手时用自家 20–50 份真实文档跑一遍，重点看"全文档全对率"而不是字段准确率；Schema 保持简单，避开解码器不支持的约束；把人工复核设计进流程。只做 PDF 转 Markdown 的话，同团队的 marker 更对口，不必上 Lift。