把 PDF 转成 Markdown，真的能让 AI 读得更好、更省 Token 吗？

最近在帮助药物警戒（Pharmacovigilance，PV）部门开发一个小工具，我遇到的第一个难题并不是怎么设计程序和输出，而是怎样理解源数据。

PV 的安全性数据来自 Argus 系统。我对这套系统并不熟悉，一些重要变量的录入规则、取值方式和相互之间的逻辑关系，即使是熟悉业务的同事，也很难在一次沟通中准确、完整地说清楚。

业务同事更习惯解释某个字段在实际工作中代表什么，开发人员关心的却是另一组问题：这个指标应从哪些源数据中获取？需要怎样衍生？字段之间有哪些必须满足的条件？哪些情况属于例外？如果这些问题的答案仍然是“这样也可以”“大概如此”或“偶尔会出现”，程序就无法真正落地。

这并不是谁不够专业，而是不同岗位组织信息的方式本来就不一样。业务知识要变成可执行的程序规则，中间还需要一次翻译。对一个手里握着多个 AI Agent 工具、以为很快就能开工的程序员来说，这恰恰是最容易遇到的“滑铁卢”。

后来，我拿到了一份约 150 页的 User Guide，把它交给 AI Agent，请它围绕几个重点变量查找填写要求和关联逻辑。出乎意料的是，AI 很快就整理出了我需要的信息，帮助我迅速建立了对源数据结构的初步认识。

更让我好奇的是：整个过程看起来并没有消耗多少 token。

我原先一直以为，PDF 对大模型不够友好。如果先把全文转换成 Markdown，模型应该会读得更好，也更节省 token。这次经历让我意识到，这个看似合理的认识，可能把文件格式、文档解析和模型上下文混在了一起。

AI 到底怎样读取 PDF？150 页内容是否都进入了模型？转成 Markdown 又究竟解决了什么问题？

01省不省 Token，取决于什么？

如果只想从一份长文档中查找几个变量，通常没有必要先把整本 PDF 转成 Markdown，再让模型从头阅读。更合适的方式是先搜索和定位，再把相关段落、表格或页面交给模型分析。

不过，这并不意味着 Markdown 没有价值。它很适合保存结构、人工审阅和后续复用，只是它不是 AI 阅读 PDF 的必经步骤，更不是一个自动压缩 token 的开关。

02AI 读取 PDF，首先要经过一个解析过程

PDF 更像一个用于固定页面呈现的容器。里面可能同时存在：

所以，我们在对话框里上传一个 PDF 后，模型并不是简单地接收了一个“.pdf 文件名”。平台或 Agent 需要先把其中可用的信息转换成模型能够处理的输入。

常见过程可以概括为：

PDF 文件→ 判断页面和内容类型→ 提取文字 / OCR / 渲染页面→ 搜索并选择相关内容→ 将文字或图像送入模型→ 生成回答

图 1　PDF 交给 AI Agent 后，可能先经过解析、搜索和上下文筛选；复杂版式仍需回到原始页面复核。

不同产品的具体实现并不完全相同。有的平台会把 PDF 直接作为模型文件输入，有的 Agent 会先使用本地工具提取文字和搜索页码，还有的系统会先把文档建立成可检索的知识库。

MarkItDown 就是这类预处理工具的一个例子。它是一个轻量级 Python 工具，可以把 PDF、Word、Excel、PowerPoint 等文件转换成 Markdown，并尽量保留标题、列表、表格和链接等结构。借助这类工具，Agent 可以先在模型之外完成文件转换，再决定把哪些结果交给模型。

先分清：是模型在读，还是 Agent 在处理？

讨论“AI 读取 PDF”时，最好先分清三个角色。

大模型负责理解文字、分析变量关系和生成回答。例如，DeepSeek 或 GLM 的具体模型，能看到什么取决于传入的上下文。

AI Agent 工具负责组织过程。例如，Trae 或 WorkBuddy 可能先读取文件、调用 OCR、搜索关键词、建立索引，再把命中的片段交给大模型。

MarkItDown 这类文件处理工具则更靠前，主要负责把 PDF 转成可搜索的文本或 Markdown。它本身不是大模型，也不负责判断业务规则。

