文件格式转换实战：为什么很多系统要走“文件 → PDF → Markdown”，到底应该怎么做？

在大模型应用、知识库、RAG、文档解析、智能问答系统里，经常会遇到一个问题：

用户上传 Word、PPT、Excel、图片、PDF，系统最后却要把它们统一转成 Markdown。

更常见的是，很多工程不是直接：

Word / PPT / Excel → Markdown

而是先走一层：

原始文件 → PDF → Markdown

这不是多此一举，而是为了让文档解析更稳定、更统一、更适合后续给大模型使用。

下面就详细说清楚：文件格式转换“文件 → PDF → Markdown”到底应该怎么做。

一、先说结论：文件转 Markdown，本质不是“格式转换”，而是“内容结构还原”

很多人一听“文件格式转换”，会以为只是把 .docx 变成 .md，就像改个文件后缀一样。

其实不是。

真正难的是：

把一个复杂文件里的内容、层级、表格、图片、标题、页眉页脚、段落顺序、阅读顺序，尽可能还原成大模型能理解的文本结构。

比如一个 Word 文档里可能有：

一、标题
二、正文段落
三、表格
四、图片
五、脚注
六、页眉页脚
七、多栏排版
八、批注
九、目录
十、复杂编号

如果直接粗暴提取，很可能出现：

正文顺序乱了，表格散了，标题层级丢了，图片说明没了，页眉页脚混进正文，甚至一页内容被拆得七零八落。

所以工程上通常要做三件事：

第一步：统一入口格式。
不同文件先转换成一个相对稳定的中间格式，比如 PDF。

第二步：从 PDF 中解析内容。
包括文本、表格、图片、坐标、版面结构。

第三步：生成适合大模型使用的 Markdown。
Markdown 的好处是结构清晰、文本干净、方便切分、方便进入向量库和 RAG 流程。

二、为什么要走“文件 → PDF → Markdown”？

1、PDF 是一种“版式固定”的中间格式

Word、PPT、Excel 这类文件，本质上是可编辑文档。不同软件、不同字体、不同系统打开，显示效果可能不一样。

比如：

同一个 Word 文件，在 Windows Office 里看是一页，在 WPS 里可能换行位置不同，在 Linux 服务端转换时又可能字体丢失。

但是 PDF 的特点是：版式相对固定。

也就是说，PDF 更像是“最终展示效果”。标题在哪、表格在哪、图片在哪、每段文字的位置是什么，都比较稳定。

这就是为什么很多系统喜欢先转 PDF。

2、统一成 PDF 后，后续处理链路更简单

如果不转 PDF，你就要分别处理：

Word 解析一套逻辑；
PPT 解析一套逻辑；
Excel 解析一套逻辑；
图片 OCR 一套逻辑；
HTML 解析一套逻辑；
PDF 解析一套逻辑。

这样系统会非常复杂。

如果先统一成 PDF，后面就可以变成：

Word → PDF
PPT → PDF
Excel → PDF
图片 → PDF
HTML → PDF
PDF → Markdown

后半段只需要重点打磨：

PDF → Markdown

工程复杂度会降低很多。

3、PDF 更适合做版面分析

大模型知识库最怕什么？

不是没内容，而是内容顺序乱。

比如一份两栏论文，如果直接提取文字，很可能提取成：

左栏第一行、右栏第一行、左栏第二行、右栏第二行……

这样大模型读起来就是乱的。

PDF 里通常可以拿到文字坐标、字体大小、块位置、图片位置。像 PyMuPDF 这类库可以做 PDF 文本提取、版面分析、表格提取等操作。PyMuPDF 官方也说明它可用于 PDF 的数据提取、分析、转换和操作。

所以 PDF 不是万能，但它很适合做统一解析入口。

三、为什么最终要转成 Markdown？

1、Markdown 结构清晰，适合大模型阅读

Markdown 很简单，比如：

# 一级标题 ## 二级标题 这是一段正文。 | 字段 | 含义 | |---|---| | name | 用户名 | | age | 年龄 |

