跳到正文
实时
Hugging Face Blog·· 10 天前精选65

Dharma-AI 发布 Dharma Field Extractor:2B 参数模型把任意文档抽取为 JSON 字段

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

要点速览

Dharma-AI 发布 Dharma Field Extractor,一个 2B 参数模型,输入文档图像和可选 schema,输出带类型的结构化 JSON,支持开放抽取与按 schema 定向抽取,未出现的字段返回 null。

Why it matters

原文给出自建基准上的质量与成本对比,读者可据此判断小模型专精路线在字段抽取任务上的可行性。

正文 · AI 翻译

一个拥有20亿参数的模型,能够精确提取您所需的字段,适用于任何文档类型,其性能优于我们测试过的所有前沿大语言模型,且成本仅为其几分之一。

cover_combined_1 在4月份,我们发布了DharmaOCR-LITE,这是一个专门用于广泛文档的OCR模型,从合同和法院文件到发票、身份证和表格。其背后的论文为领域专业化提供了一个狭窄但经过仔细测量的案例:一个更小的模型更接近其任务,在该任务上击败了通用前沿API。

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

然而,有一个不同的用例:您不需要页面,您需要从中提取特定的字段,以便下游系统可以消费。发票上的每一项作为列表。医疗申请单上的患者姓名、检查类型和日期,准备好安排。身份证上的字段映射到员工记录的列。

将文档通过OCR处理,您将获得其上打印的所有内容,逐行显示,没有任何指示哪个字符串是检查类型,哪个是日期或哪个数字是总计。在它到达数据库之前,仍需要有人编写代码来将每个值映射到正确的字段。

通用的大语言模型今天可以完成这项工作,只需仔细提示。在前沿API的定价和延迟下,在许多企业需要以高容量运行的任务上,这很快就会成为解决一个明确定义问题的昂贵方法。

因此,我们为此构建了一个模型。字段提取器接收一个文档图像和一个请求找到所有内容或一个用于填充的精确模式,并返回结构化的JSON:逐字段类型化,在文档嵌套的地方嵌套。发票将返回每个行项目作为一个有序列表,每个列表都有自己的数量和价值,以及总计。身份证将返回您将存储的字段,使用您的系统已经为它们使用的名称。同一个检查点处理所有这些内容,无需每种类型的单独微调。

您可以自己试试这里。

模型的功能

假设每天早上有一批供应商发票到达,您需要从每个发票中提取四个项目以推送到您的系统:供应商、发票号、到期日期、总计。对于进入调度器的医疗申请单,或输入合规系统的合同,重要的是当事人、期限、罚款和罚款金额。您不需要页面,您需要某些字段。使用字段提取器,有两种方法可以请求它们:

field-extractor-1280

  • 开放:未提供模式。模型读取页面并根据上下文和布局确定哪些部分是结构化字段(标签后跟值、带有标题行的表格覆盖其列),而不是从固定的字段名列表中,并返回它找到的所有内容作为键值对。
  • 基于模式: 你可以精确指定所需的结构,逐个字段定义类型(字符串、数字或布尔值),并使用你的系统已有的键名。请求 "service_provider" 和 "client_company",返回的就是这些精确的键。请求一个表格,它会逐行逐列填充,将每个单元格与它所属的键匹配。请求文档中不存在的字段,它会返回 null 而不是编造一个值。

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

无论哪种方式,返回的都是 JSON:字段作为键,值按请求的类型定义,null 表示文档中没有你请求的内容。当你发送一个模式时,输出会严格遵循它,具有相同的键且没有额外的字段,因此可以直接输入到下一个系统。

它是如何训练的

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

数据组织成三个流:

  • 英语多领域数据:从公共网络收集的多样化文档,涵盖多种文档类型。
  • 巴西领域数据:内部来源的真实巴西文档,使用葡萄牙语。
  • 多语言数据:较小的一部分,涵盖其他欧洲和亚洲语言,用于超越英语和葡萄牙语更广泛的泛化。

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

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 GPU 小时的成本,每小时 2.24 美元。

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

一个泛化测试

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

在一个 SROIE 收据上,我们要求打印的所有 18 个字段,这次没有幽灵字段,每一个都正确返回:多行、未标记的账单地址被捕获为一个字段,两个空白字段(销售人员和参考)正确返回为 null,收据上的每个数字都与分币相符。

sroie_combined

在一个 FUNSD 复印差异表上,一个包含十二个布尔字段的清单,其中有一个包含五个子选项的嵌套组,模型准确地标记了被勾选的那个框(原始质量差,旁边有手写的 "褪色" 注释)为 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。

来源

进一步阅读

探索 Dharma AI on Hugging Face 以 尝试我们的交互式演示, 下载我们的开源模型, 并发现专门化 AI 系统如何在实际企业应用中优于通用模型。

来源: Hugging Face Blog · huggingface.co