先说一个搞 RAG 的人都头疼过的问题。
你拿到一份 50 页的 PDF，里面有双栏排版、有公式、有跨页表格、有扫描的图片。你想把它喂给大模型做问答，结果发现，不管用什么解析工具，输出要么是一坨乱序的文本，要么表格变成一堆换行符，公式直接变成乱码。
PDF 解析，是 RAG 和 Agent 工作流里最不起眼但最要命的一环。模型再强，喂进去的是垃圾，出来的也只能是垃圾。
opendatalab/MinerU 就是专治这个的。截止 2026 年 6 月 28 日 ，7.12 万 Star，5989 Fork。它把 PDF、图片、DOCX、PPTX、XLSX 这些复杂的文档，解析成结构化的 Markdown 和 JSON，专门给下游的 LLM、RAG、Agent 用。
这个 Star 数放在文档解析这个细分领域，是统治级的。
它解决的核心问题，是「版面还原」
很多人对 PDF 解析的理解还停留在「抽文本」。就是把 PDF 里的文字提取出来，按顺序排好就行。
这个理解对纯文本 PDF 大致成立，但对真实的复杂文档完全不成立。
你想想看，一篇学术论文，左边是正文，右边是图表说明，底下是脚注，中间还插着跨两栏的大表格。你按「从左到右、从上到下」抽文本，读出来的顺序是错乱的。正文和图表说明混在一起，表格被打散成碎片。
MinerU 解决的就是这个，它做的是版面还原。它先用模型识别文档的版面结构，哪里是标题、哪里是段落、哪里是表格、哪里是图片、哪里是页眉页脚，然后按人类的阅读顺序重新组织输出。它还会自动去掉页眉、页脚、脚注、页码这些干扰语义的部分。
输出的格式也很讲究。不只是 Markdown，还支持按阅读顺序排序的 JSON，以及富中间格式。公式自动转成 LaTeX，表格自动转成 HTML，图片、图片描述、表格标题、脚注都会单独提取出来。
这才是 LLM 能消化的输入。
双引擎，是它和同类工具拉开差距的地方
MinerU 最核心的技术决策，是它搞了两套解析引擎，让你按需选。
第一套叫 pipeline ，传统管线。它用版面分析模型识别布局，用 OCR 模型识别文字，用公式检测模型识别公式，各司其职。这套引擎的好处是兼容性好、不幻觉，能在纯 CPU 上跑，最低 4GB 显存、16GB 内存就能用。在 OmniDocBench v1.6 这个权威评测上，它拿到 86.47 分。
第二套叫 vlm-engine ，用视觉语言模型直接「看」文档。准确率更高，high 模式 95.39 分，但需要 GPU，最低 8GB 显存。还有一套 hybrid-engine，把两者的优点结合起来，高精度的同时保留原生文本提取，降低幻觉。
这三套引擎的取舍很清楚。
| 引擎 | 准确率 | 硬件要求 | 特点 |
|---|---|---|---|
| pipeline | 86.47 | 纯 CPU 可跑 | 兼容性好，不幻觉 |
| hybrid | 95.26-95.39 | 需 GPU 8GB | 高精度，低幻觉 |
| vlm | 95.30-95.39 | 需 GPU 8GB | 纯 VLM，最高精度 |
v3.3 还引入了一个很聪明的 effort 参数，medium 和 high 两档。medium 比 high 准确率只低 0.13 分，但在 macOS 上文本 PDF 场景快了 220%。默认就用 medium，兼顾精度和速度，要极致精度再切 high。这种「给你选择权」的工程哲学，比一刀切强太多。
它的进化速度，快得有点吓人
我翻了它的 changelog，这个项目的迭代节奏可以用疯狂来形容。
2024 年 2 月创建，到现在两年多，已经发了 175 个 release。光 2026 年 6 月这一个月，就发了 3.4、3.3、3.1.0、3.0.0 四个大版本。
几个关键节点值得说。
3.0.0，系统架构升级。 它把自己从「一个解析工具」变成了「一个解析基础设施」。加了 mineru-router 做多服务多 GPU 的统一入口和任务负载均衡，支持一键多卡部署。长文档解析用滑动窗口机制，把峰值内存压下来，几万页的文档不用再手动切分。线程安全优化后支持多线程并发推理。这是从「单机工具」到「企业级基础设施」的跨越。
3.1.0，协议松绑。 这是个大事。它从 AGPLv3 换成了基于 Apache 2.0 的自定义开源协议。AGPLv3 那个「网络服务也要开源」的条款，把很多商业团队吓跑了。换成 Apache 2.0 系，商业部署的摩擦大幅降低。同时原生支持了 PPTX 和 XLSX 解析，凑齐了主流文档格式。
3.4，OCR 大升级。 pipeline 后端的 OCR 模型升级到 PP-OCRv6，准确率提升约 11%，处理速度提升约 100%。
这种迭代密度，背后是 OpenDataLab 这个团队在持续投入。它脱胎于 InternLM 大模型的预训练过程，本来就是为「给大模型喂数据」这个刚需而生的。
生态集成，是它的隐藏壁垒
一个文档解析工具，光解析得好还不够，得能接进工作流。MinerU 在这点上铺得很广。
AI 编程工具，它提供了 MCP Server，能直接接进 Cursor、Claude Desktop、Windsurf。你在这些工具里就能调用 MinerU 解析文档。
RAG 框架，原生集成 LangChain、LlamaIndex、RAGFlow、Dify、FastGPT。这意味着你搭 RAG 管线的时候，MinerU 可以直接当文档加载器用。
开发接口，Python/Go/TypeScript SDK、CLI、REST API、Docker，全都有。无代码的方案也有，在线版 mineru.net、Gradio WebUI、桌面客户端。
还有一个细节让我觉得这个团队很务实，它支持10 多种国产 AI 芯片。华为昇腾、寒武纪、燧原、摩尔线程、昆仑芯、海光、壁仞，全列出来了。在国内信创的大环境下，这个支持的含金量不用多说。
解析是概率任务，硬件和协议也有坑
这个项目很强，但有几个地方得诚实面对。
第一，文档解析天生是个「概率任务」，不是 100% 准确的。 README 里有一句很坦诚的话，说文档解析是困难且复杂的任务，在复杂版面、扫描件、手写内容场景下，解析结果可能达不到预期。它甚至建议你先用在线 demo 评估效果，再决定怎么部署。这种诚实比吹嘘强一百倍。
第二，高精度引擎的硬件门槛不低。 pipeline 能在纯 CPU 跑，但 hybrid 和 vlm 要 GPU，最低 8GB 显存，内存推荐 32GB。如果你的文档量大且要高精度，硬件成本是实打实的。
第三，非主线环境不保证。 它明确说只在特定软硬件环境下优化和测试。Linux 只支持 2019 年以后的发行版，Windows 因为依赖 ray 不支持 Python 3.13，macOS 要 14.0 以上。冷门环境出问题，它不背锅。
第四，License 虽然宽松了，但不是纯 Apache 2.0。 它是「基于 Apache 2.0 的自定义协议」，商用前最好读一下 LICENSE.md 的具体条款，别想当然。
瓶颈正在从模型转移到数据质量
我一直觉得，大模型时代有个被低估的工种，叫「数据工程师」。
所有人都在卷模型、卷参数、卷 benchmark，但很少有人愿意沉下心去处理「怎么把现实世界乱七八糟的文档，变成模型能吃的数据」这种脏活。MinerU 就是干这个脏活的，而且干到了 7.1 万 Star。
它背后揭示的一个判断值得提炼出来，Agent 工作流的天花板，正在被数据质量而不是模型能力锁死。你的 Agent 能不能准确回答一份合同里的条款，不取决于模型多聪明，取决于你喂给它的合同文本是不是结构化、是不是保真、有没有把表格和公式解析对。这个判断可以迁移到任何 RAG/Agent 选型，在追更强的模型之前，先问一句喂进去的数据是不是干净、是不是保真。模型是乘数，数据是基数，基数是零，乘数再大也是零。
MinerU 给出的答案是双引擎加版面还原，把 PDF 这种「为打印设计、反人类解析」的格式，翻译成 LLM 友好的 Markdown。听起来不性感，但它是 RAG 和 Agent 真正落地的那块地基。
如果你在做 RAG、在做 Agent、在做任何需要处理真实文档的 AI 应用，这个工具值得放进你的工具箱。那个 86 分到 95 分的准确率跨度，可能就是你应用从「勉强能用」到「真的好用」的距离。