它不像 HTML 那样标签很多，也不像 PDF 那样强调页面坐标。

Markdown 的优势是：

结构清楚；
文本干净；
体积小；
方便切分；
方便存入向量库；
方便给大模型作为上下文。

所以在 RAG、知识库、Agent 文档理解场景里，Markdown 是非常常见的中间文本格式。

2、Markdown 更适合做 Chunk 切分

知识库通常不会把整篇文档一次性塞给大模型，而是要切成一段一段。

比如：

按标题切；
按段落切；
按页码切；
按表格切；
按语义切。

如果是 Markdown，就可以根据：

#
##
###
表格
代码块
列表

这些结构做更合理的切分。

比如：

## 3.2 费用结算规则 这里是费用规则正文……

这一段可以单独作为一个知识块。

如果只是纯文本，就很难知道哪个段落属于哪个标题。

3、Markdown 更容易保留“内容层级”

大模型不只是看文字，还要理解上下文关系。

比如：

# 合同条款 ## 付款方式 ## 违约责任 ## 保密条款

这种层级结构对大模型非常友好。

它能知道“违约责任”是合同条款下的一个章节，而不是一段孤立文本。

四、整体架构应该怎么设计？

一个成熟的“文件 → PDF → Markdown”系统，通常可以分成 8 层。

五、第一层：文件上传与类型识别

1、先识别文件类型

用户可能上传：

.doc
.docx
.ppt
.pptx
.xls
.xlsx
.pdf
.jpg
.png
.txt
.html
.csv

不要只依赖文件后缀。

因为有些文件可能被用户改过后缀，比如一个 PDF 被改成 .docx。

更稳妥的做法是：

根据文件后缀初步判断；
根据 MIME Type 再判断；
根据文件头魔数再确认；
必要时尝试用解析器打开验证。

2、上传后先做安全检查

文件转换系统很容易被攻击，因为它要打开用户上传的文件。

所以需要做：

文件大小限制；
文件类型白名单；
病毒扫描；
压缩包炸弹检查；
文件名清洗；
路径穿越防护；
临时目录隔离；
转换容器隔离。

比如不要让用户上传一个超大的 2GB Word 文件，也不要让用户上传恶意宏文档直接在服务端执行。

3、文件需要生成唯一任务 ID

一次转换不要只靠文件名。

应该生成：

taskId
fileId
requestId
traceId

后续所有日志都围绕这些 ID 串起来。

这样转换失败、解析失败、Markdown 质量异常时，才方便排查。

六、第二层：原始文件预处理

1、Word 文档预处理

Word 文档最常见的问题是：

字体缺失；
目录字段异常；
批注影响正文；
页眉页脚干扰；
隐藏文字；
复杂表格；
嵌入图片；
公式；
文本框。

处理建议：

优先保留正文、标题、表格、图片；
批注可以根据业务决定是否保留；
页眉页脚一般默认弱化；
目录可以保留，但不要当作正文重点；
隐藏文字通常不进入知识库；
文本框内容要尽量提取。

2、PPT 文档预处理

PPT 比 Word 更难，因为 PPT 是强视觉文档。

它有：

标题；
副标题；
图形；
文本框；
流程图；
图片；
备注；
动画；
母版；
图表。

PPT 转 Markdown 时，不能只提取文字，否则很多信息会丢。

比较实用的方式是：

每页 PPT 转成一页 PDF；
提取页面里的文本块；
保留页码；
图片单独保存；
图表可转图片并生成说明；
备注区可以作为补充内容。

3、Excel 文档预处理

Excel 最麻烦的地方是它不是天然的文章结构，而是表格结构。

Excel 可能有：

多个 Sheet；
合并单元格；
公式；
隐藏行列；
筛选；
图表；
透视表；
宽表；
多层表头。

Excel 转 PDF 有个问题：如果页面设置不好，可能会把表格切得很碎。

