先交代一个背景。前阵子公司要做内部知识库目标是把过去七八年沉淀下来的一堆PDF文档变成可以检索、可以喂给大模型、可以持续维护的Markdown文件。业务方一开始觉得这事简单不就是个“另存为”——可真的跑起来以后才发现PDF转Markdown这件事的坑比想象中深得多。这篇文章就是一次相对完整的工具对比复盘重点说清楚我会怎么选、为什么这么选以及实测下来哪些工具能打、哪些是花架子。开头先把结论摆出来如果明年再让我做一次选型我会以开源解析引擎为主干以SaaS/云端API做兜底再配一条人工校验的质量门禁。纯靠单个工具打天下基本不现实。1. 这个需求是怎么来的为什么企业会盯上 PDF 转 Markdown1.1 企业里最常见的几个真实场景先说场景不然没法聊技术选型。这轮需求方是文档密集型部门手头PDF类型五花八门有早期用Word直接导出的文本型PDF有扫描的纸质合同有产品说明书还有大量学术范儿的技术白皮书。这些文档过去只能躺在文件服务器里检索靠文件名复用靠复制粘贴而且复制出来的格式经常乱成一锅粥。现在要做的事主要有四类给检索增强生成RAG类的知识库供数要求输出干净的Markdown文本片段。给内容中台做文档结构化要求文档能拆成标题、段落、表格、图片、公式等独立元素。做跨文档的版本对比需要先把历史PDF统一转成文本格式再做差异比对。给运营编辑提供可再编辑的源文件不少同事习惯用Markdown编辑器写东西拿到PDF没法直接改。这几个场景看起来都是“转格式”但各自的验收标准完全不同。RAG场景更关心文本语义是否连续换不换行不是最重要内容中台场景更关心结构是否可编程解析版本对比场景则更关心原文是否被忠实保留。所以选择工具之前必须先把“转完给谁用”问清楚否则后续验收阶段一定会打架。1.2 为什么不直接用 PDF非要转成 Markdown这是个很值得较真的问题。直接说结论PDF 是“显示格式”不是“内容格式”。它记录了每个文字、每个图形在页面上的坐标位置却几乎不记录“什么是标题”“什么是段落”“这个单元格归属哪一行”。早期我做传统出版类项目的时候深有体会PDF里的文字块经常被切得乱七八糟视觉上连成一句话实际内部可能是七八个独立的文本块。这种情况导致两个后果第一直接把PDF文本喂给大模型要么因为夹杂了大量页眉页脚、页码、断字导致检索效果差要么因为表格嵌在文本流中完全失去行列关系第二PDF改起来极其痛苦哪怕只是想统一一个标题字号也得回到源文件去改等于把编辑活路堵死了。Markdown的优势正好补上这些短板。Markdown用轻量级标记语法表达文档结构输出文件是纯文本任何编辑器都能打开也方便用脚本继续处理。对于数字化知识库这样的场景Markdown天然适合按标题切块、按段落嵌入向量库、按代码块展示技术内容。而且Markdown转HTML或者转Word的生态比较成熟真需要演示版文档时可以随时再生成。2. 选型之前先搞清楚下面这几个对比维度2.1 按文档类型做区分而不是按工具名气做区分做工具选型最忌讳的就是拿一份“干净整洁”的白皮书PDF测试全部工具因为那种文档对谁来说都没难度。企业里真正让人头疼的是下面这几种扫描件纯图片PDF考验OCR识别能力。双栏或者三栏排版的论文考验版面分析能力。含复杂表格合并单元格、跨页表的财务报表考验表格结构重建能力。含数学公式、化学式的技术文档考验公式解析能力。带水印、页眉页脚、批注的公文考验内容清洗能力。我建议做选型对比时先拿出企业内部有代表性的20到30份文档划成几类分别测试然后再按“加权得分”来判断工具优劣。不要拿一份文档定生死否则上线后半数文档会翻车。2.2 输出质量的下限比上限更重要很多工具在优质PDF上的转换效果差别不大真正的分水岭在劣质文档上。我见过某些商用转换服务对扫描件的准确率高到99%可一遇到扫描歪斜、带印章的合同就开始犯迷糊。反过来某些开源工具对清晰扫描件识别得很好但对彩色底纹敏感经常把背景文字识别进去。所以选型一定要看“质量下限”最差的文档转出来不能烂到没法读。如果一套工具链里有20%的文档需要人工重写那这个工具就不适合做企业级生产尤其不适合规模化处理。好的方案应该是95%的文档自动转完直接可用还有5%的文档进入人工处理队列。2.3 有没有批量处理和增量更新能力企业文档有个特点数量大、更新频繁。知识库上线只是开始之后每一天都有新PDF进来老PDF可能还有修订版。这时候如果工具不能批量处理不能只转换新增或变更的文档人力和时间成本会成倍上涨。在这个维度上开源工具通常更灵活。只要留好命令行接口脚本里加个文件判重就能实现只处理增量文件。SaaS服务则要看有没有提供批量API是否需要排队以及按页计费还是按次计费这些都要提前注意。2.4 部署方式与成本模型企业环境通常绕不开数据安全。如果文档里有客户信息、内部财务数据走公网SaaS就得做严格的数据脱敏和授权审批。实测下来很多企业最终都会在本地或者在私有云容器里部署一套开源引擎只有处理公开资料时才走SaaS形成两套链路。成本也不只是软件许可证费用。开源工具看起来不要钱但服务器资源、算法调优、失败样本标注、人工校验都是隐形成本。商用API按页数计费看起来单价不高但处理几十万页文档算下来也不是小数目。我习惯这样算总账总的成本 工具采购费 服务器费用 人力校验工时 * 单价 错误导致的返工成本。2.5 还有一条容易被忽略的输出格式的规范性这一条很少人提但实际影响很大。很多工具转出来的Markdown看着没问题一打开原始文本就会发现各种问题一个超大表格挤在同一行、图片路径里带乱七八糟的参数、标题层级用的不是井号而是加粗字。这些对人工浏览影响不大但对接自动化流程时会很麻烦。我给知识库做切块时就遇到过Markdown里同一段落被错误地拆成多个空行分隔的片段切块逻辑直接失效。所以选型时一定要指定“样板文件”用工具转完后检查一下输出的文本结构而不是只看渲染效果。3. 工具池盘点我实测过的四类方案3.1 通用转换工具Pandoc 与其他库组合说到格式转换Pandoc 是绕不开的名字。但它本身强在“把一种结构化文档转成另一种”比如 Markdown 转 Word、HTML 转 Markdown直接拿 PDF 喂给 Pandoc 其实不太行因为它不负责做版面分析和 OCR。实际工程里我通常用 Pandoc 做后处理先把 PDF 里的文本抽取出来再组织成 Pandoc 能吃的中间格式最后由 Pandoc 统一输出 Markdown。抽取文本这一步常用的组合是 pdfplumber 加 pdfminer.six。pdfplumber 对表格的抽取比较友好能按坐标还原单元格pdfminer.six 胜在能拿到更多的排版细节。遇到扫描件就得叠加 Tesseract、PaddleOCR 这一类的 OCR 引擎。这个方案的优点是完全可控每一条管线都可以自己调缺点是搭起来费时间得自己写不少胶水代码。3.2 专为 LLM 场景设计的解析器Marker、Docling、PyMuPDF4LLM 与 MinerU近两年涌现了一批专门做“PDF 转 Markdown”的开源项目思路比传统方案激进。它们一般都引入深度学习模型来做版面检测、阅读顺序还原、公式识别目标就是让输出更适合大模型直接消费。Marker 是我最早一批关注的工具它基于深度学习检测版面能识别标题、段落、图片、表格还自带了公式识别和 OCR 能力。实测它在英文论文、英文报告上的效果相当不错但在中文扫描件上的表现略逊。Docling 是 IBM 开源的文档转换工具架构上很完整支持PDF、Word、PPT导入具备版面分析和表格结构识别能力。它对表格的处理尤其用心能还原合并单元格这在企业财报场景里是一大优点。PyMuPDF4LLM 不是独立工具是 PyMuPDF 库提供的一个轻量接口。它把原来基于规则的文本抽取做了 Markdown 化整理适合对质量要求不高、追求速度的场景。我之前拿它做了个快速原形处理几百页文本型 PDF速度比其他方案快了一个量级。MinerU 是上海人工智能实验室开源的工具官方叫法叫“数据提取工具”对中文文档的版面分析和公式识别做得很扎实。我拿它处理过一批中文扫描教材识别效果在开源方案里是首屈一指的。它部署稍重一些需要下载模型权重但值得花时间。我自己的分工习惯是中文文档优先跑 MinerU标准英文论文优先跑 Marker需要快速批量处理的纯文本 PDF 直接上 PyMuPDF4LLM表格多的结构化文档用 Docling。这四兄弟并不冲突组合起来用效果更好。3.3 云端 SaaS 与商用级 API适合不想自己维护的团队如果团队没有算法工程师或者文档量波动比较大云端方案更方便。这里只说类型不逐一列名字因为这类服务更新很快接哪家都得先测试。常见的有通用型的文件转换云服务、文档结构化服务以及专门的公式 OCR 服务。云端方案最大的优点是省事上传、转换、下载或者直接调 API几行代码就能接入公司系统。而且头部云服务商背后有大量数据做优化对复杂排版的鲁棒性很高。缺点是长期成本高而且数据出境问题在部分行业是硬伤。上云之前一定要跟安全部门过一遍数据分类和合规评审。3.4 企业版 Office/PDF 套件自带的另存功能还有一个容易被忽略的选项就是公司已经采购的办公软件套装。很多企业版 PDF 阅读器或编辑器都内置了“导出为 Word / HTML / 文本”的功能导出的文件结构通常比命令行工具更符合办公习惯。不过这种方案的劣势也非常明显一是格式不稳定批处理基本别想二是依赖GUI交互很难嵌入自动化流程三是遇到扫描件同样需要依赖自带 OCR质量参差不齐。我的建议是这种方案用来做个人临时处理可以企业生产环境尽量别当主力。它适合做“人工更正质量门禁”环节的辅助工具员工发现自动转换结果不对时可以拿商业套件手工重新导出一次。4. 实测过程我用同一批文档做了哪些测试4.1 测试样本的设计方法为了不让选型变成拍脑袋我特意从公司文档库里抽了24份文件覆盖6类常见场景每一类各4份。文本型行业报告、扫描版合同、排版精美的产品手册、表格密集的财务报表、含大量公式的学术论文、带复杂页眉页脚的内部公文各占一档。每份文档我先人工做了“标准答案”也就是把关键信息点提取出来列成清单一共几个一级标题、几个表格、表格里关键数值是什么、有没有公式。转换完成后我不看渲染效果而是直接对照清单打分。这样做的好处是主观干扰小工具到底有没有把内容保住一目了然。4.2 表格与公式是重灾区先说结论这6类文档里最翻车的就是财务报表和学术论文问题几乎全出在表格和公式上。表格的难点在于行列关系重建。很多PDF是“视觉上对齐”的表格页面上看是一行行对齐的但在文本流里每个单元格其实是一个独立的文本块。简单的抽取规则看到的就是一行行的杂散文本根本不知道谁属于哪一列。Docling 和 MinerU 在表格重建上做得较好会把表格结构抽象成类似HTML表的形式再转成 Markdown 表格。Pandoc pdfplumber 的方案虽然也能抽但遇到合并单元格就开始错位。公式就更麻烦了。PDF里的公式大多以矢量图形或者嵌入的公式对象存在直接抽取文本只会得到一堆残缺符号。Mathpix 这种专门做公式 OCR 的服务准确率很高但单价不低。MinerU 匹配的公式识别模型在开源方案里已经算上游水平能直接输出 LaTeX 格式的公式源码方便转成 Markdown 的数学公式块。4.3 双栏 PDF 和不规则版式双栏排版是学术论文的常见格式对转换工具来说却是障碍。普通文本抽取是按物理顺序读内容左栏没读完就开始读右栏结果语义完全错乱。传统方案在这里几乎全部失效需要依赖版面分析模型先把页面划成不同阅读区域再按“从左到右、从上到下”的正确顺序输出。实测下来Marker 和 MinerU 对双栏的恢复做得最自然Docling 次之传统方案就不太行了。还有个细节图片标题和表格标题经常被识别成独立文本块如何正确归属到图片或表格下面各家的处理逻辑也不一样这会导致Markdown结构出现层级混乱。4.4 扫描件 OCR 的组合效果纸质合同这种扫描件本质上是图片不做 OCR 一个字都抽不出来。实测时我把 PaddleOCR 和 Tesseract 都跑了一遍。PaddleOCR 对中文识别准确率更高Tesseract 的好处是部署轻、免商业授权。Marker 内置的 OCR 方案在扫描件上的表现也不错但对中文支持不如 PaddleOCR 稳。这里有个很现实的教训扫描件 OCR 之后一定要做“校对抽检”。OCR 的错误往往不是单个字错而是专有名词、数字、金额被替换成形近字比如“O”和“0”“l”和“1”单个看没问题用在财务核对里就是事故了。5. 结果对比谁更适合企业生产线5.1 综合评分表下表是我基于实测样本的打分结果每项满分10分权重做了人工调整。这个结果只代表特定文档集下的表现换个文档分布结论可能会变。工具/方案文本型PDF扫描件复杂表格公式双栏论文部署难度综合推荐度Pandoc pdfplumber OCR85533中中规中矩二次开发空间大Marker86778中英文文档效果好Docling95967中表格与结构化首选PyMuPDF4LLM83534低快速粗转首选MinerU98898较高中文文档综合最强云端SaaS98888低省心但费钱办公套件另存74634低只适合人工兜底5.2 给不同企业场景的推荐组合如果你所在的团队人力少、没有专职算法工程师我的建议是先用云端SaaS把流程跑通量上来之后再做成本评估。不要一上来就自研。如果你有研发资源能把开源工具封装成内部服务那我会推荐这样一套组合拳中文通用文档走 MinerU英文文献走 Marker表格密集场景走 Docling纯文本快速解析走 PyMuPDF4LLM。四套服务用容器化部署前面挂一个统一的任务调度接口。处理流程里加上指纹判重按文档哈希值做增量处理避免做重复劳动。至于 Pandoc它是这套流程的“组装工”而不是“核心引擎”。所有工具产出的中间结果最后统一交给 Pandoc 做格式规范化能省掉很多 Markdown 语法不统一的问题。6. 企业落地时容易踩的坑6.1 把“能跑通Demo”当成“能投产”很多工具在小样本上效果惊艳一到生产环境就露馅。原因通常是样本太干净页码没干扰、标题层级明确、扫描件都是端正的A4纸。真实环境里各种状况都有页眉页脚误识别进正文、水印被当成正文、歪斜的拍照件根本没法定位版面。我的处理方式是在选型阶段就建立一个“脏样本库”。凡是人工觉得难处理的PDF都扔进去持续积累。每次工具升级或换方案时先用这批脏样本做回归测试要求得分不低于上一版本否则不推进替换。6.2 没有量化指标质量就是一笔糊涂账如果不把“转换质量”量化业务方和技术方必然会产生分歧。业务方说“这个表格不对”技术方说“你给个错误样例看看”双方来回拉扯。更好的做法是定义几个简单指标标题识别准确率、表格结构还原准确率、正文漏字率、公式可编译率。然后选取固定样本集每次调整都跑一遍对比指标变化。我在这轮复盘里用的办法是把转换结果和人工标注的标准答案对齐用脚本比对标题层级命中的比例、表格关键数值的覆盖比例。这样每条结论背后都有数据支撑讨论起来效率高很多。6.3 低估了人工校验环节的成本无论工具多强纯自动转换后直接上线风险都太大了。企业文档常涉及到合同条款、财务数字一个字符的错误都可能带来大麻烦。所以我坚持在流水线里加一道人工抽检关卡。具体做法是按文档类型设定抽检比例比如合同类100%人工复核报告类抽检30%内部草稿抽检10%。人工复核不需要重新排版只需要对照原PDF快速浏览一遍转出的Markdown重点看标题层级、表格数字和关键段落。这听起来很简单但实践下来能把问题扼杀在初始阶段避免错误被后续流程无限放大。6.4 权限与数据安全边界没划清楚这是最容易出问题的地方所以放最后强调。企业内部的合同、财务表、人力资源文件一旦传到外部SaaS就是一个数据泄露风险点。我见过一个团队为了提高识别率把客户信息PDF传到公网OCR服务结果被安全部门查了个底朝天。稳妥的做法是在数据进入转换流水线之前先做分级公开资料可以走SaaS内部资料走私有化部署工具。容器化之后开源引擎全部跑在内网网络出方向策略保持最小化。这一步最好在项目启动时就把安全部门拉进来而不是等到快上线再补。7. 常见问题与排查技巧实录7.1 表格结构乱套了怎么办这是反馈最多的问题。哪怕 Docling 和 MinerU 已经做得不错也总有极端样本出错。排查步骤先确认原PDF的表格是“真表格”还是“文本对齐的假表格”。很多设计软件导出PDF时会把表格画成一段段文本加直线这种识别难度极高。暂时关闭“分页拆分”选项。有些工具为了处理跨页表格会把一个大表切成多个小表反而破坏了结构。如果表格里内容特别复杂干脆不追求转成Markdown表格改成保留为HTML表格。Markdown表格不支持合并单元格HTML能更好地还原原貌。用代码在转换结果里定位“|”符号过多的行这类行往往是表格重建异常的重灾区。7.2 公式变成了乱码或者空白公式问题得分两种情况看。一种是PDF里公式本来就是图片这种情况需要接数学公式 OCR 引擎。另一种是公式用特殊字体嵌入普通文本抽取只能得到一堆字符遇到这种情况可以先尝试把字体信息提取出来看看是不是符号映射问题。我常用的兜底方案是在Markdown输出里保留公式图片路径同时附带OCR识别的 LaTeX 源码。这样即使自动识别不完美人工复核时也能对照图片修复。7.3 图片位置错乱、全被堆到末尾不少工具在转Markdown时会把图片抽出来统一放到最后原因是它们把“图片提取”和“文字抽取”分开执行了最后合并时找不到锚点。这个问题在长文档里非常影响阅读体验。排查思路查看Markdown里图片引用是否带上了原始页码或坐标信息有些工具会把这类信息写在文件路径里。检查工具是否支持“按阅读顺序输出”选项Marker 和 MinerU 都有相关参数开启后图片锚点会准确很多。如果工具不支持锚点后处理脚本可以根据PDF里图片的坐标和正文文本块坐标的距离把图片引用插回最近段落效果也能接受。7.4 批量处理几十万个文件跑得太慢这个问题通常是资源规划问题不完全是工具的锅。OCR和版面分析这两步特别吃CPU/GPU纯CPU跑扫描件可能一页几秒钟批量处理时根本等不起。我建议这样优化准备带GPU的机器专门跑版面分析和OCR把纯文本抽取和格式转换放到CPU节点中间文件放内网存储用消息队列驱动任务分发。如果PPT视频里就类似场景可以做成两级任务先快速过滤一遍识别出哪些是二值化后仍清晰的PDF哪些必须上重模型。这样能节省大量算力。7.5 转出来的Markdown渲染好看源码却乱糟糟很多人验收时只看渲染效果这其实是误操作。Markdown的渲染结果可以通过调整CSS美化但源码结构才是自动化流程真正消费的东西。我踩过的坑包括列表被错误缩进导致嵌套层级错乱、表格列数不齐导致渲染异常、代码块语言标识缺失导致高亮失效。针对这一问题我在流水线里加了一个 Markdown 语法检查脚本遇到常见的源码级错误直接报错并进入人工队列。没有这一步问题可能到下游向量化时才会暴露到时候排查更困难。8. 复盘之后的一些心里话到这里整轮工具对比的工作基本就算收尾了。我没有给出一个“全网唯一最优解”因为这本来就不存在。每家企业手里的文档结构千奇百怪数据安全要求也不一样能落到生产环境的方案必然是个性化的。我个人的体会是这一类工具选型项目真正难的不是找到那个“性能最猛”的引擎而是搭出一套“可维护、可度量、可兜底”的流水线。宁可先跑通一个80分方案也别憋大招非得一步到位上100分方案。先把流程转起来再根据失败样本持续迭代这是最稳妥的路线。最后分享一个实操时的小技巧给所有PDF文件在进流水线时算一个哈希值处理完毕后把结果Markdown和哈希一起存起来。后面如果换了新工具想重新处理旧文档直接比对哈希跳过未变化的文件能省下非常多的时间和算力。这套思路虽然简单但在这个场景里是我最想推荐的一条经验。