跳到正文
Hugging Face Blog·· 2 小时前精选AI 评分66

Dharma-AI 发布 Dharma Field Extractor：20 亿参数模型把任意文档抽取为 JSON 字段

Dharma Field Extractor: Any Document In, Structured Fields in JSON Out

AI 导读

Dharma-AI 发布 Dharma Field Extractor，一个 20 亿参数模型，输入文档图像后可返回结构化 JSON，支持无 schema 的开放式抽取和按指定 schema 逐字段填充，同一 checkpoint 无需按文档类型微调。

推荐理由

原文给出自建基准上的字段级 F1 与自托管成本对比，读者可据此判断专用小模型在结构化抽取任务上的取舍。

正文 · AI 翻译

一个20亿参数的模型，能从任何文档类型中精确提取你所需的字段，在我们测试过的所有前沿LLM中表现最佳，而成本仅为其一小部分。

cover_combined_1 今年4月，我们发布了DharmaOCR-LITE，这是一个专为OCR打造的模型，覆盖从合同、法院文书到发票、身份证件和表单等各类文档。其背后的论文为领域专业化提出了一个范围明确、论证充分的理由：一个更贴近任务训练的较小模型，在该任务上胜过了通用前沿API。

OCR给你的是页面上的文本，忠实于原始排版。当任务对象是整份文档时——比如你要从头读到尾的合同，或正在数字化的手稿——这正是你想要的。

然而，还有另一种使用场景：你不需要整页内容，你需要从中提取特定字段，并以下游系统可消费的形式呈现。发票上的每一个行项目，作为一个列表。医疗申请单上的患者姓名、检查类型和日期，可直接用于排期。身份证件上的字段，映射到员工记录的各个列。

把那份文档跑一遍OCR，你得到的是上面印着的所有内容，逐行返回，却没有任何信息告诉你哪个字符串是检查类型、哪个是日期、哪个数字是总额。在数据进入数据库之前，仍然得有人编写代码把每个值映射到正确的字段。

如今，通用LLM通过精心设计的提示词就能完成这项工作。但以尖端API的价格和延迟，去处理一项许多企业需要高频运行的任务，很快就会变成用昂贵的方式解决一个定义明确的问题。

于是我们为此专门构建了一个模型。Field Extractor接收一张文档图像，以及要么一个“找出所有可发现内容”的请求、要么一个待填充的精确schema，然后返回结构化JSON：带类型、逐字段、在文档有嵌套处同样嵌套。一张发票返回时，每个行项目都是一个有序列表，各自带有数量和金额，并与总计并列。一张身份证件返回时，就是你将要存储的字段，使用你系统已有的字段名。同一个checkpoint处理所有这些，无需按类型微调。

你可以在这里亲自试用。

模型能做什么

假设每天早上都有一批供应商发票到达，你需要从每张发票上取四样东西推入系统：供应商、发票号、到期日、总额。医疗申请单进入排期系统、合同进入合规系统也是同样的情形，其中重要的是当事方、期限、罚则和罚款金额。你不需要整页内容，你需要特定字段。使用Field Extractor，有两种方式请求这些字段：

field-extractor-1280

  • 开放模式：不提供schema。模型读取页面，根据上下文和布局判断哪些部分是结构化字段（标签后跟值、带表头行的表格），而非依赖固定的字段名列表，并将找到的所有内容以键值对形式返回。
  • Schema 定向：你逐字段指定所需的确切结构，为每个字段指定类型（字符串、数字或布尔值），并使用你系统已在使用的键名。要求 "service_provider" 和 "client_company"，返回的就是这两个确切的键。要求一个表格，它就会逐行、逐列填充，将每个单元格匹配到其所属的键。要求一个文档中不存在的字段，它会返回 null，而不是编造一个值。

选择取决于你已知的信息。当你不知道文档包含什么时，发送开放式请求。当输出必须匹配某个已存在于别处的结构时，发送 schema。

无论哪种方式，返回的都是 JSON：字段作为键，值按请求的类型化，文档中没有你所要求的内容时则为 null。当你发送 schema 时，输出完全遵循它，键相同且没有多余字段，因此可以直接进入下一个系统。

训练方式

基础模型是 DharmaOCR-LITE v1.1，这是一个新的 20 亿参数版本，从论文中的版本优化而来，并已通过监督微调和 DPO 专门针对 OCR 进行了特化。在这个检查点之上，我们在覆盖两种请求模式的 43,384 个训练样本上训练了一个 LoRA 适配器。

