Wiki Notes

Appearance

视觉模型专题 ​

版本：v1.2

最后更新：2026-07-09

适用对象：正在做图像理解、OCR、文档视觉理解、图像生成与编辑、多图对比、UI 截图分析与视觉质检的产品、应用研发、平台工程与评测同学

视觉能力是很多 AI 产品里最容易“演示起来很惊艳”，但最容易在真实数据上暴露问题的一类能力。

因为视觉任务一旦进入生产，系统面对的就不再是“给模型一张清晰图片然后问一句话”，而是：

  • 不同来源的图片质量差异
  • 多页文档、表格、版面和截图
  • 多图比对与时间前后对照
  • 结构化字段抽取
  • 成本、延迟和 token 预算
  • 审核、安全与人工复核

所以视觉专题真正要解决的不是“会不会看图”，而是：

  • 如何把图像输入、任务拆分、输出协议、成本控制、文件组织和评测闭环接成一条可用链路。

按 2026-07-09 复核可访问的 OpenAI Images and vision、File inputs、Image generation 当前官方资料来看，视觉系统至少要同时回答六个问题：

  1. 图像、PDF、截图和参考图到底分别怎么喂给模型。
  2. 什么时候直接整图输入，什么时候必须先裁切、拆页或分区域。
  3. detail、PDF detail、图像大小和多图数量怎么和预算绑定。
  4. OCR、文档解析、图像问答、多图比较和图像编辑为什么不能用同一套心智。
  5. 图像编辑里的 mask、background、size、quality、input fidelity 怎么进工程配置。
  6. 结果怎么引用证据、怎么回放、怎么接进结构化输出和人工复核。

1. 视觉任务至少该拆成五类 ​

不要把所有“带图”的需求都叫视觉模型。

更稳的划分方式至少有五类：

1.1 图像理解 ​

典型任务：

  • 看图问答
  • 场景描述
  • 目标识别
  • 缺陷检测
  • 截图理解
  • UI 分析

1.2 OCR 与文档视觉理解 ​

典型任务：

  • 扫描件转结构化文本
  • 合同 / 票据 / 表单字段抽取
  • 表格解析
  • 多页 PDF 版面理解

1.3 多图理解与对比 ​

典型任务：

  • 商品图前后对比
  • 质检图多角度比对
  • 设计稿与实际页面差异检查
  • 医疗 / 工业图像序列分析

1.4 图像生成 ​

典型任务：

  • 文生图
  • 品牌图批量生成
  • 海报与营销素材
  • 概念图和创意草稿

1.5 图像编辑 ​

典型任务：

  • 局部编辑
  • 替换背景
  • 商品修图
  • 在已有素材上做受控修改

这五类任务经常被放进一个产品里，但工程目标完全不同。

2. 输入方式决定一半效果，也决定你后面能不能治理 ​

OpenAI 当前 Images and vision 文档明确给出三类常见输入方式：

  • 完整 URL
  • Base64 data URL
  • 通过 Files API 创建的 file_id

2.1 URL 更像快速接入 ​

适合：

  • Demo
  • 单图问答
  • 内容本身简单、图像生命周期短

优点：

  • 接入快
  • 不用先做文件管理

缺点：

  • 更依赖外部对象可访问性
  • 后续回放和审计不如自有文件引用稳定

2.2 Base64 更像一次性嵌入 ​

适合：

  • 本地图片快速实验
  • 需要不落外部 URL 的小型请求

缺点也很直接：

  • 请求体更大
  • 不适合高频生产复用

2.3 file_id 更像生产系统的主路 ​

OpenAI 当前文档明确支持：

  • 先通过 Files API 创建文件
  • 再在 input_image 里传 file_id

这对生产非常重要，因为它意味着：

  • 文件生命周期可以独立治理
  • 回放时更容易绑定原始输入
  • 多个流程可以复用同一资产

更实用的工程建议通常是：

  • 先把图片、PDF、mask、参考图都变成可追溯文件对象
  • 再通过 file_id 进入推理或编辑链路

3. 直接整图输入什么时候够用，什么时候一定不够 ​

很多团队在视觉系统里最常见的误判是：

  • 既然模型能看图，那整图直接丢进去就好了

这在简单单图场景里有时可行，但一到生产就容易出问题。

3.1 更适合直接整图输入的场景 ​

  • 单图问答
  • 粗分类
  • 商品图或营销图的大意理解
  • 截图里只需要全局状态判断

