Vision LLMs are PDF Parsers Too: Reading Charts and Diagrams for RAG

Vision LLMs 也是 PDF 解析器：为 RAG 读取图表和图表 | Towards Data Science

LLM 应用

Vision LLMs 也是 PDF 解析器：为 RAG 读取图表和图表

企业文档智能 [Vol.1 #5quater] – 其他解析器读取页面上的文字。视觉模型还能读取图片

Kezhan Shi

2026年6月14日

15分钟阅读

分享

照片由 CDC 提供，来源：Unsplash。

本文是《企业文档智能》系列的解析伴侣，该系列从四个模块构建一个企业级 RAG 系统。第5篇文章（文档解析）使用了 PyMuPDF（fitz）构建了解析器，它读取页面上的文字。而这篇伴侣文章则将引擎换成了视觉 LLM，它将页面作为图像进行处理，因此它不仅提供文字，还提供文本解析器无法提供的内容：图片内容。

该伴侣文章的位置：它扩展了第5篇文章（文档解析），在第二部分（四个模块）中，使用了不同的解析引擎 – 图片由作者提供

给一个 PDF 解析器看一个图表，它看到的只是一个空框。文本引擎，无论是本地还是云端，都会在页面上找到文字并将其放入可搜索的表格中。图表没有文字，因此对它们来说，该区域是空白的，对检索系统来说，它并不存在。

视觉模型则不同。它像人一样查看页面。让它查找文本，它会给你文本和表格，和其他解析器一样。给它看一个图表，它会用你可搜索的普通语言告诉你图表的内容。最后一部分是其他解析器无法做到的。

难点在于：它速度较慢，成本更高，而且只能大致地从图表中读取数字。它的好坏也取决于你选择的模型。gpt-4.1 能够读取图表，而更便宜的 gpt-4o-mini 只能部分识别。因此你不会在所有地方都使用它。你只在那些主要是图片的页面上使用它，因为其他解析器在这些页面上无法返回任何内容。

1. 只有视觉模型能做的一件事：使图像可搜索

从这个解析器存在的原因开始。文本引擎将页面转换为早期文章中提到的关系表格，但图表却击败了它们：它们返回一个图像中的图表，可能带有一个孤立的坐标轴标签。图表中没有文字，因此对 OCR 和布局模型来说，该区域是空的，对检索系统来说，它并不存在。

OCR 和布局返回一个框；视觉解析器写入你可以检索的文本 – 图片由作者提供

视觉模型读取图片。下面是从两个 PDF 中直接提取的三个图表：来自《Attention Is All You Need》（Vaswani 等人，2017）的 Transformer 图表和来自世界银行《大宗商品市场展望》（2026年4月刊）的大宗商品价格图表。每个图表旁边是 gpt-4.1 为它撰写的单句描述。来源文档和授权信息在文章末尾列出。

每个提取的图像都会得到一个单句描述，文本检索可以匹配 – 图片由作者提供

现在价格图表变成了一句话：按行业划分的大宗商品价格指数，自2022年峰值以来一直在下降。一个搜索“自2022年以来的大宗商品价格指数”的用户现在可以找到该页面。在此之前，页面上没有任何内容可以匹配。

这是该论点最尖锐的表述方式。设想一下一张停车场的卫星图像，它没有任何文字。OCR 什么也找不到，布局分析只识别出一个框，对检索系统而言，这张图像根本就不存在。而视觉模型则会写出“停车场的航拍图，大约一半满，大约有四十辆车”。现在，对停车场占用情况的搜索就可以找到它了。这句话就是解析结果，只有视觉模型才能生成它。OCR 和布局分析从定义上就无法做到这一点，因为从来就没有可供阅读的字符。

2. 它也能解析文本和表格，就像其他解析器一样

图像部分是独特的，但一个只能读取图像的解析器是毫无用处的。视觉模型不仅能读取图像，还能读取文本和表格，而且在干净的材料上，其表现不比文本引擎差。我们让 parse_page_vision 处理 NIST 网络安全框架第 30 页的“框架核心”表格，并要求其输出 Markdown 格式。它完整地返回了表格的列，并正确处理了合并单元格（功能名称位于其块的第一行，后续行则留空）。

其他引擎也能重建这个四列表格，直接从图像中读取 – 图片由作者提供

这与前两篇文章中 Docling 和 Azure 从同一页生成的单元格结构相同：它们也生成 Markdown 表格，因此格式并不是视觉模型与其他模型之间的区别所在。视觉模型从未构建过表格对象；它只是从图像中读取了网格，并写入了 Markdown（它同样可以返回 HTML）。因此，最初的主张依然成立：它是一个解析器，返回与其它模型相同的可重用模型，同时还解析了其他模型无法解析的图像。

3. 模型的重要性：gpt-4o-mini 无法识别 gpt-4.1 能识别的图表

解析的质量在很大程度上取决于模型，而差距恰好体现在图像上。我们将相同的 CMO 图表页面分别输入 gpt-4o-mini 和 gpt-4.1 进行处理。

两者都能读取页面上的文本和表格；在图表上，较便宜的模型只识别出一半 – 图片由作者提供

gpt-4o-mini 识别出了六个图表中的三个，并将其中两个标记为表格。gpt-4.1 识别出了全部六个图表，并将它们的坐标轴精确到月份，包括 gpt-4o-mini 未能识别的政策不确定性图表和温度异常图表。两者都正确读取了页面上的文本和 NIST 表格。较弱的模型在图像上表现不佳，而这正是你引入视觉模型的目的。因此，使用这个解析器时，模型是质量的一部分，而不仅仅是延迟和成本的调节器：更便宜的视觉模型在文本上表现良好，但在图像上表现不佳。

4. 真实的权衡：精确度与成本

这一切都不是免费的，而这个权衡值得明确指出。视觉模型“并不是真正的解析器”这一说法是错误的，因为它确实是解析器。真正的问题在于，视觉模型的解析精确度较低，且每页的成本更高。

在文本和表格上也是如此；视觉模型只能读取图像；代价是精确度和成本 – 图片由作者提供

有两个成本尤为突出。

精确度有两个方面：它从曲线中读取的值是近似的：形状和大致内容是正确的，但某个具体的刻度可能有偏差，因此应将转录的数字视为线索，而非事实。更糟糕的是，它可能会静默地遗漏某个元素，例如表格中的一行或面板中的一个图表，就像 gpt-4o-mini 在第 3 节中遗漏了一半的图表一样。这是一个完整性问题，是一种因遗漏而产生的幻觉，而确定性解析器永远不会出现这种情况：当 fitz 或 Docling 读取表格时，不会有任何一行丢失。

视觉模型可以恢复图表的形状，但无法恢复精确的值；将转录的数字视为需要验证的线索 – 图片由作者提供

成本：每一页都是一张大图像和一次模型调用，按页计费，之后没有边界框可供突出显示。文本解析器只需运行一次，每页成本几乎可以忽略不计，并且能提供精确的文本范围。

因此，规则不是“用视觉代替解析”。而是“对文本解析器无法处理的页面使用视觉解析”。

5. 工作原理：parse_page_vision

机制很简单。该函数渲染页面，通过与 responses.parse 结构化输出调用相同的接口将图像发送给视觉模型，并返回一个小型对象：页面的 Markdown 格式内容，以及一个图表列表，每个图表包含类型、描述和转录文本。

page = parse_page_vision("CMO-April-2026.pdf", 10, model="gpt-4.1")
page.markdown                  # 标题、段落、表格
page.figures                   # 每个图表/图示一个条目
page.figures[0].description    # "折线图，价格指数..."
page.figures[0].transcription  # 坐标轴、图例、可读值

parse_page_vision 与 fitz、azure_layout 和 docling 解析器是同类型的解析器，因为它本身也是一个解析器。自适应解析调度器（文章 10）会在页面足够视觉化，以至于文本引擎返回空结果时调用它。

正文足够简短，可以一次性阅读。两个 Pydantic 模型定义了输出：页面的 Markdown 格式内容，以及每个图表的一个条目，包含其类型、描述和转录文本。该函数将页面渲染为图像，添加指令，并通过共享的 llm_parse 封装器进行一次结构化调用。重试、令牌限制和调用缓存都由封装器提供。没有布局模型，也没有 OCR 步骤：模型直接读取像素并填充模式。

class FigureContent(BaseModel):
    kind: str           # 图表、图示、照片、地图等
    description: str    # 用可搜索的词语描述其内容
    transcription: str  # 坐标轴、图例、可读值

class VisionPageParse(BaseModel):
    markdown: str                 # 页面的 Markdown 格式内容，保留表格
    figures: list[FigureContent]  # 页面中每个图表的一个条目

def parse_page_vision(pdf_path, page, *, client=None, model=None, zoom=2.0):
    client = client or get_vision_client()
    model = model or vision_model()
    page_image = render_page_data_url(pdf_path, page, zoom=zoom)
    content = [{"type": "input_text", "text": "Parse this page."},
               {"type": "input_image", "image_url": page_image}]
    return llm_parse(
        input=[{"role": "system", "content": VISION_PARSE_SYSTEM_PROMPT},
               {"role": "user", "content": content}],
        text_format=VisionPageParse,   # 上面的 Pydantic 合约
        client=client, model=model, label="vision.parse_page",
    )

系统提示（VISION_PARSE_SYSTEM_PROMPT）是引擎的另一半：它告诉模型保留标题和阅读顺序，将每个表格渲染为 Markdown 表格，并为每个图表添加一个条目，该条目可以用可搜索的词语进行描述。更改该指令，就相当于更改了解析器。

6. 更轻量的模式：直接向页面提问

有一种一次性使用相同功能的方式。与其将页面解析为可重复使用的结构，不如将页面和一个问题直接交给模型，然后读取一个答案。不生成 Markdown，不生成索引，也不保存任何内容。在构建模型过于繁琐时，这种方式非常有用。

ans = answer_from_pdf_vision(
    "data/nist/NIST.CSWP.04162018.pdf",
    "Category Unique Identifier for 'Asset Management'?",
    pages=30,
)
ans.answer        # "ID.AM"
ans.answer_found  # True (False when not on the page)

它的行为表现如此，这里模型几乎不重要：无论是 gpt-4o-mini 还是 gpt-4.1 都以相同的方式回答这些问题。Framework Core 查询返回了 ID.AM，Function Identify；关于注意力论文图 1 的一个问题，可以通过图表读取，返回了正确的答案；而一个答案不在页面上的问题则返回了空值。

第三行是安全检查：当询问一个不存在的内容时，它拒绝回答而不是编造答案 – 图片由作者提供

第三行与前两行一样重要。如果一个模型读取了页面内容，除非架构和指令明确告诉它“这里没有”，否则它会编造一个看似合理的答案。null 路径的触发使这种模式的使用变得安全。

同样的想法，打包成产品。现在，将视觉识别作为解析器的模式已经被几家供应商作为优化产品推出。Mistral Document AI 在 Azure AI Foundry 上（模型为 mistral-document-ai-2512，作为无服务器 API 在美国东部 / 美国东部 2 / 瑞典中部提供）捆绑了 OCR 组件（mistral-ocr-2512）和一个小型推理模型（mistral-small-2506），并返回 markdown 和一个您可以自定义其架构的 JSON 对象。输出合同与 parse_page_vision 不同，使用 markdown 而不是 line_df，结构化提取直接包含在同一个调用中，而不是委托给生成。同样的底层理念，打包成按页面计费的模型。对于已经以 markdown 为思维模式或希望将布局 + 提取步骤合并到一个 API 调用中的管道，与本文中使用的 OpenAI 视觉路线进行比较是值得的。

bbox 之间的差距是真实的。Mistral OCR 仅对页面中嵌入的图像返回边界框（每个图像携带 top_left_x / top_left_y / bottom_right_x / bottom_right_y）。markdown 正文本身没有每行、每段或每个表格单元格的边界框。这破坏了本系列其余部分所依赖的两件事：第 1 篇文章的 PDF 注释步骤（需要边界框来高亮源 PDF 中引用的行）和第 7 篇文章的行级检索审计（每个检索的行都指向其边界框，以便读者可以在页面上验证）。

那么，给读者一个开放性的问题。你将如何将两个在同一页面上运行的解析器，Mistral 的 markdown（结构化但没有边界框）和 fitz / Docling 的 line_df（边界框丰富但更扁平），整合成一个下游可以使用的连贯输出？在行或标记级别对齐两个文本流是一个已知的难题（分割方式不同，OCR 错误不同，markdown 的表格扁平化会丢失单元格位置）。本文没有提出解决方案。如果你的下游需要边界框级别的可追溯性，那么整合的成本是真实存在的，值得在承诺使用 markdown 合约之前进行衡量。

本节的来源：

• Mistral OCR API 端点规范，输入架构，响应架构（包含 markdown + 图像数组的页面，图像边界框仅限于图像）。

• Mistral OCR 处理器文档（基础 OCR），table_format 参数，每页响应结构。

• Mistral 文档注释文档，使用自定义架构的可选结构化提取，当明确请求时的边界框级别注释。

• Azure AI Foundry 目录中的 Mistral Document AI 2512，无服务器部署在美国东部 / 美国东部 2 / 瑞典中部，按页面计费。

• 使用 Microsoft Foundry 中的 Mistral Document AI 解锁文档理解，捆绑的 mistral-ocr-2512 + mistral-small-2506 组合。

7. 现在有四种解析器，其中一种可以读取图片

所有四种引擎都是解析器。其中三种可以读取文本和结构；第四种也可以读取这些内容，还可以读取图片。

fitz、azure 和 docling 从文本和布局构建模型；vision 也可以读取图片 – 图片由作者提供

第 10 篇文章（自适应解析）构建了调度器，根据每一页的内容从中选择合适的解析器。vision 解析器位于视觉端：当一页主要是图表时，当图表包含答案时，当扫描图像退化到无法进行 OCR 时，或者当内容是完全没有文本的图片时，使用它。它是每页最昂贵的解析器，对数字的识别也最不准确，所以它最后运行。但它也是唯一能够将图片转化为可检索内容的引擎。

8. 结论

视觉模型是一种解析器：要求返回 markdown，它会像 fitz 或 Azure 一样返回文本和表格；要求它描述图像，它会返回文本解析器无法做到的关于图像的可搜索文字。这种权衡是真实的（准确性较低、没有边界框、每页一次模型调用），因此视觉解析器不会取代文本解析器，而是填补了它们的盲区。它们读取页面上的文字；它读取没有文字的页面。

9. 参考资料和进一步阅读

作为文档解析器的视觉语言模型源自两个流派：开放的 VLM 文献（PaliGemma、Florence-2、Qwen-VL 系列）和前沿的多模态 API（OpenAI GPT-4o / GPT-4.1、Anthropic Claude 带视觉、Google Gemini）。本文的正确交叉阅读是 ColPali（Faysse 等人，2024 年），它将视觉页面本身作为检索的基本单位，并且是 OpenAI 发布的 gpt-4.1 和 gpt-4o-mini 的视觉能力的模型特定文档页面。

与文章方向一致：

• OpenAI，gpt-4.1 家族的视觉能力。parse_page_vision 所用模型的参考文档；相同的架构模式（视觉大语言模型作为解析器，返回 markdown 或结构化输出）。

• Faysse 等人，ColPali：使用视觉语言模型的高效文档检索，2024 年（arXiv:2407.01449）。在页面图像本身上进行视觉语言检索。锚定第 4 篇诊断网格的视觉行；将相同的技术应用于不同的模块（检索而非解析）。

不同角度，不同背景：

• Auer 等人，Docling 技术报告，IBM 研究，2024 年（arXiv:2408.09869）。基于布局的解析，不使用生成模型。不同的成本-质量权衡：确定性、便宜、对图表视而不见。第 5ter 篇（Docling 解析）从头到尾开发了这个引擎。

• Microsoft，Azure AI 文档智能。云单元级解析器。与 Docling 在图表上的盲点相同，但在其他所有内容类型上与视觉大语言模型互补。

来源文档和许可。本文中的图表和表格均来自公开许可的来源：

• Attention Is All You Need（Vaswani 等人，2017 年），arXiv:1706.03762。arXiv 非独家分发许可，声明在 arXiv 摘要页面上。

• 世界银行，《商品市场展望》，2026 年 4 月刊。CC BY 3.0 IGO，如 OKR 出版页面上所声明。

• NIST 网络安全框架 v1.1（NIST CSWP 04162018）。美国政府作品，在美国属于公共领域（参见 NIST 版权声明）。

• gpt-4.1 和 gpt-4o-mini 是 OpenAI 的专有视觉能力模型，受 OpenAI 使用条款的约束。

系列早期内容：

• 文档智能：系列简介。系列是如何一块块构建，以及构建的顺序。

• 基线企业级 RAG，从 PDF 到高亮答案。四块砖的完整流程：PDF 输入，高亮答案输出。

• 嵌入不是魔法：RAG 检索的可预测失败模式。嵌入相似性在哪些地方有效（同义词、拼写错误、改写），在哪些地方可预测地失效（未知术语、否定、术语与答案的相关性），以及如何仍然使用它。

• 重排序器也不是魔法：交叉编码器层是否值得付出代价。交叉编码器相对于双编码器嵌入增加了什么，经过测量，以及何时值得付出延迟的代价。

• RAG 不是机器学习，机器学习工具箱解决的是错误的问题。为什么块大小扫描和微调优化的是错误的东西；应根据问题类型进行路由。

• 从正则表达式到视觉模型：哪种 RAG 技术适合哪种问题。两个维度，文档复杂度和问题控制，用于为每种情况选择合适的技术。

• 我们在生产中持续看到的 10 个常见 RAG 错误。10 个生产错误，按砖块逐一组织，每个错误都有对应的修复方法。

• 超越 extract_text：驱动 RAG 质量的 PDF 的两层。解析砖的第一部分：文档的性质、信号和摘要。

• 停止从 PDF 返回扁平文本：RAG 所需的关系结构。解析砖的第二部分：每个下游砖块读取的关系表。

• 当 PyMuPDF 无法识别表格时：使用 Azure Layout 解析 PDF 用于 RAG（链接即将发布）。Azure Layout 提供的相同表格：原生表格单元格、OCR、段落角色。

• 使用 Docling 本地解析 PDF 用于 RAG：丰富的表格，无需上传云端（链接即将发布）。使用 Docling 在本地计算的相同表格：TableFormer 单元格，数据不出机器。

撰写者

查看 Kezhan Shi 的所有文章

文档处理

,

大语言模型

解析

RAG

视觉语言模型

分享本文

• 在 Facebook 上分享

• 在 LinkedIn 上分享

• 在 X 上分享

Towards Data Science 是一个社区出版物。提交你的见解，以触达全球受众，并通过 TDS 作者支付计划获得报酬。

更新为你的实际投稿链接

为 TDS 撰写文章

✦ 结束 CTA ✦