跳到正文
RadarAI· Hugging Face 社区博客（混合发现）·· 3 小时前AI 评分58

Dharma-AI 发布 20 亿参数 Dharma Field Extractor 模型，文档图片直出结构化 JSON

Dharma-AI 发布 20 亿参数 Field Extractor 模型，文档图片直出结构化 JSON

AI 导读

Dharma-AI 在 Hugging Face 发布 20 亿参数的 Dharma Field Extractor，可将文档图片按开放或指定 schema 两种方式抽取为带类型的结构化 JSON，缺失字段返回 null。

正文 · AI 翻译

Hugging Face 社区博客·2026-11-05 01:50· 1 小时前AI 评分55

Dharma Field Extractor：任意文档输入，结构化字段以 JSON 输出

AI 导读

Dharma-AI 在 Hugging Face 发布 Dharma Field Extractor，一个 20 亿参数模型，基于 DharmaOCR-LITE v1.1 训练 LoRA 适配器（43,384 条样本），支持开放和按 schema 两种请求方式，将文档图片转为带类型的结构化 JSON，缺失字段返回 null。

正文 · 原文

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

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

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

训练方式

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

数据被组织为三个流：

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

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

03_training_data_mix_v2

基准测试的界限

完整基准测试覆盖三种请求场景下的 546 份文档，共 1,638 个案例：无模式提取所有字段、仅命名真实字段的部分模式，以及还包含故意不存在的字段的模式。分数是字段级 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 社区博客 · huggingface.co

来源：RadarAI · aihot.news

Hugging Face多模态开源生态模型发布#模型发布#多模态#开源/仓库#Hugging Face