Dharma Field Extractor 拆解：2B 小模型做文档字段抽取，凭什么赢前沿大模型 1.8 分还便宜 147 倍？

笔名：小六 / 上海 / 1995 女 / 某互联网公司工程师

先说结论

三天前（11 月 4 日），Dharma-AI 在 Hugging Face 博客（团队投稿栏目，非平台官方撰稿）发布 Dharma Field Extractor——一个 20 亿参数的专用模型，输入是文档图片加可选的目标 schema，输出是逐字段类型化、结构嵌套、缺失即 null 的 JSON。它在一个自建基准上拿到 0.834 分，比 Claude Opus 5 的 0.816 高 1.8 个百分点，比 GPT-5.6 Luna 的 0.741 高 9.3 个百分点；成本口径是单张 L40S 自托管，比对照的前沿 API 低 6 到 147 倍。

我的结论：真正值钱的不是”2B 打败前沿”这个结论，而是它把评测口径改成了”字段级 F1 × 值相似度 × JSON 合法率”——这个口径衡量的不是”读起来像不像”，而是”能不能直接进库”。但要注意两件事：评测集是巴西葡语文档，训练数据里也有巴西葡语真实文档，这是主场作战；而且字段抽取模型的权重并没有放出来，只有上一代 OCR 模型在 Hub 上。

发生了什么

官方事实一：发布主体、时间与位置。 主来源是 Dharma-AI 团队在 Hugging Face 社区博客发布的《Dharma Field Extractor: Any Document In, Structured Fields in JSON Out》，页面标注发布日期 2026 年 11 月 4 日（UTC 17:50 落库，折合北京时间 11 月 5 日凌晨），作者共四人，原始 URL 见文末 Q&A。文章定位很明确：不是通用多模态模型的又一次刷榜，而是”文档进、字段出”这个具体工序的专用件。

官方事实二：它要解决的是 OCR 之后那一段。 官方把痛点讲得很直白：OCR 给你的是”页面上印了什么”，逐行忠实还原版式；但很多业务要的不是页面，而是”某几个字段，以某种形状交给下游系统”。比如每天早上到一批供应商发票，你只需要供应商名、发票号、到期日、总额这四项；医疗申请单只关心患者姓名、检查类型、日期；合同只关心签约方、期限、违约金。OCR 把这些都识别出来，但不会告诉你哪个字符串是检查类型、哪个数字是总额——中间那段映射代码，过去得人写，现在官方的主张是让模型直接吐结构化结果。

官方事实三：两种调用模式，对应两种信息状态。 一种叫 open，不给 schema，模型自己判断页面上哪些部分是”标签 + 值”或”带表头的表格”，把找到的都作为键值对返回；另一种叫 schema-directed，你把目标结构逐字段写清楚（每个字段声明 string、number 或 boolean，键名用下游系统已有的名字），模型严格按这个形状填，不多不少。官方还特别写了一条行为约定：请求一个页面上不存在的字段，返回 null，而不是编一个值。

相关背景：这不是第一次。 同一团队今年 4 月发过 DharmaOCR-LITE，论文（arXiv 2604.14314，2026 年 4 月 15 日提交）走的是”专用小模型在窄任务上打赢通用前沿 API”的路线，核心方法论是先用 SFT 强约束 JSON 结构，再用 DPO 把”退化生成”（模型陷入重复循环）当作负样本压下去，论文报告退化率相对下降最高 87.6%。这次的字段抽取模型，是这条路线从”整页转录”往”字段抽取”推进的一步。

技术细节

1. 结构：一个 2B 基座加一个 LoRA 适配器

官方写得很清楚：基座是 DharmaOCR-LITE v1.1，一个 20 亿参数、在论文版本基础上继续优化的检查点，本身已经过 SFT 和 DPO 的 OCR 专精训练；在它之上，团队用 43,384 条训练样本训了一个 LoRA 适配器，同时覆盖 open 和 schema-directed 两种请求模式。也就是说，”字段抽取”这个能力不是从零训出来的，而是在一个已经会读文档的模型上做的一次窄幅增量适配。

训练数据分三路：英文多域数据（从公开网络收集的多种文档类型）、巴西域数据（内部来源的真实葡语文档）、以及占比更小的多语数据（覆盖其他欧亚语言，用于超出英葡的泛化）。三路数据都在字段级做了标注，混合比例刻意做成多域——收据、商业发票、表单、银行流水、身份证件、合成文档都有，而不是死磕单一票据类型。

