做知识库项目和 RAG 应用落地这半年我经手处理过的 PDF 没有一千也有八百份。之前一直有个体会没来得及展开说PDF 转 Markdown 这个环节直接决定你 RAG 系统是“能用”还是“好用”。很多人把精力全花在调 embedding、调 rerank、写 prompt 上结果召回效果一塌糊涂回头查才发现源头就烂了——PDF 转出来的文本是乱的表格是碎的代码是歪的那后面所有环节都是屎上雕花。这篇文章就把我实际选型、测试、跑通的经验整理一遍重点聊清楚两件事PDF 转 Markdown 的工具到底怎么挑在 AI 知识库和 RAG 场景下转换这一步有哪些别人不强调但你迟早会踩的坑。1. 为什么 RAG 场景对“PDF 转 Markdown”特别挑剔1.1 先搞清楚RAG 需要的不是“能读的文本”而是“适合切分的语义块”很多朋友一开始用的是最简单的 PDF 文本提取比如 PyPDF2、pdfplumber、pdfminer 那一类提取出来一段纯文本看着内容完整丢进向量库效果却奇差。原因在于RAG 的核心链路是“切分 → 向量化 → 召回”而切分器是拿字符串做规则的。纯文本提取出来的 PDF会丢失大量结构信息标题层级没了、表格的行列关系糊了、代码块和正文混在一起、公式变成了一堆乱码符号。这时候切分器只能靠字数硬切经常把一个表格从中间劈开或者把代码块和正文切到同一个 chunk 里。embedding 模型再强面对这种来源就残缺的 chunk召回质量也上不去。Markdown 恰好能保留“标题层级、表格结构、代码块、强调、列表”这些语义信息。切分器拿到 Markdown 以后可以按标题层级切分可以识别表格区域并单独处理代码块也能当成独立单元。这本质上是把“文本提取”升级成了“版面结构识别与语义还原”RAG 的性能上限从这时候就定下了。1.2 版面噪声不清理干净的代价非常大PDF 转换的另一个大坑是噪声。页眉页脚、页码、目录、版权页、参考文献、页边注、水印这些在视觉阅读时不影响人但在 RAG 里全是干扰。它们被切进去以后会产生大量无意义的向量。举例一份 60 页的技术文档每页都带页码和公司名六七十页转出来就有六七十段“1 / 2 / 3 / 4...”和重复的公司名。检索阶段用户如果搜一个数字或者搜公司名相关的问题这些噪声 chunk 就会高亮返回把真正有用的内容挤下去。RAG 项目的召回效果如果一直上不去第一步就该回头查转换后的 Markdown 里噪声占比是多少。1.3 “能看”和“能检索”是两套标准我自己有个习惯把 PDF 转成 Markdown 以后先肉眼扫一遍排版再丢一小段进向量库里跑测试。肉眼看着很舒服的转换结果检索效果可能依然很差。原因在于人对版面的理解是全局的机器对语义的理解是局部的。表格里的一列数据人眼扫过去会自动对应表头纯文本切碎以后表头和数据列的连接关系就丢了。所以 RAG 场景对 PDF 转换的要求本质上是“让机器的局部理解尽量接近人的全局理解”。能做到这一点的工具必须完成版面分析、阅读顺序还原、表格结构重建、公式语义化这几层工作。这就是为什么我在这篇文章里反复强调别只看它能不能提取出文字要看它提取出的文字里结构还剩多少。2. 工具怎么选我从项目实战里拉出的对比清单2.1 先做个用途分类不是所有 PDF 都该用重武器聊工具之前先建立认知PDF 转换工具没有绝对的“最强”只有“最适合当前场景”。我把碰到过的 PDF 分成几类扫描件 / 图片型 PDF本质是图片必须用 OCR没有 OCR 能力的工具直接排除。数字原生的文字版 PDF有文本层但要小心文本顺序错乱、字体编码诡异的情况。复杂版面 PDF双栏、三栏、图文混排、多级标题、脚注密集考验版面分析能力。强结构化 PDF含大量表格、公式、代码块比如论文、技术手册、财报考验专项识别能力。多页且成批量的 PDF考验稳定性、批处理速度和并发能力。不同的用途该用的工具完全不一样。下面这段我就把这些工具按“场景”而非“品牌”来拆顺便把我实测的参数、优劣势和适用边界都标清楚。2.2 工具横向对比Marker、MinerU、Mathpix、Docling、Pandoc 全家桶为了直观我先把对比表放出来后面逐个细说工具适用场景版面还原表格支持公式支持OCR速度部署成本MinerU论文/技术文档/扫描件兼顾准确率与速度强强强支持 LaTeX内置快GPU中Marker通用文档追求高还原度很强中上中可转 LaTeX内置中GPU中Mathpix论文/数学文档公式识别天花板中强极强云端中按量付费Docling企业文档/表格密集文档强很强中可选集成中中低Pandoc已具备文本层的 PDF/多格式互转弱仅文本流一般弱无快低PyMuPDF文本层 PDF 快速抽取弱一般无无极快低这里先讲 MinerU。这是我目前在 RAG 项目里主力使用的工具。它本底是开源项目专门面向文档解析最吸引我的点在于它将“版面分析、文字识别、表格识别、公式识别、阅读顺序还原”全部内置了尤其针对 PDF 里的双栏、三栏排版还原做得非常准确。实测下来一份 8 页的双栏论文 PDF转成 Markdown 之后左栏右栏的阅读顺序是连贯的不像部分工具会把两栏内容穿插成一团。公式部分支持转换成 LaTeX 格式这是后续做数学类知识库的刚需。它自带 OCR 能力扫描件可以直接喂进去不需要先额外跑一遍 OCR 软件。缺点就是如果想要 GPU 加速部署成本略高纯 CPU 跑大批量会比较慢。Marker 是另一个我非常欣赏的开源项目。它对版面的整体还原度更突出尤其是图表标题、段落间距、列表缩进这些小细节生成的 Markdown 排版肉眼看起来最接近原始文档。如果你的文档里包含了大量“图文穿插”的复杂设计稿Marker 的视觉还原能力会比 MinerU 更稳。但它的表格识别相对中规中矩遇到行列合并很复杂的表格偶尔会丢失结构。Marker 支持 OCR同样适合扫描件。不过必须说清楚Marker 的 Python 依赖比较多部署过程中踩过一些坑后面在问题排查章节单独讲。Mathpix 是公式识别领域的老牌选手。它的 API 识别精度极高尤其适合数学论文、物理讲义、理工科教材这类“公式密度大”的文档。我做过一个测试把一本 300 页的高数教材丢给 Mathpix输出的 LaTeX 公式几乎不用二次修改这在其他工具里很难做到。但它是一个云端付费服务按页计费大批量转换成本不低。在意成本或者有数据合规要求的项目要慎重。Docling 是 IBM 开源的一个文档转换工具。它的亮点在于企业文档解析对表格的支持特别扎实能把复杂的嵌套表格还原成结构良好的 HTML/Markdown 表格。如果你的知识库里有大量财报、审计报告、供应链表单这类表格密集的文档Docling 值得优先试。它对中文的支持也还行但对强公式场景支持不如前两个。Pandoc 是一个“文本层转换器”。它最大的价值在于可以把已经具备文本层的 PDF 转成 Markdown但它不会做版面分析也不会识别表格结构更不会识别扫描件。它会把 PDF 当成一个连续的文本流标题层级靠缩进和文本模式猜测效果远不如前面几种。但它几乎是零成本、零依赖CPU 跑得非常快适合处理“文本简单、没有复杂结构”的那种原生 PDF比如一些纯文本合同、纯文字的邮件归档。PyMuPDFfitz则是“高效提取工具”的代名词。它的优势就是快几百页的 PDF 几秒钟就能抽完文本。但它的输出基本是丢结构的纯文本块表格和公式就更不用想了。我一般把它用在“批量预检”阶段先快速抽文本判断一份 PDF 值不值得上重工具还是直接用轻量工具处理就够了。这一步能省下大量 GPU 时间。2.3 选型决策我建议你这样排查自己的需求工具对比得再细最后还是要落到场景。我总结出一套选型思考路径你可以直接拿来用先问自己三个问题。第一你的 PDF 是扫描件还是文本件文本件可以跳过 OCR 需求选择范围大幅扩大扫描件则必须选带 OCR 的工具。第二你的文档里“结构密度”高不高如果里面大量是表格、公式、代码、多栏排版就必须选版面分析和表格识别能力强的如果只是政策文件、制度文本这类纯段落文档用轻量工具就够了。第三你的转换量级是多大是几十份、几百份还是几万份批量场景还要考虑自动化调度和中间失败重试。这些想清楚之后再回头看对比表就清晰了扫描件选 MinerU/Marker公式密度高选 Mathpix表格密集选 Docling纯文本直接 Pandoc/PyMuPDF。最忌讳的就是拿一把锤子把所有 PDF 都当钉子敲。3. RAG 场景下的实操要点从 PDF 到高质量知识库的全流程3.1 转换前的准备先做 PDF 体检再决定转哪套我强烈建议在批量转换之前先花半小时做“PDF 体检”。这一步能避免你拿重工具跑了一整夜第二天发现方向错了。体检办法很简单用 PyMuPDF 快速抽取前 5 页文本肉眼判断这份文件是文字版还是扫描版、有没有文字层、表格多不多、有没有嵌入了奇怪字体。再用 pdfplumber 或 pdfminer 查看一下文本提取顺序是否正常。如果提取出来的文本顺序是乱的说明这份 PDF 的文本流本身就存在问题后续不管用多贵的工具都要格外小心。体检还有一个作用判断文件是否“加密”或“缺少字体”。加密 PDF 会导致很多工具直接报错需要在预处理阶段用工具解除限制缺字体的 PDF 在文字版转换时容易产生乱码此时更要倾向于走 OCR 路线。3.2 核心转换流程一种可复制的“三步走”方案我自己跑通的一套流程适合大多数 RAG 知识库项目分享出来给你参考第一步预处理与格式分流扫描件/图片型 PDF直接进入 MinerU/Marker 的 OCR 转换流程。文本型 PDF简单文档用 Pandoc/PyMuPDF 快速转换复杂文档送 MinerU/Marker。将文件统一命名按编号管理方便后续排查。第二步批量转换与中间产物保存使用 MinerU 或 Marker 的 Python API 写一个小型批处理脚本逐文件解析输出 Markdown 文件和元数据 JSON。特别注意中间产物如版面分析结果、OCR 原始输出、识别的阅读顺序一定要保存下来。后续如果发现某个文件转得不对可以直接查看中间产物定位问题出在哪个环节不用重新跑一遍全部流程。第三步后处理与质量校验批量转换完成后绝不能直接进向量库。先做一个自动化清洗去除页眉页脚、页码、目录页冗余修正 OCR 常见误识别如把“0”识别成“O”、把“l”识别成“1”检查 Markdown 表格是否完整闭合竖线、表头分隔行检查 LaTeX 公式是否能正常渲染符号是否被截断再做一个抽检流程随机抽 10% 的文件人工查看转换质量重点看标题层级是否保留、表格是否错位、代码块是否独立。3.3 切分策略与元数据保留这是 RAG 效果的分水岭文件转成 Markdown 之后下一步就是切分。这一步如果你还是用“固定长度 重叠”这种粗暴方式前面转换的努力就白费了一半。我推荐的方式是**“按结构切分 局部长度自适应”**先利用 Markdown 的标题层级作为切分边界把文档切成“章节块”如果某个章节块过长再在段落或列表边界进行二次切分如果某个章节块很短就与其相邻章节合并避免产生过小、无语义价值的孤块。同时一定要保留元数据。在切分后的每个 chunk 里把文件名、章节路径、页码、表格/代码块标记一起写入 metadata。这些信息在召回阶段有两个大作用一是方便溯源你知道这个答案是从哪份文档的第几页来的二是方便过滤比如用户只问“2023 年的营收数据”你可以在召回前直接按元数据里的年度字段过滤一遍候选文档。这个用法效率提升非常明显。3.4 向量化之前的最后一道防线统一校验的检查清单切分完成不代表就可以向量化了。我给自己定了一个“进库前检查清单”每批数据都要过一遍Markdown 语法是否完整标题的井号是否保留表格分隔行是否还在代码块的反引号是否成对。是否残留“文本噪声”页眉页脚、页码、版权行、水印、目录跳转页码。是否有乱码中文乱码、英文 ASCII 错位、日文假名丢失。表格是否结构完整表头和数据行是否对应列数是否一致。公式是否可渲染LaTeX 公式有没有被拆成普通文本未闭合的美元符号。代码块是否独立代码是否被误切到正文段落里。元数据是否齐全文件名、页码、章节路径、日期。这个清单我每次批量导入前都会跑一遍脚本检查。脚本本身不复杂但能拦住 90% 的低级问题省下大量后续排查时间。4. 常见问题与排查技巧实录4.1 为什么转出来的表格全乱了这个是我被问得最多的问题。表格错乱的根源通常是原 PDF 的表格不是真正“规则表格”而是用文本框拼出来的视觉表格。PDF 本身里面可能根本没有表格结构只是用线条和文本框绘制了一个看起来像表格的东西任何工具都很难直接从中还原出 Markdown 表格。应对办法有两个一是优先选择表格识别能力强的工具比如 Docling 或 MinerU二是对重要表格可以走“表格截图 OCR 结构化”的补偿流程把表格区域单独截出来用专门的结构化 OCR 工具识别成 JSON再组装回 Markdown。这个方法上线快、效果可控适合表格占比不高的场景。还有一个埋得很深的坑表格跨页。很多长表格被 PDF 分页切成了两半每页都有各自的表头。转换工具可能在中间插入一个页面分隔符导致最后生成两个独立的表格。处理方式是在后处理脚本里检测连续表格的重复表头并做合并。4.2 扫描件 OCR 结果乱码、错字多怎么办扫描件是 RAG 项目里最大的痛没有之一。解决乱码问题的第一步是提高输入图像质量扫描件如果是低分辨率150 DPI 以下OCR 识别率会大幅下降。建议在转换前先用图像处理工具做一下去噪、旋转校正、对比度增强。300 DPI 是一个比较靠谱的扫描精度。第二步是选择带自研 OCR 模型或可接入更优 OCR 服务的工具。MinerU 和 Marker 虽然自带 OCR但默认模型对特定字体、公式的能力有限。如果你要处理大批量扫描件且对精度要求极高试试先跑一遍 PaddleOCR 或 Tesseract拿到文本和坐标框再结合版面分析还原结构。不要迷信“一个工具干到底”多工具协同的效果往往比单一工具硬扛更稳。第三步是建立领域词替换表。OCR 错字往往有规律比如“肺”识别成“月市”、“像”识别成“象”。针对你的文档领域做一个高频错字映射表后处理阶段自动替换可以显著提高文本质量。这个办法对中文场景尤其有效。4.3 双栏 PDF 转换后阅读顺序错乱双栏 PDF 是所有版面分析工具的噩梦。早期用 Pandoc 转双栏论文左右两栏内容是穿插着输出的先读左栏的前几行跳右栏的前几行再跳回左栏下一段。这种顺序错乱对 RAG 来说是致命的因为切分后的 chunk 语义完全是乱的。现在主力工具MinerU、Marker在这方面已经做得不错了但偶尔还会出错。排查方法很简单转换完成后随机抽几份双栏文档看 Markdown 输出里段落 1 和段落 2 是否在语义上连续。如果发现错乱优先检查是不是工具识别成了单栏模式通常可以通过调整版面分析参数解决如果还不稳定就只能在后处理里根据版式坐标手动调整阅读顺序或者干脆将左栏和右栏拆成两个独立模块分别处理。4.4 公式变乱码数学类知识库的专属噩梦公式场景和普通文本完全不一样。普通文本工具转公式最大的问题是把数学符号当成普通字符导致“分数”变成“1/2”、“根号”变成“√”甚至希腊字母直接变乱码。我的建议如果公式密度很高不要挣扎直接用 Mathpix。它的公式识别精度是断档式的领先。如果你用的是 MinerU 或 Marker在转换后一定要抽查公式的 LaTeX 结果尤其注意有没有未闭合的\begin{equation}有没有多余的$符号。公式排版出问题比乱码还隐蔽因为它看起来还是文字只是语义完全变了。4.5 批处理中途崩溃文件级隔离与断点续跑批量转换几百份 PDF 时偶尔会遇到某一份文件导致进程崩溃——可能是文件本身损坏可能是一个嵌套极深的表格让解析器内存溢出。一次性全部重跑非常浪费时间。我的经验是将每个文件的转换任务独立成一个子进程增加超时和错误捕获。某个文件失败就标记出来不中断整体流程。然后建立一个“失败文件列表”全部跑完后统一重试或人工处理。这个做法表面上看多写了一点代码实际上能少熬好几个夜。另外转换中间结果要定期落盘。如果真的遇到程序崩溃至少可以从断点继续不用从头再来。4.6 一个容易被忽略的问题英文引号、连字符和换行符别看这些都是小细节它们对 RAG 的影响一点都不小。PDF 转出来的文本里经常出现“弯引号”和“直引号”混用、单词被连字符拆到两行、半角全角空格错乱。这些看起来“无关紧要”的字符会让切分器把不该断的词切断或者让 embedding 模型把同一个词的不同形态当成完全不同的 token。我的做法是在后处理脚本里做一轮统一规范化把弯引号统一成直引号把行尾连字符和换行符合并把全角空格替换成半角统一换行符格式。这个步骤可以让向量检索的命中率提升不少操作成本却极低。5. 从一个项目实例看整体落地路径这部分我拿一个之前做的“企业技术文档知识库”项目当例子把整个流程串一遍。这个项目要处理大约 4000 份 PDF内容包括产品手册、实施方案、故障排查文档、技术白皮书每一类还都有扫描件和文字件混着来。预处理阶段我先用 PyMuPDF 全量抽取文本层自动化判断“有没有文本层、占比多少”然后再把文件分成三类纯文字件、复杂排版文字件、扫描件。纯文字件直接走 Pandoc 快速转换复杂排版文字件走 MinerU扫描件走 Marker 或者 MinerU 的 OCR 模式。这样分层处理GPU 时间至少省了 40%。转换完成后跑了一遍我前面写的清洗和规范化脚本。这一步剔掉了大量页眉页脚、目录页和版权页还修了一批 OCR 常见的“0/O、1/l”错字。切分阶段我定了“章节标题优先、表格和代码块独立成块、段落边界二次切分”的分块策略并且给每个 chunk 打上了文档名、章节路径、页码等元数据。最后进向量库之前我抽了 50 份文档做人眼质检。发现模板类文档的表格跨页合并问题比较严重专门补了一版后处理逻辑去识别跨页表格做合并。上线后做了三个月的效果追踪用户提问后召回的准确率比用纯文本提取方案提高了大约 35%。这个数字不一定普适但至少说明转换环节每多投入一分质量后面的效果回报是几何级的。写在后面的一点心得我以前也犯过“重模型、轻解析”的错误。直到有一次排查了很久总发现某个领域问题检索不准最后定位到源头原 PDF 里有一批表格被转换工具完全转乱了向量化之后全是垃圾数据。从那以后我再也不敢把“PDF 转 Markdown”当做一个可有可无的预处理步骤而是当成整个 RAG 系统的地基来对待。现在这个环节已经有不少新工具在持续迭代也有人在尝试端到端的文档解析大模型但我个人的感受是在实际业务里没有一劳永逸的工具只有“适合自己场景 认真做后处理 持续监控效果”这一条路最可靠。希望这篇文章能把你的注意力引到正确的地方少走一些我当时走过的弯路。