所以 Excel 不一定所有场景都适合先转 PDF。

更好的策略是：

如果是简单报表，可以转 PDF 后再转 Markdown；
如果是结构化数据，建议直接解析 Excel 生成 Markdown 表格；
如果是超大表格，建议转 CSV 或数据库表结构，不要强行塞成 Markdown。

4、图片文件预处理

图片类文档需要 OCR。

比如扫描件、合同照片、截图。

图片转 PDF 后再做 OCR 的好处是统一流程，但要注意：

图片清晰度；
方向是否旋转；
是否有倾斜；
是否有阴影；
是否有水印；
是否是多图拼接；
是否有表格线。

常见处理包括：

图片去噪；
自动旋转；
倾斜校正；
增强对比度；
裁剪边框；
OCR 识别；
版面区域检测。

七、第三层：文件转 PDF

1、Office 文件转 PDF

工程上常见方案是使用 LibreOffice 的 headless 模式，也就是无界面转换。

LibreOffice 支持在命令行中将 Office 文档转换为 PDF，常见命令形式类似：

libreoffice --headless --convert-to pdf input.docx --outdir output_dir

LibreOffice 可以处理它能打开读取的输入格式，并转换成它能写出的格式，包括 Office 文档转 PDF，不过转换效果并不是所有文件都完美。

实际工程中要注意：

服务端必须安装字体；
中文字体要完整；
不同版本 LibreOffice 转换效果可能不同；
转换过程要设置超时；
失败要能重试；
要防止多个任务抢同一个临时目录；
最好放在容器中隔离运行。

2、HTML 转 PDF

HTML 转 PDF 常见工具有：

Chromium headless；
Playwright；
wkhtmltopdf。

如果 HTML 中有复杂 CSS，建议用 Chromium 系方案，因为现代 CSS 支持更好。

处理重点：

等待页面渲染完成；
处理远程图片；
处理字体；
处理分页；
处理懒加载；
处理动态内容；
禁用不安全脚本。

3、图片转 PDF

图片转 PDF 相对简单。

可以把每张图片作为 PDF 的一页。

但要注意：

保持图片比例；
不要过度压缩；
控制 DPI；
多张图片按顺序合并；
保留原始图片路径，方便 Markdown 引用。

4、PDF 文件直接进入下一步

如果用户本来上传的就是 PDF，就不需要再转 PDF。

但仍然要做：

是否加密；
是否损坏；
是否扫描版；
是否有文本层；
是否页数过多；
是否包含图片和表格。

八、第四层：PDF 解析

PDF 转 Markdown 是整个流程的核心。

这一步不是简单“复制文字”，而是要完成：

文本提取；
阅读顺序还原；
标题识别；
段落合并；
表格识别；
图片提取；
页码保留；
脚注处理；
多栏处理；
公式处理；
OCR 兜底。

1、文本提取

普通 PDF 里通常有文本层，可以直接提取文字。

但直接提取经常会有问题：

换行乱；
空格乱；
段落断裂；
左右栏混在一起；
页眉页脚混入正文；
标题和正文无法区分。

所以要结合：

文本块坐标；
字体大小；
字体粗细；
行间距；
段落间距；
页面位置。

PyMuPDF 提供了 PDF 文本提取、自然阅读顺序提取、表格提取、Markdown 提取等相关能力说明。

2、阅读顺序还原

这是最容易被忽略的一步。

人看 PDF 时，会自动知道先读左边，再读右边，先读标题，再读正文。

但程序不一定知道。

所以需要根据版面做排序：

先按页面；
再按区域；
再按从上到下；
再按从左到右；
多栏文档要先识别栏；
表格区域不要按普通文本乱排。

如果阅读顺序错了，后面的 Markdown 再漂亮也没用。

3、标题识别

标题通常有几个特征：

字体更大；
加粗；
居中；
前面有编号；
上下间距更大；
出现在页面靠上位置。

比如：

一、系统架构设计 1.1 文件解析流程 2.3 表格识别策略

