8B小模型票据反超GPT-5.6

一台只有24GB内存的笔记本，跑一个Q4量化的8B视觉模型，在137份脏乱业务文档上以59%的整份正确率超过了GPT-5.6 Terra的57%。

这不是Qwen3-VL 8B在所有视觉任务上战胜前沿闭源模型的证明，但它暴露了一个更值得关注的变化：在格式固定、字段密集、容错率接近零的票据提取任务里，小型本地模型已经不只是便宜的替代品，而可能成为某些垂直场景里的最优解。

这项测试于2026年9月26日运行，并在9月28日公开。测试者使用搭载M5芯片和24GB统一内存的笔记本，通过Ollama运行Qwen3-VL 8B Instruct的Q4_K_M量化版本，平均每份文档约需30秒。对手则是Claude Opus 5.5、Claude Sonnet 5，以及测试报告中标记为GPT-5.6 Terra的模型。需要强调的是，GPT-5.6 Terra是测试仓库采用的模型名称，本文不进一步推断其服务配置或内部推理档位。(reddit.com)

137份文档，要求一个字段都不能错

整份文档完全正确率是指一份文档内所有目标字段均正确，任何一个字段出错都将整份文档判为失败。

这个指标比常见的OCR字符准确率或字段平均准确率严苛得多。企业处理发票、税表和银行流水时，识别出99个字段却把第100个字段的金额读错，通常仍然需要人工复核整份文件；因此，测试者把“整份完全正确”设为核心指标，而不是用大量简单字段稀释少量致命错误。

测试集共包含137份文档，覆盖六类材料：

• 30张印度尼西亚CORD收据；
• 30张马来西亚SROIE收据；
• 20张来自20世纪80至90年代的扫描发票；
• 32份基于美国国税局正式版式生成的W-2税表；
• 10份合成的印度银行对账单；
• 15份来自CUAD数据集的真实合同。

其中，W-2税表专门为本轮测试生成，并被施加了4档图像损坏，因此不存在被模型直接记住测试样本的可能。公开收据和合同数据则可能出现在部分模型的训练语料中，这也是这项社区测试不能直接等同于标准化盲测的原因。(github.com)

Qwen只赢了3份文档，但字段识别优势更明显

Qwen3-VL 8B在整份正确率上只领先GPT-5.6 Terra两个百分点，但在字段级准确率上领先3.4个百分点。

| 模型 | 字段正确率 | 整份文档正确率 | 完全正确文档数 | |---|---:|---:|---:| | Claude Opus 5.5 | 98.1% | 89% | 122/137 | | Claude Sonnet 5 | 97.6% | 85% | 116/137 | | Qwen3-VL 8B Instruct Q4_K_M | 92.7% | 59% | 81/137 | | GPT-5.6 Terra | 89.3% | 57% | 78/137 |

这个结果需要同时从两个方向解读。

一方面，Qwen3-VL 8B确实以81份完全正确文档超过了GPT-5.6 Terra的78份，而且是在本地Q4量化条件下完成的。对于数据不方便上传、需要离线运行或业务量足够大的团队，这种性能已经具备部署价值。

另一方面，两者只相差3份文档，尚不足以证明Qwen在通用文档理解能力上稳定领先。测试者也明确指出，每类文档只有10至32份样本，几个百分点的差距可能属于统计噪声；两次相同配置的GPT-5.6 Terra运行，在某个类别上的结果最多相差4个百分点。

真正拉开差距的是W-2税表，而不是所有类别都由Qwen获胜。

W-2税表成为Qwen的主场

Qwen3-VL 8B在32份W-2税表中完整答对21份，GPT-5.6 Terra只答对7份。

换算成正确率，Qwen达到65.6%，GPT-5.6 Terra为21.9%；前者的完全正确文档数正好是后者的3倍。

W-2税表是一类高度结构化文档，它的字段位置、编号和语义关系相对稳定，但同时包含姓名、地址、社会安全号码、工资、预扣税等大量容易串行或错位的字段。模型不仅要看清字符，还要理解“第1栏”和“第2栏”分别对应什么，并把值映射到正确的结构化字段。

Qwen在这里的优势说明，它的强项并不只是传统意义上的OCR，而是视觉布局与字段语义的联合建模。**视觉语言模型是同时处理图像、文本和空间布局关系的多模态模型。**与先把图片转成纯文本、再由语言模型整理字段的两段式流程相比，视觉语言模型可以直接理解某个数字位于哪一个表格单元、靠近哪一个标签，以及它在整张表中的层级关系。

