先看证据
OCR给出文字，字段提取给出可用数据
OCR 的任务是把页面上的文字转出来。若业务系统需要的是发票号、到期日、金额，或医疗申请上的姓名和检查类型，单有一串识别文本还不够：还得有人或一段程序判断哪个值对应哪个字段。Dharma-AI 此前发布的 DharmaOCR-LITE 面向 OCR；这次的 Field Extractor 则把目标放在从文档图像中提取指定字段并整理成 JSON。
发布方认为，通用大模型也能通过仔细设计提示词完成字段抽取，但高频处理时，API 费用和延迟可能成为负担。这是 Dharma-AI 对产品需求的说明，不是独立验证过的普遍结论；这款模型是否合适，仍取决于具体文档和部署条件。
不确定字段时开放提取；已有格式时给出 schema
Field Extractor 有两种请求方式。开放模式不预先给出字段清单，模型根据页面内容和版式识别标签—数值配对、表格等结构，并把找到的内容作为键值对返回。适合还不知道文档里有哪些字段、希望先提取可识别内容的情况。
Schema-directed 模式则由调用方指定字段名、类型和结构，例如字符串、数字或布尔值。模型按这些键名返回结果；文档里没有所需字段时，博客称它会返回 `null`，而不是补造一个值，也不会在 schema 输出中额外添加字段。对于表格，目标是按行、列对应单元格；博客举例称，发票明细可作为有序列表返回。材料没有提供覆盖各类复杂表格的独立测试结果。
基础模型与训练数据：两种请求模式共用一个适配器
Dharma-AI 称，Field Extractor 以 DharmaOCR-LITE v1.1 为基础。该版本已经通过监督微调（SFT）和直接偏好优化（DPO）针对 OCR 做过训练；团队再在其上训练 LoRA 适配器，使用 43,384 条覆盖两种请求模式的样本。博客将基础模型参数量写为 20 亿。
训练数据分为三路：从公开网络收集的多领域英文文档、内部来源的巴西葡萄牙语真实文档，以及占比较小的其他欧洲和亚洲语言数据。样本按字段标注，文档类型包括收据、商业发票、表格、银行对账单、身份证件和合成文档。链接的 DharmaOCR-LITE 模型卡则描述为 30 亿参数；发布文章没有解释这与文中 20 亿参数的版本如何对应。
546份文档构成基准，结果仍是发布方报告
Dharma-AI 的基准包含 546 份文档、共 1,638 个测试案例，分为三种场景：不提供 schema、提取全部字段；只提供真实字段的部分 schema；以及加入文档中不存在字段的 schema。评分采用字段级 F1，按字段路径匹配，并结合匹配值的 Levenshtein 相似度及输出为有效 JSON 的比例。
发布方报告的综合分数为 0.834，高于其测试配置中的 Claude Opus 5（0.816）和 GPT-5.6 Luna（0.741）。博客称测试的前沿模型均以低推理设置运行；Claude Opus 5 使用 adaptive effort。结果支持的范围是这组内部基准和所测配置，并不能据此推断模型优于所有通用模型或适用于所有文档。
成本比较取决于部署口径
博客报告，Field Extractor 的自托管成本比被测 API 低约 6 至 147 倍：比较区间的两端分别对应 GPT-5.6 Luna 和 GPT-5.6 Sol。API 成本按各供应商公开单价及每页实测平均输入、输出 token 数估算，其中包括推理 token；自托管一侧则按单张 L40S、每小时 2.24 美元的 GPU 时间计价。
这不是一份可直接套用到所有部署的报价。Dharma-AI 也提醒，自托管成本会随硬件、处理量和延迟要求变化。GPU 小时成本与 API 按 token 计费并非完全相同的口径，因此这组数字应理解为发布方在所述假设下的比较，而不是每个用户都能实现的节省幅度。
SROIE与FUNSD示例展示了什么，又没有证明什么
Dharma-AI 称 SROIE 和 FUNSD 是未参与训练的公开数据集，并各展示一个例子。在 SROIE 收据上，模型按开放请求提取全部 18 个字段；博客特别提到，多行且没有标签的账单地址被作为一个字段处理，两个空白字段返回 `null`，金额也与收据上的数值相符。
FUNSD 示例是一张复印件形式的表单，含 12 个布尔字段和一个包含五个子选项的嵌套组。博客称，模型把唯一勾选项标为 true，其余 11 项标为 false；它还读出了手写 Bates ID，并对两个空白字段返回 `null`。这些案例说明模型在这两份样例上的表现，不能替代对不同文档类型、扫描质量和语言的系统评测。