不过，“工具处理”并不等于“Python 处理”。同样的工作也可以由命令行程序、其他编程语言、本地 OCR 引擎、云端文档服务或平台内置解析器完成。需要关注的是处理结果是否进入了模型上下文，工具用什么语言编写并不是关键。

03“读取 150 页”不一定等于“把 150 页全部塞进上下文”

人阅读一本 150 页的 User Guide，通常要从前往后翻阅。Agent 不一定采用同样的顺序。

当任务是“查找几个重点变量”时，它可能先做这些事情：

在这条路径中，全文可能被工具扫描或建立索引，但实际进入模型上下文的只有少量相关内容。

这与我们使用搜索引擎查资料有些相似：搜索引擎需要索引大量页面，但回答一个具体问题时，并不需要把整个互联网都放进当前对话。

另一种常见方式是 File Search 或检索增强生成（Retrieval-Augmented Generation，RAG）。系统先把文档解析并切分成多个片段，提问时再通过关键词和语义搜索找出相关片段。OpenAI 的 File Search 就支持对已上传文件进行语义和关键词检索；还可以限制返回结果数量，以减少 token 和延迟，但片段过少也可能降低答案质量。

因此，看到 Agent 很快处理完 150 页 PDF，只能说明它完成了任务，不能据此断定它已经把 150 页逐字送入模型，也不能断定它一定只读了几页。要知道确切路径，仍需查看相应产品的文件处理和用量说明。

04Token 到底花在了哪里？

理解 token 成本，需要区分三件事：文档预处理、工具返回给模型的内容，以及模型真正接收到的上下文。

所以，“处理了一个很大的文件”和“消耗了很多模型 token”并不是同一件事。

如果 Agent 在本地完成文字提取、搜索和页码定位，这些操作会消耗计算时间，但不一定消耗大模型 token。不过，不能因此简单地说“调用工具不费 token”：模型需要决定是否调用工具，而工具返回的内容一旦交回模型，仍可能成为上下文的一部分。

以 MarkItDown 为例，下面两种用法的结果可能很不一样。

第一种是让它把 PDF 转换为本地文件：

markitdown user-guide.pdf -o user-guide.md

如果工具只向 Agent 返回“转换完成”和文件位置，正文暂时没有进入模型。随后再在 Markdown 文件中搜索目标变量，只返回少量命中段落，模型接收到的内容就可能很少。

150 页 PDF→ MarkItDown 在本地生成 Markdown→ 本地搜索变量及相关术语→ 只返回命中段落和前后文→ 模型综合规则并生成答案

第二种是让 MarkItDown 直接把整份转换结果输出给 Agent。如果这份完整 Markdown 被纳入后续上下文，那么转换本身虽然不消耗模型 token，转换结果仍可能形成一大段模型输入。

MarkItDown 还有可选的 OCR 和云端解析能力。例如，它的 OCR 插件可以调用带视觉能力的大模型识别嵌入图片；这时图像和识别提示会进入模型，不能再归入“纯本地、无模型 token”的处理。它也可以连接付费云端文档服务，这类调用可能使用另一套计费方式。

反过来，如果直接把整本 PDF 作为视觉文件输入，平台又同时发送了文字层和每页图像，即使原文件不大，也可能产生较多输入 token。

因此，很难用“每页固定消耗多少 token”来估算所有 PDF。实际成本至少受这些因素影响：

所以，“50 页 PDF 一定是多少 token”或“图片一定是文字的多少倍”都只能是特定条件下的估算，不适合作为通用结论。

05Markdown 能解决哪些问题？

Markdown 的优势不在于文件扩展名，而在于它能为已经提取出来的内容补充结构。

MarkItDown 的项目说明将 Markdown 描述为一种接近纯文本、标记较少，同时又能表达重要文档结构的格式，并认为它适合后续 LLM 和文本分析流程。这里的“token-efficient”更适合理解为：与包含大量标签和样式的 HTML、Office 内部结构等表示相比，Markdown 通常更紧凑。它并不意味着同一份内容转成 Markdown 后一定比干净的纯文本更短，也不意味着把整份 Markdown 交给模型会比选择性读取更省 token。

同样一段文字，转换成 Markdown 后还会增加标题符号、列表符号和表格分隔符。它可能因为结构更清楚而帮助模型理解内容，却不会因为文件名变成 .md 就自动减少 token。

不过，PDF 转 Markdown 本身也可能丢失信息。例如：

