Today for AI
返回全部资讯
Dharma Field Extractor 发布 2B 参数模型实现文档结构化提取Hugging Face BlogT1·基座大模型

Dharma Field Extractor 发布 2B 参数模型实现文档结构化提取

原标题：Dharma Field Extractor: Any Document In, Structured Fields in JSON Out
68AI 研判分

Dharma AI 团队发布了 Dharma Field Extractor，这是一个拥有 20 亿参数的专用小语言模型。该模型旨在从任意类型的文档中精确提取用户指定的字段并输出为 JSON 格式，声称在成本显著低于前沿大模型的情况下，性能超越了测试中的所有主流 LLM。

报道正文

本文目录7 个章节

返回文章列表

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

团队文章 发布于 2026 年 11 月 4 日 点赞 8

一个拥有 20 亿参数的模型，能够从任意类型的文档中精准提取你所需的字段，性能超越我们测试的所有前沿 LLM，且成本仅为其中的一小部分。

cover_combined_1 今年四月，我们发布了 DharmaOCR-LITE，这是一款专门用于处理各类文档 OCR 的模型，涵盖合同、法庭文件、发票、身份证件及表格等。其背后的 论文 为领域专业化提供了严谨且有据可依的论证：在特定任务上，经过针对性训练的小型模型能够击败通用型前沿 API。

OCR 能够还原页面上的文本，并忠实保留原始格式。当你的需求是获取整个文档内容时——例如通读一份合同或将手稿数字化——这正是你所需要的。

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

如果将该文档通过 OCR 处理，你会得到页面上打印的所有内容，逐行排列，但无法指明哪个字符串是检查类型，哪个是日期，或哪个数字是总额。仍需有人编写代码，将每个值映射到正确的字段，然后才能存入数据库。

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

因此，我们专门为此构建了一个模型。Field Extractor 接收文档图像，以及“提取所有可识别内容”的请求或一个待填充的精确 Schema，并返回结构化 JSON：逐字段类型化，并根据文档的嵌套结构进行相应嵌套。发票会返回包含每个行项目（line item）的有序列表，每项均带有其数量和金额，同时附带总计信息。身份证件则返回你需要存储的字段，并使用你系统中已有的名称作为键名。同一个检查点（checkpoint）即可处理所有这些情况，无需针对每种类型进行微调。

你可以在此处亲自试用。

模型功能

假设每天早晨都会收到一批供应商发票，而你需要从中提取四项信息推送到你的系统：供应商、发票号码、到期日和总金额。对于进入调度系统的医疗申请单，或输入合规系统的合同，情况也是如此——关键在于当事方、期限、罚则和罚款金额。你不需要整页内容，只需要特定字段。使用 Field Extractor，有两种方式来请求这些字段：

field-extractor-1280

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

选择取决于你已掌握的信息。如果你不知道文档包含什么内容，就发送开放式请求；如果输出必须匹配某个已存在的结构，则发送 schema。

无论哪种方式，返回的都是 JSON：字段作为键，值按请求类型进行格式化，而当文档中缺少所请求的内容时，对应位置为 null。当你发送 schema 时，输出将严格遵循该 schema，保持相同的键且不包含额外字段，因此可以直接接入下一个系统。

训练方法

基础模型是 DharmaOCR-LITE v1.1，这是一个新推出的 20 亿参数版本，基于论文中的模型进行了优化，并通过监督微调（SFT）和直接偏好优化（DPO）专门针对 OCR 任务进行了定制。在此基础上，我们使用涵盖两种请求模式的 43,384 个训练样本训练了一个 LoRA 适配器。

数据分为三个流：

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

所有三个数据流均进行了字段级标注。数据混合刻意采用多领域策略：包括收据、商业发票、表单、银行对账单、身份证件以及合成文档，而非单一类型的文件。

03_training_data_mix_v2

基准测试的评估标准

完整的基准测试涵盖三种请求场景下的 546 份文档，共计 1,638 个案例：无 schema 提取所有字段、仅包含真实字段的 partial schema，以及包含故意不存在的字段的 schema。评分指标为字段级 F1（通过路径匹配，包括表格内的位置），并乘以匹配值的 Levenshtein 相似度以及有效 JSON 输出的比例。

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

image

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

成本范围从大约低 6 倍（GPT-5.6 Luna）到大约低 147 倍（GPT-5.6 Sol）。双方的定价方式不同。前沿模型的数字基于每个提供商公布的列表价格，通过测量每页的平均输入和输出 token 数（包括推理 token）得出。所有前沿模型均将推理设置为“低”级别运行；Claude Opus 5 使用了自适应努力策略，这可以在处理较简单的页面时跳过推理步骤，同时保持低级别的设置。我们的模型不按 token 计费：该模型是自托管的，因此该数字反映的是在单张 L40S GPU 上以每小时 2.24 美元计算出的 GPU 时间。

这不是销售价格。自托管成本取决于硬件、吞吐量以及每次部署所需的延迟。此比较旨在表明，部署在您自己基础设施上的主权 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。

Sources