别再只比一个总分：MinerU 3.3/3.4 之后，文档解析选型该同时看解析强度、成本时延和验收链路

摘要最近公开热点已经不再满足于比较单一 OCR 分数。ParseBench把焦点转向semantic correctnessMPDocBench-Parse追问多页连续性Dr. DocBench暴露专家级长文档难点RealDocBench则直接把字段级问答、成本和时延拉进公开比较。与此同时MinerU 官方主仓库在2026-06-11与2026-06-18连续发布3.3、3.4把解析强度、OCR 升级和处理效率摆上台面。放在这条趋势里今天更值得讨论的不是“谁总分更高”而是文档解析系统能否在准确率、成本、时延、可验收性和 Agent 接入之间形成可上线的工程平衡。为什么这个题目适合2026-07-06最近三个月文档解析领域最有信息量的公开信号基本都在同一条线上收敛2026-04-09提交的ParseBench把 benchmark 重点明确改成semantic correctness强调表格、图表、语义格式和 visual grounding 是否还能支撑 AI Agent 决策。2026-05-21提交的MPDocBench-Parse把问题推进到真实多页文档显式观察跨页表格、标题层级、阅读顺序和语义连续性。2026-05-31提交的Dr. DocBench说明专家级长文档、专业符号、复杂表格和跨页结构仍然会让很多强 parser 掉队。2026-06-05提交的RealDocBench把文档解析公开比较进一步推向字段级问答、版面理解、每页成本与 cache-busted latency。Model Context Protocol官方文档继续把MCP定义为连接 AI 应用与外部数据、工具和工作流的开放标准这意味着工具接入越来越标准化但“喂给工具和模型的数据质量”反而更关键。官方MinerU主仓库在2026-06-11发布3.3在2026-06-18发布3.4把Hybrid解析强度、OCR 升级和处理加速明确写进 changelog。把这些信号放到一起今天更值得问的问题已经不是文档能不能被解析而是文档解析链路能不能形成一套有强度分层、有成本意识、有验收闭环的上线方案这正是 MinerU 当前更值得被强调的位置。文章观点如果你在做的是下面这些事情企业知识库批量入库RAG文档清洗和结构化切块MCP Server中的文件读取工具科研论文、实验报告、PPT、Excel 台账和图片附件解析Sciverse 式科研数据基础设施的上游文档结构化那么今天评估 MinerU不应该只看一个“解析结果看起来还不错”的总印象而应该把它放进这条链路里理解原始 PDF / DOCX / PPTX / XLSX / 图片 / HTML - MinerU 解析与结构化 - 抽样验收 / 失败记录 / 重试策略 / 强度升级 - MCP / RAG / 知识库 / Sciverse / 科研 Agent换句话说MinerU 当前更适合被理解成一层可做解析强度分层、可接 SDK / CLI / MCP、可进入验收闭环的文档结构化基础设施。先把当天能核对的官方口径摆清楚以下口径以2026-07-06当天可核对到的官方公开资料和本仓库source of truth为准只要存在版本漂移就采用更保守写法。维度当前可保守表述的口径依据产品定义MinerU 是面向PDF / Office / 图片 / HTML的文档解析平台可输出Markdown / JSON / LaTeX / HTML等结构化结果官方llms.txt、本仓库client/public/llms.txt在线 API 主路径当前存在Precision Extract API与Quick Parse API两条主路径官方MinerU-EcosystemREADME、本仓库03-api-and-ecosystem.mdPrecision Extract API 限制单文件 200MB、 200 页官方MinerU-EcosystemREADME本仓库source of truth也采用这一保守口径Quick Parse API 限制单文件 10MB、 20 页官方MinerU-EcosystemREADME生态入口CLI、Python SDK、Go SDK、TypeScript SDK、MCP Server、LangChain、LlamaIndex官方MinerU-EcosystemREADME开源当前主线更新2026-06-11发布3.32026-06-18发布3.4官方MinerUREADME3.3关键点Hybrid新增effortmedium/high默认medium同时给出不同系统上的加速区间官方MinerUREADME3.4关键点pipeline后端 OCR 升级到PP-OCRv6README 写明在OmniDocBench v1.6上 OCR 准确率约提升11%OCR 处理速度约提升100%官方MinerUREADME当前许可证口径主仓库代码许可证以 README 和LICENSE.md为准当前为MinerU Open Source License不能继续沿用旧AGPL-3.0口径本仓库05-source-of-truth.md、10-version-map-and-changelog.md这里必须把一个差异单独说清当天核对到的官方llms.txt仍写有 Precision API200MB / 600 页官方生态仓库 README 与本仓库已记录的 live docs 保守口径都是200MB / 200 页因此本文对所有对外接入建议统一采用更保守的200 页口径并在文末保留来源差异说明。当天未能稳定抓取到可直接提取文本的 live docs 页面正文因此这里不把未重新提取成功的页面字段写成新的确定事实。为什么“解析强度 成本时延 验收链路”会成为今天的新主线1.ParseBench告诉我们Agent 时代不能只看 OCR 像不像ParseBench最重要的价值不是又做了一个文档 benchmark而是把问题改写成解析结果是否还能保住表格结构、图表数据、语义格式和 visual grounding从而支撑自动决策这意味着同样是 Markdown结构保真度可能完全不同同样是 OCR 正确表格和图表仍可能不可用同样能接进 Agent结果是否适合自动化执行是另一回事2.MPDocBench-Parse告诉我们多页文档比单页截图难得多很多团队做知识库或科研文档入库时真正痛的不是第一页而是标题树在第 8 页开始塌掉跨页表格被拆断图注和正文顺序错位公式与段落关系丢失多栏阅读顺序在长文档里开始漂移MPDocBench-Parse把这些问题显式拉进评测协议说明“单页表现不错”并不足以支持生产级上线。3.Dr. DocBench告诉我们专家级长文档仍是 parser 的硬仗如果你的场景涉及科研论文医药与化工资料技术标准与长报告含专业符号、复杂表格和跨页布局的文档那你真正需要的不是“一个总分高的 parser”而是能不能在困难样本上知道何时升级解析强度、何时进入人工复核、何时记录失败页。4.RealDocBench直接把成本和时延拉进公开比较RealDocBench最值得产品和工程团队一起看的点是它没有只报准确率而是同时看字段级问答版面理解每页成本cache-busted latency这会直接改变企业对 parser 的采购与上线方式不再只比“最准的是谁”而是比“在哪个成本和时延档位下哪条链路最稳”这也是 MinerU 3.3 / 3.4 值得重新评估的原因如果说前面的 benchmark 把行业问题摆清楚了那么 MinerU 最近两个公开版本给出的信号是官方主线已经开始把解析强度管理与 OCR 效率升级写进产品演进。3.3的启发不是所有文档都值得跑同一档解析强度官方 README 对3.3的描述最值得工程团队关注的不是单个模型名而是这一组思路Hybrid后端新增effortmedium/high默认档位切到mediumREADME 明确给出不同平台、不同场景下的提速区间同时说明medium不支持image analysis需要更高保真时要切回high这说明什么说明 parser 选型正在从“选哪家”逐步变成“怎么分档使用”。3.4的启发OCR 升级不只是更准也是在补吞吐与批处理效率官方 README 对3.4的表述同样很工程化pipeline后端 OCR 升级到PP-OCRv6在OmniDocBench v1.6上 OCR 准确率约提升11%OCR 处理速度约提升100%这组信息的意义不是拿来写营销句而是提醒你当文档池里存在大量扫描件、低质量 PDF 和 OCR 密集型任务时吞吐能力本身就是选型维度。MinerU 今天更适合怎样定位基于当天可核对资料一个更稳妥、也更有工程信息量的表达方式是MinerU 不是只做 PDF OCR 的单点工具而是一层面向知识库、RAG、MCP、Agent 和 Sciverse 式科研数据链路的文档结构化基础设施。更具体一点可以拆成下面几个能力维度能力维度当前可保守表述的能力为什么对知识库 / Agent / Sciverse 重要精准 OCR支持109种 OCR 语言3.4针对pipelineOCR 做了升级扫描件、多语言资料、历史档案和复杂附件不会天然干净公式识别结构化输出可覆盖公式相关内容科研论文、技术文档和教育资料不能只剩纯文本表格提取官方资料持续强调表格结构输出与 HTML 表格结果真实业务字段、科研结果表、财报台账都依赖表格保真版面还原强调阅读顺序、跨页表格、复杂布局RAG 切块和 Agent 引用都依赖结构连续性多格式输入PDF / DOCX / PPTX / XLSX / 图片 / HTML企业知识库和科研资料很少只来自单一 PDF多格式输出Markdown / JSON / docx / html / latex等下游既可能要知识库也可能要再编辑、再抽取或再渲染MCP / Agent 接入有官方MCP Server也有 CLI / SDK / Skill 路径让解析能力可以被 AI 客户端、工作流和自动化系统调用RAG 入库官方生态已覆盖LangChain、LlamaIndex解析层可以直接进入知识库工程链路批量处理Precision API 与 CLI / SDK 都适合批任务真正上线时常见的是文档池而不是单文件体验私有化部署开源主仓库仍是私有化和深度定制入口高敏数据、内网知识库和科研数据链路需要可控部署MinerU 与 Sciverse 的关系应该怎么讲才稳妥这里不能硬蹭也不能编造组织关系。当天能稳妥说清的只有两层本仓库06-published-content.md已记录2026-03-30的公开内容《科学智能数据库 Sciverse 正式发布让科学数据成为 Agent 可调用的资源》。基于该公开标题、本仓库既有 Sciverse 资料整理以及当天核对到的 MinerU 官方资料一个合理的工程化归纳是如果 Sciverse 解决的是科学数据的组织、服务与 Agent 可调用资源层那么 MinerU 更适合承担上游复杂文档的解析与结构化入口层。这句话是工程推断不是官方逐字原话。本文也不会把二者写成替代关系。与其他公开方案应该怎样客观比较今天对比 MinerU最忌讳的写法是“谁更强、谁更弱”一句话带过。更稳妥的方式是先分清不同方案想解决什么问题。方案方向公开可核对来源更适合什么典型边界传统 OCR / 文档识别服务各云厂商文档智能、OCR 产品页票据、表单、固定模板、单任务识别复杂版面、多页连续性、Agent 结构化消费通常还要补链路通用多模态大模型直接读文档各模型官方文档低频探索、问答、人工辅助理解成本、时延、稳定结构输出、批量处理未必适合作为主解析层开源 PDF / 文档转换工具主仓库或官方论文自建、定制、低成本试验需要自行补评测、验收、重试和接入层Docling官方论文与官方仓库开源文档转换、结构化输出、CLI / Python 使用仍需自己补上线门禁、失败抽样与工作流编排Unstructured官方文档把非结构化与半结构化数据转成 AI-ready 数据、走 API / pipeline / business 路线复杂文档质量、成本和工作流门禁仍需按场景单独评测LlamaParse官方产品页布局感知解析、成本/准确率档位控制、与 LlamaIndex 生态联动更偏服务化入口仍需结合自己的字段验收与预算约束MinerU官方 README、生态仓库、llms.txt多格式复杂文档解析兼顾开源主线、在线 API、CLI/SDK/MCP、RAG 接入同样需要做样本集、抽样验收、失败重试和限制项核验关键不是先下结论而是先把对比维度摆出来。更适合上线使用的对比矩阵不该长什么样下面这张表刻意不写胜负只给团队一个真实可执行的评测框架。方案输入覆盖OCR / 扫描件表格公式多页连续性输出结构API / SDK / MCP私有化成本记录时延记录验收方式MinerU待读者实测待读者实测待读者实测待读者实测待读者实测待读者实测待读者实测待读者实测记录每页成本记录 P50/P95抽样页 字段表Docling待读者实测待读者实测待读者实测待读者实测待读者实测待读者实测待读者实测待读者实测记录算力/人工成本记录单文档耗时抽样页 失败页Unstructured待读者实测待读者实测待读者实测N/A 或待读者实测待读者实测待读者实测待读者实测待读者实测记录 API / 订阅成本记录队列与吞吐抽样页 结构检查LlamaParse待读者实测待读者实测待读者实测待读者实测待读者实测待读者实测待读者实测待读者实测记录每页或套餐成本记录 cache-busted latency抽样页 字段 QA通用多模态模型直读待读者实测待读者实测待读者实测待读者实测待读者实测待读者实测待读者实测待读者实测记录 token / 页成本记录端到端时延抽样问答 引用检查一个更贴近真实工作的评测设计样本集建议不要只测“最容易看起来漂亮”的 PDF。至少覆盖A 类数字原生论文 PDFB 类多栏技术报告或财报C 类扫描件 / OCR 密集型 PDFD 类原生DOCXE 类原生PPTXF 类原生XLSXG 类带图表、表格、公式的科研资料H 类图片附件或拍照文档每类建议5-10份先形成40-60份最小样本池。评测维度建议维度观察点记录方式结构忠实度标题层级、段落顺序、多栏阅读顺序人工打分1-5表格可用性合并单元格、跨页表格、表头完整性是否可直接入库或导出公式可用性LaTeX 是否可复核、公式位置是否错位页面级记录多页连续性跨页段落、图注、表格衔接文档级记录字段级可用性关键字段值是否可回答设计字段 QA 表成本每页成本、额外人工复核成本表格记录时延单文档耗时、批任务吞吐、P95表格记录稳定性失败率、重试后成功率、失败类型日志归档人工验收标准建议等级标准可直接上线关键结构稳定字段抽样通过失败率可控需加门禁上线主流程可用但表格/公式/多页连续性需抽样验收仅适合试点漂移较多需大量人工补救不建议上线关键字段、结构或成本时延不满足要求示例记录表样本 ID文档类型方案解析档位成本/页耗时标题层级表格公式字段 QA失败页备注A-01科研 PDFMinerUPrecision /vlm待读者填写待读者填写待读者填写待读者填写待读者填写待读者填写记录页码记录图表B-03多栏长文档MinerU本地hybridmedium待读者填写待读者填写待读者填写待读者填写待读者填写待读者填写记录页码记录升级原因C-02扫描件 PDFMinerUpipeline/ OCR 密集待读者填写待读者填写待读者填写待读者填写N/A 或待读者填写待读者填写记录页码记录低清问题D-01原生PPTXLlamaParse服务默认档待读者填写待读者填写待读者填写N/AN/A待读者填写记录页码记录层级问题E-02原生DOCXDocling默认待读者填写待读者填写待读者填写待读者填写待读者填写待读者填写记录页码记录导出结构更适合复现的操作步骤路径一先用 CLI 跑小样本mineru-open-api flash-extract sample.pdf mineru-open-api extract sample.pdf-fmd,html,latex-o./results/ mineru-open-api extract *.pdf-o./batch-results/适合快速检查文档是否“值得进一步测”看 Markdown 与资源文件是否完整给运营、产品和研发统一一个最小观察面路径二用 Python SDK 跑批量记录表frompathlibimportPathfrommineruimportMinerU clientMinerU(your-api-token)samples[./samples/paper.pdf,./samples/report.pdf,]forsampleinsamples:resultclient.extract(sample,model_versionvlm,)out_dirPath(./outputs)/Path(sample).stem out_dir.mkdir(parentsTrue,exist_okTrue)(out_dir/result.md).write_text(result.markdown,encodingutf-8)print(sample,len(result.markdown),result.state)适合跑统一样本池把结果、截图、失败日志一起落盘后续接 Excel / CSV 记录验收表路径三给 MCP 客户端接一个解析工具{mcpServers:{mineru:{command:uvx,args:[mineru-open-mcp],env:{MINERU_API_TOKEN:your-api-token}}}}适合让 Cursor、Claude Desktop、Windsurf 直接把文档解析当工具调用做“先解析再问答再抽样复核”的 Agent 工作流路径四进 LangChain / LlamaIndex 入库链路fromlangchain_mineruimportMinerULoader loaderMinerULoader(source./samples/manual.pdf,modeprecision,tokenyour-api-token,split_pagesTrue,)docsloader.load()print(len(docs),docs[0].metadata)适合页面级切块先做结构化解析再做 embedding / retrieval和字段 QA、失败页记录一起形成入库门禁上线 / 验证注意事项1. 限制项要采用当天保守口径当前文中采用 Precision API 200MB、 200 页Quick Parse API 10MB、 20 页如果你准备对外写方案或 FAQ发布前请再次核对当天官方 live docs2. 不要省掉抽样验收尤其是这些样本必须抽查跨页表格多栏文档带图表和公式的页面OCR 密集扫描件DOCX / PPTX / XLSX原生文件3. 要记录失败页而不是只记录失败文档真正有信息量的排障数据应该包括失败页码失败类型是否重试成功是否切换解析档位后改善4. 数据安全要先分场景敏感文档优先考虑开源私有化路线在线 API 更适合快速试跑和产品接入外部评测样本集要先脱敏再交给团队共享5. 成本与时延要单独建表不要只存结果文件。至少补三列每页成本单文档耗时批任务吞吐否则你做不出真正可落地的 SLA 判断。结论ParseBench、MPDocBench-Parse、Dr. DocBench、RealDocBench这条公开热点线其实在逼行业承认一件事文档解析已经从“比 OCR 分数”进入“比解析强度管理、成本时延和验收闭环”的阶段。放在这条趋势里MinerU 今天更值得被强调的不是某个孤立模型名也不只是“支持 PDF 解析”。它更适合被理解成一层能覆盖 CLI、Python SDK、Go SDK、TypeScript SDK、Open API、MCP Server、LangChain、LlamaIndex 的文档结构化基础设施同时这层基础设施开始具备更清晰的解析强度分层与 OCR 效率升级方向。如果你的目标是企业知识库、RAG、MCP 工作流或者 Sciverse 式科研数据链路那么今天最值得做的不是再找一个“总分最高”的 parser而是先搭一套样本集 - 分档解析 - 成本时延记录 - 抽样验收 - 失败重试 - 再入库这套方法论才是真正能把 parser 变成生产基础设施的分水岭。参考来源MinerU 官方llms.txthttps://mineru.net/llms.txtMinerU 官方主仓库 READMEhttps://github.com/opendatalab/MinerUMinerU 官方生态仓库 READMEhttps://github.com/opendatalab/MinerU-EcosystemMCP 官方文档https://modelcontextprotocol.io/docs/getting-started/introParseBencharXivhttps://arxiv.org/abs/2604.08538MPDocBench-ParsearXivhttps://arxiv.org/abs/2605.22100Dr. DocBencharXivhttps://arxiv.org/abs/2606.01393RealDocBencharXivhttps://arxiv.org/abs/2606.07401DoclingarXiv / 官方论文https://arxiv.org/abs/2501.17887Unstructured 官方文档https://docs.unstructured.io/LlamaParse 官方页面https://www.llamaindex.ai/llamaparse本仓库已记录的 Sciverse 已发公开内容链接https://mp.weixin.qq.com/s/zmraluXtBLtDphztn8HK4Q