3.2 更适合先做预处理的场景 ​

  • 表单角度歪斜
  • 小字密集
  • 页面里有效区域很少
  • UI 截图只关心局部面板
  • 工业 / 电商场景背景噪声很大
  • PDF 含多栏、表格、图表

常见预处理动作：

  • resize
  • crop
  • de-skew
  • contrast enhancement
  • page split
  • ROI 提取

3.3 一个常见误区 ​

很多“模型看不懂”的问题，最后其实不是模型能力问题，而是：

  • 关键信息占比太小
  • 噪声占比太大
  • 版面结构根本没被预处理成模型容易消费的形态

4. detail 不是小参数，而是视觉预算拨盘 ​

OpenAI 当前 Images and vision 文档把 detail 明确拆成：

  • low
  • high
  • original
  • auto

并且给出了更具体的使用建议。

4.1 low 适合什么 ​

官方文档明确说明：

  • low 适合快速、低成本理解
  • 模型看到的是大约 512px x 512px 的低分辨率版本

所以更适合：

  • 粗分类
  • 是否存在某类对象
  • 图片安全初筛
  • 多图粗召回

4.2 high 适合什么 ​

官方文档把它定义成：

  • 标准高保真理解

这更适合：

  • 普通图像问答
  • 中等复杂度截图理解
  • 一般商品图和营销图理解

4.3 original 适合什么 ​

官方文档明确推荐：

  • 大图
  • 密集信息
  • 空间敏感
  • computer use 或点击精度场景

更适合：

  • 小字体密集截图
  • 复杂布局
  • 精准定位
  • 文档页中局部空间关系判断

4.4 auto 在 gpt-5.5 上的一个现实差异 ​

OpenAI 当前文档明确写到：

  • 在 gpt-5.5 上，auto 和默认省略行为等价于 original

这点非常值得工程同学注意，因为很多旧经验会默认把 auto 理解成“成本友好的自动权衡”，但在 gpt-5.5 上它更接近：

  • 默认走更高保真路线

4.5 为什么这会影响成本 ​

官方文档还给出了更具体的尺寸与 patch 约束：

  • high 支持到约 2,500 patches 或 2048px 最大边
  • original 支持到约 10,000 patches 或 6000px 最大边

这意味着：

  • original 不是白来的“更准一点”
  • 它对应的是更高的视觉预算

5. PDF 输入不是普通文本，也不是普通图片 ​

OpenAI 当前 File inputs 文档里有几条非常值得直接进团队规范的结论。

5.1 PDF 解析会同时带入文本和页面图像 ​

官方文档明确说明：

  • PDF parsing 会把提取文本和页面图像一起带进上下文

这意味着 PDF 系统不是单纯 OCR，也不是单纯文本问答。

5.2 Responses API 里的 PDF 也有 detail ​

官方文档明确写到：

  • PDF input_file 支持 detail
  • low 是默认值
  • high 更适合密集图表、小字、复杂图示

这条非常关键，因为很多团队会把所有 PDF 都默认高精度处理，结果：

  • token 飙升
  • 大量普通文档没必要

5.3 非 PDF 文件有一条很容易忽略的限制 ​

OpenAI 当前 File inputs 文档明确写到：

  • 对于非 PDF 文件，API 不会把嵌入图片或图表自动提到模型上下文
  • 如果想保留图表和示意图，最好先转成 PDF 再送 input_file

这对文档系统的启发非常直接：

  • PPT、Word、富文档不一定按你以为的方式把图表喂给模型
  • 想保住版面和图示，先转 PDF 往往更稳

5.4 PDF 系统为什么最容易被低估 ​

因为它常常同时包含：

  • 数字文本
  • 页面图像
  • 表格
  • 页眉页脚
  • 跨页结构

所以一个靠谱的 PDF 系统，通常不只是“丢给模型问答”，而是要想清楚：

  • 页面级切分
  • 页码引用
  • 表格与正文分流
  • 图片页与文本页的混合处理

6. OCR、版面理解、字段抽取、视觉问答不要再混成一件事 ​

很多团队会把下面这些都叫“OCR”，但它们并不是同一件事：

  • 文本识别
  • 表格抽取
  • 布局理解
  • 字段映射
  • 跨页聚合
  • 图表解释

6.1 OCR 风险 ​

  • 字认错
  • 行列顺序错
  • 特殊字符丢失
  • 页码 / 编号错乱

6.2 版面理解风险 ​

  • 表头和表体关系断裂
  • 左右栏串行
  • 表单字段错位
  • 页间连续性丢失

