夜雨聆风
MinerU 3.0发布:从PDF到Agent可用知识
从PDF到Agent可用知识：MinerU 3.0让文档解析从”能用”变成”真能用”。
你知道吗？把一份PDF扔给AI处理，大部分工具只会把它变成一坨乱码。
双栏论文变成交替混乱的文本流，表格变成没有行列关系的字符，公式直接消失，图片直接不见。
这不是OCR的问题，而是整个思路都错了。
MinerU 3.0想做的事，不是”识别文字”，而是把非结构化文档变成Agent能理解的结构化知识。
一、传统OCR为什么不够用？
一份学术论文PDF里有什么？
-
双栏甚至三栏的复杂排版 -
跨页的大表格，带合并单元格 -
行内公式和行间公式混在一起 -
图表、图片说明、表格脚注 -
页眉、页脚、脚注、参考文献编号
传统OCR会怎么处理？自上而下机械扫描所有像素，结果就是：
-
双栏被读成交替混乱的文本流 -
表格变成一堆没有行列关系的字符 -
公式变成乱码或直接丢失 -
页眉页脚混进正文，把上下文搅得一团糟 -
图片直接消失
你拿这种东西喂给Agent，模型再强也救不回来。
二、MinerU的解决思路
MinerU要解决四个层层递进的问题：
1. 版面理解：这页纸上，什么是标题、什么是正文、什么是表格、什么是公式？
2. 结构重建：表格的行列关系是什么？合并单元格怎么还原？公式怎么变成LaTeX？
3. 阅读顺序推断：双栏排版先读左还是先读上？跨页表格怎么拼接？
4. 噪声过滤：页眉、页脚、页码——哪些是正文，哪些是干扰项？
只有这四件事都做对了，输出的Markdown才是Agent真能”读懂”的格式。
三、三套后端：怎么选？
MinerU有三种完全不同的解析技术路线：
Pipeline（分而治之）
把解析过程拆成四步，每步由专门的模型负责。
| 指标 | 数据 |
|---|---|
| 精度 | OmniDocBench 86.2分 |
| GPU要求 | 4GB / 纯CPU可用 |
| 速度 | 中等 |
优势：门槛极低，一行命令就能用，出了问题可以定位到具体环节
劣势：串行处理，最慢环节决定整体速度
适合：大多数人先试这个后端
VLM（端到端视觉理解）
用一个大型视觉语言模型直接看整页图像，然后生成结构化文本。
| 指标 | 数据 |
|---|---|
| 精度 | OmniDocBench 90+分 |
| GPU要求 | 8GB+ |
| 速度 | 慢 |
优势：全局语义理解，不会因为某个边界框画歪了就出错，精度天花板
劣势：硬件门槛高，需要高端GPU
适合：有GPU服务器、追求最高精度的场景
Diffusion（并行扩散解码）
不再逐字生成，而是并行扩散解码，让所有位置同时收敛到正确结果。
| 指标 | 数据 |
|---|---|
| 速度 | 比自回归快 3倍 |
| 精度 | 略低但极快 |
| 状态 | 早期探索阶段 |
适合：大规模语料生产、数据工厂、对吞吐量有极致要求的场景
四、3.0.0的核心变化
从”能跑”变成”能在生产环境大规模跑”。
DOCX原生解析：直接在XML层面解析DOCX，完全绕过视觉渲染。结果是零幻觉，速度提升数十倍。这对金融、法律这种Word文档为主的场景是杀手级更新。
滑动窗口：万页文档不再OOM。以前解析几万页的招股说明书，内存会爆掉。3.0引入了动态滑动窗口机制，无论文档多长，内存占用峰值始终稳定在低位。
mineru-router：一条命令启动多卡部署。对外接口和API完全兼容，但能在后端自动做多服务、多GPU的任务路由和负载均衡。
五、怎么快速上手
安装：
pip install --upgrade pip
pip install uv
uv pip install -U"mineru[all]"
解析单个文档（不需要GPU）：
mineru -p 你的文档.pdf -o 输出目录 -b pipeline
启动API服务：
mineru-api --host 0.0.0.0 --port 8000
多卡部署：
mineru-router --host 0.0.0.0 --port 8002 --local-gpus auto
一条命令，Router自动拉起多个worker，对外统一入口，内部自动负载均衡。
我的建议
先跑Pipeline。一行命令就能用，不需要GPU。等你发现Pipeline在你的文档上确实有瓶颈了，再考虑VLM或Diffusion。
我的预测：
-
短期：PDF解析将成为RAG系统的标配前处理 -
中期：企业文档处理将全面从OCR升级到结构化解析 -
长期：文档解析质量将直接决定AI应用的天花板
关注「小杜讲AI」，获取最新AI工具评测和技术分析。