多模态基础

真实世界的信息并不都是纯文本。你后续做知识库、票据解析、截图排障、PDF 问答时，很快就会碰到多模态问题。

这一章不是让你立刻去做多模态系统，而是建立一个判断框架：什么时候值得引入多模态，什么时候先用更简单的方案解决。

本章目标

理解多模态和 OCR 不是一回事
知道图片、PDF、音频等输入在工程里通常怎么处理
能判断什么场景值得引入多模态，什么场景仍然适合传统方案
了解多模态处理链比纯文本更容易出错的地方

什么是多模态

多模态指的是系统不仅处理文本，还能处理其他信息载体，例如：

图片
PDF
音频
视频
表格
截图

在 AI 应用里，它意味着模型既能"读文字"，也能"看图"或"理解文档结构"。

但这只是表面变化。多模态真正改变的，是系统的证据来源变复杂了。

纯文本系统里，你面对的是一串已经线性化的内容；多模态系统里，信息可能散落在图片区域、页面布局、表格结构、图表趋势、截图界面状态里。也就是说，系统不再只是读句子，而是在尝试把不同载体里的信息重新还原成可推理的证据。

为什么真实业务里绕不开它

因为真实业务资料经常不是纯文本：

合同是 PDF
错误信息截图在截图里
简历可能是扫描件
会议内容可能是音频
表格与图表混在文档里

系统只能处理纯文本，很多真实场景就落不了地。不是说现在就要全做，而是需要知道这类问题存在，并能判断什么时候必须处理它。

多模态不等于 OCR

这是一个常见的混淆点。

OCR（光学字符识别）：只做一件事——把图片里的文字转成可读文本。它不理解布局，不理解图表，不理解文字之间的关系。

多模态理解：在文字识别之外，还包括：

理解布局（这段文字是标题还是正文？左右两栏哪个是哪个？）
理解图表关系（这张折线图说明了什么趋势？）
把图像和文本联合起来回答问题（"图中的这个部件是什么？"）

所以 OCR 只是多模态处理链里的一个环节，而不是全部。

这个区别非常重要，因为很多项目一上来会以为："我把图片里的字识别出来，不就等于多模态了吗？" 真实情况往往不是。

当信息只存在于纯文字里，OCR 可能就够；但只要答案依赖版面关系、表格列对齐、图表走势、截图里的按钮位置，OCR 就会立刻显得不够。它把字拿出来了，却没把结构拿出来。

PDF 为什么是典型难题

PDF 是最常遇到的多模态挑战，因为它经常同时包含：

可复制文本（正常段落）
扫描图片（部分页面是拍照或扫描的）
表格
图表
页眉页脚（往往是干扰信息）
双栏或复杂布局

所以"把 PDF 直接塞给模型"往往效果很差。正确做法通常是：

先解析结构（区分正文、表格、图片）
清洗文本（去除页眉页脚、拼接跨页段落）
切块与检索（进入 RAG 流程）
必要时结合视觉理解（对含图表的页面单独处理）

PDF 难，恰恰难在它经常把多种信息载体混在同一个文件格式里。对系统来说，它既像文档，又像图片集合，还带着布局和分页语义。你不能把它简单视为"一大段文本"，也不能完全把它当作图片来处理。

所以 PDF 场景很适合拿来理解多模态系统的本质：不是在输入前面多接一个模型，而是在整个证据提取链条里多了更多可能失真的环节。

多模态系统的常见处理链

用户上传文件
    ↓
识别文件类型
    ↓
OCR / 解析 / 转录（根据类型选方案）
    ↓
抽取文本和结构信息
    ↓
进入总结、抽取、问答或 RAG 流程

很多"多模态系统"本质上是：

多模态输入处理 + 结构化抽取 / RAG / Agent

理解了这个处理链，你会发现前几章的内容（RAG、Structured Output、Tool Calling）都能直接复用，区别只在于最前面的"输入解析"环节。

PDF 解析实战骨架

