从 PDF 到 Markdown：为什么文档解析对 RAG 很重要

Source: Dev.to

为什么解析质量对检索很重要

RAG 通过对文本块进行嵌入、将其存入向量数据库，并在查询时检索最相关的块来工作。块越能准确反映文档的结构和含义，模型就越能回答问题。

糟糕的解析（原始文本提取、朴素的 PDF‑to‑text）

• 表格损坏 → 数字和标题混入段落；检索返回不完整或毫无意义的行
• 标题丢失 → 没有语义层次；块边界忽视章节逻辑
• 布局混乱 → 多列或复杂文档产生乱序的阅读顺序
• 噪声 → 页眉、页脚、页码污染块并稀释相关性

良好的解析（结构化 Markdown，考虑布局的提取）

• 表格整洁 → 以 HTML 或结构化块保留；块可以包含连贯的行和单元格
• 层次保留 → 标题成为自然的块边界；章节保持完整
• 逻辑流畅 → 阅读顺序遵循文档的预期结构
• 噪声更少 → 可过滤模板内容；块更能代表实际内容

结果：嵌入捕获真实意义，检索返回的块真正回答问题，而不是垃圾片段。

Markdown 作为理想的 RAG 输入格式

Markdown 天然适合 RAG 流程，因为它：

• 保持 结构（标题、列表、表格）显式，而不是隐藏在布局中
• 易于分块 —— 可在 ## 或块类型处拆分，无需随意的字符切割
• 保留 语义单元 —— 表格行、代码块或章节保持完整
• 与 嵌入 配合良好 —— 模型通常在 Markdown 上进行训练；结构化文本的嵌入更可预测

相反，原始 PDF 文本往往是一长串没有明确边界的文字。你只能按固定 token 数量分块（丢失上下文），或自行推断结构（成本高且脆弱）。从干净的 Markdown 开始，就能免费获得结构。

选型时应关注的解析器特性

在为 RAG 构建文档摄取流水线时，选择能够：

• 保留结构 —— 标题、表格、列表、代码块
• 输出 Markdown —— 或可转换为 Markdown 的结构化 JSON
• 处理布局 —— 多列、复杂格式、正确的阅读顺序
• 暴露块元数据 —— 块类型、边界框、阅读顺序，以便自定义分块