文档解析在 RAG 管线中的定位

文档解析在 RAG 管线中的定位

学习目标

读完本章后，你将能够：

• 理解文档解析在 RAG 管线中的数据流位置
• 掌握 MinerU 作为解析引擎的输入输出规范
• 设计将 MinerU 集成到 RAG/Agent 管线的方案
• 识别解析质量对下游检索和生成的影响

前置知识

• 深度文档理解：基于视觉模型的非结构化文档解析
• 文档内容转 Markdown
• LLM 应用常见模式

---

1. RAG 管线中的数据流

在典型的 RAG（Retrieval-Augmented Generation）管线中，文档解析位于数据准备阶段，是后续所有操作的基础：

关键认知：解析质量直接影响下游所有环节。如果解析阶段丢失了表格结构、公式语义或图片描述，后续的切分和检索只能在错误的信息上工作。

2. MinerU 的输入输出规范

2.1 输入格式

MinerU 支持五种输入格式：

格式	扩展名	解析特点
PDF	.pdf	最核心场景，支持扫描件/文本层混合
图片	.png/.jpg/.jpeg/.bmp/.tiff/.webp/.gif/.jp2	自动转 PDF 后解析
DOCX	.docx	原生解析，端到端速度比先转 PDF 快数十倍
PPTX	.pptx	原生解析，保留幻灯片结构与演讲者备注
XLSX	.xlsx	原生解析，保留表格结构与公式

2.2 输出格式

MinerU 提供四种输出模式（通过 --make-mode 参数控制）：

模式	说明	适用场景
mm_markdown	多模态 Markdown，保留图片引用	多模态 LLM 输入
nlp_markdown	NLP Markdown，图片替换为文本	纯文本 LLM 输入
content_list	内容列表 JSON	需要结构化处理的下游
content_list_v2	增强版内容列表	更精细的类型分类

2.3 输出目录结构

output_dir/
└── document_name/
    └── parse_method/
        ├── images/          # 提取的图片
        ├── document_name.md # Markdown 输出
        ├── document_content_list.json  # 内容列表
        ├── document_middle.json        # 中间表示
        └── document_layout.pdf         # 可视化质检

3. 集成方案

3.1 命令行集成（批量处理）

适合离线数据准备：

# 批量解析目录下的所有 PDF
mineru -p /data/papers/ -o /data/outputs/ -b pipeline

# 使用 VLM 引擎处理高优先级文档
mineru -p /data/critical/ -o /data/outputs/ -b vlm-auto-engine

3.2 API 集成（实时处理）

适合在线服务：

# 启动 API 服务
mineru-api --host 127.0.0.1 --port 8888

# Python 客户端调用
import httpx

async def parse_document(file_path: str, api_url: str):
    async with httpx.AsyncClient() as client:
        # 提交任务
        with open(file_path, "rb") as f:
            response = await client.post(
                f"{api_url}/file_parse",
                files={"file": f},
                data={"is_json": True}
            )
        return response.json()

3.3 与 LangChain 集成

MinerU 已被 LangChain 原生集成：

from langchain_community.document_loaders import UnstructuredFileLoader

# LangChain 内部可通过 Unstructured 调用 MinerU
loader = UnstructuredFileLoader(
    "document.pdf",
    strategy="hi_res",  # 使用高精度策略（背后调用 MinerU）
)
docs = loader.load()

3.4 与 Dify 集成

Dify 知识库支持 MinerU 作为解析引擎，在知识库配置中选择 MinerU 即可。

4. 解析质量对下游的影响

4.1 切分质量

解析问题	对切分的影响	解决方案
段落断裂	语义不完整的切分块	使用 pipeline 引擎，段落合并更准确
表格断裂	跨页表格被切成两半	开启跨页表格合并功能
标题丢失	无法按章节切分	确保布局识别模型能检测 title 类型

4.2 检索质量

解析问题	对检索的影响	解决方案
公式未转换为 LaTeX	向量检索无法匹配公式语义	开启公式识别（MFR）
表格转为纯文本	表格结构信息丢失	使用 HTML 表格输出
图片描述丢失	多模态检索缺少视觉信息	确保 caption 被提取

4.3 生成质量

解析问题	对生成的影响	解决方案
幻觉内容	LLM 基于错误信息生成	使用 pipeline 引擎（无幻觉）
页眉页脚残留	生成内容包含重复信息	自动过滤页眉页脚
阅读顺序错误	上下文引用关系混乱	使用正确的排序策略

5. 陷阱与对策

陷阱	对策
默认使用 VLM 引擎处理简单文档	简单文档使用 pipeline，节省 GPU 资源
未过滤页眉页脚导致向量冗余	MinerU 默认已过滤，无需额外处理
图片路径在迁移后失效	使用相对路径，输出目录整体迁移
批量处理时 OOM	使用滑动窗口模式，自动分批处理
Office 文档先转 PDF 再解析	直接使用 MinerU 原生 Office 解析，速度更快

6. 设计权衡

解析引擎选择策略

文档类型	推荐引擎	原因
简单办公 PDF	pipeline	速度快，纯 CPU 即可
学术论文（含公式）	hybrid 或 vlm	需要准确识别公式和表格
扫描件	vlm 或 pipeline（含 OCR）	需要 OCR 能力
DOCX/PPTX/XLSX	原生 Office 解析	速度最快，无幻觉
混合类型批量	pipeline 为主，VLM 增强	兼顾效率与精度

输出格式选择

下游系统	推荐格式	原因
向量数据库	nlp_markdown	纯文本即可，图片引用无意义
多模态 LLM	mm_markdown	需要图片路径
结构化处理管线	content_list	需要类型信息
人类审查	mm_markdown + 可视化 PDF	可读性 + 可质检

---

参考来源

• MinerU 官方文档：https://opendatalab.github.io/MinerU/
• MinerU GitHub：https://github.com/opendatalab/MinerU
• LangChain 文档：https://python.langchain.com/
• Dify 文档：https://docs.dify.ai/