上周我处理一份行业研报PDF 大概九十多页图省事直接把文件拖进了某个大模型对话框。结果它思考了将近一分钟最后把第三章的结论安到了第五章的案例上。换成 Markdown 版本之后同样的问题十分钟内就完成了分析而且关键数据没有再出错。这个对比特别直观PDF、Word、网页这类格式是给人看的Markdown 是给 AI 读的。别再把原始文件随手丢给 AI先转成 Markdown 再喂进去往往又快又准还省 token。这篇文章会把背后的原因讲透并给出不同文件的转换流程、清洗方法、切块策略和排查记录。适合这几类人看经常让 AI 做文档摘要和问答的办公族维护本地知识库的开发者以及研究长文档分析的提示词工程师。1. 为什么 AI 读原始文件总在翻车1.1 token 视角下AI 并不是真的“看见”了文件先捋一个很多人忽略的事实大语言模型的输入层不是文件而是 token。所谓“让 AI 读 PDF”本质上是模型服务方先把 PDF 解析成文本再把文本切成 token然后送入模型。这个解析过程由黑盒管道完成我们看不到中间产物也无法修补出错的地方。PDF 里的表格错位、扫描件里的错字、网页里的广告导航这些噪声会被原封不动地转成 token 喂给模型。模型要把这些噪声当成有效信息去推理准确率自然会掉。我做过一个简单的对照测试同一份资料一份直接从 PDF 导出的文本一份清洗后的标准 Markdown。两者字数差不多但前者的 token 消耗比后者多了将近三成。多出来的部分就是空格、孤立换行、制表符和无意义标点。转换这一动作同时解决了准确率和成本两个问题。类比一下你要让一个速记员帮你整理会议纪要你不给他一份带批注、修订痕迹的草稿而是给他一份干净的结构化笔记他做出来的东西当然更接近你想要的结果。1.2 PDF 的三大坑坐标画布、乱序文本流、无文本层PDF 的排版逻辑更像海报设计软件文字的位置是一个个坐标格式强调的是“印出来什么样”而不是“读起来什么顺序”。AI 从 PDF 提取文本时按文件内部的指令顺序去拼句子很容易把页眉、页脚、图注、正文全部混在一起。第二个坑是多栏和表格。研究报告常用双栏排版PDF 的文本流可能先读满左栏再读右栏也可能按某种内部对象顺序交错跳动。AI 拿到的文本顺序和人的阅读顺序不一致分析结果自然对不上。第三个坑最隐蔽扫描版 PDF 根本没有文本层本质就是几张图片。AI 只能靠 OCR 去“认字”。OCR 对清晰印刷体还行一旦遇到公式、浅色字体、特殊符号错字率会明显上升。最可怕的是数字错——把“2.8%”识别成“2.3%”后面所有结论都建立在错误数据上。1.3 Word 和网页也有一堆隐形噪音Word 的 docx 格式其实是压缩包里面有大量的 XML 描述样式、批注、修订记录。某些转换器会把批注、修订里的旧内容一起输出结果正文里穿插着七八种颜色标注的历史版本AI 根本分不清哪句是最终稿。网页的问题在于信息噪音。导航栏、推荐阅读、广告模块、Cookie 弹窗这些元素的文本量常常比正文还大。如果不对 HTML 做清洗AI 得到的是一锅大杂烩正文还能识别但搜索引擎的推荐烂文也一起进去了严重干扰判断。所以问题的根源很清楚原始格式是给人设计的视觉产物不是给模型设计的语义产物。AI 当然也能强行解析但代价是速度慢、token 高、错误多。与其让它在最差的地基上盖楼不如我们自己先把地基夯实。2. Markdown 到底赢在哪里2.1 纯文本是模型最舒服的信息组织方式Markdown 最核心的优势是纯文本。它没有隐藏的样式标签、没有二进制结构、没有坐标信息。模型只用面对最干净的字符串tokenizer 的负担也小很多。而且 Markdown 的结构符号是“所见即所得”的语义标记。#代表一级标题|代表表格单元格代表代码块代表引用。这些符号只多花几个 token却给模型提供了极其明确的阅读理解路标。比如同样一句话“前三季度营收增长 12%。”在 PDF 里它可能被拆成“前三季”“度营收”“增长”“12%”分布在不同的文本流位置。在 Markdown 里它就是一个完整句子前后还有标题指明这是“财务摘要”章节。模型理解后者几乎不费力气。2.2 Markdown 和 AI 的训练语料天然同频还有一个很多人忽略的因素大模型的训练语料里有海量的 Markdown 文档。开源代码仓库的 README、技术博客、知识库文件几乎都用 Markdown 组织。模型在预训练阶段已经看过无数这种结构它非常清楚# 标题后面通常跟着什么内容| 表格 |应该如何解析。换句话说你拿 Markdown 跟它交流用的是它的“母语”你拿 PDF 跟它交流相当于让它翻译一门结构混乱的外语。同样是总结文档Markdown 输入的指令遵循成本更低模型能把更多推理能力用在真正的问题分析上而不是费力识别格式。2.3 Markdown 天然适配知识库的切片需求如果你在维护一个知识库或做检索增强生成Markdown 的优势会被放得更大。目前主流的分块方法有两种按固定 token 数切块或者按语义边界切块。固定长度切块常常把完整段落拦腰截断检索时容易漏掉关键信息。Markdown 则自带清晰的语义边界——标题。按标题切块有几大好处每个切片自带一个描述性标题向量化后检索命中率更高切片之间没有重叠和截断信息完整性更好做增量更新时只需要替换对应标题下的内容块不用全库重建。我在一个内部资料库上做过实验PDF 直接切片构建向量库某类问题命中率大约七成同样的内容转成 Markdown 后按标题切片命中率提到九成以上。这背后不是魔法只是把“模型需要猜测的边界”变成了“文档自己宣告的边界”。3. 各格式转 Markdown 的实操方案3.1 第一步判断文件属于哪一类不要看到一个 PDF 就开始转先花十秒钟判断文件类型能省下后面几小时文件特征类型判断处理思路文字可以选中、复制搜索能跳到具体页文字版 PDF直接提取文本并转 Markdown文字不可选中整页像图片扫描版 PDFOCR 识别或整页转图片交给多模态模型有页码、目录、多栏排版、大量表格复杂版式文档转换后重点检查顺序和表格docx 有批注、修订、多人编辑痕迹Word 文档先接受修订或删除批注再转换网页文章有大量侧栏、广告、弹窗HTML 文档先提取正文再转 Markdown这个分类思路非常重要。很多转换翻车都源于“拿扫描件去跑文本提取”源头就错了。3.2 文字版 PDF 的转换与检查对于文字版 PDF我常用的思路是命令行工具一把梭。某开源转换工具支持保留标题层级、把表格识别为 Markdown 表格、识别粗体和斜体。核心命令大致长这样pdf2md 输入.pdf -o 输出.md --with-headings --tables转换完成之后不要急着把内容喂给 AI先做四个检查第一抽查标题。找文档目录里的一级、二级标题看 Markdown 里是否保留了#和##。如果标题全部变成了普通段落说明源 PDF 没有标准的标题结构需要手动补标记。第二对照表格。找一页含表格的内容在原文和 Markdown 之间来回看。列数是否一致合并单元格是否被拆开。如果表格显示错乱宁可删掉这个表格改成“表格内容以图片形式见images/table1.png”也不要给 AI 一份乱码表。第三查乱码。搜索常见的乱码形态比如连续的符号、孤立的一串十六进制字符。出现乱码意味着字体编码映射出了问题这部分内容直接放弃重新截图处理更靠谱。第四看页眉页脚。报告的页眉通常包含公司名、章节名页脚包含页码。转换器可能把它们当成正文内容插入段落中间。这一步要在清洗阶段统一处理。3.3 Word 和 PPT 的转换注意点Word 转 Markdown 比 PDF 简单因为 docx 本身有结构信息。但有两个地方特别容易翻车批注修订和目录页码。批量处理前一定记得先查看文档是否有批注。批注框里的内容经常会被转换器当成正文输出造成段落撕裂。处理方式是先接受所有修订、删除所有批注再执行转换。目录页码的问题也很常见。有些文档自带目录页转换器会将目录里的“第 1 章……1”“第 2 章……23”当成真实内容输出。这些数字会严重干扰 AI 对正文篇幅和结构的理解。建议在转换后搜索“第”和“页”等关键词把整块目录删掉。PPT 转 Markdown 的思路不太一样每页幻灯片对应一个二级标题标题内容加粗表示正文要点转成列表。演讲者备注是极其宝贵的上下文可以放到引用块里。公式不要直接截图优先用 LaTeX 语法$...$插入AI 对公式文本的理解能力比 OCR 强得多。3.4 网页文章的正文抓取与转换网页转 Markdown 的关键不是转换而是先去掉噪音。直接复制网页内容再转你会收获满屏的导航链接、Cookie 提示、热门推荐正文反而淹没在其中。我的做法有两个一是用浏览器的“阅读模式”打开文章此时页面已经只剩下正文和配图再复制下来转 Markdown二是用某某网页转 Markdown 的浏览器插件它内部做了正文提取能自动过滤侧栏。这里有个很常见的坑某些内容平台的正文是懒加载的往下滚动时才会加载新内容。如果直接复制你可能只抓到首屏几百字。正确做法是先把文章完整滚动一遍让所有分段都加载出来再执行复制或插件转换。验证网页转换是否成功也很简单看 Markdown 开头是否就是文章标题结尾是否就是正文最后一段。如果中间夹了“相关阅读”“免责声明”说明正文提取失败了换一种方式抓取。3.5 扫描版 PDF 的 OCR 处理流程扫描件处理相对繁琐但也不是无解。先说结论不是所有扫描件都值得转 Markdown。如果内容以图表、复杂表格为主直接把整页转成图片交给多模态模型比 OCR 转换成文字再交给纯文本模型靠谱得多。如果确实需要转文字流程是这样的先把 PDF 渲染成 300dpi 的图片方向不正的先摆正然后调用 OCR 引擎识别文字最后把识别结果整理成 Markdown。300dpi 是一个平衡点太低会丢失细节太高会让图像体积膨胀反而影响 OCR 速度。OCR 完成之后摘要一个诊断原则断言越关键越要回到原文核对。数值、百分比、人名、产品名这些属于高风险内容。OCR 把它们识别错的概率并不低。比如某个实验报告里把“显著性水平 0.05”识别成“0.005”这个错误足以推翻整个结论。数字化时代这种错误的隐蔽性极强。3.6 转换后的通用清洗三步曲不管是从 PDF 还是网页转出来的 Markdown都要经过清洗。这里分享我的三步流程。第一步清页眉页脚。如果整份文档每页页眉重复某种模式用正则把它们删掉。比如中文文档常见第 X 页可以用^第\s*\d\s*页\s*$匹配删除。注意 Haskell 风格的换行匹配时要带上^和$避免误删正文。第二步合并断行。很多文档转换后会出现“一个段落□□□换行□□□一个段落”的状态即句子中间被插入了换行符。合并的逻辑是如果一行末尾没有句号、问号、感叹号而下一行开头是小写字母或正常中文则应该合并为同一段落。可以用一系列正则把行尾的换行符替换为空格但要注意不要破坏列表和代码块。第三步修复表格。如果 Markdown 表格的列数不一致模型会看不懂。一个简单的修复策略是找出所有以|开头的连续行统计每行列数把列数不一致的行单独挑出来人工处理。绝大多数情况下这类问题源于跨行单元格或空白字符修起来不快但值得做。4. 喂给 AI 的最终姿势4.1 按标题切块比按字数切块靠谱得多Markdown 转好之后还要考虑怎么喂给模型。如果只是一两份文档全文发送没有太大问题。但如果你要处理几十份资料或者搭一个检索知识库切块策略就直接影响效果。我的经验是二级标题是最佳的切块边界。一份研究报告的大章节点往往是“行业概述”“市场规模”“竞争格局”每块内容完整、主题明确。以##为界切成小块每块单独交给模型处理既能避免输入长度超限又保留了该块完整的语义上下文。下面是一个简单的切块函数思路用 Python 表达def split_markdown_by_h2(md_text): lines md_text.splitlines() sections [] current_title current_lines [] for line in lines: if line.startswith(## ): if current_title: sections.append((current_title, \n.join(current_lines))) current_title line[3:].strip() current_lines [line] else: current_lines.append(line) if current_title: sections.append((current_title, \n.join(current_lines))) return sections这样切出来的每个块都是一个独立叙事单元。如果做向量检索块的标题可以作为 metadata 一并存储检索命中时直接带上“当前块属于哪一章”的信息模型回答时会更有依据。4.2 摘要先行精读随后这是我自己用大模型读长文档时最重要的方法论不要一上来就让 AI 通读全文。即使上下文窗口支持百万 token信息密度过低时模型依然容易“走神”——前文看了后文忘或者前后矛盾。我的固定流程是这样的第一步只把 Markdown 的大纲保留前三级标题发给模型请它生成一份两百字左右的摘要并列出最值得精读的五个章节。第二步根据摘要中模型判断的重点从原文里找到对应章节的 Markdown 文本单独发送并深入提问。这种方法在几十页甚至上百页的研究报告上效果特别明显。模型只读大纲时token 消耗极小精读时上下文窗口聚焦在一个高信息密度区域准确率显著提升。实测下来比让模型一口气读完整个文档的出错率低很多。4.3 图文混合方案专治复杂表格和图表有一类文档特别难处理大量图表、复杂表格、组织结构图混合在一起。这种情况下纯粹转成 Markdown 会丢失大量信息纯粹截图给模型又丢弃了文字脉络。推荐做法是“Markdown 为主干图片为补充”。在 Markdown 中保留叙事性文字遇到复杂的图表内容时把图片插入引用位置。如果你的模型支持多模态视觉理解它会自动读取图片内容来补充回答。为什么纯文本方案不行因为当表格跨行跨列、单元格合并严重时转 Markdown 之后的行列对应关系基本无法恢复。你做再多的人工修复都不如直接让模型看原图来得准确。使用图片时记得压缩。一份 300dpi 的截图可能几个 MB直接塞进提示词会拖慢响应。先缩放到宽度 1000 像素左右质量选中等视觉信息基本不损失传输和解析都更高效。4.4 给 Markdown 加一行元信息AI 理解力再上台阶很多 Markdown 转换之后直接就是正文文本没有说明文档背景。我建议在文件开头补一段元信息让 AI 快速建立上下文。推荐用 YAML front matter 格式--- 标题: 某行业年度发展报告 日期: 2025-01-15 来源: 某研究机构公开资料 说明: 本文档由 PDF 转换而来表格数据以原文为准 --- ## 1. 行业概述 ...这段信息看起来简短但对模型的理解很重要。它相当于告诉模型现在要读的是一份什么性质的文件、发布时间是什么、有哪些注意点。特别是在对比多份文档、判断信息时效性时日期元信息能避免模型把旧数据当成新结论。5. 常见问题与排查技巧实录5.1 表格转换后错列严重现象Markdown 表格的列数和原表对不上三维表格变成一维列表。原因源 PDF 中的表格跨行合并了单元格转换器处理不了这种结构或者表格内包含多行文本被粗暴拆成多列。对策先尝试转换工具的“表格增强”选项如果仍然错乱把这个表格截图放到 Markdown 的同级位置并在文字说明里写“详细数据见图片”。不要纠结于把每一个表格都修成规范 Markdown能读懂的表格才值得保留。5.2 代码块被拆得七零八落现象技术文档里的代码片段从保留缩进变成连续文本或者缩进被吞掉一半。原因源文档可能用制表符或全角空格做缩进转换器默认把它们折叠了。对策转换前先统一缩进——把制表符替换为四个空格转换后检查代码块是否被围栏包围。如果代码内容确实无法恢复可以考虑回到原始文档将代码部分直接复制为纯文本并手动包装进代码围栏准确率反而高。5.3 OCR 错字污染正文尤其是数字现象扫描件转换后出现明显的同音错别字比如“磋商”变成“搓商”“盈利”变成“营利”。原因OCR 引擎依赖字形匹配遇到低分辨率、艺术字体时会把相似字识别成替代字。对策建立高危词清单。凡是文档里出现统计数字、百分比、货币符号、公司专有名词在喂给 AI 之前回到原图核对。如果文档数量很大可以在提示词里加一条“以下文本由 OCR 生成遇到关键数据和专有名词时请标注置信度不要猜测。”至少能让模型给出不确定提示避免自信地输出错误结论。5.4 图表表现为“图片”而非文字提取失败现象PDF 里的柱状图、折线图、流程图在转换成 Markdown 后完全消失只留下一个空行。原因图表本身是矢量或位图对象没有文本内容可提取。对策转换时保留图片导出把图片文件保存在与 Markdown 同级的 images 目录中。需要 AI 分析图表时直接把图片视觉信息交给多模态模型处理。文字描述永远无法精确还原一张数据图的趋势关系。5.5 超长文档把上下文塞满现象一份三百页的合规文件转成 Markdown 后有几十 MB直接发送导致请求失败或响应极慢。原因模型上下文长度有限任何输入都要先经过 tokenizer 切分。对策先估算 token 量。一个简单公式中文字符数乘以 1.5 大概就是 token 数如果超过模型上下文能力的三分之一就别全文发送了。正确做法是使用上面的“摘要先行”流程让模型先建立全局图景再针对关键章节做精读分析。宁可多轮交互不要一次性超载。这里给一份速查表方便日常查阅症状根因首选处理方案PDF 文字乱序坐标文本流转换后重新核对段落顺序扫描件错字无文本层OCR关键数据回原图核对表格列错位合并单元格转为图片插入批注混入正文未清理 Word 修订先接受修订再转换网页正文混广告HTML 未清洗用阅读模式提取代码缩进丢失空格/制表符混用统一为空格再转换写在最后现在拿到一份新文档我的第一反应不再是“直接丢给 AI”而是问三个问题它有没有原生文本层标题层级是否完整里面有没有明显的噪声然后花几分钟转成 Markdown、清洗干净、按标题切好块再开始提问。这个习惯刚开始会觉得多了一步但用久了会发现它把“让 AI 猜我手里的文件到底是什么”变成了“让 AI 在我整理好的信息基础上工作”。前者是开盲盒后者是精确操作。对于每天要和大量文档打交道的人来说这是一笔投入产出比非常高的时间投资。希望这套流程也能帮你省下那些浪费在纠错上的时间。