数据被组织为三个流：

  • 英语多领域数据：从公共网络收集的多样化文档，涵盖多种文档类型。
  • 巴西领域数据：内部获取的真实巴西文档，语言为葡萄牙语。
  • 多语言数据：占比较小的部分，涵盖其他欧洲和亚洲语言，以便在英语和葡萄牙语之外实现更广泛的泛化。

三个流都在字段级别进行了标注。这个混合是刻意多领域的：收据、商业发票、表单、银行对账单、身份证件和合成文档，而不是单一的文件类型。

03_training_data_mix_v2

基准测试的界限

完整基准涵盖三种请求场景下的 546 份文档，共 1,638 个案例：在没有 schema 的情况下提取每个字段、仅命名真实字段的部分 schema，以及还包含故意不存在的字段的 schema。分数是字段级 F1（按路径匹配，包括表格内的位置），乘以匹配值的 Levenshtein 相似度，再乘以返回有效 JSON 的输出占比。

我们对四种通用前沿配置运行了相同的基准测试。

image

与通用 LLM 相比，质量差距从 1.8 分（Claude Opus 5，最接近）到 9.3 分（GPT-5.6 Luna，差距最大）。

image

成本从大约低 6 倍（GPT-5.6 Luna）到大约低 147 倍（GPT-5.6 Sol）。两边的定价方式不同。前沿数据来自实测的每页平均输入和输出 token 数（包括推理 token），对照各提供商公布的列表定价。每个前沿模型都以低推理设置运行；Claude Opus 5 使用了自适应努力，可以在较简单的页面上跳过推理，同时保持在低水平。我们的模型不按 token 计费：模型以自托管方式运行，因此该数字是单块 L40S 上每小时 2.24 美元的 GPU 时间。

这不是销售价格。自托管成本取决于硬件、规模和每个部署所需的延迟。此处的比较是为了表明，部署在你自己的基础设施上的主权 SSLM 是前沿 API 的真正替代方案。

泛化能力测试

SROIE 和 FUNSD 是我们基准测试中的两个公开数据集，未用于训练。下面是每个数据集的一个示例。

在一张 SROIE 收据上，我们要求提取其上印有的全部 18 个字段，这次没有出现多余字段，每一个都返回正确：多行、无标签的账单地址被捕获为单个字段，两个空白字段（salesperson 和 ref）正确返回为 null，收据上的每个数字都精确到分匹配。

sroie_combined

在一张 FUNSD 复印差异表上，这是一份包含十二个布尔字段的清单，其中有一组五个子选项的嵌套组，模型恰好将唯一勾选的框（原件质量差，旁边有手写的“faded”备注）标记为 true，其余十一个标记为 false，与表格完全一致。它还正确读取了页面上的手写 Bates ID，并对两个留空字段返回 null。

funsd_combined

质量与成本，兼而得之

一个 20 亿参数的模型得分为 0.834，高于我们测试过的所有前沿配置，从 Claude Opus 5 的 0.816 到 GPT-5.6 Luna 的 0.741，同时运行在单块 L40S 上，每次提取的成本低于对比中的所有 API。在同一基准、同一次运行中测得，质量更高、成本更低。

这不是我们第一次测出这样的结果。我们的 OCR 论文让首个 DharmaOCR-LITE（一个 30 亿参数的模型）在巴西葡萄牙语上超过了所有测试过的商业前沿 API；三个月后，更新、资源更充足的模型出现，差距依然保持。现在，一个 20 亿参数的模型在字段提取上做到了这一点。每个结果都为我们创办 Dharma-AI 时的论点增添了证据：在有界任务上，一个针对该任务近距离训练的小模型，胜过被要求以通用方式完成同样任务的前沿模型。在这个基准中，它的运行成本还低了 6 到 147 倍。

参数数量决定上限；训练决定模型在你的任务上能达到多少。你的业务不需要可用的最大模型，它需要一个为你的问题而训练的模型。

在这里用你自己的文档试一试。要了解更多关于 Dharma-AI 以及我们构建的专用模型，请访问 dharma-ai.com。

来源

延伸阅读

探索 Hugging Face 上的 Dharma AI，试用我们的交互式演示，下载我们的开源模型，并了解专精化 AI 系统如何在真实企业应用中胜过通用模型。

来源：Hugging Face Blog · huggingface.co

Hugging Face推理能力数据与训练模型发布#模型发布#推理#数据/训练#Hugging Face