为 LLM 和 RAG 把 PDF 转成 Markdown

如果你正在给一堆 PDF 搭检索流程，提取这一步决定了后面所有环节的质量。喂进去的是扁平文本，你的分块器就只能猜一个话题在哪结束、下一个从哪开始。喂进去的是 Markdown，文档自己会告诉它。

纯文本提取会扔掉对分块最有用的那个信号：层级。一份 40 页的手册变成一堵没有区分的文字墙。你的切分器只能退回去数字符数，于是切出来的块经常从句子中间开始，横跨两个毫不相关的章节。检索时返回的块一半在讲账单一半在讲物流，模型还得自己判断哪一半回答了问题。

Markdown 保住了标题。这给切分器提供了真实的边界，也让你能把标题路径作为元数据附到每个块上。在一个块前面加上「退款政策 → 部分退款」，用极少的 token 换来了大量上下文。

PDF 不标记标题。文件里没有 h1，只有以不同字号绘制的文字。所以转换器改用测量的办法：收集每一页上所有的字号，找出出现最多的那个——那是正文——然后把明显大于正文的字号当作标题，排序后最大的成为 h1，次大的成为 h2。

这在排版一致的文档上效果很好，涵盖了大多数报告、论文、手册和书籍。在字号为了装饰而非结构而变化的营销材料上效果较差。结果里的元信息会告诉你识别出了几级标题，这是一个快速的合理性检查：一份 60 页的手册只报告出一级标题，说明结构没有还原出来，索引之前你应该先检查输出。

列表还是列表，这在问题答案本身就是一串步骤时很重要。可检测到的强调也会保留。而且因为 Markdown 是纯文本，跟 HTML 相比几乎不占 token——HTML 里每个标签都是在上下文窗口里要计费的开销。

最后这点值得说具体些。同一份文档，HTML 形式的 token 数可以显著高于 Markdown，而多出来的 token 没有一个携带模型需要的含义。当你要把检索到的上下文塞进有限的窗口时，这个差距是实实在在的。

人们想要检索的文档，往往正是不能随便上传的那些：内部政策、合同、客户档案、未发表的研究。大多数 PDF 转 Markdown 服务在服务端处理，也就是说把流程建立在它们之上，意味着每一份文档都要经过你无法掌控的基础设施。

这个转换器在浏览器里运行。开发阶段跑一批一次性的文件，这本身往往就够了。生产环境的入库你会需要一个服务端的等价实现，但逻辑是一样的：在本地解析，在本地索引。

在写任何入库代码之前，先转两三个有代表性的文件，把 Markdown 读一遍。检查标题层级是否对应真实结构只要一分钟，能省掉你排查一个「其实是提取问题的检索问题」。