PDF 转 Markdown 给大模型用：喂给 ChatGPT、Claude 和 RAG 前的准备
把 PDF 直接贴给对话模型通常“能用”，模型会回答。但在这层之下，PDF 的排版噪音——折行、每页重复的页眉页脚、阅读顺序问题——都变成了模型必须穿透的 token，然后才轮到正文。
先转成 Markdown 就在源头去掉了大部分噪音。这篇文章讲清楚 PDF 噪音从哪来、token 上代价多大、为什么单行段落对切块和 diff 如此重要，以及本站的 LLM 优化输出模式正是为这条工作流设计的。
大模型为什么消化不了原生 PDF
聊天工具接受 PDF 时，中间必须有个东西先把它变成文本，而那个东西通常是个大路货提取器。产出的文本保留着 PDF 的存储痕迹：句中折行、两端对齐留下的连字符、每页重复的页眉页脚、按存储顺序交错的双栏文本。
模型很擅长无视这些，所以直接上传看起来能用。但模型要花注意力去重组本可以完整送达的段落，长文档上这种浪费还会累积：光是重复四十次的页脚就是数千个纯重复 token。
结构化文本还有一个好处：锚定引用。当你让模型引用它作答依据的条款时，Markdown 转换带来的条款编号和标题层级给了它稳定的坐标；一大坨重排的 PDF 文本什么坐标都没有。
PDF 噪音的隐性 token 成本
分词器按文本片段计费，而 PDF 噪音全是片段。硬折行的段落字符数一样但换行符更多；一页重复四十次的页脚是每页一笔的固定开销，无论有没有用；像“conver- sion”这样被断字拆开的词，分出来的片段既不匹配原词也不携带语义。
浪费不只是量，还有位置。上下文窗口有限，噪音排在前面就把正文往截断点上推。干净 Markdown 下装得下的文档，换成原生 PDF 倾倒就会溢出，而且早在任何内容被切掉之前，回答质量就已经在劣化。
这些都不会体现在回答的语气里，所以一直没人注意。它体现在模型实际“读到”了多少文档，以及——如果你走 API 按 token 付费——账单上。
一段一行：为什么换行这件事重要
传统文本工具把输出硬折在 72 或 80 列，因为终端和打印纸就是这么工作的。但在一份最终要喂给模型的 Markdown 文件里，每一处折行都是检索管线按换行或段落长度切块时的潜在切点。
单行段落让切块变得轻而易举：段落就是行，切分器在空行处下刀，每块都是完整句子。硬折行的文本则要求管线先撤销折行，一旦没做，块就在句中断裂，检索质量以很难排查的方式下滑。
按行 diff 得到同样的好处。合同修订改了一处条款，单行段落的文件只显示一行变更；折行的文件会把整段重排，真正的变更被埋进十几个 diff 块里。
紧凑模式实际改变了什么
本站转换器有一个显式的 LLM 优化开关。开启后做两件事：PDF 引擎以紧凑提取 profile 运行，偏向精炼的纯文本而不是忠实排版的冗长输出；Markdown writer 关闭硬折行，让每个段落独占一行。
紧凑 profile 是一种取舍，不是全面更优。忠实排版模式保留更多页面视觉结构，那是给人看的、为编辑而转换的人想要的。紧凑模式把装饰剥掉只剩内容和结构，那是 token 流想要的。
这个开关只影响 Markdown 输出，这是刻意为之：HTML、RST、LaTeX 的消费者是渲染器，反正会重新折行。目的地是模型就保持 Markdown + 开关；是人就用默认值，可读性更好。
把 Markdown 接进 RAG 管线
检索增强生成的成败系于切块质量。Markdown 给了管线 PDF 永远给不了的东西：结构边界同时是语义边界。标题标记主题，切分器可以按节切块并把标题路径挂成元数据；表格以完整的管道表块到达，作为整体被嵌入。
实用配方刻意无聊：每份 PDF 转成单行段落的 Markdown，按标题切块并设大小上限，每块保留标题路径，然后嵌入。对格式良好的 Markdown 文件，每一步都是一行代码；对原生 PDF，每一步都是脆弱的启发式。
批量转换在这里比交互式使用更重要。知识库是几十上百份文档，本工具在浏览器里串行转换并打包下载，中间没有上传步骤——当文档是你不能上传的那类时，这一点分量更重。
为什么转换必须发生在你自己的机器上
人们喂给 LLM 的文档格外敏感：合同、董事会纪要、未发表的研究、客户文件。把这些交给云转换器，等于在数据流里增加了一个保留策略不由你写的第三方，而拖拽的便利恰恰掩盖了这就是一次上传。
本转换器的 PDF 解析引擎以 WebAssembly 形式跑在浏览器标签页里。文件用浏览器文件 API 读入、在内存里处理、在本地写回，转换路径上根本没有服务器组件。你可以打开页面后断网，转换照常工作。
这个设计选择正是它适合 LLM 工作流的原因：为模型准备文档的初衷往往就是控制谁能看到它。一个会上传的转换器在第一步就背叛了这个目标。
要记住的边界
扫描版 PDF 没有文本层，任何转换 profile 都改变不了这一点。源文件是扫描件就先用 OCR 软件处理，再转换 OCR 的输出；转换器会标记没有文本层的页面，而不是悄悄返回一个空壳。
复杂表格会被简化。GFM 管道表格表达不了合并单元格和多级表头，模型看到的是拍平的版本。表格就是重点的表格型源文件，先抽查几行再信任下游回答。
还有，开关不是提取质量的旋钮：紧凑模式改变的是排版还原度，不是文字识别正确率。如果转换出现乱码，问题在源文件编码，不在 profile。