Wiki Notes

Appearance

02. 图像理解、文档解析与视觉工作流 ​

版本：v1.1

最后更新：2026-07-09

适用对象：要做图片问答、截图理解、PDF/表单抽取、视觉工作流、文档问答的产品、研发、平台和交付同学

这篇文档重点回答一个常被低估的问题：

  • 视觉系统真正难的，往往不是“模型能不能看图”，而是图片、PDF、表格、截图和结构化结果该怎样进入同一条可运营链路。

按 2026-07-09 可访问的 OpenAI Images and vision、File inputs、Structured outputs、Anthropic Vision / PDF support、Azure Document Intelligence、Google Cloud Document AI Layout Parser 官方资料来看，视觉系统至少要拆成四层来看：

  1. 输入层：图片、扫描件、PDF、表格、屏幕截图分别怎么处理。
  2. 任务层：是问答、抽取、对比、定位、审阅还是生成 / 编辑。
  3. 输出层：是自然语言回答、结构化 JSON、引用证据还是二次编辑结果。
  4. 运营层：如何评测、留证、回放、复审和治理。

1. 先把“视觉理解”和“视觉生成”分开 ​

这是做视觉系统最重要的第一步。

1.1 视觉理解更像“看懂” ​

典型任务包括：

  • 看图问答
  • 截图解释
  • 表单 / 发票 / 合同字段抽取
  • UI 组件识别
  • 多图对比
  • PDF 页面理解

这类任务通常更关心：

  • 信息有没有看全
  • 字段有没有漏
  • 图文对应关系对不对
  • 输出能不能被业务系统继续消费

1.2 视觉生成更像“出图或改图” ​

典型任务包括：

  • 文生图
  • 局部编辑
  • 扩图
  • 批量素材生成
  • 品牌风格统一

这类任务更关心：

  • 风格一致性
  • 细节控制
  • 角色或元素连续性
  • 审核与交付率

1.3 为什么这一步必须先分开 ​

因为两类系统的：

  • 评测方法
  • 成本结构
  • 输入组织方式
  • 审核链路

都完全不同。

很多团队一开始说“我们要做视觉能力”，但实际上要先回答的是：

  • 你到底是要理解内容，还是要生成 / 编辑内容。

2. 图像输入、文件输入和 PDF 输入不是一回事 ​

OpenAI 当前把 Images and vision 和 File inputs 拆开写，本身就说明视觉链路不能只想成“传一张图片给模型”。

2.1 纯图片输入更适合这些任务 ​

  • 图片问答
  • 截图解释
  • 多图对比
  • 商品图理解
  • UI 或设计稿分析

这类输入重点是：

  • 分辨率
  • 图片顺序
  • 是否需要裁切局部
  • 是否需要给模型额外的文字上下文

2.2 文件输入更适合这些任务 ​

  • PDF 文档理解
  • 表格 / CSV / JSON 配套分析
  • 合同、招标书、说明书等长文档处理
  • 图片和文本混排文档

OpenAI File inputs 的官方思路很值得注意：

  • 不同文件类型的处理方式不同。
  • PDF 不是普通文本，也不是普通图片。
  • 结构化文件更适合被当成可解析内容，而不是一张“照片”。

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

因为 PDF 常常同时包含：

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

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

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

2.4 原生 PDF、扫描件 PDF、手机拍文档，其实是三种不同输入 ​

很多团队一说“处理 PDF”，默认把所有文档都归成一类，但工程上这三种输入差异非常大：

  1. 原生 PDF
    更可能保留数字文本层、章节结构和可解析对象。
  2. 扫描件 PDF
    更接近一组页面图像，需要先处理 OCR、阅读顺序和版面结构。
  3. 手机拍文档
    除了 OCR 和版面问题，还会叠加透视畸变、阴影、反光、模糊和裁边不齐。

这三类输入如果共用一条完全相同的链路，最常见的结果就是：

  • 原生 PDF 被当图片粗暴处理，浪费结构信息
  • 扫描件没有专门的布局恢复，页内顺序乱掉
  • 手机拍照文档在进模型前就已经丢了太多有效信息

所以更稳的视觉文档系统通常会先做 route：

  • 原生 PDF 优先走文件解析 / 布局解析 lane
  • 扫描件优先走 OCR + layout lane
  • 拍照文档优先走图像预处理 + ROI 检测 + OCR lane

