MinerU 是什么
MinerU 是 OpenDataLab 出品的开源文档解析引擎，把 PDF、DOCX、PPTX、XLSX、图片和网页转换成面向 LLM、RAG、Agent 工作流的 Markdown 与 JSON。GitHub 仓库为 opendatalab/MinerU，2026 年 9 月 Star 约 8 万，OCR 覆盖 109 种语言（以上信息出自官方 README）。它解决的核心问题是让大模型”读得懂”文档：给 RAG 知识库做批量预处理、给 Agent 提供干净可检索的语料、把论文与财报里的表格公式搬进 Markdown。不想装环境，可以直接打开官方在线入口 mineru.net，网页版、桌面客户端、API 都在同一处；要自己部署的话，本站有一篇MinerU 安装教程，覆盖 pip、Docker 与桌面客户端三种方式。
为什么 LLM 时代需要专门的文档解析器
PDF 是为打印和排版设计的二进制格式，直接抽文本会丢掉大部分结构信息——这是通用事实，也是文档解析工具这一品类存在的理由。对 RAG 来说，入库语料的结构质量决定检索上限，这一步做不好，后面换什么模型都救不回来。
三个典型痛点。第一，扫描件和图片型 PDF 没有文本层，pypdf 这类库抽出来是空的，必须走 OCR。第二，学术文献的公式在 PDF 内部是排版指令，常规抽取会得到乱码或直接丢失；表格则被拆成散落的字符流，行列关系全毁。第三，双栏、多栏、跨页的版式打乱阅读顺序，抽出的文本句子错位，切块之后检索必然不准。
MinerU 的思路是把版面分析、OCR、表格识别、公式识别整成一条流水线，输出符合人类阅读顺序的 Markdown，并自动去掉页眉页脚。它在 InternLM 预训练过程中诞生（官方 README），最初为解决科学文献的符号转换问题而生，工程基因从一开始就对着文档解析这块硬骨头。
核心能力清单：它到底解决了什么
官方 README 列出的核心能力可以直接当验收清单用，逐条对应实际含义如下：
- 原生支持 DOCX、PPTX、XLSX 解析（3.1.0 起全覆盖，不用先转 PDF）；
- 公式转 LaTeX、表格转 HTML，版面精确重建；
- 支持扫描件、手写内容、多栏版式，跨页表格自动合并；
- 输出符合人类阅读顺序，自动去除页眉、页脚、页码、脚注；
- VLM + OCR 双引擎，OCR 支持 109 种语言；
- 自动检测扫描版和乱码 PDF 并启用 OCR；
- 输出多模态 Markdown、按阅读顺序排序的 JSON 等多种格式，附版面与 span 可视化结果。
最后一条常被忽略。做数据质检时，看可视化结果比肉眼比对 Markdown 高效得多，批量入库前抽查版面识别是否正确全靠它。
三种推理后端怎么选
结论先行：批量预处理选 pipeline，追求精度选 vlm-engine，两者折中选 hybrid-engine。精度数字出自官方 README 的部署表（OmniDocBench v1.6 端到端总分），选型建议是工程判断。
| 后端 | 定位 | 精度（OmniDocBench v1.6） | 纯 CPU | 典型场景 |
|---|---|---|---|---|
| pipeline | 快而稳、无幻觉 | 86.47 | 支持 | 大批量入库、机器资源有限 |
| vlm-engine | 高精度 | 95.30 | 不支持 | 复杂版面、精度优先 |
| hybrid-engine | 高精度 + 原生文本提取 + 低幻觉 | 95.39（high）/ 95.26（medium） | 不支持 | 精度与速度折中 |
两条补充经验。pipeline 后端无幻觉，代价是复杂版面上的精度低于 VLM 路线，但它连纯 CPU 环境都能跑，个人电脑和企业旧服务器照样能用。hybrid 的 medium 档位（3.3 起为默认值）相比 high 在 OmniDocBench v1.6 只低 0.13 分，速度却提升 35%~220%（官方 Changelog），日常文档用 medium 就够；对精度极度敏感或需要图片分析能力时再切 high。
集成矩阵：从 MCP 到无代码
官方 README 给出的集成矩阵基本覆盖当前主流的 LLM 工具链，四类场景各有入口：
| 使用场景 | 方案 |
|---|---|
| AI 编码工具 | MCP Server，接 Cursor、Claude Desktop、Windsurf |
| RAG 框架 | LangChain、LlamaIndex、RAGFlow、RAG-Anything、Flowise、Dify、FastGPT |
| 开发接入 | Python / Go / TypeScript SDK、CLI、REST API、Docker |
| 无代码 | mineru.net 在线版、Gradio WebUI、桌面客户端 |
这份矩阵的实际含义是：同一个解析引擎可以同时出现在个人编码工作流和企业数据管线里。具体接法在MinerU 的 RAG 与 MCP 集成指南里有完整展开。
版本演进：许可证是 3.x 最重要的变化
四个版本节点按时间线过一遍（均出自官方 Changelog）：
| 版本 | 发布日期 | 关键更新 |
|---|---|---|
| 3.0.0 | 2026-03-29 | 原生 DOCX 解析，相比先转 PDF 再解析端到端提速数十倍；pipeline 后端 OmniDocBench v1.5 得分 86.2 |
| 3.1.0 | 2026-04-18 | 许可证从 AGPLv3 升级为基于 Apache 2.0 的 MinerU Open Source License；主模型升级 MinerU2.5-Pro-2604-1.2B；原生支持 PPTX/XLSX |
| 3.3 | 2026-06-11 | hybrid 后端新增 effort 档位，默认 medium；VLM 升级 MinerU2.5-Pro-2605-1.2B |
| 3.4 | 2026-06-18 | pipeline 后端 OCR 模型升级 PP-OCRv6，OmniDocBench v1.6 上 OCR 精度提升约 11%、处理速度提升约 100%；模型下载自动选源 + 本地缓存复用 |
许可证变化值得单独讲。3.1 之前 MinerU 用 AGPLv3，这是强传染性许可证：企业把它包装成内部服务或云端产品时，法务通常要求开源修改部分，多数公司直接选择禁用。2026 年 3 月的 3.0.0 还顺手移除了两个 AGPLv3 模型（doclayoutyolo、mfd_yolov8）和一个 CC-BY-NC-SA 4.0 模型（layoutreader），先把依赖链清理干净。3.1.0 换成基于 Apache 2.0 的自定义许可证后，官方的说法是显著减少了社区用户和商业部署的采用阻力。对要在内网私有化部署文档解析服务的企业，这一步的意义与模型精度提升同等重要。
直接把 PDF 丢给多模态大模型，行不行
行，但有三个约束决定了它只适合轻量场景。成本上，长文档按页消耗多模态 token，整个知识库批量过一遍模型 API 的费用，远高于本地解析引擎的一次性部署加近乎零边际成本的解析。吞吐上，逐页调用 API 的速度撑不起”每晚增量入库数万页”这类任务。合规上，敏感合同、财报上传第三方 API 在金融、医疗、政务等行业往往直接过不了。本地解析引擎把重活留在内网完成，模型只消费解析后的干净文本，token 消耗也更省。至于解析质量与同类工具的横向对比，看这篇MinerU 对比 Marker、Docling、PaddleOCR。
常见问题
mineru 是什么？
MinerU 是 OpenDataLab 开源的文档解析引擎，把 PDF、DOCX、PPTX、XLSX、图片、网页转成 LLM 可用的 Markdown 和 JSON，GitHub Star 约 8 万，OCR 支持 109 种语言（官方 README）。常见用途是 RAG 知识库预处理与 Agent 语料准备，提供在线版、桌面客户端、pip、Docker 多种使用形态。
PDF 转 Markdown 用什么工具好？
解析扫描件、表格、公式密集的文档，MinerU 是开源阵营的主力选择之一；纯文本 PDF 用 pypdf 之类的轻量库抽文本就够，不必上解析引擎。具体选型差异（许可证、部署形态、中文效果）见本站 MinerU 与 Marker、Docling、PaddleOCR 的横评。
mineru github 仓库在哪，商用要授权吗？
仓库地址是 opendatalab/MinerU，Star 约 8 万（2026 年 9 月）。3.1.0 版本（2026-04-18）起许可证从 AGPLv3 改为基于 Apache 2.0 的 MinerU Open Source License，商用部署阻力比旧版小得多；具体条款以仓库 LICENSE.md 为准，正式商用前建议让法务过一遍。