做 RAG 或企业知识库时，PDF 往往是第一批要处理的材料：合同、手册、白皮书、内部规范都堆在里面。直接提取纯文本看起来很快，但切片后检索质量通常上不去——标题边界消失，表格变成一串字，图片和正文也失去对应关系。
所以很多人真正搜索的是「PDF 转 Markdown」，而且目标很具体：输出能不能进入切片、向量化和问答流程，而不是再得到一坨失去结构的文字。
纯文本为什么不够做 RAG？
RAG 的质量，很大一部分取决于切片有没有语义边界。
- 没有标题层级时，模型很难知道哪一段属于哪个章节。
- 表格被拍扁后，「行」和「列」的对应关系断了，数字问答更容易错。
- 图片如果只剩孤立文件，正文里的「见图 3」就失去锚点。
- 页眉、页脚、页码反复出现，会污染摘要、检索命中和模型回答。
Markdown 之所以常被选作中间格式，不是因为它漂亮，而是因为它能用很轻的语法表达标题、列表、表格和图片引用，方便后续切块和入库。
用于 RAG 的 PDF → Markdown，至少要保留什么？
一份适合知识库的 Markdown，通常需要这些结构信号：
- 标题层级
#/##之类的层级，决定章节边界，也决定很多切片策略从哪里切开。 - 列表
步骤、条款、bullet 如果退化成普通段落，检索时会丢掉「这是一组并列项」的信息。 - 表格
标准 Markdown 表格能保住行列关系，便于后续问答引用数据。 - 图片引用
正文中的图片位置应保留为相对路径引用，并和图片文件一起打包，而不是只剩空链接。 - 干净正文
跨页重复的页眉页脚、页码尽量不要进入语料；同时，若你需要回溯原文页，又希望留下源页标记。
SimplifyAI 的 PDF 转 Markdown 面向的就是这类结构化提取：标题、列表、表格、图片资源和页眉页脚清理会尽量保留；中西文换行也会按阅读习惯合并，减少「一词被撕成两行」的噪音。
源页标记和页眉页脚：来源追踪还是干净语料？
知识库团队经常要在两种目标之间做选择：
- 需要追溯原文页：保留源页标记，切片命中后还能回到 PDF 对应页。
- 需要更干净的训练/检索语料：去掉页码注释，并继续清理跨页重复的页眉页脚。
在 SimplifyAI 的 PDF「提取 Markdown」配置里，你可以分别选择：
- 保留源页标记（默认开启）：Markdown 中保留源 PDF 页码注释，方便回溯。
- 保留页眉页脚（默认关闭）：默认尽量去掉跨页重复内容；只有在你需要对照原件时再打开。
这两项不会改变「结构化提取」本身，但会直接影响语料干净程度和出处可追踪性。建议先按默认配置跑一份样例，再根据知识库规范调整。
实际工作流：从 PDF 到可入库的 Markdown
- 上传 PDF，选择「提取 Markdown」。
- 按知识库需求勾选源页标记、页眉页脚选项。
- 在预览中检查标题层级、表格和图片引用是否完整。
- 下载
.md，或下载包含images/的 ZIP，接入切片与向量化流程。
交付物面向的是语义结构，而不是视觉版式。换句话说：目标是让模型读懂章节、列表和表格，不是复刻 PDF 的双栏排版。
当前边界：先写清楚，避免高估
适合：
- 文本层清晰的单栏 PDF
- 需要标题、列表、表格进入 RAG / 知识库
- 需要图片与正文位置一起打包
需要人工复核：
- 多栏版面的阅读顺序
- 复杂公式的语义还原
- 扫描件（当前版本不以 OCR 结果作为默认能力承诺）
- 非常不规则、靠坐标硬排的表格
如果你最终还要把结构化内容回流成可编辑 Word，可以看 PDF 转 Word 后为什么格式会乱；如果源头已经是 Word，也可参考 DOCX 转 Markdown 时如何保留表格结构和标题层级。
下一步
选一份真实会入库的 PDF，用 SimplifyAI 转成 Markdown，检查三件事：标题能不能支撑切片、表格还能不能按行列读、图片是否还在正文对应位置。确认这三点，比纠结「有没有和 PDF 看起来一模一样」更接近 RAG 的真实目标。