2. 评测：546 份文档、1,638 个 case、三重乘数

基准设计是这个发布里最值得看的部分。546 份文档分三种请求场景，合计 1,638 个 case：不带 schema 抽全部字段、只给部分真实字段的 schema、以及在 schema 里塞入故意不存在的字段（考”会不会编”）。

评分公式是三段相乘：字段级 F1（按路径匹配，表格内还要匹配行列位置）× 匹配上的值的 Levenshtein 相似度 × 输出为合法 JSON 的比例。这个设计比”整体相似度”狠得多——一个字段错位、一个空值被编成非空、一次输出尾部多一个逗号导致 JSON 解析失败，都会被惩罚，而且是乘法惩罚。

3. 数字：0.834 对 0.816 / 0.741，成本差 6 到 147 倍

同一轮评测里，Dharma Field Extractor 得 0.834；四个通用前沿配置中，最接近的是 Claude Opus 5 的 0.816，差距 1.8 个百分点；最远的是 GPT-5.6 Luna 的 0.741，差距 9.3 个百分点。

成本口径值得单独说，因为它很容易被误读。前沿模型这边是按”每页实测平均输入输出 token 数（含推理 token）乘以各家公开标价”折算，且统一把推理档位设成 low（Opus 5 用自适应档，简单页面会跳过推理）；专用模型这边不是按 token 计价，而是单卡 L40S 的 GPU 时间，按每小时 2.24 美元折算。结果区间是便宜 6 倍（对 GPT-5.6 Luna）到 147 倍（对 GPT-5.6 Sol）。官方自己也在文中留了一句免责：这不是销售价，自托管成本取决于硬件、吞吐和延迟要求。

4. 泛化：两个训练时没见过的公开数据集

为了证明不是只在自己数据上好看，官方拿了 SROIE（收据）和 FUNSD（表单）两个公开集做 held-out 测试。SROIE 那张收据要抽 18 个字段，多行且无标签的账单地址被合成一个字段，两个空白字段（销售员、单号）正确返回 null，每个金额对到分。FUNSD 那张复印差异表单是 12 个布尔字段加一组 5 个嵌套子选项，模型只把真正打了勾的那一项标成 true（原件质量差，旁边还有手写的”faded”），其余 11 项 false，手写的 Bates 编号也读对了，两个空字段返回 null。

这两段描述在工程上比分数更有信息量：它验证的不是”识别率”，而是”该空的时候空”这个行为。

5. 一个容易被忽略的事实：模型没有开源

这一点我专门去 Hub 上核过。截至今天，Dharma-AI 组织下公开的模型只有一个 DharmaOCR-LITE（3B 版本，许可证是自定义的 other，不是 Apache 或 MIT，下载量 612 次）；用 field-extractor 做关键词检索，Hub 上只有两个不相关的第三方仓库。文中”下载我们的开源模型”链接指向的是那个 OCR 模型，不是字段抽取模型；Field Extractor 的试用入口是一个需要登录的在线门户。

换句话说：这是一次有完整方法论和数据披露的产品发布，但不是一次可自托管验证的开源发布。官方给的 0.834 和 6 到 147 倍成本差，目前只能读，不能自己跑。

对 Agent / 工程的影响

立刻能用上的场景：

• 文档摄取流水线：Agent 系统里最脏的一段一直是”把非结构化文档变成工具调用的入参”。schema-directed 模式本质上是把这一步变成”填表”——下游系统先定义字段，模型按字段填，缺失返回 null。这比让 Agent 自由总结再让代码去猜字段名可靠得多。
• 契约优先的抽取：类型声明（string / number / boolean）、键名对齐下游、不存在即 null，这三条合起来构成一个可校验合同。模型只负责”看见并归类”，类型校验、必填校验、枚举校验仍然交给确定性代码——这正是”AI 不替代可确定实现”的正确切法。
• 高频低价值页面：发票、申请单、表单这类每天几千上万页、单页价值不高但错一个字段就要人工返工的场景，6 到 147 倍的成本差是实打实的账。

需要进一步验证的：