2.5 文档解析器真正解决的不是“识别文字”，而是“恢复结构” ​

Azure Document Intelligence 当前 Layout 与总览文档，Google Cloud Document AI Layout Parser 当前文档都在强调一个共同点：

  • 文档处理不只是把字认出来
  • 还要恢复段落、标题、表格、列表、手写样式、图形、层级结构和 chunk 上下文

Google 当前 layout parser 文档明确把它描述成：

  • 生成带祖先标题和表头上下文的 layout-aware chunks

Azure 当前 layout 文档则明确强调：

  • lines / words
  • tables
  • handwriting style
  • figure detection
  • 层级结构与 logical roles

这说明“文档理解”比通用 OCR 更接近：

  • 版面恢复 + 结构对象化 + 后续语义消费

所以如果你的系统开始遇到下面这些问题：

  • 段落上下文断裂
  • 表格头和表格体分家
  • 小标题找不到对应正文
  • 字都识别出来了，但问答还是乱

问题往往已经不在“识别率”，而在：

  • layout parser 和 chunking 策略不够强

3. 视觉输入链路要先解决哪些工程问题 ​

3.1 分辨率和 detail 不是小参数 ​

OpenAI Images and vision 明确把 detail 当成视觉输入策略的一部分，这说明：

  • 图像质量
  • 观察粒度
  • 成本

不是可以后补的细节。

更实用的心智通常是：

  • 粗分类 / 场景感知：先低成本扫一遍。
  • 字段抽取 / 小字识别 / 复杂图表：再切到更高细节或局部裁切。

3.2 先裁切再识别，通常比整图强推更稳 ​

企业图片里最常见的问题不是模型“笨”，而是：

  • 关键信息只占很小一块
  • 整张图有大量噪声
  • 多栏布局让关键信息淹没

所以更常见的工程做法是：

  1. 先检测版面或区域。
  2. 再把局部图送进精读链路。
  3. 最后做全局汇总和字段校验。

3.3 多图任务要明确“比较关系” ​

多图输入最容易出的问题是：

  • 模型不知道你想比较什么
  • 没有建立顺序和角色
  • 多图证据被混在一起

因此更稳的写法通常是：

  • 明确每张图的编号和角色。
  • 指出你要比较的是差异、相同点还是时序变化。
  • 要求输出按图片编号引用证据。

3.4 视觉输入最好先做页面或区域路由，而不是一把梭 ​

很多视觉链路一开始为了省事，会把：

  • 整份 PDF
  • 整页截图
  • 整张拍照文档

直接一把送给模型。

这在 Demo 阶段没问题，但只要进入生产，很快就会遇到：

  • 小字段淹没在大页面里
  • 表格区和说明文字区最优策略不同
  • OCR 噪声把问答结果带偏

更稳的工程做法通常是先做 route：

  • 文本主导页
  • 表格主导页
  • 图表主导页
  • 签字 / 盖章 / 批注页
  • UI 截图页

然后每类页再走不同子链路：

  • 文本页更重阅读顺序与章节结构
  • 表格页更重表头、合并单元格和字段映射
  • 图表页更重图例、坐标轴和数据标签
  • 截图页更重组件关系和交互状态

也就是说，视觉输入治理最关键的第一步常常不是“换模型”，而是：

  • 先把不同页面类型分流

4. 文档解析比普通看图更接近“结构化工程” ​

4.1 常见文档任务其实是不同问题 ​

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

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

4.2 文档问答和字段抽取也不是同一路线 ​

文档问答更关心：

  • 答案是否在文档里
  • 页码和证据能不能引用回来

字段抽取更关心：

  • 输出 schema 是否稳定
  • 缺失字段如何处理
  • 同义字段和历史格式如何兼容

4.3 结构化输出是视觉系统进入业务链路的关键 ​

如果结果只能给人看一眼，大多数企业链路都接不下去。

更实用的落地方式通常是：

  • 先定义 JSON schema
  • 再定义字段校验规则
  • 最后把模型输出接进复核或下游系统

这一步比“模型看懂没有”更影响最终可用率。

OpenAI 当前 Structured outputs 官方文档已经把这件事说得很明确：

  • 如果你希望结果稳定被系统消费，最好让输出直接遵守你定义的 JSON Schema