6.3 字段抽取风险 ​

  • 字段齐了但语义错了
  • 多页信息没合并
  • 缺失值和未知值被混写

6.4 问答风险 ​

  • 模型答得像理解了，其实没引用对区域
  • 将视觉证据和常识混写
  • 对细节位置、数值判断不稳

工程上更稳的链路通常是：

text
图像 / 文档
 -> 预处理
 -> OCR / 版面理解
 -> 结构化中间结果
 -> 问答 / 字段抽取 / 审核
 -> 校验

而不是直接把整份文档扔给模型问：

  • “帮我抽字段”

7. 多图任务最容易被低估，也最容易偷偷烧钱 ​

OpenAI 当前文档明确说明：

  • 一次请求可以放多张图
  • 多张图会一起计入 token 成本并计费

7.1 多图任务前先定义角色 ​

例如：

  • 图 1 是原始图片
  • 图 2 是修改后图片
  • 图 3 是参考标准图

如果不把角色明确写清楚，模型很容易混淆：

  • 哪张是基准
  • 哪张是问题图
  • 哪张是用户想保留风格的参考图

7.2 多图最好先做排序和筛选 ​

适合先做前置处理的场景：

  • 视频抽帧后只取关键帧
  • 商品质检图只取关键角度
  • 多页 PDF 先按页码和章节组织

否则视觉模型容易把真正关键图淹没在冗余图片里。

7.3 多图对比任务最好要求显式引用 ​

更稳的输出协议通常是：

  • 引用图片编号
  • 指出差异发生在哪一张
  • 对比结果按编号分段

这样后续人工复核和自动 grader 都更容易接。

8. 视觉系统里的截图、UI 和 computer-use 心智也要单列 ​

这类任务和普通看图问答表面相似，但工程要求更高。

8.1 截图理解更像状态判断 ​

常见任务：

  • 页面在干什么
  • 哪个按钮可点击
  • 为什么报错
  • 当前流程卡在哪

8.2 UI 自动化辅助更像“视觉 + 工具” ​

一旦要把视觉理解接进自动化或 Agent 工具调用，重点就不再只是“认出按钮”，而是：

  • 识别结果够不够稳定
  • 位置和语义是否可复现
  • 执行动作是否有二次确认

8.3 这类场景为什么更适合 detail: original ​

OpenAI 当前文档明确建议：

  • computer use、localization、click accuracy 场景更适合 original

因为这类任务最怕的是：

  • 看懂大意，却点错位置

9. 图像生成和图像编辑不是一个“出图按钮” ​

OpenAI 当前 Image generation 文档已经把这条线拆得更细：

  • 生成
  • 参考图工作流
  • 多图参考编辑
  • mask 编辑
  • 输出尺寸 / 质量 / 背景配置

9.1 从零生成 ​

适合：

  • 营销素材
  • 海报概念图
  • 场景草图

9.2 参考图工作流 ​

OpenAI 当前文档明确支持：

  • 在输入里放多张参考图
  • 可以混用 image_url 和 file_id

这更适合：

  • 保留配色
  • 保留物件组合
  • 让生成贴近既有品牌资产

9.3 局部编辑 ​

更适合：

  • 换背景
  • 替换道具
  • 修改局部颜色或材质
  • 电商修图

9.4 为什么编辑更像工程任务 ​

因为你不仅要写 prompt，还要明确：

  • 哪一张是底图
  • 哪一张是参考图
  • 哪一块允许改
  • 输出是否要透明 / 固定尺寸 / 指定质量

10. mask 编辑要把技术约束提前设计进去 ​

OpenAI 当前官方文档对 mask 给了非常明确的约束：

  • 底图和 mask 必须同格式、同尺寸
  • 文件要小于 50MB
  • mask 必须有 alpha channel
  • 如果多图输入，mask 只应用在第一张图上

10.1 这意味着什么 ​

这意味着局部编辑不是：

  • “写一句 prompt 自动局改”

更稳的做法通常是：

  1. 先在前端或后端准备编辑区域
  2. 明确哪些区域允许修改
  3. 把 prompt 限制成单一改动
  4. 编辑后再做人工或规则复核

10.2 还有一个容易忽略的现实 ​

OpenAI 当前文档还明确说明：

  • masking 是 prompt-guided 的
  • 模型不保证完美贴合 mask 边界

这意味着：

  • mask 不是像素级硬约束
  • 需要给业务留二次检查空间

10.3 gpt-image-2 的输入保真度也有固定设定 ​