可以转换成：

# 一、系统架构设计 ## 1.1 文件解析流程 ## 2.3 表格识别策略

标题识别准确后，Markdown 才有层级。

4、段落合并

PDF 里的文本经常是一行一行存的。

比如原文是：

文件格式转换系统需要先完成文件类型识别， 然后将不同格式统一转换为 PDF， 最后再解析为 Markdown。

直接提取可能变成三行。

但在 Markdown 中，它应该是一段：

文件格式转换系统需要先完成文件类型识别，然后将不同格式统一转换为 PDF，最后再解析为 Markdown。

所以要做段落合并。

判断依据包括：

行尾是否有句号；
下一行是否缩进；
两行之间距离是否很近；
字体是否一致；
是否属于同一个文本块；
是否遇到标题、列表、表格。

5、表格识别

表格是 PDF 转 Markdown 最难的部分之一。

表格可能有线框，也可能无线框。

有线表格可以根据线条和单元格边界识别。

无线表格要根据文字坐标对齐关系识别。

最终可以转成：

| 字段 | 类型 | 说明 | |---|---|---| | user_id | string | 用户ID | | amount | decimal | 金额 | | create_time | datetime | 创建时间 |

但复杂表格不要强行转成普通 Markdown 表格。

比如：

多级表头；
合并单元格；
跨页表格；
嵌套表格；
超宽表格。

这些可以选择：

保留为 HTML table；
转成图片并附 OCR 文本；
拆成多个小表；
输出为 CSV 附件；
在 Markdown 中标注“该表格结构复杂”。

6、图片提取

PDF 里的图片不能简单丢掉。

很多技术文档、合同、方案里，图片可能包含重要信息：

架构图；
流程图；
截图；
签章；
图表；
二维码；
扫描件。

建议做法：

将图片单独保存；
在 Markdown 中插入图片引用；
给图片生成描述；
必要时对图片做 OCR；
保留图片所在页码。

比如：

![第3页架构图](images/page_3_img_1.png) 图片说明：该图展示了文件上传、PDF转换、Markdown解析、向量入库的整体流程。

7、页眉页脚处理

页眉页脚经常污染正文。

比如每一页都有：

公司名称；
文档编号；
第 1 页 / 共 20 页；
保密声明；
日期。

如果不处理，最后切分出来的知识块里会到处都是重复噪声。

处理方式：

统计每页相同位置的重复文本；
识别顶部和底部固定区域；
将高频重复内容移除；
页码可以单独保留为元数据。

8、水印处理

很多 PDF 有水印，比如：

内部资料；
保密；
草稿；
公司名称斜着铺满页面。

水印如果被提取进正文，会严重影响 Markdown 质量。

处理方式：

根据透明度识别；
根据旋转角度识别；
根据重复频率识别；
根据位置和字体颜色识别；
必要时加入黑名单词。

九、第五层：OCR 兜底

1、什么时候需要 OCR？

不是所有 PDF 都能直接提取文字。

有些 PDF 其实是图片扫描件。

判断方式：

每页提取文本为空；
文本字符很少；
页面主要由大图组成；
复制 PDF 内容复制不出来。

这时就要 OCR。

2、OCR 不是越多越好

OCR 成本高，速度慢，而且会有识别错误。

所以建议：

能直接提取文本，就不要 OCR；
只有扫描页才 OCR；
图片区域可以局部 OCR；
表格图片可以用表格 OCR；
OCR 结果要做清洗。

3、OCR 后还要做版面恢复

OCR 不是终点。

OCR 只解决“图片变文字”，但还要继续处理：

标题识别；
段落合并；
表格还原；
阅读顺序；
页码定位；
置信度过滤。

否则 OCR 出来也是一堆乱文本。

十、第六层：Markdown 生成

1、Markdown 不是越花哨越好

用于大模型的 Markdown，要追求：

干净；
稳定；
结构清晰；
少噪声；
可切分；
可追溯。

不要为了好看加太多复杂格式。