在工程上，区分"文本页"和"图片页"是处理 PDF 的第一步，因为两类页面的后续处理路径完全不同。

文本页（页面本身包含可选中的文字）可以直接提取文本，速度快、质量高，不需要走视觉模型。图片页（扫描件或全图嵌入的页面）则必须走视觉模型或 OCR，否则内容根本拿不到。用 pymupdf（import fitz）可以在提取阶段就做出这个判断：

python

import fitz  # pymupdf
import base64

def parse_pdf(pdf_path: str):
    doc = fitz.open(pdf_path)
    text_pages = []
    image_pages = []

    for page_num, page in enumerate(doc):
        text = page.get_text().strip()
        if text:
            text_pages.append({"page": page_num, "text": text})
        else:
            # 页面没有可提取文字，渲染成图片再走视觉模型
            pix = page.get_pixmap(dpi=150)
            img_bytes = pix.tobytes("png")
            image_pages.append({
                "page": page_num,
                "image_b64": base64.b64encode(img_bytes).decode()
            })

    return text_pages, image_pages

这段代码的判断逻辑很简单：get_text() 能拿到内容就视为文本页，否则渲染成图片交给后续的视觉模型处理。实际项目中，"文本页"通常还需要额外清洗（去页眉页脚、拼接跨页段落），但核心分流逻辑就是这个。

图片页的处理可以直接接入下面的视觉模型调用流程——把 image_b64 传给视觉模型，让它提取页面里的关键信息。这也是 PDF 解析和纯 OCR 方案的分叉点：纯 OCR 只认字，视觉模型还能理解表格结构、图表趋势和页面布局。

最小可运行：用视觉模型分析一张截图

视觉模型调用在结构上和普通文本调用差别不大，核心区别是消息里多了一个 image_url 内容块，可以放 base64 编码的图片数据。下面这段代码演示的场景是：用户上传了一张报错截图，系统把它发给 gpt-4o，同时要求模型把识别结果以结构化格式返回（提取出错误信息和修复建议）。

python

import base64
from pathlib import Path
from openai import OpenAI
from pydantic import BaseModel

client = OpenAI()

class ErrorAnalysis(BaseModel):
    error_message: str
    likely_cause: str
    fix_steps: list[str]

def analyze_screenshot(image_path: str) -> ErrorAnalysis:
    image_data = base64.b64encode(Path(image_path).read_bytes()).decode()

    response = client.beta.chat.completions.parse(
        model="gpt-4o",
        messages=[
            {
                "role": "user",
                "content": [
                    {
                        "type": "image_url",
                        "image_url": {
                            "url": f"data:image/png;base64,{image_data}"
                        }
                    },
                    {
                        "type": "text",
                        "text": "这是一张报错截图。请提取错误信息、分析可能原因，并给出修复步骤。"
                    }
                ]
            }
        ],
        response_format=ErrorAnalysis,
    )

    return response.choices[0].message.parsed

client.beta.chat.completions.parse 是 OpenAI SDK 内置的 Structured Output 调用方式，传入 Pydantic 模型后会直接返回解析好的对象，不需要手动 json.loads。

这段代码的典型用途是"截图报错分析"功能：用户把错误截图粘贴进来，系统自动提取 error_message、likely_cause、fix_steps，再把结果渲染成页面。比起让模型直接用自然语言回答，结构化输出让后续的展示、存储和统计都更容易处理。

如果图片是动态生成的（比如前面 PDF 解析中渲染出来的图片页），直接把对应的 base64 字符串填入 image_url.url 字段即可，调用结构完全相同。

多模态为什么不是“前面加一层解析”这么简单

表面上看，处理链好像只是比纯文本系统多了一段预处理。但真正麻烦的是，一旦前面的解析有误，后面所有步骤都会在错误证据上继续工作。

比如：

OCR 把金额识别错了，结构化抽取再精确也没用
双栏 PDF 拼接顺序乱了，RAG 检索召回的就不是原本语义
图表标题没读出来，后面的总结会失去关键上下文
截图里真正重要的是界面状态，不是可见文字，单纯抽字会漏掉问题核心

