金融报告结构化数据提取：6大开源模型横评

在财务报表提取领域，JSON校验器可能是最宽松的审查者——它只检查数字是不是数字，却不关心符号、量级或来源。一个真实的翻车案例：某财报的分部收入表提取结果干净利落，四个经营分部各有收入、周期和单位，schema校验全部通过。但当有人把各分部加总时，得到的数字却超过了合并报表的总收入——模型把「分部间抵销」行读成了正数，抵销项被加回而非扣除。

这份评测聚焦于允许商用的开源权重模型，任务是将报告文本或页面图像转化为收入、周期、单位、量级、分部等字段。前提是文本已可获得：对EDGAR文件来说，这意味着文件自身的HTML；仅对PDF来源才需要OCR。

值得先说明一点：对美国发行人的主报表，你可能根本不需要模型。SEC的XBRL API会以基础单位返回已标记的事实数据。但API遗漏的地方正是模型的价值所在——MD&A和EX-99.1财报发布中的未标记表格、仅以PDF存在的非美国年报，以及后面讨论的分部明细。

六大开源模型排行

1. Qwen3.8-27B：最强的通用提取器

Qwen3.8-27B是Qwen旗下的278亿参数稠密模型，原生支持视觉-语言输入，采用Apache-2.0许可。它能直接读取页面图像，在布局允许时无需单独的OCR步骤。

它在证据和能力两个维度上均排名第一。模型卡报告其在OmniDocBench v1.5上得分91.1，是本次评测生成式模型中最强的文档解析分数。它支持单次请求同时输入文本和图像，在服务层支持时可输出符合JSON-schema语法的结构化结果，原生上下文长达262,144个token，可扩展至100万，足以容纳完整的10-K章节。思考模式默认开启，做提取时应按请求关闭，否则每个字段都要为不必要的推理付出代价。

局限在于体积：自托管27B模型需要大显存GPU，且模型卡未报告金融专用提取分数。它适合需要判断力的schema——分部表格、附注调整，以及需要跨行阅读的字段。

2. NuExtract3：最好的专用提取模型

NuExtract3来自NuMind，专为一件事而生：从文档填充JSON模板。它是Qwen3.5-4B的40亿参数微调版本，Apache-2.0许可，支持文本和图像输入，处理多语言文档，在其模型卡给出的vLLM配置下运行131,072 token上下文。NuMind还发布了FP8和GGUF等量化版本。

模板语言是它的强项。你描述字段，模型在值缺失时返回null或空数组。这在金融领域至关重要：对缺失分部数据选择弃权的模型，比编造一个看似合理数字的模型更值得信任。它还提供推理和非推理模式，并能将页面转换为Markdown，表格以HTML形式呈现。

数据来自NuMind自有基准：在约600份文档（据称包括发票、电影海报和平面图）的内部测试中，NuExtract3得分0.651，其基座Qwen3.5-4B为0.417；在ExtractBench上平均分82.35。两组数据均未说明覆盖财报文件。

3. Qwen3.5-4B：高性价比之选

Qwen3.5-4B是小规模生成模型，权重参数4.66B，Apache-2.0许可。它共享家族的262,144 token上下文，与Qwen3.8一样默认开启思考模式，除非手动关闭。

它的定位是成本。每期从同一报告章节提取十几个字段，小GPU上的4B模型往往够用，规模化时节省的费用就是测试它的理由。模型卡也报告了OmniDocBench v1.5结果，但这里的排名依据是体积和成本。准确度是否足够只有你自己的评估集能回答——用你覆盖的最难申报文件测试它，而非最整洁的那些。

4. Qwen3-4B-Instruct-2507：延迟最稳定

Qwen3-4B-Instruct-2507是较早的4B代际，Apache-2.0许可。其模型卡直白地指出了关键差异：仅支持非思考模式，上下文原生262,144 token。

这使它成为可预测的选择。没有思考token，每字段延迟稳定，适合有响应时间预算的提取服务，输出长度也更易控制。它比Qwen3.5-4B老旧，在更难页面上预期后者会略胜一筹。在同一评估集上跑两者成本很低，能告诉你差距对你的schema是否重要。

5. GLiNER2 Large：CPU上的实体标记利器

GLiNER2来自Fastino，是编码器模型，large权重4.86亿参数，Apache-2.0许可。模型卡描述其在单次前向传播中完成实体识别、分类、结构化提取和关系抽取，并称其「CPU优先」。

速度是卖点。对于命名实体而非计算得出的字段——公司名、审计机构、分部标签或财年末——schema驱动的编码器又快又便宜。它不生成文本，也不跨表格推理，因此需要与两行数据核对的合计数超出其能力范围。它适合管道的第一遍：标记实体、路由页面，再交由生成式模型处理数字。

6. NuNER_Zero：最轻量的零样本标记器

NuNER_Zero来自NuMind，是4.49亿参数的零样本实体标记器，MIT许可。你传入标签，它找到span。

它排名最后是因为任务最小——只标记span，不处理schema，也不理解数字含义。对最简单的字段（公司、审计机构、日期），这已足够，而且这个体量的模型在每份文档上运行都很便宜。其模型卡自2025年2月后未再更新。

OmniDocBench v1.5 是文档解析领域的综合评测基准，覆盖版面分析、表格识别、公式识别和文本识别等子任务，评分越高代表模型在页面图像到结构化内容转换上的整体能力越强。它不等同于金融字段提取准确率——一张表格被正确识别为表格结构，并不保证其中的「抵销」行被赋予正确的符号。因此本文将 OmniDocBench 分数列为发布方证据，而非排序依据。

