跳到正文
原文
Hugging Face Blog·· 2 小时前

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

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

SI 导读

Dharma-AI 发布 2B 参数 Dharma Field Extractor 模型，可从任意文档图像提取指定字段并输出 JSON，基准质量超前沿 LLM 且成本仅 1/6 至 1/147。

精选SI 评分62
推荐理由

该2B参数模型在文档字段提取上超越测试的前沿LLM，且运行成本仅其1/6至1/147，显示专用小模型优势。

#模型发布#多模态#开源生态#Hugging Face
正文 · SI 翻译

一个 20 亿参数的模型，可从任何类型的文档中精确提取您所需的字段，性能超越我们测试过的所有前沿大语言模型，且成本仅为后者的一小部分。

cover_combined_1 今年四月，我们发布了 DharmaOCR-LITE，这是一款专为广泛文档类型的 OCR 优化的模型，涵盖从合同、法庭文件到发票、身份证件和表格。其背后的论文为领域专业化提出了一个狭窄但经过精确论证的观点：一个更贴近其任务训练的较小模型，在该特定任务上击败了通用型前沿 API。

OCR 为您提供页面上的文本，并忠实于原始格式。当任务涉及整个文档时，例如您需要通读的合约或正在数字化的手稿，这正是您想要的。

然而，存在另一种使用场景：您不想要整页内容，而是想要从中提取特定字段，并以下游系统可消费的格式呈现。例如，将发票上的每一行项目作为列表；从医疗申请单中提取患者姓名、检查类型和日期，以便直接安排日程；或者将身份证件上的字段映射到员工记录的列中。

将该文档通过 OCR 处理后，您会得到上面打印的所有内容，逐行返回，但没有任何指示说明哪个字符串是检查类型，哪个是日期，或者哪个数字是总计。在数据到达数据库之前，仍有人需要编写代码将每个值映射到正确的字段。

通用型大语言模型今天就可以通过精心设计的提示词完成这项工作。但在前沿 API 的定价和延迟下，对于许多企业需要高频率运行的任务而言，这很快就会成为解决一个定义明确问题的昂贵方式。

因此，我们为此构建了一个模型。Field Extractor 接收文档图像以及一个请求（可以是查找所有可识别内容，也可以是一个待填充的精确模式），并返回结构化的 JSON：按类型、逐字段、并在文档嵌套处进行嵌套。发票返回时，每一行项目都作为有序列表，每项包含其数量和金额，旁边是总计。身份证件返回时，则是您将要存储的字段，使用您的系统已经使用的名称。同一个检查点处理所有这些，无需针对每种类型进行微调。

您可以在此自行尝试。

模型的功能

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

field-extractor-1280

  • 开放模式：不提供模式。模型阅读页面，并根据上下文和布局（而非固定的字段名称列表）确定哪些部分是结构化字段（标签后跟值，或带有表头行的表格），然后将其发现的所有内容作为键值对返回。
  • 模式导向：你逐字段指定所需的精确结构，并为每个字段指定类型（字符串、数字或布尔值），使用你的系统已有的键名。请求“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）。双方定价不同。前沿数字来自每页测量的平均输入和输出令牌（包括推理令牌），对照各提供商公布的列表价格。所有前沿模型都设置为低推理；Claude Opus 5 使用自适应努力，可以在更简单的页面上跳过推理，同时保持在低水平。我们的不按令牌计费：模型自托管，因此数字是单个 L40S 上每小时 2.24 美元的 GPU 时间。

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

泛化能力测试

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

在一张 SROIE 收据上，我们要求提取其上打印的所有 18 个字段，这次没有虚构字段，且所有字段均正确返回：多行且无标签的账单地址被捕获为单个字段，两个空白字段（销售员和参考号）正确返回为 null，收据上的每个数字都精确匹配到分。

sroie_combined

在一张 FUNSD 复印差异表上，该表单包含一个由 12 个布尔字段组成的清单，以及一个包含 5 个子选项的嵌套组。模型准确地将唯一被勾选的框（原始质量差，旁边有手写“褪色”备注）标记为 true，其余 11 个标记为 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

© 2026 SI·Hot · Super Intelligence Hot · 超级智能热点 · 网站数据均来源于网络公开资料，版权归来源方所有