2、推荐 Markdown 输出格式

可以采用这种结构：

<!-- source: contract.pdf --> <!-- page: 1 --> # 合同标题 ## 一、合作内容 这里是正文内容。 ## 二、付款方式 | 阶段 | 金额 | 时间 | |---|---:|---| | 首付款 | 10000 | 合同签署后 | | 尾款 | 20000 | 项目验收后 | ![第2页图片](images/page_2_img_1.png)

这样有几个好处：

可以追踪来源文件；
可以追踪页码；
可以保留表格；
可以保留图片；
方便后续切块。

3、标题层级怎么生成？

一般可以按规则：

最大标题 → #
二级标题 → ##
三级标题 → ###
小节标题 → ####

但不要过度依赖字体大小。

最好综合判断：

字体大小；
编号格式；
是否加粗；
上下间距；
是否独占一行；
是否出现在目录中；
是否符合标题关键词。

4、列表怎么处理？

原始内容：

1. 支持 Word 文件上传 2. 支持 PDF 解析 3. 支持 Markdown 输出

转换后：

1. 支持 Word 文件上传 2. 支持 PDF 解析 3. 支持 Markdown 输出

无序列表：

- 文件上传 - PDF 转换 - Markdown 生成

列表要尽量保留，因为它对大模型理解步骤非常重要。

5、代码块怎么处理？

技术文档中经常有代码。

如果不处理，代码缩进会丢。

应该转成：

```java public class FileConvertService { public String convert(String filePath) { return "markdown"; } }

代码块要尽量保留语言类型，比如 Java、Python、SQL、Shell。 --- ### 6、表格怎么处理？ 简单表格转 Markdown。 复杂表格可以转 HTML。 比如： ```html <table> <tr> <th>模块</th> <th>能力</th> </tr> <tr> <td>PDF解析</td> <td>文本、表格、图片提取</td> </tr> </table>

Markdown 支持 HTML，所以这是一个不错的兜底方案。

十一、第七层：内容清洗

PDF 转 Markdown 后，不能直接入库。

还要做清洗。

1、去掉乱码

常见乱码包括：

不可见字符；
异常空格；
重复换行；
编码错误；
控制字符；
错误分隔符。

处理方式：

统一编码为 UTF-8；
清理控制字符；
多个空格合并；
多个空行合并；
修复中文之间异常空格。

2、去掉重复内容

重复内容常见来源：

页眉；
页脚；
水印；
目录重复；
跨页表头；
免责声明。

比如每页都有：

内部资料，禁止外传

就应该从正文中去掉，或者只作为元数据保留一次。

3、修复断句

PDF 中常见问题：

本系统采用文件 转换服务进行处理

应该修复为：

本系统采用文件转换服务进行处理。

但不能盲目合并。

比如列表、标题、表格不能乱合并。

4、清洗无意义内容

比如：

空页面；
只有页码的页面；
只有水印的页面；
重复目录；
乱码比例过高的段落。

这些内容进入知识库后，只会影响召回质量。

十二、第八层：质量评估

文件转 Markdown，一定要做质量评估。

否则你不知道转换出来的内容到底能不能用。

1、基础指标

可以检查：

原文件页数；
PDF 页数；
Markdown 字数；
提取文本页数；
空白页比例；
乱码比例；
表格数量；
图片数量；
OCR 页数；
转换耗时；
失败原因。

2、内容完整性检查

比如：

Word 有 20 页，PDF 只转出 3 页，肯定有问题。

PDF 有 100 页，Markdown 只有 500 字，也大概率有问题。

可以做规则：

页数差异过大报警；
文本量过少报警；
连续空页报警；
乱码比例过高报警；
表格丢失报警；
图片数量异常报警。

3、抽样人工校验

对于重要文档，最好做抽样校验。

比如：

随机抽 3 页；
对比 PDF 页面和 Markdown 内容；
检查标题是否正确；
检查表格是否可读；
检查图片是否保留；
检查顺序是否正常。

