最近在做一个知识库类项目时发现一个特别有意思的现象同样的 PDF 喂给大模型直接拖文件进去的效果和先转成 Markdown 再投喂的效果差距不是一点半点。前者经常出现答非所问、抓不住重点的情况后者则能稳定给出结构清晰、定位准确的回答。后来我认真复盘了一下问题根源不在模型本身而在输入数据的形态。这也是我写这篇博文的动机如果你是经常跟大模型打交道的人或者正在搭 RAG 知识库、做文档自动化处理的建议你认真看完——把文件转成 Markdown 再交给 AI这个习惯一旦养成你会发现模型的输出质量能稳定提升一个档次而且 token 消耗还能降下来。1. 为什么把文件直接丢给 AI 是个坏习惯很多人的使用习惯是拿到一个 PDF 或者 Word直接拖到大模型对话框里然后开始提问。表面上模型好像“读”懂了实际上它是在用极其低效的方式在处理你的文档。这背后有三个核心问题。1.1 token 浪费比你想的严重先算一笔账。一个 20 页的 PDF假设每页 500 字全文大约 1 万汉字。直接投喂 PDF 时模型不仅要处理文字本身还要解析 PDF 内部复杂的编码结构、字体信息、排版指令这些字节都会占用上下文窗口。你感觉只是丢了一个文件进去实际上塞进去的信息里掺了大量“杂质”。这里有个粗略估算公式1 个汉字大约等于 1~2 个 token一篇 1 万字的文档至少要吃 1.5 万到 2 万 token。如果你用的是上下文窗口较小的模型这部分开销直接挤压了有效问答空间。更麻烦的是图片型 PDF——扫描件或者带大量截图的文档每张图片进入模型都要按视觉 token 计费一张高清图可能相当于几百甚至上千个文本 token。有些人在不知情的情况下把整本扫描书喂给模型一次对话烧掉几十万 token结果答案质量还很差。转成 Markdown 之后纯文本内容以最精简的形态呈现token 消耗能压缩相当可观的比例。同一个 PDF转出来后如果是 1.2 万字符那么 token 数大概在 6k~9k 之间比直接投喂省了至少三分之一。1.2 排版信息在流转中全丢了PDF 格式有一个根本性问题它本质上是一份“打印描述”描述的是字符出现在页面哪个位置而不是文档的结构。同样一段文字PDF 里记录的可能是几十个绘制指令而不是一个完整的段落元素。Word 的 docx 结构上其实比 PDF 好它内部是 XML 语法树标题、段落、表格都有明确标签。但问题在于当你把 docx 直接拖给模型时很多模型对二进制格式的解析能力并不稳定。实测下来同一个 docx 文件在不同模型手里的解析结果差异很大有的能识别标题层级有的干脆把整份文档当成一大坨连续文本处理。HTML 网页的问题更明显——页面上有导航栏、侧边栏、广告位、页脚信息这些噪声和正文混在一起。模型面对这种输入时经常被无关信息干扰提取出来的答案也容易跑偏。Markdown 是结构最干净的中间格式之一。标题就是#、##、###列表就是-或者1.表格就是管道符和短横线。这些标记符把文档的逻辑结构直接展示给模型相当于你提前帮模型做了一遍“阅读理解”它不需要再从混乱的排版中自己摸索结构。1.3 看不见的上下文污染最要命我在实际项目中踩过一个大坑把一篇双栏排版的学术 PDF 直接丢给模型让它提取核心结论。结果模型输出的内容里出现了大量莫名其妙的“文本串行”——两个栏目的文字被横向拼在了一起一句话读到一半突然跳到了另一栏的句子。这就是 PDF 解析过程中的“文本流乱序”问题。PDF 里文字的物理位置和逻辑阅读顺序并不总是一致双栏页面的阅读顺序是从左栏顶部到底部、再从右栏顶部到底部但底层字符流往往是按某种内部顺序排列的模型在读这个流的时候根本分不清该按什么顺序重组。更隐蔽的污染源还有页眉页脚。很多 PDF 每一页顶部都有重复出现的标题或者章节名这些内容在解析时会被当成正文的一部分反复出现。模型看到“某某系统使用手册”在上下文里出现二十多次有可能会误判这是重点信息然后围绕它做文章完全偏离你的真实问题。转成 Markdown 的过程其实就是一次人工介入的文档净化。你可以顺手把页眉页脚删掉把双栏结构修正为线性阅读顺序把多余的重复信息清干净。这一步做得好不好直接决定后面模型输出的准确率上限。2. Markdown 到底好在哪讲完了直接投喂的坏处再来正面拆解为什么 Markdown 是当前最适合喂给大模型的文本格式。这不是偶然而是由它的三个底层特性决定的。2.1 一个文档只用几种符号Markdown 的语法集小到可以用一页纸讲完井号代表标题层级短横线代表列表管道符代表表格反引号代表代码。这恰恰是它最大的优势——信息密度极高每一字节都在表达语义。对比一下 HTML表达一个二级标题需要h2标题内容/h2算上标签符号一共 20 多个字符而 Markdown 只需要## 标题内容6 个字符就够了。三倍以上的压缩率。在 LLM 的上下文窗口里字符越少意味着有效信息的占比越高模型在推理时受到的干扰也越少。而且这些符号的含义是跨平台一致的。##在任何解析器里都代表二级标题不会出现像 PDF 那样“同一个文档在不同解析器里层层拆解结果不一样”的情况。你在某款工具里写的 Markdown换一个工具读语义完全不会丢。2.2 给 AI 的“电梯简报”想象一下你要在电梯里用 30 秒向老板汇报项目的核心内容你会怎么讲你肯定会先说结论再讲依据然后列关键数据。Markdown 本质上就是这个逻辑——它的标题层级天然构造了“结论先行”的信息结构#是最高层级的论点##是分论点###是支撑论据列表是细节。这种结构与 LLM 的注意力机制高度契合。模型在预测下一个 token 时会不断参考上下文里的关键位置信息。标题行因为以#开局形态上非常显眼模型能快速定位到你问题的相关内容区域。我在测试中发现把一份调研报告的 Markdown 版喂给模型它定位到对应章节并组织答案的准确率明显高于投喂纯文本版——因为纯文本里章节标题和正文之间没有任何区分度。表格在 Markdown 里也有天然优势。| 项目 | 数值 |这种固定格式模型很容易识别出每行是一条记录、每列是一个字段。很多模型对 Markdown 表格的理解能力强到可以直接做聚合计算比如我让它从一张 50 行的 Markdown 表格里统计某个分类的总和它给出的结果基本零误差。2.3 能直接进知识库的格式现在做 RAG检索增强生成架构的人越来越多知识库里存的文档切片质量直接决定检索效果。Markdown 在这个环节的优势更加明显。向量化嵌入时Markdown 文本切出的 chunk 天然带结构边界。你可以按##标题切块每个 chunk 就是一个逻辑完整的章节而不是像纯文本那样硬按字符长度切切出来的内容支离破碎检索时还经常匹配到驴唇不对马嘴的片段。很多向量数据库和知识库工具已经原生支持 Markdown 解析切片时能自动保留标题层级作为 chunk 的元数据。这意味着你后面做召回时可以借助标题层级做更精准的过滤。比如用户问题涉及“部署环境配置”你可以直接把## 环境配置这个标题下的内容作为高优先级检索范围而不是在全库范围内做模糊匹配。这种结构化检索的精准度是纯文本方案很难达到的。3. 常见文件格式怎么转成 Markdown明确了目标接下来是实操环节。不同来源的文件有不同的转换路径选对工具能少踩很多坑。我按 PDF、Word、网页和其他特殊场景分别展开每一步都是实测验证过的你可以直接照着做。3.1 PDF先分清电子版还是扫描版PDF 分两大类处理方式完全不同。第一类是电子版 PDF也就是通过 Word、LaTeX、排版软件直接导出的文件里面的文字是真实存在的文本层可以直接提取。第二类是扫描版 PDF本质上是图片集合每页是一张照片或者扫描图需要 OCR 识别才能出文字。如何快速判断用鼠标在 PDF 里拖选一段文字能选中的就是电子版选不动的就是扫描版。这一步很基础但是关键因为很多人拿扫描件直接去跑文本提取工具折腾半天出来的全是乱码。对于电子版 PDF我目前的推荐方案是分场景选择工具简单场景纯文字排版、无复杂表格、单栏结构直接用pdftotext或者pymupdf速度快输出干净。这类文本本身结构就相对线性转换后基本就是标准 Markdown 雏形稍微补一下标题符号就能直接用。复杂场景多栏排版、含表格、含公式、有页眉页脚推荐用基于端到端深度学习模型的转换工具比如marker或者minerU。这类工具有版面分析能力能自动识别标题区域、表格区域、正文区域并按阅读顺序重组内容输出质量远超传统 PDF 解析库。我用一个实际测试来说明差距一份双栏排版的技术白皮书直接pdftotext提取出来的文本是两栏内容交错的状态完全没法读用minerU转出来之后标题层级清晰、正文顺序正确、表格也还原成了 Markdown 表格基本等于人工整理过的效果。扫描版 PDF 的路径是 OCR。小规模场景用tesseract就够中文识别精度尚可如果文档量大、精度要求高建议用PaddleOCR对中英文混排、表格结构的还原能力都更强。OCR 出的结果一般是自身带空格的纯文本需要再手动补标题层级符号——这一步没有全自动的完美方案因为扫描件的标题和正文排版千差万别机器确实没法判断哪个是标题哪个是正文。3.2 Word 和网页转换工具对比Word 文档转 Markdown 最简单pandoc一行命令搞定前提是你的 Word 文档用了规范的内置标题样式。如果你的文档是拿不同字号手动调的“伪标题”pandoc 无法识别成标题输出就全是平铺的段落文本。这种情况下我建议先把文档里的标题统一改成 Word 内置的“标题 1”“标题 2”样式再跑转换一级标题对应#二级对应##层层对应很清晰。如果你不想动原文档也可以用python-docx写个几十行的小脚本遍历文档的段落样式来做针对性提取。这种方式的优点是可以自由控制输出——比如只提取正文、删除文本框、把特定的列表转成 Markdown 列表。缺点是脚本得维护通用性不如 pandoc。网页转 Markdown核心目标是去噪。一个新闻页面里真正有价值的正文可能只占全部 HTML 内容的 30%其余都是导航、侧栏、推荐位、页脚。我用过比较顺手的是trafilatura它能自动识别页面的正文区域把标题、段落、列表抽取出来输出基本是干净的 Markdown 结构。简单场景用readability-lxml配合html2text也可以前一个负责提取正文主区域后一个负责把 HTML 转成 Markdown。这里分享一个个人偏好抽取网页正文时我一般会保留原文链接。因为 AI 在回答引用类问题时如果能看到来源 URL可以显著降低编造风险。你在转换脚本里顺手把 URL 拼到标题后面成本几乎为零收益却很实在。3.3 表格、公式和图片的兜底方案表格是文件转 Markdown 的重灾区。很多 PDF 里所谓的表格实际上是各种文本框拼出来的视觉效果没有真正的表格结构。转换后经常出现列错位、合并单元格丢失、表头行消失。应对策略是分级处理如果表格结构简单、行列规整常规转换工具一般能还原成标准 Markdown 表格如果表格有合并单元格、跨行列结构、嵌套内容我建议放弃自动转换直接把表格截图剪下来单独喂给多模态模型识别让模型按 Markdown 表格格式回归文本结构然后再人工校一遍。这个方案在处理复杂表格时效率反而比全自动转换高。公式的处理也有讲究。Markdown 本身不直接支持公式约定俗成的做法是转成 LaTeX 语法用$包裹行内公式、$$包裹独立公式。大模型对这种格式的理解力普遍不错转换工具minerU对公式的支持尤其好能识别常见数学符号并输出 LaTeX 表达。如果目标文档是理工科教材或论文建议选带公式识别能力的转换工具避免公式变成乱字符流。图片类内容走另一条路不追求转成文字保留图片并在 Markdown 里用相对路径引用。RAG 系统在检索到该 chunk 时可以把图片路径作为附加信息一并返回让大模型结合图片内容回答。这种方式在图文混排文档里很实用既避免了 OCR 识别的信息损耗又保留了视觉信息。4. 实操流程一次完整的转换投喂前面讲了不少原理和工具现在用一个完整的实操案例把这些串起来。假设手头有一份 40 页的产品技术文档 PDF目标是让 AI 回答“部署配置有哪些步骤、依赖哪些环境变量”。下面是我实际跑过的工作流。4.1 先说清需求再做转换很多人拿到文档就会直接开始转但我想强调转换之前的“需求拆解”这一步影响极大。你问的问题类型不同转换策略也不同。如果目标是摘要归纳只需要提取全文标题和正文不重要的图片可以丢弃如果目标是精确问答比如某个参数的值必须保证表格内容完整无损如果目标是做知识库长期存储还要额外考虑分词、切块策略以及是否保留原文件的页码映射。需求决定转换的精细度先想清楚 AI 要帮你做什么再决定文档怎么处理这个顺序别搞反了。在示例场景里核心诉求是提取部署配置和步骤那么转换时关注点就是章节标题层级要准、列表步骤不能乱、参数表格必须完整。4.2 分步操作实录第一步判断 PDF 类型。用鼠标拖选几处文字能选中确认是电子版 PDF走文本提取路线。第二步跑版面分析工具。我用的是minerU的命令行模式指定输入输出路径它自动完成页面解析、结构识别、表格还原和公式转换。整个过程在本地 CPU 上耗时约 5 分钟GPU 机器上大概 1 分钟不到。mineru-cli -p input.pdf -o output_dir第三步检查输出文件。打开生成的 Markdown重点检查三处标题层级是否准确对应原文结构表格每行列数是否一致步骤类列表是否保持了正确的先后顺序。实测中我发现一个常见问题原文的标题是用图片形式嵌入的工具会把图片识别成普通图片而不是标题导致这一章的标题层级丢失。遇到这种情况直接手动在对应位置补一个##符号就行。第四步轻量清洗。这一步是很多人容易忽略的。我写了一个脚本把页眉页脚文字、重复出现的公司名、连续空行统一清理掉。不要小看这一步页眉页脚在整篇文档里可能出现几十次不清洗干净模型就会被这些高频重复信息带偏。清理效果对比很直观清洗前模型生成的摘要里频繁出现文档版权信息清洗后摘要焦点全部落在技术内容上。4.3 投喂方式与上下文管理文档转好了接下来的投喂方式同样有讲究。我见过不少人把 40 页转换后的 Markdown 一次性全部塞进上下文然后问部署步骤——结果模型被过长的上下文拖累速度变慢不说答案还经常引入后面的内容造成混淆。更合理的做法是分块投喂按二级标题切块每次只喂相关章节。比如要问部署配置先通过检索或者人工定位找到“部署配置”相关章节只把这一段 Markdown 放入上下文模型专注度会高很多回答也更精准。切块时我习惯用##作为分界符因为二级标题一般对应完整的主题单元切出来的 chunk 自带标题语义。chunk 之间不要重叠太多控制在 200~500 行左右比较合适既能保证信息完整又不会超出模型的处理窗口。还有一个技巧值得分享在投喂时用一句话给模型“框定角色”——在 Markdown 内容前加一句“以下是产品文档的部署章节请基于内容回答问题”。别小看这种定位语实测下来有这层定位和没有模型回答的规范程度是有差别的。5. 常见问题与排查笔记这套工作流跑多了以后我把高频问题整理成了一份排查表。你遇到类似情况时可以按表里列的思路快速定位省掉不少试错时间。问题原因处理方案转换后中文变乱码PDF 字体编码不规范提取库映射失败换minerU或pymupdf重试确认 PDF 是电子版而非扫描版双栏 PDF 文字交错工具未做版面分析文本按内部顺序提取换带版面分析的转换工具手动确认阅读顺序后再投喂表格列错位原表格是文本框拼出来的非真实表格结构截图交给多模态模型识别手动修正成 Markdown 表格扫描件 OCR 效果差图片分辨率低或倾斜先做图像预处理提高 DPI 到 300 以上再进行 OCR文档太长超出上下文一次性投喂全文档按##标题切块按需检索定位后分块投喂答案被页眉页脚干扰提取时未清理重复页眉转换后做清洗删除高频重复的非正文文本块5.1 几条绕不开的经验有几个问题不怎么起眼但踩过坑之后影响很大单独拿出来强调一下。第一工具的“版面分析”能力和“文本提取”能力要分开看。有些库文本提取很快但版面分析能力很弱有些工具版面识别很准但提取速度偏慢。没有全能的工具实际工作中我的做法是速度快、结构简单的文档用轻量方案结构复杂、对准确率要求高的文档用重方案哪怕多花几分钟转换也是值得的。第二清洗这一步永远不要省。很多人在转换后就直接投喂觉得“转换过了就干净了”。实际上转换只是把格式从二进制变成了文本并不等于内容变干净。页眉、页脚、水印、重复出现的公司版权信息、脚注编号这些噪声仍然存在。我在长期实践中养成了固定习惯每份文档转换后至少跑一遍轻量清洗脚本删除重复的和无关的高频文本块这个动作大概花十几秒但换来的是模型回答质量的明显提升。第三不要对 OCR 的能力产生不切实际的期望。扫描件的识别结果在手写体、艺术字体、复杂排版面前依然不可靠。如果你想长期做文档投喂但手头有大量扫描件我的建议是优先考虑找到原始电子文件或者人工录入关键信息而不是指望 OCR 完全替代人工。6. 我的投喂习惯沉淀现在我的工作流已经固定下来了凡是需要进入大模型处理流程的文档九成以上会先过一遍 Markdown 转换和清洗。这套流程不仅帮我稳定了模型输出的质量还让 token 开销更可控知识库检索更精准。最后再分享一个实用的小技巧把转换和清洗流程做成一个固定脚本放在本地遇到新文档就跑一遍输出一个干净的 Markdown 文件。文件命名建议保留原文名称和版本号方便后续追溯。存储时我会按“原始文件/转换后文件/清洗后文件”三类分开管理这样即使后续发现转换有问题也能回溯到上一步不需要重新跑整套流程。如果你还在用“直接拖文件进对话框”的老办法建议你下一份文档就试试先转成 Markdown 再投喂。这个动作不会花你超过五分钟但对后续问答质量的提升是立竿见影的。