百炼视觉理解与 OCR 文字提取：模型选型专题
适用场景 ：从手机截图、扫描件、票据图像中抽取结构化字段（金额、编号、时间、户名等），版式多变、可能多语言、可能多图拼接。
本文不涉及具体业务系统实现，仅从阿里云百炼（Model Studio）产品线与 API 行为出发，说明如何「对口选型」而非「能用就行」。
一、专题概要：先搞清「两条产品线」
很多人第一次选型会踩同一个坑：把「视觉理解旗舰」和「OCR 文字提取」当成一回事 ，然后在错误的文档里找模型、套错误的参数，最后报 InvalidParameter。
百炼实际上是这样分的：
| 维度 | 视觉理解（Vision Understanding） | 文字提取 / Qwen-OCR |
|---|---|---|
| 文档入口 | 视觉理解 | 文字提取 |
| 代表模型 | qwen3.7-plus、qwen3.7-flash、qwen3.8-max |
qwen3.5-ocr、qwen-vl-ocr 系列 |
| 训练目标 | 通用看图、看视频、GUI/Agent、语义推理 | 文档解析、文字定位、票据/卡证信息抽取 |
| 输入模态 | 文本 + 图像 + 视频 | 主要是图像（部分支持 PDF） |
| 输出 | 文本（可结构化 Prompt） | 文本 / ocr_result 结构化字段 |
| 关系 | 并列产品线，不是包含关系 | 并列产品线，不是包含关系 |
两者都是「多模态模型」（能看图），但产品定位不同：
- 多模态：能力属性------模型能处理多种输入模态。
- 视觉理解：产品分类------偏通用场景理解、Agent、长视频等。
- 文字提取 / OCR：产品分类------偏识字、定位、票据/文档抽取。
官方在视觉理解文档里也写了：OCR 场景推荐 qwen3.5-ocr；通用图片识字也可用 qwen3.7-plus。
所以「OCR 文档的模型选型表里没有 qwen3.7-plus」是正常的------它本来就不在这条产品线上。
二、本次选型结论（概要）
| 决策项 | 推荐 | 理由（一句话） |
|---|---|---|
| 产品线 | Qwen-OCR（文字提取） | 目标是「从图像抽结构化字段」，不是通用视觉 Agent |
| 具体模型 | **qwen3.5-ocr** |
官方主推、卡证/票据抽取优化、早期版明确迁移目标 |
| 成本备选 | qwen-vl-ocr |
更便宜，但属上一代，长期维护弱于 3.5-OCR |
| 不选 | qwen3.7-plus 作为 OCR 主模型 |
通用 VL 旗舰，成本高、参数约束不同，非 OCR 文档推荐选型 |
| 不选 | qwen-vl-ocr-2025-04-13 及更早 |
官方明确不推荐 |
| 代码改动 | 仅改配置中的 model 字段 |
现有 OpenAI 兼容 chat/completions + image_url + Prompt 对 OCR 模型同样适用 |
三、踩过的坑（选型与调用）
坑 1：在 OCR 文档里找 qwen3.7-plus，以为「模型不存在」
现象 ：配置写了 qwen3.7-plus，打开 文字提取文档 的「模型选型」，找不到该模型。
原因 ：qwen3.7-plus 属于视觉理解产品线，不会出现在 OCR 选型表中。
正确做法：先确定场景属于哪条产品线，再打开对应文档选模型。
坑 2：把 OCR 文档示例参数原样套到 qwen3.7-plus 上
现象：调用报错：
json
{
"error": {
"message": "Parameter min_pixels must be greater than or equal to 65536",
"code": "invalid_parameter_error"
}
}原因 ：OCR 文档示例里常见 "min_pixels": 3072（即 32×32×3），这是 Qwen-OCR 系列 的合法取值；而 **qwen3.7-plus 属于 Qwen3.7 视觉理解系列**，min_pixels 默认值为 65536，传入 3072 会触发参数校验失败。
补充说明 ：min_pixels 是图像送入模型前的像素下限 ------当图片总像素小于该值时，平台会先放大再识别。OCR 系列允许较低下限（3072 ≈ 55×55），适合小图、裁剪图、票据局部；视觉理解系列（Qwen3.7）默认下限为 65536（即 256×256），是为高分辨率通用识图设计的。两条产品线的图像预处理策略不同，参数不能跨文档混抄 ；若当前代码未传 min_pixels（走各模型默认值），则不会触发此报错，坑主要出现在「从 OCR 文档复制 curl 示例、却只改了 model 名」时。
| 模型系列 | min_pixels 典型约束 |
|---|---|
qwen3.5-ocr、qwen-vl-ocr-latest 等 OCR 新版 |
默认/最小约 3072 |
qwen3.7-plus、qwen3.7-flash 等视觉理解 |
默认 65536，有效下限更高 |
正确做法：
- 用
qwen3.7-plus：不传min_pixels（用默认），或设为>= 65536。 - 用
qwen3.5-ocr：可沿用 OCR 文档的3072示例，或不传参用默认。
坑 3：旧版 qwen-vl 下线后，误迁到 qwen3.7 旗舰
现象：注释写「qwen-vl 已下线，改用 qwen3.7 旗舰」。
原因：混淆了两条迁移路径：
| 旧模型 | 正确继任 | 常见误选 |
|---|---|---|
qwen-vl-ocr 等 OCR 模型 |
**qwen3.5-ocr** |
qwen3.7-plus（视觉理解旗舰） |
通用 qwen-vl-plus 等 |
qwen3.7-plus / qwen3.7-flash |
--- |
OCR 场景应迁到 OCR 产品线，不是视觉理解旗舰。
坑 4：以为必须换 API 或接 DashScope 专有参数
现象 ：担心 OpenAI 兼容模式用不了 OCR 的 ocr_options、enable_rotate。
事实：
- 当前方案是 自定义 Prompt → JSON 结构化输出 ，不依赖内置
ocr_options任务。 - OpenAI 兼容模式下，
ocr_options/enable_rotate需 DashScope SDK 或手动 Prompt 模拟；不传这些参数时，两个产品线行为一致，都只靠 Prompt + 图像。 - 图像方向：应用层 EXIF 矫正 + 模型自身抗倾斜即可覆盖大部分场景。
结论 ：对口场景下，改 model 名往往就够，不必大改调用链。
四、OCR 模型族内对比：选谁、不选谁
4.1 候选一览
| 模型 ID | 代际 | 官方态度 | 选型建议 |
|---|---|---|---|
**qwen3.5-ocr** |
最新 OCR（Qwen3.5） | 主推 | ✅ 首选 |
qwen-vl-ocr |
稳定版（Qwen3-VL） | 可用，逐步被取代 | ⚠️ 成本备选 |
qwen-vl-ocr-latest |
追新快照 | 行为可能随平台更新变化 | ⚠️ 不推荐生产锁版本 |
qwen-vl-ocr-2025-11-20 |
固定快照 | 便于回归测试 | ✅ 要锁版本时可选 |
qwen-vl-ocr-2025-08-28 |
固定快照；高精识别文档曾推荐 | 可用 | ⚠️ 不如 3.5-OCR 长期 |
qwen-vl-ocr-2025-04-13 及更早 |
早期 | 明确不推荐 | ❌ 排除 |
4.2 为什么选 qwen3.5-ocr
| 维度 | 说明 |
|---|---|
| 官方定位 | 「文档解析、文字定位、关键信息提取全面升级」；早期 OCR 版明确迁移目标 |
| 业务对口 | 卡证、票据类信息抽取为官方优化方向（虽非内置清单的 UI 截图，但 Prompt 抽取路径一致） |
| 多轮对话 | 支持；旧版 qwen-vl-ocr-2025-11-20 及更早仅处理最新消息 |
| 输出长度 | max_tokens 默认 32768，适合较长 JSON |
| 与现有代码 | OpenAI 兼容 image_url + Prompt，只改 model |
| 长期维护 | 当前 OCR 产品线终点，新能力优先落在此 |
4.3 为什么不选 qwen-vl-ocr 系列（作首选）
| 模型 | 不首选的原因 | 何时仍可考虑 |
|---|---|---|
qwen-vl-ocr（稳定版） |
上一代架构；官方引导迁移至 qwen3.5-ocr |
成本敏感、调用量大时（见下节定价） |
qwen-vl-ocr-latest |
版本不固定，线上行为可能变 | 仅做尝鲜，不适合生产基线 |
2025-11-20 等快照 |
效果弱于 3.5-OCR 的新能力 | 需要固定版本回归时 |
| 2025-04 及更早 | 官方写明「功能和效果均不及新版本」 | ❌ 不应选用 |
4.4 定价对比（华北2，官方标价，以控制台为准）
| 模型 | 输入（元/百万 Token） | 输出（元/百万 Token） |
|---|---|---|
qwen3.5-ocr |
0.5 | 2.0 |
qwen-vl-ocr（稳定版等） |
0.3 | 0.5 |
解读：
- 若输出 Token 占主导（结构化 JSON 较短时差异不大），
qwen-vl-ocr更便宜。 - 若更看重抽取准确率与官方长期支持，多付一些费用换
qwen3.5-ocr通常更对口。 - 选型不应只看单价：错误字段带来的业务成本往往远高于模型差价。
五、qwen3.7-plus 与 OCR 模型：对口场景对比
这是本次选型最核心的「为什么不用旗舰 VL、而用 OCR」。
5.1 定位差异
| 维度 | qwen3.7-plus |
qwen3.5-ocr |
|---|---|---|
| 产品线 | 视觉理解 | 文字提取 / OCR |
| 核心能力 | 看图、看视频、GUI Agent、视觉编程、长上下文推理 | 文档/表格/票据识字、定位、字段抽取 |
| 典型用户问题 | 「这张图里有什么」「帮我操作这个界面」 | 「把这张图里的字段抽成 JSON」 |
| 是否 OCR 文档推荐 | 否（在视觉理解文档中作为通用识字备选） | 是（OCR 文档首推） |
5.2 为什么选 OCR、不选 qwen3.7-plus（对本场景）
| 考量 | qwen3.5-ocr ✅ |
qwen3.7-plus ❌（作 OCR 主模型） |
|---|---|---|
| 场景对口 | 专为文字提取与信息抽取优化 | 通用理解强，但非 OCR 专项 |
| 成本 | OCR 档定价 | 旗舰 VL 档，显著更贵 |
| 参数兼容 | min_pixels 与 OCR 文档一致（3072 起） |
min_pixels 最低 65536，易与 OCR 示例混用报错 |
| 内置 OCR 任务 | 有（DashScope SDK）；Prompt 路径亦可用 | 无，全靠 Prompt |
| 幻觉风险 | 官方提示低分辨率文字有风险；OCR 场景有针对性优化 | 通用模型在「纯识字」上并非最优性价比 |
| 改动成本 | 改 model 即可 | 已是错误产品线上的「能跑」 |
5.3 什么时候仍可考虑 qwen3.7-plus
以下情况 qwen3.7-plus 反而更对口，而非 OCR：
- 需要同时理解图像语义与复杂推理（例如根据 UI 截图推断操作流程，而非只抽字段）。
- 输入含长视频或需 Agent / Function Calling / 内置工具。
- 版式极端非结构化，标签命名非常规，需要强语义理解补全。
- 已与视觉理解文档、参数规范对齐，且不再混用 OCR 文档示例。
对「固定字段集、从截图抽 JSON 」类需求，上述通常不是主路径，OCR 产品线更对口。
六、引申：「图片理解」与「文字提取」怎么选
6.1 概念对照
┌─────────────────────────────────────┐
│ 多模态（能看图） │
└─────────────────────────────────────┘
/ \
/ \
┌──────────────────────┐ ┌──────────────────────┐
│ 图片理解 / 视觉理解 │ │ 文字提取 / OCR │
│ (Vision Understanding)│ │ (Text Extraction) │
└──────────────────────┘ └──────────────────────┘
│ │
qwen3.7-plus / flash qwen3.5-ocr / qwen-vl-ocr
│ │
看懂场景、推理、Agent 识字、定位、抽字段二者都能从图里拿文字，但优化目标不同：
| 问题类型 | 更对口的产品线 | 原因 |
|---|---|---|
| 这张图是什么场景？发生了什么？ | 图片理解 | 需要语义与常识 |
| 图里每个字是什么？坐标在哪？ | 文字提取 | 需要定位与识字精度 |
| 按固定 schema 抽金额、编号、时间 | 文字提取（+ Prompt） | 与 OCR / 信息抽取任务一致 |
| 多图拼一张长截图再识别 | 文字提取 + 应用层「逐图识别再合并」 | OCR 支持多图；拆分合并更可控 |
| 视频内容摘要 | 图片理解 | OCR 不主打视频 |
6.2 与传统 OCR（Tesseract、云 OCR API）的区别
| 方式 | 优势 | 劣势 | 何时用 |
|---|---|---|---|
| 传统 OCR | 快、便宜、成熟 | 只出文字块；字段语义要靠规则/模板 | 版式固定、量大 |
| 大模型 OCR（qwen3.5-ocr） | Prompt 直接出 JSON；版式泛化好 | 成本较高；偶有幻觉 | 版式多变、字段语义抽取 |
| 通用 VL（qwen3.7-plus） | 语义最强、功能最全 | 最贵；非 OCR 专项 | 要推理+看图，不单识字 |
本类需求本质是 「图像理解 + 语义字段抽取」 ，不是「把所有字 OCR 出来再写几百条规则」。
因此选 大模型 OCR 线 比传统 OCR 省规则维护，比 通用 VL 旗舰 更对口、更省成本。
6.3 多样性场景：OCR 模型能否覆盖
| 场景 | OCR 模型能力 | 应用层建议 | 结论 |
|---|---|---|---|
| 多语言（中英混排、繁体、外文标签） | 官方支持多语言识别 | Prompt 指定输出字段与格式 | ✅ 兼容 |
| 多格式（JPG/PNG/BMP 等） | 支持多种图像格式 | 入口统一转 JPEG | ✅ 兼容（格式由预处理兜底） |
| 方向/倾斜 | 支持 enable_rotate（SDK）；模型可识倾斜图 |
EXIF 方向矫正 | ✅ 兼容 |
| 一笔内容分多张图上传 | 支持多图输入 | 逐图识别 + 按字段置信度合并 往往更稳 | ✅ 兼容 |
6.4 传统 OCR 与大模型 OCR 的多样性对比
本节在 6.2、6.3 基础上，按同一套多样性维度 对比「传统 OCR」与「大模型 OCR（如 qwen3.5-ocr）」，说明各自边界------不是「能不能用」，而是对谁更对口。
范围说明：
- 传统 OCR：Tesseract、PaddleOCR、各云厂商「通用文字识别」API 等，输出以文字块/行为主。
- 大模型 OCR：百炼 Qwen-OCR 产品线，通过 Prompt 或内置任务输出结构化结果。
6.4.1 多样性维度对照
| 多样性维度 | 传统 OCR | 大模型 OCR（qwen3.5-ocr 等） | 选型含义 |
|---|---|---|---|
| 多语言（中英混排、繁体、外文标签） | ⚠️ 部分支持：需指定语言包；单图多语同屏准确率下降 | ✅ 较好：官方多语言识别 + Prompt 约束输出格式 | 混排、外文标签场景倾向大模型 OCR |
| 多格式（JPG/PNG/BMP 等） | ✅ 经解码/转码后均可；格式能力在应用层 | ✅ 模型侧支持多种格式；同样建议入口统一转码 | 两者相当，不靠选型解决，靠预处理 |
| 方向/倾斜 | ⚠️ 常需 OSD 或 EXIF 预处理；大角度、透视易掉字 | ✅ 内置旋转矫正（SDK）+ 模型抗倾斜；应用层 EXIF 可叠加 | 手机随手拍、倾斜截图倾向大模型 OCR |
| 一笔分多张图 | ⚠️ 仅单图出字；合并与去重全靠业务规则 | ✅ 支持多图输入；逐图识别 + 字段置信度合并更可控 | 多图补全字段时，大模型 OCR 省规则、语义更强 |
| 版式多变（不同 App/机构界面） | ❌ 弱：换版式就要改模板/正则 | ✅ 较强：Prompt 描述字段语义，零样本泛化好 | 版式多变是选大模型 OCR 的核心理由 |
| 字段语义抽取（如「Reference No」= 编号） | ❌ 不支持：只出字+坐标，含义靠规则 | ✅ 支持：Prompt 直接映射到 JSON schema | 固定字段集 + 语义映射，传统 OCR 维护成本极高 |
| 图像质量差（模糊、反光、遮挡） | ❌ 敏感；置信度弱或不可用 | ⚠️ 有风险但优于传统 OCR；可输出 confidence 辅助仲裁 | 均需清晰图；大模型略好，不能替代质检 |
| 手写体 | ❌ 弱（除非专用手写引擎） | ⚠️ 视清晰度而定，优于通用传统 OCR | 手写凭证需实测，或专用模型 |
| 结构化 JSON 输出 | ❌ 需自建解析链路 | ✅ Prompt 或内置信息抽取任务 | 要直接落库字段时，大模型 OCR 更对口 |
6.4.2 传统 OCR 明显不擅长的多样性
以下场景不是「调参就能解决」，而是能力边界问题：
- 语义级字段理解------不知道标签与业务字段的对应关系，只能靠关键词、位置规则硬匹配。
- 版式零样本泛化------界面一改版，规则就要跟着改；无法像大模型那样用自然语言描述字段。
- 多图语义合并------不能理解「多张图属于同一业务单据」，只能应用层按规则拼接。
- 复杂成像条件------无 EXIF 的大角度倾斜、透视、艺术字体、竖排混排等，误识、乱序常见。
- 端到端结构化------默认产物是文字流，不是可直接消费的 JSON。
6.4.3 传统 OCR 仍然更对口的场景
| 场景 | 为何仍选传统 OCR |
|---|---|
| 版式长期固定（同一套扫描模板、印刷票据） | 规则一次写好即可，成本低、延迟小 |
| 仅需全文 OCR，不做字段抽取 | 不需要语义层，大模型性价比低 |
| 高并发、极低成本、毫秒级延迟 | 无大模型推理开销 |
| 离线/私有化、不能出网 | 本地引擎可控，不依赖云端 VL/OCR API |
6.4.4 小结：为何本类需求落在「大模型 OCR」
本类需求典型特征是：版式多变 + 固定字段集 + 可能多图 + 可能多语言 ，且目标是 结构化 JSON，而非全文 OCR。
text
传统 OCR → 擅长「识字」，不擅长「懂字段」
大模型 OCR → 在识字基础上 + Prompt/任务 → 直接出 schema
通用 VL 旗舰 → 语义最强，但非 OCR 专项、成本更高（见第五节）因此：多样性里的「版式、语义、多图合并」是传统 OCR 的短板，恰恰是大模型 OCR 的选型理由；「格式、方向」两类则更多依赖应用层预处理，两条技术路线均可配合，但大模型 OCR 上限更高。
七、决策树（可直接用于评审）
text
需要从图像抽取结构化字段？
│
├─ 否 → 考虑视觉理解（qwen3.7-plus / flash）或纯文本模型
│
└─ 是 → 进入 OCR 产品线
│
├─ 要官方长期支持 + 票据/卡证优化 → qwen3.5-ocr ✅
│
├─ 要最低 API 成本 → qwen-vl-ocr（接受上一代定位）⚠️
│
├─ 要锁版本回归 → qwen-vl-ocr-2025-11-20 ⚠️
│
└─ 排除：早期 qwen-vl-ocr、把 qwen3.7-plus 当 OCR 主模型 ❌八、落地检查清单
实施前逐项确认：
- 已确认场景属于 文字提取 / 信息抽取，而非通用视觉 Agent
-
model已改为目标 OCR 模型（推荐qwen3.5-ocr） - 未将 OCR 文档的
min_pixels: 3072套在非 OCR 模型上 -
Authorization: Bearer sk-...格式正确 - 未依赖
ocr_options却走 OpenAI 兼容模式（若只用 Prompt，可忽略） - 多图场景已明确：逐图识别 + 字段合并，或单请求多图（二选一，推荐前者）
- 用真实样本做过字段准确率与耗时抽检（理论选型不能替代实测）
九、参考链接
| 资料 | URL |
|---|---|
| 视觉理解（含 OCR 与 VL 关系说明） | https://help.aliyun.com/zh/model-studio/vision-model/ |
| 文字提取 / Qwen-OCR 使用 | https://help.aliyun.com/zh/model-studio/qwen-vl-ocr |
| Qwen-OCR API 参考（含 min_pixels） | https://help.aliyun.com/zh/model-studio/qwen-vl-ocr-api-reference |
| qwen3.5-ocr 模型信息（定价） | https://help.aliyun.com/zh/model-studio/qwen3-5-ocr |
| qwen-vl-ocr 模型信息（定价） | https://help.aliyun.com/zh/model-studio/qwenvl-ocr |
| OpenAI 兼容 Chat（qwen3.7-plus min_pixels） | https://www.alibabacloud.com/help/en/model-studio/qwen-api-via-openai-chat-completions |
十、一句话总结
「能从图里抽 JSON」不等于「用最强的看图模型」；对口选型是 OCR 产品线 +
qwen3.5-ocr，改 model 名即可接入，但要避开产品线混用、参数混用、以及把视觉理解旗舰误当 OCR 继任者这三类坑。
文档版本：2026-08-23 · 基于阿里云百炼公开文档整理，定价与模型列表以控制台为准。