换句话说，多模态系统的问题常常不是出在最后一轮回答，而是出在最前面的证据重建。

多模态为什么更容易出错

比纯文本系统多了几个出错环节：

OCR 识别不准（扫描质量差、手写字）
页面布局被解析错（双栏误拼，表格变乱文本）
图表内容被遗漏（图片里的数据无法直接转文字）
处理链更长，每一步的误差会向后传播累积

所以多模态场景对质量保障的要求更高，需要：

引用原文位置（让用户能对照原始文件）
高亮命中区域（让用户知道答案来自哪里）
允许人工确认（对解析结果标注不确定性）

多模态比纯文本更脆，根源在三个地方：

输入更脏。 图像质量、拍摄角度、扫描偏斜、噪点、阴影都会影响识别。
结构更隐含。 纯文本顺序通常天然明确，图像和 PDF 的结构要靠系统自己还原。
误差传播更强。 前面一旦识别错，后面总结、抽取、问答都会基于这个错误继续放大。

这也是为什么多模态系统特别需要可追溯性。你必须让用户和开发者有机会回到原始区域，去检查问题是出在识别、解析、检索，还是最后的生成。

什么时候值得引入多模态

值得引入的场景：

用户上传文件是核心功能（PDF 问答、合同分析、票据解析）
纯文本提取已经明显不满足需求（表格、图表是关键信息）
截图/图片是用户的主要输入方式（截图报错、手写笔记）

先不要引入的场景：

用户只上传文本文档（用普通文本解析就够）
核心业务还在纯文本阶段，还没遇到非文本数据
多模态只是"感觉应该支持"，但实际上没有真实需求驱动
处理链复杂度会显著超出当前团队维护能力

一个常见的错误是：看到多模态能力很强，就提前集成，结果大部分时间在调试 OCR 质量和解析格式，而不是在推进核心功能。能力引入时机和能力本身同样重要。

一个更实用的判断：你缺的是“看懂”，还是“抽出文字”

很多团队到底要不要上多模态，卡的不是技术，而是判断标准不清。一个很好用的区分方式是问自己：

当前问题是不是只要把文字抽出来就能解决？
还是说，真正重要的信息在布局、图表、区域关系或视觉上下文里？

如果只是前者，先做 OCR + 文本流程通常更稳、更便宜。只有当后者开始决定答案质量时，多模态理解才值得真正进入核心链路。

多模态内容进入 RAG 的处理方式

图文混合文档（典型的是 PDF）进入 RAG 之前，需要先把文字部分和图片部分分开处理，因为两者后续的处理路径不同。

文字部分按正常流程走：提取、清洗、切块、向量化，进入向量库。

图片部分不能直接向量化。原因很简单：图片 embedding 和文本 embedding 通常不在同一个语义空间里，搜出来的结果对不上。更重要的是，检索系统召回的内容要能被语言模型直接读懂，而原始图片字节没有直接的语义可供比较。

正确做法是把图片先转成文本描述再进向量库。转换方式有两种：

Image captioning：用专门的视觉语言模型生成对图片内容的自然语言描述（如"图表展示了 2023 年各季度销售额走势，Q3 增长最明显"）
直接用视觉模型生成摘要：把图片发给 gpt-4o 这类视觉模型，要求它用一段文字总结图片的核心信息，质量通常更高，但成本也更高

两种方式最终都把图片转成了文本，然后和文字部分统一进入向量库。检索时没有区别——都是文本匹配。

检索命中后，组装上下文时需要注意：如果命中的是图片页生成的摘要，最好把原始图片也带上。光靠摘要文字，模型在回答时可能会漏掉摘要没覆盖到的细节。常见做法是把图片和摘要作为一个 chunk 存储，检索时一起取回：召回 chunk → 如果有图片附件 → 把图片和文本一起塞进上下文。

工程上最容易出错的地方：

