知识库回答一个参数问题时，找到了正确的产品手册，却把旁边型号的数值当成答案。这种错误很难靠修改提示词解决：解析阶段已经把表格的列关系弄乱了。用 MinerU 处理文档时，最值得先验证的是关键内容有没有保留下来，以及检索命中后能否回到原文件核对。
先用一个能判断对错的问题验收
假设一份设备手册的表格列着 A、B 两个型号，每个型号都有工作温度和功耗。你希望知识库回答“B 型在什么温度范围内工作”。这是一份假设样例，用来说明验收方法，并非本文实测过的设备数据。
开始接入前，人工记录 B 型对应的温度范围、单位、脚注，以及表格所在的文件页码。再检查转换输出：数字是否正确，表头有没有关联到正确列，负号有没有丢失，脚注是否说明了不同环境下的限制。最后才把结果切分、入库并提出同一个问题。
如果解析输出已经出错，就回到解析环节处理；如果输出正确但检索片段缺了表头，应调整切分；若片段完整而答案仍误用型号，再检查生成环节。这样的样例不需要很多，却能帮助团队确定每一类错误由谁负责。仅检查“生成了一份 Markdown 文件”，无法发现这些差异。
旧文章中的 pipeline 与 VLM，需要放回版本背景
原文依据 MinerU 3.x 的使用方式讨论解析后端。核对到 2026 年 9 月 23 日，官方主线已经进入 4.0。官方仓库现在把解析质量分为 Flash、Basic、Standard 和 Advanced，并增加了本地文档库与相关服务工具。旧版系统仍可按自己的锁定版本维护，但新建环境不应把两个版本的命令和输出混在一起。
当前档位与运行时说明将质量档位与底层引擎分开。Basic 使用小模型，Standard 与 Advanced 涉及 VLM；Advanced 使用更多推理计算。档位名称表达的是处理方式和资源取舍，不能保证每份文档都按同样幅度提高质量。Office 等原生文档与 PDF、图片也不是完全相同的处理路径。
实际选择时，可以先按输入类型准备样本：文本层清晰的 PDF、扫描件、带跨页表格的手册，以及团队真正使用的 Office 文件。分别观察质量和耗时，再决定默认路线。本文没有在目标 GPU 上运行 MinerU 推理，不提供未经测量的吞吐量或准确率，也不把最贵档位写成所有文档的默认答案。
4.0 接入首先要检查页数和入口
迁移文档列出了一个容易影响 RAG 的区别：mineru parse 使用文档库与续读机制，默认处理 PDF 的前十页；mineru-kit parse 和 Python SDK 默认处理全部页面。旧命令 mineru -p ... -o ... 也不能直接作为新版调用模板。
如果你的资料恰好只有五页，两种入口的差异很难在演示里暴露。换成一百页的手册后，前十页可能主要是封面、目录和前言，知识库仍会生成一批片段，看起来像“入库成功”，重要章节却从未进入索引。
因此任务记录应包含预计页数、请求页范围、实际返回的原始页索引，以及是否还有后续内容。范围解析成功不等于整份文件完成。对于分段读取，只有全部计划范围都处理完，才能把文档标成完整入库；失败的区间要能单独重试，而不是重跑时重复写入已经完成的页面。
还要检查页码的含义。纸面印刷页码可能从正文开始计数，而 PDF 文件前面还有封面和目录。你可以在界面展示印刷页码，但底层引用仍需保留文件中的物理页位置，否则“见第十二页”会把读者带到不同内容。
JSON 长得相似，也可能是不同协议
4.0 的输出格式说明区分命令响应、中间文档结构和面向消费者的结构化内容。mineru parse --json 返回的状态与续读信息，不是可以直接交给 ParseResult.from_dict() 的 MiddleJson。渲染器支持某种格式，也不意味着所有 CLI 入口都提供相同参数。
接入代码需要明确自己读的究竟是哪一种输出，而不是看见 pages 或 content 字段就开始遍历。保存原始响应和解析器版本，有助于升级后判断结构变化。旧缓存或历史 JSON 能否读取，应按对应兼容入口确认；修改版本号不会补回缺失的数据。
在当前中间协议中，序列化的 schema 与 schema_version 用来识别格式，页上的 page_idx 从零开始。生产者版本与实际解析档位也有各自的位置。界面展示和引用定位时，要把内部索引与面向读者的一基页号转换清楚。不要在不同模块里各加一次一，造成整批引用偏移。
如果你只需要把资料交给人阅读，Markdown 很方便；需要保存块关系、定位表格和追踪页码时，应额外保留实际使用的结构化输出。不要在转换结束后马上删除原始结果，等用户发现引用错误时才尝试从一大段拼接文本还原页面。
表格验收要保留行列、单位和条件
回到开头的手册样例。单元格中的“二十”识别正确，仍不代表信息完整：它可能是二十摄氏度、二十瓦，或者某种测试条件下的最大值。表头、单位和说明应与数值一起进入下游处理。
对关键表格，建议选几组业务人员真会问的问题，人工标注答案单元格与依赖的表头、脚注。比较时不要只统计识别出了多少字符；还要检查这些关系是否能从输出中恢复。跨页表格尤其需要核对，第二页可能省略总标题，却重复了部分表头。
为了检索方便，可以为一张表建立概述片段，并让具体行记录携带必要的列名和单位。概述用来帮助检索找到表格，原始单元格与页面证据用来确认数字。概述若由模型生成，应作为派生内容单独保存，不能替换原始解析结果，也不能被当成逐字引文。
对于合并单元格或多层表头，不要急着转换成每列只有一个名字的 CSV。先定义如何表达上层分组，再检查导出是否丢了条件。解析器可以生成可读表格，但你仍需要按业务问题决定哪些结构必须留到检索阶段。
阅读顺序与公式，应分别准备检查项
双栏论文里，正确阅读顺序通常不是按整页从左到右扫每一条水平线。侧边提示框、脚注和图注也可能插进正文。可以从样本中挑几句关键句，标注它们应出现的顺序，再检查转换结果。不要仅凭“文字都在”就通过验收，顺序错误会让切分后的段落包含两件无关的事。
公式的检查则取决于用途。如果知识库只需要找到讨论某个公式的章节，保留原页图像和可靠定位可能已经有用；若要解释推导或据此计算，就必须核对上下标、分式、变量定义与适用条件。把识别得不确定的公式交给生成模型“补全”，可能制造原文没有的表达。
建议把变量说明与公式放在可共同检索的范围内，同时保留各自的原块定位。公式跨页、说明在下一段的样本应进入评测集。对识别不可靠的页面，可以标记为需要查看原图，避免让知识库以确定语气回答一个尚未核实的计算问题。
页眉页脚也需要按文档类型处理。重复的公司名通常不该挤占检索内容，但合同中的版本号、保密级别或文件编号可能有用途。清洗规则应说明保留到哪里，而不是简单删除所有重复行。
让每个片段都能找到它的原文版本
团队可以在自己的入库记录中保存文件哈希、业务文档 ID、原文件版本、解析版本、质量档位、页范围和块标识。这些是应用层的设计字段，不应误写成 MinerU 所有入口都会自动提供的同名字段。解析器输出已有的定位信息应保留，业务系统需要的信息则自行补齐。
假设同名手册后来更新了温度范围，只按文件名覆盖文本，会让旧引用失去依据。更稳妥的做法是为新文件建立新版本，重新解析和检查，在通过后把检索入口切向新版本。旧答案仍可追溯到当时所用文件；不必让读者拿最新版去验证过去的结论。
原文件、解析结果和切分结果可以分别计算摘要。发现错误时，就能知道是上传文件变了、解析器变了，还是切分配置变了。同一份 PDF 改用另一个档位重跑，也应留下独立记录，而不是悄悄替换已有结果。
入库状态不要只有成功和失败
上传结束、解析结束、质量通过和检索可见，是四个不同的时间点。若解析任务一完成就直接写进正式索引，人工后来发现缺页时，用户可能已经得到了受影响的回答。
一种可行流程是：文件进入暂存区，完成解析后接受规则检查；异常项进入复核队列；通过的版本再生成索引，最后发布到查询入口。每个状态都记录原因和时间。重试时沿用同一任务身份或明确生成替代版本，避免一次网络重试产生两份可检索内容。
自动检查适合发现缺页、空内容、引用位置缺失或输出结构不合法。它不能单独证明每个数字都正确。人工复核可以聚焦异常页、关键表格和随机抽样，再用一组真实问答检查切分与引用。对高影响数据，验收范围应更严格；对只用于粗检索的材料，可以采用不同门槛，并在使用端体现限制。
回退也应按文档版本进行。新索引出现问题时，把查询入口切回已验收版本，保留失败版本供排查。不要为恢复一份文档而覆盖整个知识库，丢掉同一期间其他人的更新。
处理权限与部署边界
解析发生在本机，不代表后续所有步骤都在本机。模型端点、远程解析服务、对象存储和 embedding 服务可能分别接收不同内容。接入前画出实际数据流，确认每一处处理什么、保存多久，以及谁能访问。对于不能离开内网的文件，应让网络和服务配置落实这一要求。
切成片段后，文档权限仍要跟着内容走。检索阶段过滤不属于当前用户的片段，比等答案生成后再删除敏感句子更容易检查。生成的摘要、表格概述和缓存也应继承相应限制，不能因它们是“加工后的内容”就放进公共索引。
部署方还应阅读项目的许可证文本，并分别核对模型和依赖的条件。本文不根据“开源”两个字推导商业服务化或再分发权限，也不以 GitHub 的自动识别标签代替许可证原文。
最后交付的验收材料，可以从开头那一个参数问题开始：原文件哪一页、表格哪一格、解析后怎样表示、检索拿到哪个片段，以及答案能否点击回原文。把这条链路说明白，再扩展到更多版式和批量任务，后续每次升级才有一组可以重复核查的依据。