Qwen官方将Qwen3-VL定位为支持图像、视频与文本理解的视觉语言模型系列，并强调其对文档结构解析、低光照、模糊、倾斜图像及多语言OCR的增强。官方仓库称其OCR覆盖32种语言，原生上下文达到256K，并可通过YaRN扩展至更长上下文；Qwen3-VL 8B Instruct权重采用Apache 2.0许可发布。(github.com)

印度银行流水暴露的不是OCR问题，而是日期常识问题

Qwen在10份印度银行对账单中只完整答对2份，但金额、交易额和余额几乎全部识别正确。

失败集中在日期字段：模型把印度常用的日-月-年格式dd-mm-yyyy，当成了美国常用的月-日-年格式mm-dd-yyyy。

例如，文档中的05-06-2026在印度语境下通常表示2026年6月5日，模型却可能归一化为2026年5月6日。图片里的数字并没有看错，错误发生在模型试图解释这些数字时。

**日期格式归一化是把不同地区、语言和书写习惯中的日期，转换为统一机器格式的过程。**这一步看似简单，实际上需要模型结合国家、币种、银行名称、地址和整份文档的语言环境做判断。若模型过度依赖美国格式的统计先验，即使字符识别达到100%，最终结构化结果仍然会失败。

这也是文档AI最难处理的一类错误：它看起来像OCR错误，实质上是区域语义错误。单纯提高图像分辨率、换用更高精度量化或让模型重新检查答案，未必能解决问题。

测试中的自检结果也支持这一判断。研究者让模型重新查看原始文档和自己的第一次输出并进行纠正，但137份文档中有119份答案原样返回；以GPT-5.6 Terra为例，自检只修好1份，同时又改坏了1份。模型如果没有意识到自己的日期规则假设有问题，多思考一遍通常只是重复原判断。(reddit.com)

长合同仍然不是8B模型擅长的战场

Qwen3-VL 8B在15份长合同中只完整答对2份，主要错误集中在合同到期日。

合同日期与票据日期不是同一种任务。票据通常只有一个交易日期，且附近会出现Date、Transaction Date之类的明确标签；合同可能同时出现签署日、生效日、初始期限、自动续期日、通知截止日和最终到期日，同一日期还可能通过“生效后36个月”等相对表达出现。

这要求模型跨越多个页面寻找条款，并判断哪个日期才是问题要求的法律意义上的到期日。8B模型即使拥有足够长的理论上下文，也不意味着它能在长上下文中稳定建立事件关系。上下文窗口解决的是“能不能放进去”，长文档推理解决的是“放进去后能不能找对、连对和算对”，两者不能画等号。

Claude Opus 5.5和Sonnet 5最终分别取得89%和85%的整份正确率，说明前沿闭源模型在跨页面语义整合、异常格式处理和长文本推理上依然有明显优势。Qwen与Opus之间相差30个百分点，与Sonnet之间相差26个百分点，这不是靠一次提示词微调就能抹平的差距。

因此，Qwen3-VL 8B更适合字段固定、布局稳定、允许增加校验规则的文档流水线，而不是直接替代律师或财务人员处理任意长合同。

本地部署时，选错Ollama标签可能直接拿不到答案

Ollama中的默认qwen3-vl:8b标签曾指向Thinking版本，而不是本次跑分采用的Instruct版本。

测试者发现，默认版本在长合同任务中会把4,096个输出Token全部用于思考，最终没有返回可用正文；即使设置think:false，也可能被模板忽略。本次有效成绩来自qwen3-vl:8b-instruct。

这个问题不是孤例。Ollama的GitHub Issue显示，qwen3-vl:8b使用的模板一度缺少思考开关逻辑，导致think:false被静默忽略；在一个复现案例中，4,096 Token预算全部被思考内容消耗，最终答案为空。Issue给出的直接规避方式同样是使用Instruct模型。(github.com)

**Instruct模型是针对直接执行用户指令和输出最终答案进行微调的版本。**Thinking模型则会分配更多Token进行显式推理，在数学和复杂逻辑问题上可能更有价值，但文档字段提取通常更需要稳定、短促、格式严格的输出。

对于批量票据任务，Thinking版本甚至可能适得其反。每份文档多消耗数千Token，不但拉高延迟，还增加输出被截断、JSON结构损坏或最终答案缺失的概率。若任务只是提取日期、金额和编号，Instruct往往比Thinking更符合生产需求。