这对视觉抽取尤其重要，因为很多文档系统失败并不是：

  • 模型没认出来

而是：

  • 字段名漂移了
  • 枚举值不稳定
  • 可选字段和必填字段混了
  • 下游系统不知道缺失值是“没找到”还是“没解析”

4.4 OCR、layout、字段抽取、语义归一化，最好分成四层 ​

很多系统把“文档抽取”写成一个黑盒步骤：

  • 上传文件
  • 返回 JSON

这样短期简单，长期却最难复盘。

更稳的心智通常是把它拆成四层：

  1. OCR / text layer 解决字词识别、阅读顺序、手写检测。
  2. layout layer 解决段落、标题、表格、列表、页眉页脚、图形区域。
  3. field extraction layer 解决键值对、表头字段、业务字段定位。
  4. semantic normalization layer 解决别名统一、日期格式归一、金额单位换算、缺失值语义。

这样拆开的价值很大，因为出了问题时你才能分清：

  • 是文字根本没识别出来
  • 还是结构恢复错了
  • 还是字段定位错了
  • 还是业务归一化把本来对的值改坏了

4.5 坐标、页码、bounding box 最好作为一等产物保留下来 ​

Google Cloud Document AI 当前响应处理文档，Azure Document Intelligence 当前 layout / SDK 文档，都把 bounding boxes、页面对象、表格区域等当成正式输出对象。

这件事非常关键，因为一旦你做：

  • 人工复核
  • 高亮证据
  • 二次裁切
  • 点击回看原文
  • 局部重试

就会发现自然语言答案远远不够。

更稳的视觉产物对象通常至少要带：

  • page number
  • bounding region / bounding box
  • field confidence
  • source block id
  • table / paragraph / figure object id

这样下游系统才能真正支持：

  • 点字段回原页
  • 点证据看截图框
  • 对低置信度字段单独复审
  • 对局部区域单独重试

5. 截图理解、UI 理解和文档理解也不要混在一起 ​

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

常见任务：

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

这类任务常常需要：

  • 组件关系
  • 对话框层级
  • 操作前后状态对比

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

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

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

5.3 文档理解更像知识抽取 ​

它更关注：

  • 文档结构
  • 字段规范
  • 证据回引
  • 多页聚合

所以截图助手和 PDF 抽取，虽然都叫“视觉”，但最好不要共用同一套评测集。

5.4 UI / screenshot 系统更容易踩“坐标可执行性”这个坑 ​

Anthropic 当前 Vision 文档明确把 coordinate-based workflows 单独拿出来说，本身就在提醒一件事：

  • 视觉识别结果如果要进入工具执行，坐标和元素引用必须足够稳定

这和普通图片问答完全不同。

因为一旦你从：

  • “图里这是什么按钮”

走到：

  • “请点击它”

系统要求就会从“理解正确”升级成：

  • 位置是否可重复定位
  • 缩放和分辨率变化后还能不能找回
  • 相邻元素是否会误触
  • 执行动作前是否有二次确认

所以视觉 Agent 如果真的要进 UI 自动化，最好多加一层：

  • element grounding / coordinate verification

而不要直接把自然语言理解结果当执行依据。

6. 视觉系统最常见的四类产品路线 ​

6.1 图片问答 / 商品图理解 ​

更适合：

  • 单张或少量图片
  • 以解释和摘要为主
  • 允许自然语言输出

6.2 文档抽取 / 表单识别 ​

更适合：

  • 明确 schema
  • 明确校验规则
  • 明确人工复核点

6.3 截图分析 / 界面助手 ​

更适合：

  • 多轮上下文
  • 强调状态变化
  • 和工具调用或工作流联动

6.4 视觉生成 / 素材编辑 ​

更适合：

  • 品牌和风格规范
  • 模板化生成
  • 审核与二次编辑链

7. 视觉工作流更像 pipeline，而不是单条 prompt ​

一个更稳的视觉工作流通常像这样：

text
Upload / Capture
 -> Preprocess
 -> Region / Page Split
 -> Vision or File Understanding
 -> Structured Extraction
 -> Validator / Human Review
 -> System Output

7.1 预处理层看什么 ​

  • 压缩
  • 纠偏
  • 裁切
  • 页面拆分
  • 文件转码

