又一个人工录入岗位要被改写了:PDF直接吐出schema 对齐的 JSON

很多团队嘴上说要做自动化，真正卡住的地方却很土：合同、票据、表单、报告都在 PDF 里，机器看不懂，人又要一条条录。

所以过去几年，大家对“PDF 识别”这件事一直有点失望。能识别文字不稀奇，真正难的是把一份版式复杂、字段不稳定的文档，变成业务系统能直接吃下去的结构化数据。

而 Datalab 这次放出来的lift，值得看的点就在这里：它不是再做一次“看见文字”，而是在尝试把PDF 直接变成 schema 对齐的 JSON。如果这条路跑通，受影响的就不是 OCR 工具本身，而是整条人工录入链路。

它真正想掀掉的，不是 OCR，而是“人肉录字段”

很多人看到这类产品，第一反应还是“又一个 OCR 模型”。但这次更值得注意的，不是识别能力本身，而是输出形态开始变了。

过去的常见流程是：先把 PDF 转成文本，再靠规则、脚本或人工去找字段、补格式、校结果。只要文档版式一复杂，后面那一长串加工链就会迅速变脆。

而 lift 的方向更像是一步到位：直接围绕 schema 抽取 JSON。也就是说，你关心的不是“它看到了多少文字”，而是“它能不能把你要的字段，以你系统能接的结构吐出来”。这两者对业务的意义完全不是一个量级。

为什么这件事现在更值得看

第一，它是9B open-weights。这意味着它不像很多封闭 SaaS 工具那样只能在线调用，理论上更适合被放进企业自己的文档流、审批流和数据流里。

第二，它强调schema-constrained decoding。这很关键，因为企业真正怕的不是“漏一点”，而是“结构乱了、字段飘了、结果没法入库”。只要输出结构稳定，系统化接入的成本会明显下降。

第三，它提到trained abstention，也就是遇到不存在的字段时更倾向于返回空，而不是胡乱编值。别小看这一点，很多业务场景真正贵的不是识别错误，而是“看起来像对的假数据”混进系统后，后面一串流程都被污染。

【1/4 财务票据和报销单】过去最耗人的是字段录入和校验。只要能稳定抽发票号、金额、日期、抬头这些字段，自动化价值就很直接。

【2/4 合同与法务文档】企业不缺 PDF，缺的是把关键条款、时间节点、付款条件整理成可检索、可对比的数据对象。

【3/4 供应链与物流单据】表单长得像，但细节经常不同。如果模型能按统一 schema 吐结果，很多手工搬运和对账动作都能被缩短。

【4/4 行业报告与表格文档】很多分析团队花时间不是在判断，而是在整理资料。能先把数据结构化，后面的分析和可视化才有意义。

市场上不缺“演示很好看”的文档理解工具，真正稀缺的是那种能接到业务里、出错能追、结构能复用、权限能治理的底座。

所以我更在意的，不是某一个 benchmark 数字，而是这类模型开始把目标从“看懂文档”切换到“把文档转成业务对象”。一旦目标变成后者，采购、财务、法务、运营这些部门的使用意愿会完全不同。

换句话说，以前企业买的是一个“更聪明的 OCR”；以后企业更想买的，可能是一台“能把 PDF 直接送进流程系统的数据机器”。

每次聊到这类工具，很多人都会先问一句：是不是谁要被替代了。

我的判断是，更快发生的变化，通常不是岗位消失，而是流程先被压缩。过去需要 3 个人配合、来回核对、分段录入的一串动作，可能先被压成 1 个人做审核和例外处理。

这也是为什么这类工具值得盯紧。因为一旦 PDF 到 JSON 这一步开始真正可控，后面连着变化的，就不会只是一个工具市场，而是整条企业文档处理链的效率模型。