别再把 PDF 直接喂给大模型了：我用 MinerU 做了一次从文档解析到 RAG 问答的完整实战

m0_61134850

501人浏览 · 2026-06-01 10:51:59

m0_61134850 · 2026-06-01 10:51:59 发布

别再把 PDF 直接喂给大模型了：我用 MinerU 做了一次从文档解析到 RAG 问答的完整实战

做知识库、RAG、AI Agent 的同学，几乎都会踩到同一个坑：文档能读到，不代表文档能读懂。

很多项目一开始都以为这一步很简单。PDF 能提文本，Word 能转 Markdown，不行就上 OCR，把字识别出来再喂给模型，不就可以了？

但真正上线后，问题很快就暴露出来：

论文是双栏，阅读顺序乱了
财报有复杂表格，数字关系丢了
合同混着扫描页，部分内容直接读不到
技术文档里有公式，最后全成了乱码

这也是为什么很多团队明明模型选得不差，回答效果却始终不稳定。问题不一定出在模型，而是前面的文档解析已经丢掉了大量结构信息。

这也是我最近重点研究 MinerU 的原因。

如果只用一句话概括它的价值，我会这么说：

MinerU 不是“再造一个 PDF 提文本工具”，而是一层把复杂文档转换成大模型可用结构化知识的基础设施。

这篇文章我会从一个真实应用场景出发，讲清楚 MinerU 在 RAG 链路里到底解决了什么问题，同时再和几类主流方案做一次工程视角的对比和评测。

1. 文档解析为什么会成为 RAG 的第一道门槛

很多人画 RAG 链路时，都会写成这样：

文档 -> 切块 -> 向量化 -> 检索 -> 大模型回答

但真实工程里，真正决定上限的其实是最前面的“文档怎么变成可用文本”。

因为一旦解析阶段出错，后面几乎没法补救：

段落顺序错，切块就会把语义打散
表格结构没了，模型看到的只是一堆数字
公式损坏，问答和总结都会失真
页眉页脚混进正文，召回噪音会很大

所以，文档解析不是预处理的小步骤，而是整个知识工程质量的起点。

过去那种“能抽纯文本就够了”的方案，在 Agent 时代明显不够用了。Agent 真正需要的不是“看到文字”，而是“理解文档结构”。

2. MinerU 到底是什么

根据 MinerU 官方仓库、llms.txt 和 API 文档，MinerU 面向 LLM / RAG / Agent 场景，支持把 PDF、图片、DOCX、PPTX、XLSX、网页等内容转换成结构化 Markdown / JSON，并支持表格、公式、图片等复杂元素处理。

公开资料里，有几个信息非常关键：

支持 VLM + OCR
支持 109 种 OCR 语言
支持 MCP Server
支持 LangChain、LlamaIndex、Dify、RAGFlow
同时提供开源部署、在线 API、CLI 和 SDK

简单说，MinerU 做的不是“提字”，而是“还原结构”。

它更像这样一条链路：

PDF / 图片 / Office 文档
        ↓
OCR / 版面分析 / 元素检测
        ↓
阅读顺序恢复
        ↓
表格、公式、图片结构化
        ↓
Markdown / JSON / HTML / LaTeX
        ↓
RAG / Agent / 知识库

这就是它和传统 PDF reader 的根本差异。

3. 一个真实可落地的案例：MinerU + LangChain 做 PDF 问答

最常见的落地场景其实很直接：

把一份 PDF 文档解析后接进 LangChain，做一个可问答的小型知识库。

比如：

产品文档问答
合同条款检索
研究报告摘要
财报知识问答

安装依赖

pip install langchain-mineru
pip install langchain-text-splitters
pip install langchain-openai
pip install faiss-cpu

核心代码

from langchain_mineru import MinerULoader
from langchain_text_splitters import RecursiveCharacterTextSplitter
from langchain_openai import OpenAIEmbeddings
from langchain_community.vectorstores import FAISS

loader = MinerULoader(
    source="demo.pdf",
    split_pages=True
)
docs = loader.load()

splitter = RecursiveCharacterTextSplitter(
    chunk_size=1200,
    chunk_overlap=200
)
chunks = splitter.split_documents(docs)

vs = FAISS.from_documents(chunks, OpenAIEmbeddings())
results = vs.similarity_search("这份文档的核心结论是什么？", k=3)

for r in results:
    print(r.page_content[:200])

如果文档更复杂，比如扫描页、长报告、表格和公式比较多，可以切到更高精度模式：

loader = MinerULoader(
    source="manual.pdf",
    mode="precision",
    token="your-api-token",
    split_pages=True
)
docs = loader.load()

这一步最大的价值不是“我拿到了字符串”，而是拿到的内容更适合后续检索：

标题层级更清晰
页面切分更自然
表格没那么容易碎掉
扫描页也能进入同一条链路
多栏布局更容易保住阅读顺序

换句话说，MinerU 在 RAG 里真正重要的地方，不是替代大模型，而是先把文档变成“机器也能按人类方式读”的结构。

4. 为什么很多传统方案在复杂文档上会失灵

如果只是简单文本 PDF，很多工具都能工作，比如 PyMuPDF、pdfplumber、MarkItDown。

但一旦文档复杂起来，问题就会集中暴露。

双栏论文

很多纯文本抽取方案的输出会像这样：

左栏第一段
右栏第一段
左栏第二段
右栏第二段

这对 RAG 很致命，因为上下文已经被打散。

财报和研报表格

表格不是普通文字。如果工具把表格抽成一串数字和字段，大模型很难稳定回答“哪一年营收更高”“哪一项同比最大”这类问题。

公式文档

公式如果在解析阶段已经碎掉，后面的总结和检索都会失真。MinerU 官方资料里明确提到支持公式输出为 LaTeX，这一点对科研和技术知识库非常关键。

扫描件

这类文档如果没有 OCR，基本直接失效；如果只有 OCR，没有版面理解和结构化，输出仍然是一坨连续文本，对 Agent 的帮助也有限。

所以，MinerU 的核心优势不是“会 OCR”，而是把 OCR 放进了更长的结构化链路。

5. 工程视角下，MinerU 和几类主流方案怎么比

为了避免单点吹捧，我把常见方案放到一起做一个工程视角的对比。这里不是统一硬件下的严格跑分，而是站在开发者落地角度看能力边界。

我这里选择 5 类典型方案：

PyMuPDF：轻量 PDF 文本抽取
Docling：开源文档解析工具
LlamaParse：云端解析服务
Unstructured：偏企业数据管线的文档处理方案
MinerU：面向 LLM / RAG / Agent 的文档解析方案

工程能力对比表

工具	原生 PDF	扫描 PDF	多栏顺序	表格	公式	Office	本地部署	Agent / RAG 接入
PyMuPDF	强	弱	弱	弱到中	弱	弱	强	弱
Docling	强	中	中到强	中到强	中	强	强	中到强
LlamaParse	强	强	强	强	中到强	中	弱	强
Unstructured	中到强	中	中	中	弱到中	强	强	强
MinerU	强	强	强	强	强	强	强	强