因此，Markdown 更适合作为经过检查的中间表示，而不是默认比 PDF 更准确的“升级格式”。

06为什么这次 150 页 User Guide 看起来没有花很多 Token？

回到开头的场景，Agent 很快找到了重点变量的信息，而且可见的 token 消耗不高。背后可能有以下几种原因：

但这些只能作为可能的机制，不能仅凭界面上的 token 数量反推出具体实现。

基于这些观察，我们只能说：

两种表述看似接近，技术含义却不同。前者暗示模型逐字处理了全文；后者只描述我们实际观察到的结果。

07只查几个变量，更合适的流程是什么？

对于 User Guide、数据采集指南、系统说明书或其他长篇技术文档，可以按下面的步骤处理。

第一步：把问题说具体

不要只问“请帮我读懂这份指南”，而要给出明确对象：

例如要求整理：字段含义、录入方式、允许值、必填条件、与其他字段的依赖关系，以及对应页码。

第二步：先判断 PDF 类型

第三步：先定位，再精读

搜索不应只依赖变量名，还可以加入：

找到命中位置后，还要读取前后文，并沿着“参见某章节”之类的交叉引用继续核对。

第四步：回到原页复核

纯文本适合定位，却可能破坏版式。涉及以下内容时，应回看对应 PDF 页面：

第五步：让结论带着证据出来

最终结果不要只有一段流畅的总结，最好形成一张可核对的表：

如果不同章节存在冲突，应该保留冲突，而不是让模型自行选择一个看起来更合理的答案。

08PDF 直接交给 Agent，还是先转成 Markdown？

这取决于准备怎样使用这份文档，而不是哪种文件格式看起来对 AI 更友好。

对于一份 150 页的指南，如果只是查询几个明确变量，可以直接把 PDF 交给 AI Agent，让它先检索，再读取相关内容。没有必要先把全文转换成 Markdown，也没有必要要求模型逐页读取整本 PDF。

如果同一份指南以后还要长期、反复查询，全文转换就有了价值。经过人工检查的 Markdown 方便修订提取结果、比较不同版本，也适合进一步整理成字段字典或文档知识库。

不过，即使已经转换成 Markdown，遇到复杂表格、系统截图、流程图或跨栏注释时，仍然应该回到原始 PDF 页面核对。三种方式并不互相排斥，实际使用时经常需要组合起来：全文用于搜索，相关部分用于阅读，关键页面用于核对。

图 2　根据任务选择处理方式：一次性查询可直接交给 Agent，长期复用再考虑 Markdown，复杂版式仍需核对原始页面。

09三个常见误区

误区一：转成 Markdown 就会更省 Token

token 取决于实际进入模型的内容，不取决于文件后缀。把整本 PDF 转成 Markdown 后再全文发送，仍然可能是一段很长的输入。

误区二：AI 找到了答案，就说明它完整读过全文

它可能通过搜索和检索找到了相关章节。对于明确的信息提取任务，这通常已经足够；但对于要求全文综合、检查遗漏或判断章节冲突的任务，仍需扩大检索范围并验证覆盖度。

误区三：只要答案合理，就不必看原文页码

在临床和 PV 等专业场景中，流畅不等于准确。User Guide 描述的标准规则，也不一定完全等同于当前系统配置和最终导出数据。AI 的结果适合帮助我们建立初步认知、提高沟通效率，但关键字段和逻辑仍应与实际数据及业务人员核对。

10回到最初的问题

这次经历之后，我不再把“PDF 是否转成 Markdown”当作判断 AI 阅读效果和成本的关键。我开始追问：文件经过了哪些处理，最后又有多少内容进入模型？

我们看到的只是“上传文件，得到答案”。在这中间，可能还发生了文字提取、OCR、关键词搜索、语义检索、页面渲染和上下文筛选。

Markdown 是这条链路中一种可选的中间形式。它适合整理结构和长期保存，但是否节省 token，还要看转换后的内容怎样交给模型。

回到开头那个问题：如果只想从一份长文档中找到几个关键变量，可以先定位相关内容，再把证据交给 AI 阅读；遇到表格、截图或流程图时，再回到原始页面核对。

这样既能控制上下文，也方便核对答案。对于需要追溯依据的专业工作，答案是否可以回查，往往比具体节省了多少 token 更重要。

11参考资料