官方文档明确说明：

  • gpt-image-2 的输入图像默认就是高保真处理
  • 不提供手动调整 input_fidelity

所以编辑链路里别再假设“我可以随时把输入 fidelity 调低换成本”。

11. 输出参数不是后处理小细节，而是产品配置面 ​

OpenAI 当前图像生成文档明确给出几个重要输出配置：

  • size
  • quality
  • format
  • compression
  • background

11.1 size 有明确边界，不是随便填 ​

官方文档明确说明：

  • 最大边不能超过 3840px
  • 边长都要是 16px 的倍数
  • 长宽比不能超过 3:1
  • 总像素范围也有限制

这意味着生成后台里更稳的做法通常是：

  • 提前给前端有限档位
  • 不要让业务自由输入任意分辨率

11.2 quality 也应该成为产品档位 ​

官方文档给出：

  • low
  • medium
  • high
  • auto

并明确建议：

  • low 适合快速草稿、缩略图和迭代

所以更合理的工作流通常是：

  • 草稿走 low
  • 最终交付再上 medium/high

11.3 background 也不是想当然 ​

OpenAI 当前文档明确写到：

  • background 支持 opaque 或 auto
  • gpt-image-2 当前不支持透明背景
  • background: "transparent" 对这个模型不适用

这点非常关键，因为很多设计或电商场景默认会要求透明 PNG。

如果前面不确认模型能力，后面就会在导出阶段翻车。

12. 视觉系统常见链路模板 ​

12.1 图片问答 ​

text
Image
 -> Resize / Crop
 -> Vision reasoning
 -> Structured answer
 -> Citation / field validation

12.2 文档抽取 ​

text
PDF / Scan
 -> Page split
 -> OCR / layout parse
 -> Schema extraction
 -> Rule validation
 -> Human review on high-risk pages

12.3 多图比对 ​

text
Multi-image input
 -> Role labeling
 -> Ordering / filtering
 -> Comparison reasoning
 -> Difference report with image refs
 -> Manual review on high-risk diffs

12.4 图像生成运营后台 ​

text
Prompt template
 -> Reference assets
 -> Generation / edit
 -> Safety check
 -> Human curation
 -> Export / publish

不同链路的瓶颈完全不一样，所以不要用一个“视觉模型服务”抽象把它们全抹平。

13. 视觉任务怎么评测才不会只剩主观感觉 ​

13.1 理解类指标 ​

  • 字段抽取准确率
  • OCR 正确率
  • 关键细节问答准确率
  • 多图比对一致率
  • 定位或区域判断正确率

13.2 生成类指标 ​

  • 指令遵循度
  • 文本可读性
  • 风格一致性
  • 局部编辑保真度
  • 可直接交付率

13.3 产品类指标 ​

  • 上传成功率
  • 平均响应时长
  • 大图失败率
  • 人工纠错率
  • 重试率

13.4 企业里最容易缺失的一层 ​

很多团队只做模型准确率，不做：

  • 输入质量分桶
  • 失败样本归因
  • 人工返工成本

但视觉任务线上最贵的，往往恰恰是返工和复核。

14. 视觉能力上线前要先问的几个问题 ​

14.1 你到底是在做“看图回答”，还是“提取可执行字段” ​

如果是后者，重点就不该只放在自然语言回答，而应放在：

  • schema
  • 校验规则
  • 缺失字段处理
  • 人工复核入口

14.2 图片分辨率真的都要拉满吗 ​

如果不是空间敏感任务，过高细节只会拉高成本。

14.3 多图是不是都要一起送进去 ​

很多时候先做前置召回或排序更划算。

14.4 PDF 到底要不要先转 ​

如果你要保图表和版面，官方资料已经明确提示：

  • 对非 PDF 富文档，更稳的路线往往是先转 PDF 再送 input_file

14.5 图像编辑是不是已经考虑了 mask 和输出格式 ​

如果没有，这条链路大概率还没到“可交付”。

15. 常见反模式 ​

  • 把 OCR、文档理解、看图问答、图像生成混成一个接口。
  • 一上来所有图都用最高细节。
  • 不做 ROI 裁剪，直接整图硬喂。
  • 多图没有顺序和角色说明。
  • 结构化抽取不做字段校验。
  • 局部编辑不用 mask，靠 prompt 硬改。
  • 生成类任务只看“好不好看”，不看交付可用率。
  • 富文档里的图表丢失了还以为是模型理解能力差。

16. 推荐搭配阅读 ​

17. 重点官方资源 ​

以下入口在 2026-07-09 复查时可访问：