GPT-5.6的“主动纠错”在票据场景里反而是风险

GPT-5.6 Terra在测试中会主动修正它认为不自然的人名或地名拼写。

测试者举出的例子包括把Rachael改为Rachel，把Kelleyland改为Kellyland。对于普通问答，这种修正常被视为语言能力；对于票据、合同和身份材料，它却是一种数据污染。

文档提取的目标不是输出“最合理的文字”，而是忠实还原原始文件。姓名少一个字母、公司名被自动规范化、发票编号中的字母O被替换成数字0，都可能造成数据库匹配失败。

这说明评估文档模型不能只看它是否理解了内容，还要看它是否愿意克制。生成式模型习惯补全、纠错和润色，而高可靠OCR系统恰恰要求模型在不确定时少做推断，保留原始拼写，并输出置信度或异常标记。

这项测试有价值，但还不能当成最终排行榜

这项社区基准最大的价值是公开了提示词、答案、评分器和原始输出，而不是制造了一个新的模型排名。

测试仓库提供了每个模型的原始结果、评分脚本、答案校验记录和95% Wilson置信区间，复现透明度高于只发一张跑分截图的横评。测试者还发现，30张SROIE收据中至少有4张的公开答案键可能有误，例如票面印刷的是81750，标签却写成B1750；这提醒开发者，模型评测的上限经常由答案质量决定。(github.com)

不过，这仍然是一项由单个测试者完成的小样本实验。测试没有覆盖更多量化精度、不同图像分辨率、不同提示词、批处理吞吐和多次重复运行，也没有测试Gemini或GPT-5.6 Luna。Qwen使用本地Ollama，Claude通过Claude Code CLI运行，不同服务链路的图像预处理也可能影响结果。

此外，报告称各模型按标价计算的单份文档成本均低于0.01美元，因此这轮测试真正拉开差异的并不是单次调用价格，而是隐私、离线能力、可定制性和长期规模化成本。Qwen可以在本地部署和微调，闭源模型则免去了设备管理成本，并提供更强的长文档综合能力。

OpenAI Hub判断：Qwen已经能进生产，但必须给它加护栏

Qwen3-VL 8B已经达到可用于特定票据生产流程的水平，但不能在没有规则校验的情况下直接写入核心业务系统。

它最适合以下场景：

1. 文档版式相对固定，例如税表、报销单、物流单和标准发票；
2. 数据不能离开本地设备或企业内网；
3. 业务方拥有确定的字段规则，可以校验金额、币种和日期；
4. 错误样本可以持续积累，用于LoRA微调或提示词迭代；
5. 允许把低置信度和规则冲突的文档转交人工复核。

它暂时不适合以下场景：

1. 跨国家、跨语言且日期格式混杂的银行文件；
2. 需要识别多个法律日期并判断条款关系的长合同；
3. 姓名、地址和编号必须逐字符忠实保留的零容错流程；
4. 缺少人工抽检、字段校验和异常回退机制的全自动系统。

真正可用的方案不是“把PDF扔给模型”，而是模型加规则引擎。日期字段应结合国家、币种和银行所在地锁定格式；金额字段应检查期初余额、交易流水和期末余额能否对上；姓名和编号应禁止自动纠错；长合同则应先按条款切分，再分别提取签署日、生效日和到期日。

Qwen3-VL 8B这次最重要的成绩，也不是比GPT-5.6多答对了3份文档，而是证明了一台普通高内存笔记本已经能运行具备实际业务价值的文档视觉模型。它的错误模式也足够清晰：表格和金额很强，区域日期规则薄弱，长距离法律语义仍不可靠。

对于开发者来说，这比一句“小模型击败大模型”更有用。知道模型在哪里会赢，只决定你要不要试；知道它会在哪里稳定犯错，才决定你敢不敢上线。

参考来源

• Reddit：Qwen3-VL 8B与多款闭源模型的137份文档实测：测试者发布的结果摘要、设备配置和主要错误案例。
• GitHub：messy-docs-bench完整评测仓库：包含测试方法、答案键、评分器、原始输出及限制说明。
• GitHub：Qwen3-VL官方仓库：Qwen3-VL系列的能力说明、上下文长度、模型版本和部署资料。
• Hugging Face：Qwen3-VL-8B-Instruct模型页：官方权重、许可证、模型信息及支持的推理框架。
• GitHub：Ollama思考开关失效问题：记录qwen3-vl:8b忽略think:false并耗尽输出预算的问题。