为什么今天值得写这个题如果你最近还在把文档解析理解成“谁 OCR 更准”这周已经有点跟不上讨论焦点了。过去两个月公开研究里有一条很清楚的线2026-04-09的ParseBench开始把文档解析评测往 Agent 可用性上拉强调表格、图表、内容忠实度、语义格式和视觉 grounding。2026-05-21的MPDocBench-Parse把问题推进到多页文档重点检查跨页表格、标题层级、阅读顺序和语义连续性。2026-05-24的MinerU-Popo进一步说明光有页级 OCR 或页级解析还不够后面还要补文档级 post-processing。2026-06-10的ParseFixer则把话说得更直接工程上不一定要重写整条解析链而是可以先跑稳定 backbone再做 selective correction。与此同时官方MinerU仓库在2026-06-11更新到3.3重点放在Hybrid解析性能优化与 VLM 能力升级。这说明另一个现实一边是 parser 主干继续进化另一边是大家开始认真补“校正层”和“验收层”。这篇文章想回答的不是“MinerU 强不强”这种空问题而是更贴近落地的三个问题为什么最近文档解析开始转向“校正层”思路。MinerU 在这波趋势里更适合扮演什么角色。如果你今天做企业知识库、RAG、MCP 或科研资料处理怎样用一套不伪造跑分的方法验证它。先给结论如果你做的是企业知识库、科研数据处理或 Agent 文件读取MinerU 更适合被放在稳定解析 backbone 质量门禁入口 必要时再补 selective correction而不是被理解成“跑一次 OCR 就完事”的单点工具。原因很简单近期 benchmark 已经不再只盯字符识别而是盯结构和语义可用性。多页文档、跨页表格、标题树和图文关系天然需要后处理。真正上线时最昂贵的不是“慢一点”而是“看起来有结果实际上把下游 RAG 和 Agent 带偏”。所以今天更有价值的架构不是文档 - parser - 直接入库而是文档 - MinerU 解析 - 质量门禁 - 选择性校正 - 入库 / MCP / RAG最近公开热点在说什么1.ParseBench讲的是“Agent 视角的解析正确性”ParseBench的重点不是 OCR 字符相似度而是 Agent 真正在乎的五类能力表格是否还能消费图表数据是否还可信内容是否忠实语义格式是否保留视觉定位是否还能回指这对 MinerU 这类工具的启发是输出Markdown本身不值钱Markdown是否还能进入自动化流程才值钱。2.MPDocBench-Parse讲的是“多页文档不是单页解析的简单叠加”很多系统单页表现不差但一到真实长文档就会暴露问题跨页段落断裂跨页表格散掉标题层级错乱阅读顺序被双栏或页边元素打乱这也是为什么企业知识库和科研论文处理比普通 OCR 更难因为它们真正依赖的是文档级连续性。3.MinerU-Popo讲的是“post-processing 是独立问题”MinerU-Popo的思路很有代表性先复用现有 OCR 或 parser 输出再做四类文档级恢复截断文本恢复截断表格恢复标题层级重建图片与文本关系恢复这意味着 parser 主干再强也不代表你可以省掉后处理。4.ParseFixer讲的是“别逢错必重跑整页先做 selective correction”ParseFixer的公开摘要非常贴近工程现实先跑稳定的 full-page backbone parsing再识别高价值失败点只修该修的位置如果修坏了还能 verify-and-rollback这个思路尤其适合企业场景因为企业最怕的是全量重算太贵局部错误会污染后续审批或知识库人工验收成本太高但又不能彻底省掉截至 2026-06-15MinerU 当前有哪些可核对事实下面只写今天仍能核验、且与方案设计直接相关的内容。维度2026-06-15可核对口径对落地的意义主线版本官方MinerUREADME 已记录2026/06/11 3.3 Released说明当前主线已进入Hybrid性能优化和 VLM 能力升级阶段输入类型README 写明支持PDF / DOCX / PPTX / XLSX / Images / Web pages可以作为统一文档入口层而不是只做 PDF结构化输出README 写Markdown / JSONAPI docs 写默认Markdown / JSON可额外导出docx/html/latex适合接知识库、抽取、审计和再加工精准解析 API官方 live docs 当前为 200MB、 200 页、1000 页/天高优先级额度适合标准生产流程但要带 TokenAgent 轻量解析 API官方 live docs 当前为 10MB、 20 页、无需 Token、按 IP 限频适合试跑、轻量 Agent 和小样本预览模型入口API docs 当前支持pipeline / vlm / MinerU-HTMLHTML 场景和复杂文档不要混写成同一条固定路径生态接入官方MinerU-Ecosystem当前提供 CLI、Python/Go/TS SDK、MCP、LangChain、LlamaIndex 等更适合作为现有工作流的组件而不只是裸 API许可证LICENSE.md当前为MinerU Open Source License基于Apache 2.0并附加商业阈值与在线服务标识义务商业上线前必须做许可证复核一个必须保留的保守说明本仓库/Users/wangshasha/Documents/New project/wss-prd-1/docs/05-source-of-truth.md已记录过旧摘要和旧材料里出现过更高页数上限等历史口径。本文按2026-06-15官方 live docs 采用更保守写法精准解析 API 200 页每个账号每天高优先级解析额度1000 页 / 天如果你看到旧资料仍写600 页或其他口径出稿和上线时优先使用当天 live docs并把差异单独标注。MinerU 在这波“校正层”趋势里更适合扮演什么角色角色 1稳定 backbone parserMinerU 依旧首先是解析骨干层。它的价值在于先把混合文档输入统一转成更适合系统消费的中间结果MarkdownJSON必要时追加html/latex没有这一步后面的 chunk、检索、规则抽取、审批和 Agent 工具调用都会更脆弱。角色 2质量门禁前置器MinerU 不该只被放在“生成结果”这一步更适合放在“先判断这份结果能不能进下游”这一步。你真正该检查的是标题层级是否还在表格是否仍可程序消费跨页段落是否断裂重复页眉页脚是否污染正文公式和图注是否明显丢失这一步并不要求你立刻训练一个新模型先用规则检查、抽样人工验收和小规模回放就能挡掉很多坏样本。角色 3selective correction 的上游供给层如果你后续真要做 selective correction不论是人工校正、规则校正还是像ParseFixer/MinerU-Popo那样的模型化校正MinerU 都适合作为前面的统一输入层。因为你至少先拿到了统一格式输入统一结构化输出可回放的中间结果包适合 MCP / SDK / RAG 的接入面这比每种文件类型都临时拼一个 parser 稳得多。更值得采用的工程架构下面这条链路比“文档直接喂模型”更适合上线阶段目标建议做法文档接入接收PDF / Office / 图片 / HTML统一走 MinerU 入口解析生成结构化中间结果输出Markdown / JSON必要时追加html/latex质量门禁拦截高风险坏结果检查标题、表格、公式、噪声、页级连续性选择性校正只修高价值错误规则修复、人工复核或局部二次模型处理下游消费进入 RAG / MCP / 知识库 / 抽取按结构切分不要直接按字数粗切追溯验收回查问题来源保留原文档、原始输出包、门禁记录这个架构的好处不是“更先进”而是更容易定位责任边界。你可以明确区分是 parser 出错是质量门禁漏检是 correction 修坏还是下游检索和推理出了问题一套不伪造跑分的可复现实验方案说明以下内容不是官方 benchmark也不是本文作者已完成的实测成绩。它只是给企业团队或个人开发者一套当天可执行的验证方案。实验目标验证三种链路在真实业务文档上的差异链路描述你真正想验证什么A原始文档直接进入下游流程不做结构治理时知识库和 Agent 会怎么失真BMinerU - 直接入库只有 parser没有门禁时错误会不会被放大CMinerU - 质量门禁 - 选择性校正 - 入库多加一层验收后是否更稳更可控样本设计样本类型最少样本数主要风险双栏论文 PDF3阅读顺序、公式、图注财报/招股书 PDF3跨页表格、目录层级、页眉页脚扫描合同/票据3OCR 噪声、印章、反光、裁切产品介绍 PPTX3标题层级、项目符号、图文混排Excel 台账 XLSX3Sheet 结构、表头、行列可消费性如果时间有限最少也要保留一组双栏论文一组跨页表格财报一组 PPTX 或 XLSX观察指标维度观察问题建议记录方式标题层级保留章节树还能否恢复人工抽查Markdown层级表格可消费性表格还能否被程序读取检查 Markdown 表格或html导出跨页连续性断行、断表、断段是否明显对照原文逐页抽查噪声控制页眉页脚、页码、水印是否污染正文统计重复行Agent 可用性下游工具调用后是否仍需大量返工记录通过 / 待复核 / 失败示例记录表下表是模板不是实测成绩。文档输入格式链路输出文件人工判定备注paper-01PDFA / B / Cfull.md/layout.json待读者填写双栏是否串行report-01PDFA / B / Cfull.md/html待读者填写跨页表头是否保留contract-01PDF/图片A / B / Cfull.md待读者填写是否需强制 OCRdeck-01PPTXA / B / Cfull.md待读者填写页标题是否稳定ledger-01XLSXA / B / Cfull.md/json待读者填写行列是否可二次处理判定建议分值含义1结构严重损坏需要大量人工返工3可用但要清洗适合半自动流程5基本可进入知识库 / Agent / 抽取链路读者可以直接复现的操作步骤步骤 1准备一组真实坏样本不要只跑官方 demo。至少要包含一类真正会把业务带偏的文档双栏论文跨页表格财报拍照扫描合同图文混排 PPTX步骤 2先跑 MinerU 精准解析 API下面示例只演示流程。字段名、状态名和下载字段请以你运行当天的官方 API 文档为准。importtimeimportrequests TOKENyour-tokenBASE_URLhttps://mineru.net/api/v4headers{Authorization:fBearer{TOKEN},Content-Type:application/json,}payload{url:https://cdn-mineru.openxlab.org.cn/demo/example.pdf,model_version:vlm,language:en,is_ocr:False,extra_formats:[html,latex],}create_resprequests.post(f{BASE_URL}/extract/task,headersheaders,jsonpayload,timeout60,)create_resp.raise_for_status()task_idcreate_resp.json()[data][task_id]whileTrue:resprequests.get(f{BASE_URL}/extract/task/{task_id},headersheaders,timeout60,)resp.raise_for_status()dataresp.json()[data]statedata[state]print(state:,state)ifstatedone:print(zip:,data[full_zip_url])breakifstatefailed:raiseRuntimeError(data.get(err_msg,parse failed))time.sleep(5)步骤 3先加一个最小质量门禁不要直接入库这个脚本不是 benchmark只是一个低成本门禁器。它检查标题数量表格数量公式数量重复噪声行是否需要人工复核from__future__importannotationsimportrefromcollectionsimportCounterfrompathlibimportPathdefread_text(path:str)-str:returnPath(path).read_text(encodingutf-8,errorsignore)defcount_tables(text:str)-int:linestext.splitlines()total0foriinrange(len(lines)-1):if|inlines[i]andre.search(r\|\s*:?-{3,}:?\s*\|,lines[i1]):total1returntotaldefcount_formulas(text:str)-int:return(len(re.findall(r\$\$[\s\S]?\$\$,text))len(re.findall(r(?!\$)\$[^$\n]{2,}\$(?!\$),text))len(re.findall(r\\begin\{(?:equation|align|matrix|cases)\},text)))defrepeated_noise_lines(text:str,min_repeat:int3)-list[tuple[str,int]]:lines[re.sub(r\s, ,line.strip())forlineintext.splitlines()if6len(line.strip())80]counterCounter(lines)return[(line,count)forline,countincounter.most_common()ifcountmin_repeat]definspect_markdown(path:str)-dict:textread_text(path)review_reasons[]headingslen(re.findall(r^#{1,6}\s,text,flagsre.M))tablescount_tables(text)formulascount_formulas(text)noiselen(repeated_noise_lines(text))ifheadings0:review_reasons.append(missing_headings)ifnoise5:review_reasons.append(too_many_repeated_lines)iftables0andtableintext.lower():review_reasons.append(table_may_be_lost)ifformulas0and(equationintext.lower()or公式intext):review_reasons.append(formula_may_be_lost)return{chars:len(text),headings:headings,tables:tables,formulas:formulas,repeated_noise_lines:noise,needs_review:bool(review_reasons),review_reasons:review_reasons,}if__name____main__:resultinspect_markdown(./outputs/full.md)forkey,valueinresult.items():print(f{key}:{value})步骤 4只对高风险文档做 selective correction你不一定需要一套完整训练好的后处理模型先从三种低成本方法开始就够了校正方式适用问题代价规则修复页眉页脚、重复噪声、明显断行最低人工抽检高价值合同、财报、研究资料中等局部二次模型处理跨页表格、标题树、图文关系最高关键点不是“有没有 correction”而是“只修高价值错误不要把本来正确的部分也重写坏了”。步骤 5通过后再进入知识库、RAG 或 MCP通过门禁后再决定是否切 chunk建索引暴露给 MCP 工具做规则抽取进入业务审批流如果没过门禁宁可标记为待复核也不要直接进生产链路。适合直接抄走的上线/验证注意事项API 限制看当天 live docs页数、文件大小、批量数量和免费额度都可能漂移不要沿用旧截图。许可证看当前 LICENSE.md当前主仓库许可证包含商业阈值和在线服务标识义务商用前必须复核。HTML 场景要明确 model_version官方 API docs 当前明确要求 HTML 文件指定MinerU-HTML。别把“有 Markdown 输出”当成验收通过真正要看的是结构、连续性和噪声控制。不同文档类型分层上线论文、合同、财报、PPT、Excel 的风险点完全不同不要混成一个统一 SLA。关键链路保留原始结果包至少保留原文档、Markdown、JSON、额外导出格式和验收记录。MCP 跑通不代表知识库可用MCP 解决的是调用方式标准化不替你保证解析质量。优先做 selective correction不要默认全量重跑这比逢错就重做整份文档更节省成本也更利于回滚。该怎么写 MinerU 的技术价值和边界如果要用一句话概括我会这样写MinerU 的价值不只是把复杂文档转成 Markdown而是给知识库、RAG 和 Agent 提供一个可治理、可验收、可继续校正的结构化入口。这句话的重点有三层它先解决入口统一问题。它让质量门禁有地方插进去。它适合作为 selective correction 的上游骨干层。但边界也必须一起写清楚MinerU 不等于业务理解MinerU 不等于自动验收MinerU 不等于任何低质量扫描件都稳定可用开源能力、在线 API、桌面客户端与 SaaS 页面表现也不能默认完全等价真正稳妥的做法不是继续争论“谁是最强 parser”而是先把这条链路补完整解析 - 门禁 - 校正 - 入库 - 验收这比单纯追一个更高的 OCR 指标更接近企业今天真正会部署的系统。参考来源官方 API 文档https://mineru.net/apiManage/docs官方 API 限流说明https://mineru.net/apiManage/limit官方开源仓库 READMEhttps://github.com/opendatalab/MinerU官方许可证https://github.com/opendatalab/MinerU/blob/master/LICENSE.md官方生态仓库https://github.com/opendatalab/MinerU-Ecosystem
别只卷 Parser 主干了：最近一周文档解析开始转向“校正层”，MinerU 该放在什么位置
为什么今天值得写这个题如果你最近还在把文档解析理解成“谁 OCR 更准”这周已经有点跟不上讨论焦点了。过去两个月公开研究里有一条很清楚的线2026-04-09的ParseBench开始把文档解析评测往 Agent 可用性上拉强调表格、图表、内容忠实度、语义格式和视觉 grounding。2026-05-21的MPDocBench-Parse把问题推进到多页文档重点检查跨页表格、标题层级、阅读顺序和语义连续性。2026-05-24的MinerU-Popo进一步说明光有页级 OCR 或页级解析还不够后面还要补文档级 post-processing。2026-06-10的ParseFixer则把话说得更直接工程上不一定要重写整条解析链而是可以先跑稳定 backbone再做 selective correction。与此同时官方MinerU仓库在2026-06-11更新到3.3重点放在Hybrid解析性能优化与 VLM 能力升级。这说明另一个现实一边是 parser 主干继续进化另一边是大家开始认真补“校正层”和“验收层”。这篇文章想回答的不是“MinerU 强不强”这种空问题而是更贴近落地的三个问题为什么最近文档解析开始转向“校正层”思路。MinerU 在这波趋势里更适合扮演什么角色。如果你今天做企业知识库、RAG、MCP 或科研资料处理怎样用一套不伪造跑分的方法验证它。先给结论如果你做的是企业知识库、科研数据处理或 Agent 文件读取MinerU 更适合被放在稳定解析 backbone 质量门禁入口 必要时再补 selective correction而不是被理解成“跑一次 OCR 就完事”的单点工具。原因很简单近期 benchmark 已经不再只盯字符识别而是盯结构和语义可用性。多页文档、跨页表格、标题树和图文关系天然需要后处理。真正上线时最昂贵的不是“慢一点”而是“看起来有结果实际上把下游 RAG 和 Agent 带偏”。所以今天更有价值的架构不是文档 - parser - 直接入库而是文档 - MinerU 解析 - 质量门禁 - 选择性校正 - 入库 / MCP / RAG最近公开热点在说什么1.ParseBench讲的是“Agent 视角的解析正确性”ParseBench的重点不是 OCR 字符相似度而是 Agent 真正在乎的五类能力表格是否还能消费图表数据是否还可信内容是否忠实语义格式是否保留视觉定位是否还能回指这对 MinerU 这类工具的启发是输出Markdown本身不值钱Markdown是否还能进入自动化流程才值钱。2.MPDocBench-Parse讲的是“多页文档不是单页解析的简单叠加”很多系统单页表现不差但一到真实长文档就会暴露问题跨页段落断裂跨页表格散掉标题层级错乱阅读顺序被双栏或页边元素打乱这也是为什么企业知识库和科研论文处理比普通 OCR 更难因为它们真正依赖的是文档级连续性。3.MinerU-Popo讲的是“post-processing 是独立问题”MinerU-Popo的思路很有代表性先复用现有 OCR 或 parser 输出再做四类文档级恢复截断文本恢复截断表格恢复标题层级重建图片与文本关系恢复这意味着 parser 主干再强也不代表你可以省掉后处理。4.ParseFixer讲的是“别逢错必重跑整页先做 selective correction”ParseFixer的公开摘要非常贴近工程现实先跑稳定的 full-page backbone parsing再识别高价值失败点只修该修的位置如果修坏了还能 verify-and-rollback这个思路尤其适合企业场景因为企业最怕的是全量重算太贵局部错误会污染后续审批或知识库人工验收成本太高但又不能彻底省掉截至 2026-06-15MinerU 当前有哪些可核对事实下面只写今天仍能核验、且与方案设计直接相关的内容。维度2026-06-15可核对口径对落地的意义主线版本官方MinerUREADME 已记录2026/06/11 3.3 Released说明当前主线已进入Hybrid性能优化和 VLM 能力升级阶段输入类型README 写明支持PDF / DOCX / PPTX / XLSX / Images / Web pages可以作为统一文档入口层而不是只做 PDF结构化输出README 写Markdown / JSONAPI docs 写默认Markdown / JSON可额外导出docx/html/latex适合接知识库、抽取、审计和再加工精准解析 API官方 live docs 当前为 200MB、 200 页、1000 页/天高优先级额度适合标准生产流程但要带 TokenAgent 轻量解析 API官方 live docs 当前为 10MB、 20 页、无需 Token、按 IP 限频适合试跑、轻量 Agent 和小样本预览模型入口API docs 当前支持pipeline / vlm / MinerU-HTMLHTML 场景和复杂文档不要混写成同一条固定路径生态接入官方MinerU-Ecosystem当前提供 CLI、Python/Go/TS SDK、MCP、LangChain、LlamaIndex 等更适合作为现有工作流的组件而不只是裸 API许可证LICENSE.md当前为MinerU Open Source License基于Apache 2.0并附加商业阈值与在线服务标识义务商业上线前必须做许可证复核一个必须保留的保守说明本仓库/Users/wangshasha/Documents/New project/wss-prd-1/docs/05-source-of-truth.md已记录过旧摘要和旧材料里出现过更高页数上限等历史口径。本文按2026-06-15官方 live docs 采用更保守写法精准解析 API 200 页每个账号每天高优先级解析额度1000 页 / 天如果你看到旧资料仍写600 页或其他口径出稿和上线时优先使用当天 live docs并把差异单独标注。MinerU 在这波“校正层”趋势里更适合扮演什么角色角色 1稳定 backbone parserMinerU 依旧首先是解析骨干层。它的价值在于先把混合文档输入统一转成更适合系统消费的中间结果MarkdownJSON必要时追加html/latex没有这一步后面的 chunk、检索、规则抽取、审批和 Agent 工具调用都会更脆弱。角色 2质量门禁前置器MinerU 不该只被放在“生成结果”这一步更适合放在“先判断这份结果能不能进下游”这一步。你真正该检查的是标题层级是否还在表格是否仍可程序消费跨页段落是否断裂重复页眉页脚是否污染正文公式和图注是否明显丢失这一步并不要求你立刻训练一个新模型先用规则检查、抽样人工验收和小规模回放就能挡掉很多坏样本。角色 3selective correction 的上游供给层如果你后续真要做 selective correction不论是人工校正、规则校正还是像ParseFixer/MinerU-Popo那样的模型化校正MinerU 都适合作为前面的统一输入层。因为你至少先拿到了统一格式输入统一结构化输出可回放的中间结果包适合 MCP / SDK / RAG 的接入面这比每种文件类型都临时拼一个 parser 稳得多。更值得采用的工程架构下面这条链路比“文档直接喂模型”更适合上线阶段目标建议做法文档接入接收PDF / Office / 图片 / HTML统一走 MinerU 入口解析生成结构化中间结果输出Markdown / JSON必要时追加html/latex质量门禁拦截高风险坏结果检查标题、表格、公式、噪声、页级连续性选择性校正只修高价值错误规则修复、人工复核或局部二次模型处理下游消费进入 RAG / MCP / 知识库 / 抽取按结构切分不要直接按字数粗切追溯验收回查问题来源保留原文档、原始输出包、门禁记录这个架构的好处不是“更先进”而是更容易定位责任边界。你可以明确区分是 parser 出错是质量门禁漏检是 correction 修坏还是下游检索和推理出了问题一套不伪造跑分的可复现实验方案说明以下内容不是官方 benchmark也不是本文作者已完成的实测成绩。它只是给企业团队或个人开发者一套当天可执行的验证方案。实验目标验证三种链路在真实业务文档上的差异链路描述你真正想验证什么A原始文档直接进入下游流程不做结构治理时知识库和 Agent 会怎么失真BMinerU - 直接入库只有 parser没有门禁时错误会不会被放大CMinerU - 质量门禁 - 选择性校正 - 入库多加一层验收后是否更稳更可控样本设计样本类型最少样本数主要风险双栏论文 PDF3阅读顺序、公式、图注财报/招股书 PDF3跨页表格、目录层级、页眉页脚扫描合同/票据3OCR 噪声、印章、反光、裁切产品介绍 PPTX3标题层级、项目符号、图文混排Excel 台账 XLSX3Sheet 结构、表头、行列可消费性如果时间有限最少也要保留一组双栏论文一组跨页表格财报一组 PPTX 或 XLSX观察指标维度观察问题建议记录方式标题层级保留章节树还能否恢复人工抽查Markdown层级表格可消费性表格还能否被程序读取检查 Markdown 表格或html导出跨页连续性断行、断表、断段是否明显对照原文逐页抽查噪声控制页眉页脚、页码、水印是否污染正文统计重复行Agent 可用性下游工具调用后是否仍需大量返工记录通过 / 待复核 / 失败示例记录表下表是模板不是实测成绩。文档输入格式链路输出文件人工判定备注paper-01PDFA / B / Cfull.md/layout.json待读者填写双栏是否串行report-01PDFA / B / Cfull.md/html待读者填写跨页表头是否保留contract-01PDF/图片A / B / Cfull.md待读者填写是否需强制 OCRdeck-01PPTXA / B / Cfull.md待读者填写页标题是否稳定ledger-01XLSXA / B / Cfull.md/json待读者填写行列是否可二次处理判定建议分值含义1结构严重损坏需要大量人工返工3可用但要清洗适合半自动流程5基本可进入知识库 / Agent / 抽取链路读者可以直接复现的操作步骤步骤 1准备一组真实坏样本不要只跑官方 demo。至少要包含一类真正会把业务带偏的文档双栏论文跨页表格财报拍照扫描合同图文混排 PPTX步骤 2先跑 MinerU 精准解析 API下面示例只演示流程。字段名、状态名和下载字段请以你运行当天的官方 API 文档为准。importtimeimportrequests TOKENyour-tokenBASE_URLhttps://mineru.net/api/v4headers{Authorization:fBearer{TOKEN},Content-Type:application/json,}payload{url:https://cdn-mineru.openxlab.org.cn/demo/example.pdf,model_version:vlm,language:en,is_ocr:False,extra_formats:[html,latex],}create_resprequests.post(f{BASE_URL}/extract/task,headersheaders,jsonpayload,timeout60,)create_resp.raise_for_status()task_idcreate_resp.json()[data][task_id]whileTrue:resprequests.get(f{BASE_URL}/extract/task/{task_id},headersheaders,timeout60,)resp.raise_for_status()dataresp.json()[data]statedata[state]print(state:,state)ifstatedone:print(zip:,data[full_zip_url])breakifstatefailed:raiseRuntimeError(data.get(err_msg,parse failed))time.sleep(5)步骤 3先加一个最小质量门禁不要直接入库这个脚本不是 benchmark只是一个低成本门禁器。它检查标题数量表格数量公式数量重复噪声行是否需要人工复核from__future__importannotationsimportrefromcollectionsimportCounterfrompathlibimportPathdefread_text(path:str)-str:returnPath(path).read_text(encodingutf-8,errorsignore)defcount_tables(text:str)-int:linestext.splitlines()total0foriinrange(len(lines)-1):if|inlines[i]andre.search(r\|\s*:?-{3,}:?\s*\|,lines[i1]):total1returntotaldefcount_formulas(text:str)-int:return(len(re.findall(r\$\$[\s\S]?\$\$,text))len(re.findall(r(?!\$)\$[^$\n]{2,}\$(?!\$),text))len(re.findall(r\\begin\{(?:equation|align|matrix|cases)\},text)))defrepeated_noise_lines(text:str,min_repeat:int3)-list[tuple[str,int]]:lines[re.sub(r\s, ,line.strip())forlineintext.splitlines()if6len(line.strip())80]counterCounter(lines)return[(line,count)forline,countincounter.most_common()ifcountmin_repeat]definspect_markdown(path:str)-dict:textread_text(path)review_reasons[]headingslen(re.findall(r^#{1,6}\s,text,flagsre.M))tablescount_tables(text)formulascount_formulas(text)noiselen(repeated_noise_lines(text))ifheadings0:review_reasons.append(missing_headings)ifnoise5:review_reasons.append(too_many_repeated_lines)iftables0andtableintext.lower():review_reasons.append(table_may_be_lost)ifformulas0and(equationintext.lower()or公式intext):review_reasons.append(formula_may_be_lost)return{chars:len(text),headings:headings,tables:tables,formulas:formulas,repeated_noise_lines:noise,needs_review:bool(review_reasons),review_reasons:review_reasons,}if__name____main__:resultinspect_markdown(./outputs/full.md)forkey,valueinresult.items():print(f{key}:{value})步骤 4只对高风险文档做 selective correction你不一定需要一套完整训练好的后处理模型先从三种低成本方法开始就够了校正方式适用问题代价规则修复页眉页脚、重复噪声、明显断行最低人工抽检高价值合同、财报、研究资料中等局部二次模型处理跨页表格、标题树、图文关系最高关键点不是“有没有 correction”而是“只修高价值错误不要把本来正确的部分也重写坏了”。步骤 5通过后再进入知识库、RAG 或 MCP通过门禁后再决定是否切 chunk建索引暴露给 MCP 工具做规则抽取进入业务审批流如果没过门禁宁可标记为待复核也不要直接进生产链路。适合直接抄走的上线/验证注意事项API 限制看当天 live docs页数、文件大小、批量数量和免费额度都可能漂移不要沿用旧截图。许可证看当前 LICENSE.md当前主仓库许可证包含商业阈值和在线服务标识义务商用前必须复核。HTML 场景要明确 model_version官方 API docs 当前明确要求 HTML 文件指定MinerU-HTML。别把“有 Markdown 输出”当成验收通过真正要看的是结构、连续性和噪声控制。不同文档类型分层上线论文、合同、财报、PPT、Excel 的风险点完全不同不要混成一个统一 SLA。关键链路保留原始结果包至少保留原文档、Markdown、JSON、额外导出格式和验收记录。MCP 跑通不代表知识库可用MCP 解决的是调用方式标准化不替你保证解析质量。优先做 selective correction不要默认全量重跑这比逢错就重做整份文档更节省成本也更利于回滚。该怎么写 MinerU 的技术价值和边界如果要用一句话概括我会这样写MinerU 的价值不只是把复杂文档转成 Markdown而是给知识库、RAG 和 Agent 提供一个可治理、可验收、可继续校正的结构化入口。这句话的重点有三层它先解决入口统一问题。它让质量门禁有地方插进去。它适合作为 selective correction 的上游骨干层。但边界也必须一起写清楚MinerU 不等于业务理解MinerU 不等于自动验收MinerU 不等于任何低质量扫描件都稳定可用开源能力、在线 API、桌面客户端与 SaaS 页面表现也不能默认完全等价真正稳妥的做法不是继续争论“谁是最强 parser”而是先把这条链路补完整解析 - 门禁 - 校正 - 入库 - 验收这比单纯追一个更高的 OCR 指标更接近企业今天真正会部署的系统。参考来源官方 API 文档https://mineru.net/apiManage/docs官方 API 限流说明https://mineru.net/apiManage/limit官方开源仓库 READMEhttps://github.com/opendatalab/MinerU官方许可证https://github.com/opendatalab/MinerU/blob/master/LICENSE.md官方生态仓库https://github.com/opendatalab/MinerU-Ecosystem