十三、推荐技术选型

1、文件转 PDF

常见选择：

LibreOffice headless：适合 Office 转 PDF；
Chromium / Playwright：适合 HTML 转 PDF；
图片处理库：适合图片转 PDF；
专业商业转换服务：适合高保真场景。

LibreOffice 的优势是开源、通用、部署成本低，但复杂 Office 文档转换效果不一定百分百完美。

2、PDF 解析

常见选择：

PyMuPDF；
pdfplumber；
Apache PDFBox；
Poppler；
OCR 引擎；
版面分析模型。

PyMuPDF 是高性能 PDF 处理库，可用于 PDF 数据提取、分析、转换等场景。

3、Markdown 转换工具

如果是多格式转 Markdown，可以关注 MarkItDown、Pandoc 等工具。

Microsoft 开源的 MarkItDown 是一个轻量级 Python 工具，目标是把多种文件转换成 Markdown，服务于 LLM 和文本分析场景。

Pandoc 则是非常经典的文档格式转换工具，官方称它可以在多种标记格式之间转换。

不过工程上不要完全依赖一个工具“一把梭”，因为真实业务文档太复杂，通常需要自己做规则增强和质量兜底。

十四、完整处理流程示例

可以设计成下面这样的流水线：

用户上传文件 ↓ 文件类型识别 ↓ 安全检查 ↓ 原始文件预处理 ↓ 转换成 PDF ↓ PDF 质量检查 ↓ 判断是否需要 OCR ↓ 文本 / 表格 / 图片 / 版面解析 ↓ 生成 Markdown ↓ Markdown 清洗 ↓ 质量评估 ↓ 切分 Chunk ↓ 向量化 ↓ 入库 ↓ 提供检索和问答

十五、工程落地时的模块设计

1、FileUploadService：文件上传服务

负责：

接收文件；
保存原始文件；
生成 fileId；
记录文件大小、类型、上传时间；
返回任务 ID。

2、FileDetectService：文件识别服务

负责：

识别文件类型；
校验文件是否合法；
判断是否支持转换；
判断是否需要 OCR；
判断是否需要特殊处理。

3、PdfConvertService：PDF 转换服务

负责：

Word 转 PDF；
PPT 转 PDF；
Excel 转 PDF；
HTML 转 PDF；
图片转 PDF；
转换失败重试；
转换超时控制。

4、PdfParseService：PDF 解析服务

负责：

文本提取；
坐标分析；
段落重组；
标题识别；
表格识别；
图片提取；
页眉页脚去除；
水印过滤。

5、OcrService：OCR 服务

负责：

扫描件识别；
图片文字识别；
表格图片识别；
低置信度标记；
OCR 结果清洗。

6、MarkdownBuildService：Markdown 生成服务

负责：

标题转 Markdown；
段落转 Markdown；
表格转 Markdown；
图片引用生成；
代码块保留；
页码元数据写入。

7、QualityCheckService：质量检测服务

负责：

文本量检查；
页数检查；
乱码检查；
空页检查；
重复内容检查；
转换结果评分。

8、ChunkService：文档切分服务

负责：

按标题切分；
按页码切分；
按段落切分；
表格单独切分；
控制每个 Chunk 长度；
保留来源信息。

十六、Markdown 入库前，最好保留哪些元数据？

每个 Markdown 或 Chunk 最好带上这些信息：

{ "file_id": "file_001", "file_name": "产品方案.pdf", "source_type": "pdf", "page_start": 3, "page_end": 4, "title_path": "系统设计 / 文件转换流程", "chunk_index": 12, "content_type": "text", "has_table": true, "has_image": false, "ocr_used": false }

为什么要保留？

因为后续用户问答时，可以告诉用户答案来自哪一页、哪个章节。

这样可信度更高。

十七、常见坑点

1、只提取文本，不管顺序

这是最常见问题。

最后结果看似有文字，但顺序乱了，大模型理解就会错。

2、表格被拆散

