MinerU-PopoOCR 解决的是“看见文字”的问题。在文档智能场景里这一步很重要但还不够。一个 PDF 被 OCR 之后通常会得到一组页面级的结果文本块、标题块、表格块、图片块、坐标、页码以及一些模型识别出来的版面标签。它们能说明“这一页上有什么”却不一定能说明“整篇文档在讲什么、这些内容之间是什么关系”。这就是很多 RAG 系统在处理复杂 PDF 时容易遇到的问题。一份年报里表格可能从上一页延续到下一页图的标题在图上方脚注在下一段下面目录页能看到章节名称但正文页里标题层级并不总是稳定同一节内容可能跨页、跨栏、跨多个文本框。OCR 把这些内容都识别出来了但文档结构没有自动恢复。后续进入检索、分块、引用和问答时系统看到的就不是一篇结构化文档而是一串被页面切开的内容片段。MinerU-Popo 关注的正是这个断点在 OCR/Layout 之后把页面级解析结果进一步整理成文档级结构。OCR 的下游缺口传统 OCR 或版面分析模型通常以页面为基本单位工作。它们擅长回答几个问题• 这段文字在哪里• 这个区域是不是表格• 这张图的位置是什么• 当前文本块属于标题、正文还是列表• 表格能不能还原成 HTML但真实文档还有另一层信息• 哪些标题是一级、二级、三级• 哪些正文属于同一个章节• 当前段落是不是上一页内容的延续• 两个相邻页面上的表格是不是同一张表• 图片、图注、表注、脚注应该挂在哪个章节下• 长章节应该如何拆成可检索的小节点同时保留父级上下文这些信息不是单个页面能稳定判断的。它们依赖跨页顺序、标题样式、块之间的相对位置、文本连续性以及整篇文档的上下文。如果缺少这一层RAG 系统会出现一些很具体的问题。比如用户问“公司在水资源管理上的目标和完成情况是什么”检索可能只命中表格中的一行却丢掉表格标题和所属章节用户问“这张图说明了哪项环保措施”系统可能检索到图片说明却不知道图片属于哪个案例用户要求引用来源时只能给出页码不能给出更接近人类阅读习惯的章节路径。这类问题不是单纯换一个 embedding 模型就能解决的。因为问题出在文档进入索引之前结构已经损失了。OCR 的下游缺口MinerU-Popo 做了什么MinerU-Popo 可以理解为一个 OCR 输出后的结构化后处理框架。它不替代前面的 OCR/Layout 模型而是读取这些模型已经产生的页面级结果再补上文档级关系。从项目实现看它的主流程可以拆成四类判断。MinerU-Popo 的四类后处理任务第一类是文本截断分析。OCR 输出中正文经常被页面、栏位、图片或版面区域切开。两个相邻文本块在视觉上分开但语义上可能属于同一句或同一段。MinerU-Popo 会先用规则筛出可能连续的文本对例如前一个文本块没有完整结束符、后一个文本块不是列表起始项再交给模型判断是否应该合并。最终在内容里标记出|txt_contd|和|txt_split|区分连续和自然分割。第二类是标题层级分析。OCR 能识别出“这是标题”但不一定能稳定识别“这是几级标题”。尤其是中文年报、论文、合同、招股书等文档里标题样式经常混杂字号、编号、缩进、粗细、页眉样式都会干扰判断。MinerU-Popo 会把候选标题及其页码、坐标、内容组织成输入判断标题层级再用栈结构构建章节树。第三类是图文关联分析。图片、图注、表注、脚注和正文之间的位置关系很复杂。图注可能在图下方也可能在上方表格标题可能和表格隔着一段说明有些图表还嵌套在大图块里。MinerU-Popo 会把图片、表格、图注、表注、标题等视觉元素统一纳入关联判断给图表找到对应的标题节点或父级视觉块。第四类是跨页表格合并。跨页表格是文档还原里的高频难点。项目里不仅判断相邻页的表格是否应该合并还会解析 HTML 表格结构比较表头、行列数、rowspan、colspan并处理上一页最后一行与下一页第一行可能被截断的情况。合并后的表格不只是把两段 HTML 拼起来而是尽量保持单元格结构的连续性。这四类结果最后会进入构树阶段。构树逻辑并不复杂但很关键文本节点按标题层级形成父子关系表格、图片、图表、印章等特殊元素挂到对应章节页眉、页脚、页码、旁注等补充信息单独保留长文本节点还可以拆成 subnode便于后续分块和索引。最终得到的不是一段 Markdown而是一棵带有类型、标题、内容、metadata、location、block_ids、children 的 JSON 文档树。这棵树才是后续 RAG 更需要的输入。对 Agentic RAG 的价值让推理有路径Agentic RAG 和普通问答式 RAG 的差别在于它通常不会满足于一次向量检索。它会拆问题、查证据、补上下文、比较来源、做多步推理。多步推理对文档结构非常敏感。如果知识库只有扁平 chunkAgent 能做的事主要是“找相似片段”。但很多问题需要沿结构走。例如• 先定位“ESG 管理”• 再进入“利益相关方沟通”• 再读取该小节下的表格• 再把表格内容和后续“管理成效”对照• 最后给出回答和引用如果文档树存在这条路径是明确的。每个 chunk 不只是孤立文本而是知道自己的父章节、兄弟节点、子节点、页码位置以及关联的图表。这会带来三个直接变化。第一检索可以从“命中文本”升级为“命中节点”。用户的问题命中一个子节点后系统可以把父节点标题、上级章节、相邻表格一起带入上下文。这样既不会把上下文拉得过大也不会只给模型一段残缺内容。第二推理可以利用章节路径。标题层级本身就是文档作者组织信息的方式。一级标题通常表达主题二级标题表达问题域三级标题表达措施、指标或案例。Agent 在做问题拆解时可以把章节路径作为规划线索而不是完全依赖文本相似度。第三证据组织更自然。回答不只引用“第 17 页”还可以引用“水资源管理目标与完成情况”这一类结构位置。对于企业报告、技术文档、法规制度、招投标文件这种引用粒度更接近人工审阅习惯。当前项目里已经有父子分块检索逻辑子块用于精确召回父块用于补充回答上下文。MinerU-Popo 输出的文档树正好可以作为更可靠的父子分块来源。标题节点可以成为父块正文、表格、图片说明可以成为子块命中子块后再回填父章节和相关视觉元素。这比单纯按 token 长度切分更稳定。对高保真还原的价值把文档重新装回去文档解析的另一个目标是还原。很多场景并不是只要回答问题还需要把原文结构尽量完整地保存下来。例如• 把 PDF 转成可编辑的 Markdown 或 HTML• 在知识库里展示原文目录树• 检索结果中展示表格、图片和上下文• 生成带来源的报告摘要• 对比两个版本文档的章节差异这些任务都需要高保真的结构信息。标题层级决定了文档骨架。没有层级所有标题只是加粗文本有了层级才能恢复目录、章节折叠、段落归属和引用路径。表格合并决定了数据完整性。跨页表格如果被拆成两张表检索和展示都会出错。用户看到的是两段不连续数据模型看到的也是两个互不相干的 HTML 片段。MinerU-Popo 的跨页合并逻辑可以把表头重复、行列跨度、截断单元格等问题在后处理阶段修正掉。图片上下文决定了视觉内容能不能被理解。单独保存图片没有太大意义必须知道它的图注、脚注、所属章节以及前后正文在讲什么。MinerU-Popo 把图片、图注、表注和章节挂接起来后续无论是做多模态检索还是做图文摘要都有了结构锚点。这对当前项目里的 OCR 后处理尤其重要。DeepDOC、MinerU、PaddleOCR 等解析器可以负责把页面内容识别出来MinerU-Popo 可以作为后处理层接收统一后的 block 列表进一步增强文档还原效果。重点增强的不是“识别更多文字”而是• 标题层级更稳定• 正文跨页续接更准确• 表格跨页合并更完整• 图片、表格、图注、脚注的归属更清楚• 长章节能拆成子节点但仍保留父级结构换句话说OCR 负责把内容从页面里取出来MinerU-Popo 负责把内容放回文档里。对 KnowFlow 的借鉴意义对 KnowFlow 这类产品来说MinerU-Popo 的意义不在于重做一套 OCR而是在现有 OCR 结果之后追加一层结构修正。当前解析链路已经可以产出middle_json、Markdown、坐标映射和语义块。这里面包含了文档还原所需的大部分原材料文本内容、layout type、页码、bbox、表格 HTML、图片区域和块顺序。问题在于这些信息仍然偏页面级很多关系还没有被稳定地文档化。因此比较自然的方案是把middle_json作为 MinerU-Popo 的输入来源先把不同解析器产出的结构归一化为 block schema再通过 MinerU-Popo 判断标题层级、文本续接、图文关联和跨页表格合并最后回写为增强后的文档树或增强版middle_json。KnowFlow 中的后处理接入位置这条路线的好处在于边界清楚。原有 OCR 结果不被废弃仍然作为事实基础后处理层只负责修正结构关系。这样可以减少系统改造范围也便于做灰度验证同一份文档同时保留原始解析结果和后处理结果逐项比较标题、表格、图片上下文的变化。但这里有一个前提修正结果必须可信。结构后处理如果判断正确会显著提升文档解析质量如果判断错误也可能把原本正确的 OCR 结果改坏。比如把两个独立表格误合并、把图注挂到错误章节、把三级标题识别成一级标题都会影响后续检索和展示。在这个前提成立后后处理方案才适合进入 KnowFlow 的主解析链路并稳定改善复杂文档的解析效果。需要注意的边界MinerU-Popo 不是万能的文档解析器。它依赖前置 OCR/Layout 的质量。如果文字识别错误、表格 HTML 本身残缺、图片区域裁剪不准后处理只能修复一部分结构关系不能凭空恢复所有内容。它也会带来额外推理成本。尤其是长文档需要动态分块、跨块同步和模型调用。实际接入时应该优先处理高价值文档类型例如年报、论文、合同、制度文件、技术手册、招投标文件而不是对所有短文本都启用完整后处理。另外文档树并不意味着必须抛弃原有 chunk 策略。更合适的做法是让结构树成为 chunk 的来源和约束该细分时仍然细分但不要切断标题、表格、图片和正文之间的关系。结语OCR 把文档变成可读取的文本文档结构理解把这些文本重新组织成可使用的知识。对于 RAG 来说这一步的价值不在于多识别几个字而在于减少进入索引前的结构损失。标题层级、跨页续接、表格合并、图文归属这些看起来像解析细节实际会影响检索召回、上下文构造、引用定位和多步推理。MinerU-Popo 提供了一种清晰的后处理思路保留前置 OCR/Layout 的能力把模型判断集中用在文档级关系上再输出可索引、可展示、可溯源的文档树。从这个角度看文档解析链路的目标不只是“从 PDF 到文本”而是“从页面识别到结构理解”。这也是复杂文档进入 RAG 之前最值得补上的一层。