稀疏与稠密模型 的区分也值得说明。Qwen3.8-27B 属稠密模型，推理时激活全部 278 亿参数，显存占用高但行为可预测；相比之下，混合专家模型只激活部分参数。金融提取需要跨行、跨表核对，稠密模型在长上下文下的稳定性通常更好，代价是自托管门槛更高。

与托管API的对比

托管前沿模型是与上述开源权重不同的服务路径。OpenAI的Structured Outputs保证响应符合提供的JSON schema，Gemini和Claude也提供schema约束输出。提示缓存和批处理定价（约为标价一半）能降低稳定提示的成本。

OpenAI的gpt-6.1-sol定价为每百万输入token 2美元、输出10美元，gpt-6-astra为10美元和50美元。Google Gemini原生读取PDF，将页面作为图像处理，包括表格和图表，文档最多1,000页。Anthropic Claude Sonnet 5.5为2美元和10美元，提供百万token窗口的标准定价。

成本是结构性的：文档要发往提供商的服务。区域数据驻留和零保留条款存在，Azure OpenAI、Vertex AI和Bedrock可在你的云租户内运行，但模型不在你自己的集群中。每token成本也随规模增长。

关键提醒：来自任何提供商的schema遵从性只保证形状。开头案例中的抵销行本可通过严格的JSON-schema输出——因为错误在于符号，而非类型。

如何运行这些模型

Superlinked SIE是面向任务专用模型的推理层，服务于你投入生产的文档模型，与报告管道所需的OCR模型和嵌入器并列。它有三种运行模式：SIE Cloud托管（按使用付费，无需运维GPU）、自托管于你的VPC或Kubernetes集群（同一引擎，Apache 2.0）、以及本地开发。

在Cloud上，Qwen3.8-27B（FP8）以每百万token输入输出均为0.72美元支撑文档字段提取和结构化输出，GLiNER2 Large为每百万输入token 0.186美元，NuNER_Zero也可用。Qwen3.6-27B、Qwen3.5-4B和Qwen3-4B-Instruct-2507在模型目录中供自托管和本地使用。SDK的extract调用接受模型ID和标签列表，文档涵盖Qwen模型的generate，因此在同一评估集上比较两个候选无需第二套服务栈。

排名方法论

没有任何基准决定这个次序，因为所有上榜模型都未发布财报提取分数。排名依据四项标准：模型能处理的字段范围（从实体标签到计算数字）；对schema约束输出的适配度，包括弃权；发布方的证据（如OmniDocBench v1.5或模板提取分数），作为归因声明来阅读；以及运行体积与成本。许可证是门槛而非评分项——每个条目都允许商用。

常见问题

companyfacts没有分部收入怎么办？

companyfacts、companyconcept和frames只包含使用非自定义分类法且适用于整个申报实体的事实，因此分部和维度事实以及公司扩展标签均被排除。应从文件自身的inline XBRL读取：每个ix:nonFraction指向一个contextRef，该上下文携带轴和成员，如StatementBusinessSegmentsAxis和分部成员。按轴和成员提取，将抵销成员单独保留并记录其符号，最后检查分部加抵销是否等于合并数。

companyfacts、companyconcept 和 frames 是 SEC 提供的 XBRL 数据接口，分别返回某实体的全部已标记事实、某单一概念的全部事实，以及跨实体同一概念的事实集合。三者的共同限制是只包含使用标准分类法、且适用于整个申报实体的事实，因此被排除的正是带维度的分部和地区数据，以及发行人自定义的扩展标签。这与财务报表的列报逻辑一致：分部信息本就以轴和成员的形式存在，无法压平为单一实体事实。要拿到分部收入，必须回到文件自身的 inline XBRL，按轴和成员逐一提取，而不能依赖这些聚合接口。

如何避免千与百万的量级错误？

把量级做成字段。在每个数字旁提取单位和量级声明（「以千为单位」「以百万为单位」），然后在代码中归一化，绝不在提示中做。在inline XBRL中量级是标记：显示为「78,678」的数字在其ix:nonFraction元素上带有scale="6"，意味着78,678百万，decimals（如-6）表示舍入精度，是匹配时正确的容差。JSON API返回基础单位，无scale属性，可与之对照。

Inline XBRL（内联 XBRL）是把 XBRL 标记直接嵌入 HTML 的格式，美国发行人的 10-K、10-Q 普遍采用。每个财务数字被包在 ix:nonFraction 元素中，通过 contextRef 关联到上下文，上下文再携带期间、实体以及轴和成员（如分部、地区）。量级由 scale 属性表示，scale="6" 即数值乘以 10 的 6 次方，也就是百万；decimals 表示该数值的舍入精度，是数值比对时合理的容差来源。理解这套标记是绕开「千与百万」陷阱的根本办法——量级不靠模型猜，而是从标记里读。

应该微调还是提示？

先提示。配合类型化schema、少量示例和关闭的思考模式，上述模型在稳定章节上往往能达标，你也能了解它们在哪里失败。只有当评估显示存在无法通过提示消除的一致错误（比如某种申报布局模型持续误读）时，才考虑微调。

从哪里开始

从schema开始，而非模型。需要判断力的字段测试Qwen3.8-27B；严格模板加弃权选NuExtract3；稳定高容量章节用Qwen3.5-4B；实体字段用GLiNER2。SIE在Cloud或你的集群中，以一个API服务于你投入生产的文档模型。