跨页表格：表格被分到两页，解析后成了两段不相关文本，语义完全断掉。需要在切块前检测并拼接。
图表描述不完整：视觉模型生成的摘要可能把数字说错，或者漏掉图例。重要文档要人工抽检。
图片和文字的位置关系：PDF 里图片旁边的说明文字往往是对图片最重要的解释，如果切块时把它们分开了，检索回来的摘要会失去关键上下文。

适合你的切入点

如果你确实需要处理非文本输入，以下方向门槛相对低，也和前面章节直接衔接：

截图报错分析：用户上传截图，系统识别报错并给出建议。调用视觉模型 + 结构化抽取即可。
PDF 知识库问答：已有 RAG 基础，只需在文件入库前加一步 PDF 解析。
票据 / 简历结构化提取：结合 Structured Output + OCR，把扫描件变成结构化数据。

三个方向都能和 RAG 原理、Structured Output 直接结合，不需要重新搭框架。

为什么多模态最终还是会回到前面那些章节

很多人刚学多模态时，会以为这是另一条全新的主线。其实不是。多数业务里，多模态只是把"证据拿进系统"这一步变复杂了，后面的核心问题仍然是：

拿到的内容怎么结构化
资料如何进入检索和问答
输出如何校验
风险怎么控制

所以多模态不是替代前面的知识，而是在前面整条链路前面，加了一个更难、更脆弱的输入层。

几条容易踩的坑

记住格式列表没多大用，关键是建立几个判断习惯。

多模态最难的地方不在于模型能不能看图，而在于系统能不能把视觉信息稳定还原成可追溯的证据。OCR 和多模态也不是互相替代——OCR 抽字，多模态理解结构和关系，它们解决的是不同层级的问题。

PDF 之所以是典型难题，就是因为它把文本、图片、布局、表格混在了一个文件里。出了问题，最该先查的往往不是最后那轮回答，而是最前面的解析和证据重建环节。

还有一点：成熟团队通常不会一上来就全面铺开多模态。他们会先搞清楚当前业务到底缺的是文本提取能力，还是视觉理解能力，再决定怎么投入。

自查

读完这章，试着回答：

什么是多模态？它和 OCR 的区别是什么？
为什么 PDF 是典型复杂场景？
多模态系统通常会经过哪些处理阶段？
为什么多模态结果更需要引用、高亮和人工确认？
什么时候值得引入多模态，什么时候应该先跳过？

补充自测

以上 5 题考的是基本理解，下面几题更偏场景设计：

场景题 1：用户上传了一份含大量图表的 PDF 财报（共 80 页，约 60% 页面有图表）。你会怎么设计解析流程？哪一步最容易出错，怎么验证？

场景题 2：一个截图报错分析功能，有两种实现思路：A）视觉模型直接看截图，输出自然语言回答；B）先让视觉模型结构化提取错误信息，再把结构化结果交给另一步处理。两种思路各有什么优劣？什么情况下选 A，什么情况下选 B？

场景题 3：你的 RAG 知识库支持 PDF 上传。有用户反馈说"上传了一份 PDF，问里面的数据，答案经常答错"。你会从哪几个环节入手排查？排查顺序是什么？

继续读 AI 应用系统设计——把前面所有能力（聊天、工具调用、RAG、Agent、安全、评测、多模态）拼成一个完整的产品系统。

多模态基础 ​

本章目标 ​

什么是多模态 ​

为什么真实业务里绕不开它 ​

多模态不等于 OCR ​

PDF 为什么是典型难题 ​

多模态系统的常见处理链 ​

PDF 解析实战骨架 ​

最小可运行：用视觉模型分析一张截图 ​

多模态为什么不是“前面加一层解析”这么简单 ​

多模态为什么更容易出错 ​

什么时候值得引入多模态 ​

一个更实用的判断：你缺的是“看懂”，还是“抽出文字” ​

多模态内容进入 RAG 的处理方式 ​

适合你的切入点 ​

为什么多模态最终还是会回到前面那些章节 ​

几条容易踩的坑 ​

自查 ​

补充自测 ​

下一章 ​