7.2 理解层看什么 ​

  • 是按图片理解，还是按文件理解
  • 是否需要多图对比
  • 是否需要页码和引用

7.3 输出层看什么 ​

  • JSON 是否稳定
  • 缺失字段怎么填
  • 冲突字段怎么回退

7.4 运行层看什么 ​

  • 是否能回放原始输入
  • 是否能定位失败页面
  • 是否能做人工复核与纠偏

7.5 文档工作流最好同时沉淀三类产物，而不只是最终 JSON ​

一个成熟的视觉工作流，最终最好同时留下三类资产：

  1. source artifact 原图、原 PDF、页面图、裁切图、原始文件元数据。
  2. parsing artifact OCR 文本、layout 对象、表格对象、bounding boxes、page refs。
  3. business artifact 结构化字段、校验结果、人工复核状态、最终可下游消费的 JSON。

很多团队只保留第 3 类，短期最省事；但一旦线上出问题，就会发现：

  • 没法回到原始页
  • 看不到表格结构是怎么被还原的
  • 不知道字段错误是识别错、定位错，还是归一化错

所以视觉工作流真正稳定的前提，常常不是“提示词够不够强”，而是：

  • 中间产物有没有作为正式对象存下来

8. 视觉系统评测不能只看“答得像不像” ​

8.1 理解类评测更适合看 ​

  • 字段准确率
  • 漏抽率
  • 页码或证据引用正确率
  • 多图比较正确率

8.2 文档系统更适合补这些指标 ​

  • schema 合法率
  • 必填字段完备率
  • 人工复核命中率
  • 版面变化稳定性

8.3 截图或 UI 系统更适合补这些指标 ​

  • 状态识别正确率
  • 元素引用稳定性
  • 多轮上下文保持率
  • 执行前确认命中率

8.4 生成类视觉任务更适合看 ​

  • 风格一致性
  • 可编辑率
  • 审核通过率
  • 批量交付稳定性

8.5 文档系统最好把评测拆成“识别、结构、字段、业务”四层 ​

如果只看最终字段对不对，很多问题会被掩盖。

更稳的文档评测通常至少拆成四层：

  1. recognition 文本识别、手写识别、页面顺序是否正确。
  2. layout 段落、表格、标题、列表、图形区域是否恢复正确。
  3. field extraction 目标字段是否抽到、是否抽错位置、是否漏页。
  4. business validity 金额、日期、版本、合同编号、证件号是否符合业务规则。

这样做的价值在于：

  • OCR 变差了，你能先在第 1 层发现
  • 布局恢复坏了，你能在第 2 层定位
  • 字段抽取坏了，你能在第 3 层定位
  • 归一化规则坏了，你能在第 4 层定位

8.6 视觉评测集最好强制包含“坏页”和“脏页” ​

很多团队做视觉评测时，只放：

  • 清晰截图
  • 干净 PDF
  • 最常见模板

这会让分数看起来很好，但一上线就翻车。

更稳的最小评测集通常应该故意包含：

  • 歪斜拍照页
  • 低清扫描页
  • 盖章遮挡页
  • 手写批注页
  • 表格跨页页
  • 多栏排版页
  • 新旧模板混合页
  • 局部截图而非整页截图

因为真正把系统打崩的，往往不是“标准页”，而是：

  • 脏页
  • 边界页
  • 混合页
  • 结构变化页

9. 最容易踩的坑 ​

  • 把 PDF 当成普通文本。
  • 把复杂页面直接整页丢给模型，不做切分。
  • 多图任务没有编号和角色说明。
  • 只做主观体验测试，不做字段级评测。
  • 生成类任务和理解类任务共用一套验收标准。
  • 把原生 PDF、扫描件 PDF、手机拍文档共用同一条解析链路。
  • 不保留页码、bounding box、字段来源块，导致无法复核。
  • 把 OCR、layout、字段抽取、语义归一化写成一个无法解释的黑盒。
  • UI 截图识别直接驱动点击，不加坐标验证和二次确认。

10. 推荐搭配阅读 ​

11. 重点官方资源 ​

以下资源在 2026-07-09 复核到当前正式入口；其中少数站点对脚本探测可能受限，但浏览器入口仍可正常打开：

12. 什么时候该跳到别的目录 ​