MinerU 评测：把 PDF 和 Office 文档变成 LLM 可用的 Markdown，值得换掉你的解析工具吗
将 PDF、Office 文档与图片转换为可供 LLM 使用的 Markdown 或 JSON，采用 VLM+OCR 双引擎，覆盖 109 种语言、公式与复杂版面。
秒懂
- 它是什么？
- MinerU 是一款把 PDF、DOCX、PPTX、XLSX 和图片解析成结构化 Markdown 或 JSON 的开源引擎，面向 RAG 和 Agent 工作流。它提供 pipeline、vlm-engine 和 hybrid-engine 三种后端，但 4.0 仍在预发布阶段，许可证也不明确。
- 适合谁用？
- MinerU 适合需要把大量混合格式文档（扫描件、多栏 PDF、Office 文件）批量转成结构化文本的团队，尤其是已经用 LangChain、Dify 或 FastGPT 搭建 RAG 管线的开发者。它不适合只需要简单文本提取、或者对部署体积和模型下载敏感的场景，因为模型下载和 GPU 推理是绕不开的成本。
- 能商用吗？
- 请先确认。这个仓库使用的许可证不在我们自动归类的范围内，商用前请阅读仓库里的 LICENSE 文件。
- 还在维护吗？
- 在维护。仓库最近一次提交在 1 天前。
- 用什么语言写的？
- 主要是 Python（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
它解决什么问题，谁需要它
MinerU 解决的问题很具体：PDF、DOCX、PPTX、XLSX、图片和网页这些格式，不能直接喂给大模型。它们内部有版面、表格、公式、页眉页脚，直接转纯文本会丢失结构，RAG 检索和 Agent 工具调用都会变差。MinerU 的目标是把这些复杂文档转成 Markdown 或 JSON，并且保持人类阅读顺序，去掉页眉页脚，表格转成 HTML，公式转成 LaTeX。它面向的是搭建 RAG 管线、Agent 工作流或者需要批量处理文档的工程师，不是普通办公用户。如果你只是偶尔转一个 PDF，用在线版或者桌面客户端更省事，README 里也指向了 mineru.net 的零安装网页版。
三种后端，三个不同的取舍
MinerU 的核心设计是三种可切换的推理后端。pipeline 后端是传统 OCR 加版面分析，文档说它快速稳定、无幻觉，支持 CPU 和 GPU。vlm-engine 用视觉语言模型，精度更高，支持 vLLM、LMDeploy 和 mlx 生态。hybrid-engine 混合两者，宣称在高精度同时保留原生文本提取，减少幻觉。这个设计意味着用户不是选一个工具，而是选一个精度和速度的平衡点。3.3 版本给 hybrid 后端加了 effort 参数，medium 和 high 两档。medium 在 OmniDocBench v1.6 上只比 high 低 0.13 个精度点，但在不同平台上快了 35% 到 220%。默认值改成了 medium，因为它不支持图像分析，要完整功能就得切到 high。这个取舍很实在，文档没有回避 medium 的局限。
从安装到跑通：命令和配置
README 没有给出完整的安装命令，但项目发布在 PyPI 上，包名是 mineru，安装方式应该是 pip install mineru。文档提到模型下载逻辑在 3.4 版本做了优化，首次安装会根据网络环境自动选择模型源，也会优先检查本地缓存。模型源配置有专门文档页，路径是 opendatalab.github.io/MinerU/usage/model_source/。这意味着安装后第一次运行会下载模型，网络不好时可能需要手动指定源。CLI 和 Python SDK 都提供，README 列了 Python、Go、TypeScript 三种 SDK，以及 REST API 和 Docker 部署方式。实际跑通一个文件，大概就是命令行指向输入文件，输出 Markdown 或 JSON，但具体参数没有在 README 里展开，需要看官方文档。
集成方式：MCP 和 RAG 框架
MinerU 的集成面很宽。它提供 MCP Server，可以直接接进 Cursor、Claude Desktop 和 Windsurf 这类 AI 编程工具。RAG 框架方面，README 列出了 LangChain、LlamaIndex、RAGFlow、RAG-Anything、Flowise、Dify 和 FastGPT。这意味着你可以在 Dify 里把 MinerU 当作文档解析节点，或者在 LangChain 里调用它的 SDK。这种集成深度是它区别于普通 PDF 转文本库的地方。不过要注意，这些集成大多是官方适配或者社区贡献，实际使用时还需要自己处理模型部署和错误处理。如果你只用 LangChain 的 PDF loader，可能不需要引入 MinerU，但如果你要处理扫描件和复杂版面，MinerU 的结构化输出会更有价值。
OCR 能力：109 种语言和 PP-OCRv6
OCR 是 MinerU 的重头戏。3.4 版本把 pipeline 后端的 OCR 模型升级到 PP-OCRv6，在 OmniDocBench v1.6 上精度提升约 11%，处理速度提升约 100%。同时，它移除了日语、繁体中文、英语和拉丁语的独立语言选项，这些场景统一路由到 ch 模型。这个改动简化了配置，但代价是如果你之前依赖特定语言模型，现在只能接受统一模型。文档说 VLM 模型 MinerU2.5-Pro-2605-1.2B 增加了原生多语言 OCR，减少额外语言参数配置。这意味着多语言文档在 vlm-engine 下开箱即用，但 pipeline 后端的语言选择变少了。对于小语种文档，这可能是个限制，你需要测试自己的语料。
已知的限制和失败模式
MinerU 不是万能的。medium 力度不支持图像分析，这是文档明确写的。如果你需要解析文档里的图片内容，必须用 effort=high，这会牺牲速度。另外，模型下载是首次使用的必经步骤，虽然 3.4 优化了缓存和源选择，但在离线环境或者内网部署时，你仍然需要提前准备模型文件。README 提到支持 10 多种国产 AI 芯片，包括昇腾、寒武纪、沐曦等，但具体配置细节没有展开，实际部署可能需要额外适配。还有一个隐患是许可证：README 的 3.1.0 更新提到许可证升级，但仓库信息里许可证字段是 unknown，这意味着你在商业产品中集成 MinerU 之前，必须去官方文档确认当前许可证的具体条款，尤其是是否允许商用和修改。
维护成本和升级路径
MinerU 的发布节奏很快，从 2026 年 4 月的 3.1.0 到 8 月的 4.0.0a6，不到半年就有多个大版本。4.0 还是 alpha 阶段，说明功能还在变动。这意味着如果你在生产环境使用，升级可能会带来行为变化，比如 3.4 移除了 OCR 语言选项，3.3 改了默认 effort 级别。每次升级都要重新跑一遍你的测试文档集。模型下载也是维护成本的一部分，模型文件大，版本更新后可能需要重新下载。好在 3.4 加了缓存复用，减少重复下载。如果你用 Docker 部署，镜像体积会很大，因为要包含模型。如果你用 API 服务，可以避开这些，但要付费。
替代方案和选择依据
和 MinerU 最直接的对比是 PyMuPDF 或 pdfplumber 这类轻量 PDF 文本提取库。它们没有模型下载、没有 GPU 依赖，安装即用，但只能处理文本型 PDF，对扫描件和复杂版面无能为力。另一个方向是云服务，比如 README 里提到的 mineru.net 在线版，它省去部署，但数据要出内网。MinerU 的价值在于把 OCR、版面分析、公式识别和表格重建整合到一个工具里，输出格式直接对接 LLM。如果你的需求只是从 PDF 里抽几段文字，用 PyMuPDF 就够了，不需要引入模型推理的开销。但如果你要处理的是混合格式的文档库，MinerU 的结构化输出能省掉很多后处理工作。选择的关键在于你的文档复杂度和对数据隐私的要求。
编辑结论
MinerU 适合需要把大量混合格式文档（扫描件、多栏 PDF、Office 文件）批量转成结构化文本的团队，尤其是已经用 LangChain、Dify 或 FastGPT 搭建 RAG 管线的开发者。它不适合只需要简单文本提取、或者对部署体积和模型下载敏感的场景，因为模型下载和 GPU 推理是绕不开的成本。在采用前，先确认你的文档语言和版面复杂度是否能被默认的 OCR 模型覆盖，检查 4.0 预发布版的稳定性，并明确你的分发方式是否与未来确定的许可证兼容。MinerU 的路线图表明它正在从单一解析工具走向多后端、多芯片的生态，但 3.4 和 4.0 之间的差异说明，正式版发布前仍有关键功能在变动。
社区笔记