很多合同、财务报表、技术参数都在表格里。

如果表格拆散，关键信息就丢了。

3、页眉页脚污染严重

每页重复出现的内容如果不去掉，会影响检索效果。

比如用户搜索“保密”，结果召回一堆页脚。

4、OCR 结果不清洗

OCR 会产生错字、空格、断行。

不清洗直接入库，后面问答质量会明显下降。

5、Excel 强行转 PDF

Excel 如果是大宽表，转 PDF 后可能变得非常难解析。

这种情况建议直接解析 Excel。

6、转换服务没有隔离

用户上传文件不可信。

转换服务最好容器化，限制 CPU、内存、磁盘、网络权限。

7、没有失败兜底

真实文件千奇百怪，一定会失败。

要有：

重试；
降级；
错误码；
人工处理入口；
失败日志；
用户提示。

十八、文件 → PDF → Markdown 和直接文件 → Markdown，怎么选？

不是所有场景都必须先转 PDF。

可以按下面思路选择。

1、适合先转 PDF 的场景

Word 排版复杂；
PPT 页面视觉信息重要；
需要保留页面结构；
需要按页追溯；
文档格式很多；
希望统一解析链路；
需要接入 OCR；
对版式还原要求较高。

2、适合直接转 Markdown 的场景

纯文本；
标准 Markdown；
简单 HTML；
结构清晰的 DOCX；
结构化 Excel；
CSV；
JSON；
代码文件。

3、推荐采用混合策略

最好的方案不是死板地全部转 PDF，而是：

能直接结构化解析的，直接解析；版式复杂的，先转 PDF；扫描件走 OCR；异常文件走兜底。

比如：

DOCX： 简单文档 → 直接转 Markdown 复杂排版 → 先转 PDF 再转 Markdown PPT： 通常先转 PDF，再按页解析 Excel： 结构化表格 → 直接解析 报表展示型 → 可以转 PDF PDF： 有文本层 → 直接解析 扫描件 → OCR 图片： OCR 后生成 Markdown

十九、一个比较靠谱的落地方案

可以这样设计：

1、第一阶段：先跑通基础链路

支持：

PDF → Markdown
DOCX → PDF → Markdown
PPTX → PDF → Markdown
图片 → OCR → Markdown

先不要一开始就追求所有格式都完美。

2、第二阶段：重点优化 PDF 解析质量

优化：

标题识别；
段落合并；
表格识别；
图片提取；
阅读顺序；
页眉页脚清理。

这一阶段对最终效果影响最大。

3、第三阶段：接入质量检测

增加：

转换成功率；
解析成功率；
乱码率；
空页率；
OCR 占比；
表格识别率；
平均耗时；
失败原因分布。

4、第四阶段：接入大模型增强

大模型可以辅助：

图片生成说明；
复杂表格转自然语言；
标题层级修正；
OCR 错字修正；
段落摘要；
文档结构归纳。

但注意：不要一上来什么都交给大模型。

基础解析还是要靠规则和工具，大模型适合做增强和兜底。

二十、总结

文件格式转换“文件 → PDF → Markdown”，看起来只是转换格式，实际上是一个完整的文档理解工程。

它的核心不是把文件后缀换掉，而是把复杂文档变成大模型能稳定理解的结构化文本。

比较成熟的做法是：

原始文件先识别和安全检查；
复杂格式统一转 PDF；
PDF 里解析文本、表格、图片和版面；
扫描件走 OCR；
根据标题、段落、表格生成 Markdown；
清洗乱码、页眉页脚、水印和重复内容；
最后做质量评估，再切分入库。

真正落地时，不要迷信单一工具。

LibreOffice、PyMuPDF、Pandoc、MarkItDown 这些工具都很有价值，但真实业务里还需要结合规则、OCR、质量检测、日志追踪和异常兜底。

一句话总结：

文件 → PDF → Markdown 的本质，是把“给人看的文档”，转换成“给大模型读得懂、检索准、可追溯、可复用的知识结构”。