• 语言与版面：基准是巴西葡语为主，训练数据里巴西域是真实文档。中文票据、手写体、多栏排版能不能复现这个水平，官方没给数据。
• 成本口径的可比性：GPU 时间不等于总拥有成本。自托管要算上卡的空闲率、并发调度、模型加载、运维人力；API 要算上限流和重试。真正的分水岭通常出现在”稳定高并发”这条线上，而不是单页单价。
• 长文档与跨页字段：官方例子都是单页文档。合同跨 30 页、字段分散在不同页时，切页策略和字段合并逻辑要自己补。

短期不要碰的：

• 别把它当”通用文档理解”用。它是字段抽取器，不做推理、不做摘要、不做跨文档比对。
• 别在权重没拿到的情况下把成本模型写进预算。官方数字是官方环境下的官方口径。

我的判断

第一，这个发布最有价值的产出不是模型，是评测口径。“字段级 F1 × 值相似度 × JSON 合法率”这个三重乘数，把”读起来对”和”能直接进库”分开了；任何做文档抽取的团队，都可以拿这套口径去量自己现有的方案，不需要等模型。

第二，1.8 分的领先要打折，但方向是真的。 评测集是巴西葡语文档，训练数据里就有巴西葡语真实文档，这是主场；但 0.834 的绝对值、以及 SROIE / FUNSD 两个 held-out 集上”该空就空”的表现，说明这条路不是纯刷榜。专用小模型在边界清晰的任务上打赢通用前沿 API，这件事在过去一年已经被反复验证，这次只是把战场推进到”字段级”。

第三，能抄的立刻抄，不能抄的别硬等。 两个接口设计——schema-directed 加缺失返回 null——今天就能用在自己的提示词和工具定义里；权重没发布这件事，短期别指望。

Q&A

Q1：来源/出处？
A：主来源 Dharma-AI 团队《Dharma Field Extractor: Any Document In, Structured Fields in JSON Out》，发布在 Hugging Face 博客（Dharma-AI 团队投稿的社区博客栏目，非 Hugging Face 官方撰稿），页面标注发布日期 2026-11-04，URL：https://huggingface.co/blog/Dharma-AI/dharma-field-extractor 。技术背景来自同团队论文《DharmaOCR: Specialized Small Language Models for Structured OCR that outperform Open-Source and Commercial Baselines》，arXiv 2604.14314，提交日期 2026-04-15，URL：https://arxiv.org/abs/2604.14314 ；模型卡数据来自 Hugging Face 上的 Dharma-AI/Dharma-OCR-LITE 页面。基准里的 SROIE、FUNSD、CORD、DocVQA、WildReceipt 均为公开数据集，原文附有完整引用。

Q2：能不能复现／怎么验证？
A：模型权重未公开，无法本地复现推理，只能走官方登录门户试用。但评测方法可以复现：自建 200 页带人工标注的样本，按”字段级 F1 × 匹配值的编辑距离相似度 × 合法 JSON 比例”算分，再拿自己现在用的前沿 API 跑同一批样本对照，两三个小时就能得到属于自己业务的差值——这比相信任何公开榜单都可靠。想快速摸底线，可以先用 SROIE 或 FUNSD 这两个公开集跑一遍现有方案。

Q3：适用边界是什么？
A：适合边界清晰、字段可枚举、下游已有固定表结构的抽取任务，比如发票、表单、证件、申请单。不适合需要跨文档推理、需要摘要、需要处理超长多页合同、或者字段本身语义模糊（比如”合同风险等级”）的任务。

Q4：和前沿 API 的账到底怎么算？
A：官方口径是单页成本，自托管按单卡 L40S 每小时 2.24 美元的 GPU 时间折算。自己做决策时要换成月度口径：把卡的空闲率、并发峰值、重试率、人工复核比例都算进去，再和 API 的标价加限流成本对比。经验上，稳定日均万页以上、字段集稳定的场景自托管才划算；日均几百页、字段天天变的场景，API 反而更省。

Q5：实施有什么坑？
A：三个。一是”缺失返回 null”这条约定必须在提示词或 schema 里显式写死，否则模型会倾向于填一个看起来合理的值，而这类编造在下游最难排查；二是 schema 里的键名要和数据库列名严格一致，别指望中间再做一层映射——那层映射就是过去 OCR 方案里最耗人的部分；三是 JSON 合法率要作为线上监控指标，输出解析失败率突然上升通常意味着输入分布变了（新票据类型、新扫描质量），而不是模型退化。