主题精读：文档解析管线 —— HTML、PDF、DOCX、EPUB 转 Markdown 的工具与失败模式 未开始

题记与说明

• 日期：2026-11-04
• 条目前缀：knowledge-8e9pv6gy-1
• 形式：主题研究（多来源检索 + 精读综合）
• 检索方式：有网络。WebSearch 检索 + 逐篇抓取精读（arXiv HTML 全文、GitHub README 原文、官方文档、技术博客）。凡未在本次会话读到的内容一律标注【已有知识】或【检索快照，未精读】。

来源清单（本次实际精读）

另有一次未精读的检索快照：Tensorlake 在 Reddit 上称"parsers can score 99% on standard benchmarks (often built on sanitized PDFs) yet catastrophically fail in production"——方向与 S6 一致，但正文未读，仅作旁证线索。

TL;DR

1. 四种格式的"解析难度"完全不同：DOCX（OOXML）与 EPUB（XHTML+CSS）是带语义标签的容器，转换主要是"降维投影"（保留结构、丢弃样式），失败模式少而确定；PDF 是印刷指令流而非文档，必须靠版面分析模型"重建"结构，失败模式多而开放；HTML 介于两者之间，难点在 boilerplate 剥离与布局表格。
2. PDF 解析已分裂为两条技术路线：模块化管线（版面检测→OCR/表格/公式识别→阅读 order→Markdown，如 MinerU、Marker、Docling、Mathpix）与端到端 VLM（Nougat、GOT-OCR、Qwen2-VL、GPT-4o）。OmniDocBench 的核心发现是二者擅长面互补：管线赢在常规文档与高密度版面，VLM 赢在手写、退化扫描件等长尾。
3. 最重要的单一失败模式清单（有基准数据支撑）：手写笔记（MinerU 编辑距离 0.984 ≈ 全军覆没，VLM 反而 0.168）、报纸级密排（VLM 编辑距离 0.65–0.90）、表格旋转（所有模型 TEDS 崩塌，MinerU 65.8→3.0）、双栏以上阅读顺序（所有模型一致下降）、水印/模糊扫描（管线工具产生错字）。
4. 评估本身在 2025–2026 年成为新问题：OmniDocBench 被指饱和（头部 94%+）且"单一固定 ground truth + 精确匹配"会惩罚语义等价的正确输出（如该拆未拆的表、HTML vs LaTeX 记法）。基准分数与生产可用性之间的裂缝是当前领域最大的未解问题。
5. 选型结论：先做文档路由（原生 XML→pandoc/MarkItDown/Docling 直转；数字 PDF→管线工具，必要时 --use_llm；扫描/手写→VLM 路线），Markdown 只是视图，中间态应保存无损结构（DoclingDocument / marker JSON / pandoc AST）。

一、核心问题

如何把视觉/半结构化文档可靠地变成 Markdown？ 拆开是三个子问题：

• 结构重建：PDF 只有"在 (x,y) 画这个字形"的指令，没有标题/段落/表格/阅读顺序的语义（S1 把它形式化为 layout + OCR + 表格识别 + 公式识别 + 阅读顺序五个子任务；S7 指出大量文档"remain in scanned or image-based formats"，连文本层都没有）。
• 语义保真 vs 格式保真的取舍：Markdown 本身是低表达力格式——没有 colspan/rowspan、脚注仅部分方言支持、公式只能内嵌 LaTeX。转 Markdown 必然有损，问题是有损在哪一维（S5 直接把产品定位押在"语义够用"上）。
• 度量问题：怎么知道转换"对"？同一页面有多种合法 Markdown 表达（S6 的核心论点），这使"文档解析质量"本身成为一个测量学难题。

二、主要主张

S1 OmniDocBench（CVPR 2025）

• 现有基准缺陷三条："Limited document diversity… Inconsistent evaluation metrics… Lack of fine-grained evaluation"——过去只用 Edit Distance/BLEU 一把尺子量所有元素。
• 两大范式："1) Pipeline-based approaches that decompose the task into layout analysis, OCR, formula/table recognition, and reading order estimation; and 2) End-to-end vision-language models (VLMs) that directly output structured representations (e.g., Markdown)."
• 互补性结论："While general VLMs often lag behind specialized pipelines and expert models on standard documents (e.g., academic papers), they generalize better to unconventional formats (e.g., notes) and perform more robustly under degraded conditions (e.g., fuzzy scans)."
• 密排文档："VLMs, however, struggle with high-density documents like newspapers due to limitations in input resolution and token length."

S4 Marker（作者自述局限）

• "PDF is a tricky format, so marker will not always work perfectly… Very complex layouts, with nested tables and forms, may not work; Forms may not be rendered well."
• 关键运维知识："Some PDFs, even digital ones, have bad text in them. Set --force_ocr to force OCR on all lines"——数字 PDF 的内置文本层可能是坏的，乱码时强制重 OCR 是标准药方（"Make sure to set force_ocr if you see garbled text"）。
• LLM 混合模式显著提升表格：FinTabNet 上 TEDS 0.816 → use_llm 0.907。

S5 MarkItDown（微软，定位即主张）

• "it is meant to be consumed by text analysis tools -- and may not be the best option for high-fidelity document conversions for human consumption."——明确放弃对人的高保真，换取对 LLM 的结构够用。
• 选择 Markdown 的理由："Mainstream LLMs… natively speak Markdown… Markdown conventions are also highly token-efficient."
• 新增的安全段落值得全行业引用："MarkItDown performs I/O with the privileges of the current process… Sanitize your inputs in untrusted environments."（解析器 = 一个会读文件的攻击面）

S6 LlamaIndex 博客（2026-02，基准批评）

• "Top models are hitting 94%+ accuracy, yet real-world document parsing is far from solved."
• 两条批评：基准"getting saturated and the dataset types are a bit too limited/easy"；"too rigid in its evaluation metrics, penalizing innovation in much better, general parsers"。
• 时代判断："AI agents don't care if the parsed output is in HTML or markdown… They will care if the table rows/columns are misaligned, if diagrams and charts are interpreted incorrectly, and if content is dropped."——语义正确性取代格式匹配成为第一目标。

S3 Docling

• 走"统一中间表示"路线：所有格式解析进统一的 DoclingDocument，再导出 Markdown/HTML/"lossless JSON"/DocTags。README 的格式清单（PDF、DOCX、PPTX、XLSX、HTML、EPUB、EML/MSG、Pages/Numbers/Keynote、音视频……）说明工程重心在"广度 + 无损中间态"，PDF 内核仍是 DocLayNet 版面 + TableFormer 表格（S2）。

S7 综述（部分读到）

• 行内公式是独立难题："the detection of mathematical expressions, especially inline ones, is often handled separately due to their complexity."
• 无边框表格是检测瓶颈："often encounters difficulties with tables that lack clear boundaries."
• 模块化系统的代价："their architecture often leads to limitations in joint optimization and generalization across diverse document types."

三、方法（各路线的技术拆解）

3.1 模块化管线（MinerU / Marker / Docling / Mathpix）

共性流程（S1 §2.1 + S4 "How it works"）：

1. 文本层提取或 OCR：先启发式判断数字文本是否可信；Marker 用自研 surya，MinerU 用 PaddleOCR。Marker 元数据里直接输出每页 text_extraction_method: "pdftext"，即逐页记录用的是文本层还是 OCR。
2. 版面分析：检测 19 类区域（标题/段落/表格/图/页眉页脚/脚注标记……，S1 Table S6）。OmniDocBench 证明版面检测是整条管线的天花板：DocLayout-YOLO（19.6M 参数，合成数据预训练）mAP 47.38，显著高于 LayoutLMv3（28.84），"This superiority is a key factor in MinerU's integration of DocLayout-YOLO"。
3. 专项识别：表格（RapidTable/TableFormer/TEDS 优化）、公式（UniMERNet/texify，CDM 评估）、行内公式与正文的拼接。
4. 阅读顺序与装配：跨页段落合并、页眉页脚剔除、脚注归属。
5. （可选）LLM 后处理：Marker --use_llm 用 LLM 做跨页表格合并、行内公式、表单取值；"It can use any gemini or ollama model."

3.2 端到端 VLM

直接图进 Markdown 出。专家模型（Nougat、GOT-OCR2.0）小而快，通用模型（GPT-4o、Qwen2-VL-72B）靠大数据泛化。S1 的训练分布假说："This is largely due to their broader training data, enabling better handling of long-tail scenarios compared to models trained on narrow domains."

3.3 原生格式的"降维"路线（DOCX / EPUB / HTML）

• DOCX（OOXML）：文档本来就是带语义标签的 XML 树，转换是"投影"而非"重建"。工具链三档：pandoc（AST 驱动，语义最完整【已有知识】）、MarkItDown（python-docx/mammoth 类，轻量【已有知识】）、Docling（MsWordDocumentBackend 统一进 DoclingDocument）。失败点集中在非正文流内容（文本框、SmartArt、批注/修订、OLE）与"手工排版伪标题"（用加粗大字号冒充标题，机器无从判断层级）【已有知识，S3 未展开】。旧二进制格式 .doc/.xls/.ppt "requires LibreOffice"（S3）——即真实管线是 LibreOffice 先转 OOXML，失败模式叠加。
• EPUB：本质是打包的 XHTML + CSS + 导航（OPF/nav）。文本类 EPUB 转换质量普遍高；失败集中在 DRM 保护的文件（法律上就不能转）、固定版式 EPUB（fxl，本质是图片页）、纯 CSS 表达的结构（如浮动栏）与弹窗脚注标记【已有知识；本次精读来源均未展开 EPUB 失败模式，这是本主题笔记的证据薄弱区，已如实标注】。三家工具都内置 EPUB：MarkItDown（EPubs 在支持清单）、Marker（EPUB provider）、Docling（"Parsing of EPUB… for e-books"）。
• HTML：难点不在标签而在"哪些是内容"：导航、广告、版权页脚、Cookie 提示等 boilerplate 需要剥离（readability/trafilatura 一系算法【已有知识】）；rowspan/colspan 表格降维成 Markdown 表会直接丢结构；JS 渲染页面需要 headless 浏览器先取 DOM。S5 的 MarkItDown 把 HTML 列在支持清单但未承诺保真，与 S5 的整体定位一致。
• 通用点：S3 证据表明即便是"简单"的文本类输入也有编码失败模式——"BOM 决定文本编码，除非设置了 backend 的 encoding 选项；若字节在检测到的编码中无效，转换会报错"。

3.4 评估方法（S1，这是本领域方法学贡献最大的部分）

• 文本：Normalized Edit Distance（NED）；表格：全部转 HTML 后算 TEDS（树编辑距离相似度）；公式：CDM（字符检测匹配，渲染比对）+ BLEU + NED；阅读顺序：文本块序列的 NED。
• Adjacency Search Match：先按阈值配对，失败则模糊匹配 + 相邻段落合并重试——承认"模型分段的粒度和人不同不是错"。
• Ignore Handling：页眉/页脚/页码/图注不参与计分，因为各家输出标准不一致——这个设计本身就是一条失败模式清单：这些边缘元素正是工具分歧最大的地方。

四、数据与证据

4.1 OmniDocBench v1 端到端总分（Overall Edit Distance ↓，EN/ZH，S1 Table 2）

两个结构性事实：所有方法中文成绩都差于英文；Nougat 在中文页近乎全灭（0.973/表格 0.0）——训练分布窄的专家模型泛化风险有多大。

4.2 按页面类型的失败模式（S1 Table 3，文本编辑距离 ↓）

• 手写笔记上管线崩溃的原因有明确归因："MinerU detects all handwritten notes as figures, resulting in very low recognition accuracy in Notes."（版面模型把手写块全判成了图）
• 报纸上 VLM 集体失败（0.65–0.90）→ 分辨率/token 预算上限；Mathpix 作为管线也差（0.69）→ 密排是真正的大众死角。
• VLM 在幻灯片上反而最好（Qwen2-VL 0.061）→ 训练数据里 PPT 截图多。

4.3 表格的细分失败模式（S1 Table 7 / S1 / Table S1，TEDS）

• 边框类型：三线表（MinerU 69.7）与无边框（60.0）均差于全框线（59.4 的 MinerU 反而最低是中文全框线——总之边框的有无对不同模型影响方向不同："the presence or absence of table frames can significantly impact different models' performance in different ways"）。
• 旋转是致命项：MinerU 旋转表 TEDS 3.0（无旋转 65.8），GOT-OCR 0.0，Qwen2-VL 42.7（无旋转 75.1）。
• 合并单元格主要考验 VLM 训练覆盖："VLMs tend to perform worse on tables with merged cells, but colored backgrounds do not significantly impact table recognition accuracy"；管线工具相反——"Pipeline Tools' performance would not be affected by more challenging tables (e.g., merge cell), but colored backgrounds can affect recognition accuracy."

4.4 公式识别的指标陷阱（S1 Table 9）

Mathpix CDM 86.6 但 ExpRate@CDM 只有 2.8%——"Although Mathpix shows high character-level precision, it occasionally omits punctuation, such as commas, leading to a lower overall correctness rate."一个逗号使"整式全对率"归零。这直接支撑 S6 的批评：精确匹配型指标会把微小差异放大成大失败。

4.5 阅读顺序与退化扫描件（S1 Table 4/5）

• 多栏一致劣化：InternVL2 单栏 0.082 → 双栏 0.312 → 三栏 0.682；MinerU 复杂版面"incorrectly merges multiple columns during recognition"。
• 退化件（模糊/水印/彩底）上 VLM 更稳，管线更脆："Marker tends to generate typos when the PDF pages are fuzzy scanned or with watermarks."
• OCR 分项（S1 Table 8）：旋转 270° 是 OCR 集体黑洞（Tesseract 0.979、Surya 0.767、GOT-OCR 0.966 编辑距离），"Most models fail to recognize text when it is rotated 270 degrees."

4.6 Marker 自家基准（S4，注意是厂商自评）

H100 单页：Marker 启发式分 95.67 / LLM 评审 4.24，优于 LlamaParse（84.24/3.98）、Mathpix（86.43/4.16）、Docling（86.71/3.70）；吞吐宣称 batch 模式 H100 上 25 页/秒（另一处按 VRAM 推算 122 页/秒）。表格 FinTabNet：Marker 0.816 → use_llm 0.907 → 纯 Gemini 0.829（纯大模型并不比专用模型强，混合才最强）。

4.7 2026 年最新水位（S6）

• OmniDocBench v1.5（扩到 1355 页）上 GLM-OCR 94.6% SOTA，"beating not only OSS models but also recent frontier models like Gemini 3 Pro and GPT-5"；Gemini 3 Pro 90.3%。
• 基准代表性缺口："complex financial presentations, market research reports, complex legal filings, insurance claims, and intake forms"，且"heavily weights elements like text/tables/formulas, but it ignores other relevant elements like visuals, handwriting, and form fields."
• 语义等价被扣分的实例：LlamaParse 把公式表按无合并单元格输出、科学记数用 HTML 而非 LaTeX，TEDS 仅 0.6344；两表拆分输出被匹配算法判到只剩一表，TEDS 0.3825。

五、失败模式全景（格式 × 环节）

证据等级标注：〔基准〕= S1/S4/S6 数据；〔官方〕= 工具作者自述；〔经验〕= 我方已有知识，本次来源未覆盖。

六、结论

1. 没有"最好的转换器"，只有"按文档类型路由的管线"。OmniDocBench 的类型×方法矩阵本身就是选型表：学术论文/财报→MinerU 或 Marker(+LLM)；手写/退化件→通用 VLM；密排报纸→管线；幻灯片→Qwen2-VL 类或专用 PPT 后端。
2. 数字 PDF 的文本层不可信任是工程常识的起点：即使有文本层，坏字体映射也会产出乱码，force_ocr 是比换工具更快的第一响应。
3. 混合模式（专用模型 + LLM 后处理）是当前表格/公式质量的最优解，且纯 VLM 并不占优（纯 Gemini 0.829 < Marker 0.816→0.907 的跃升主要来自管线底座）。
4. 中间表示 > 最终格式：Docling 的 DoclingDocument、Marker 的 JSON/chunks、pandoc 的 AST 都在传达同一架构判断——Markdown 是多个导出视图之一，无损结构留着，下游才能重渲染、纠错、做 RAG 分块。
5. 给 LLM 消费的转换应以"语义正确"为验收标准（表格对齐、内容不丢、公式可渲染），而不是逐字符匹配原版式——这也是 S6 对下一代表单测的预言。

七、局限

• 来源偏差：Marker 数据来自厂商自评基准（其自选的 common crawl 页面集与评分启发式），与 OmniDocBench 中 Marker 明显落后于 MinerU（0.336 vs 0.150）并不矛盾——评测集不同结论不同，这本身就是 S6 论点的又一例证。
• HTML/DOCX/EPUB 证据薄：S7 综述（部分截断）与 S1 均聚焦 PDF；EPUB/HTML 失败模式主要落在〔经验〕标注区。本笔记对此不掩饰：如需生产级 DOCX/EPUB 结论，应补做 pandoc/Docling 的自建回归集实测。
• 时效：OmniDocBench v1 数据（2024 年模型版本：MinerU v0.9.3、Marker v1.2.3）已被 v1.5/2026 新模型（GLM-OCR 等）大幅超越，绝对分数不可横向迁移；但失败模式的"结构性"（手写/密排/旋转/阅读顺序）在 S6 承认下仍未解决。
• 未验证项：本次未在本机运行任何工具做对照实验（与精读任务边界一致）；Tensorlake 关于"sanitized PDFs"的论述只读了检索摘要。
• 中文文档整体表现差于英文是所有方法的共性短板，工业界中文文档选型应把 OmniDocBench 的 ZH 列而非 EN 列作为主参考。

八、对我的启发

1. 给自己的文档/知识管线加"文档路由"前置层：先判 born-digital PDF / 扫描 PDF / DOCX / EPUB / HTML，再分发到不同转换器。这一层的成本远低于在单一工具里硬调，且路由规则可直接抄 S1 的类型×方法矩阵。
2. 建立"乱码→force_ocr→换 VLM"的标准响应序列，把 Marker README 的 Troubleshooting 当运维手册用：garbled text→--force_ocr；复杂表格→--use_llm；OOM→降 worker 数。
3. Markdown 表达力天花板要提前设计绕过：合并单元格表格、脚注、复杂公式，宁可输出内嵌 HTML/LaTeX 片段，不要硬降维成破损的纯 Markdown——TEDS 评估本身就把表全转 HTML 再算，工具界已默认此路。
4. 评估自建管线时分指标验收（文本 NED / 表格 TEDS / 公式 CDM / 阅读顺序），并且每类指标配自己真实文档的小回归集——外部基准在 94%+ 饱和后对你关心的长尾（合同、表单、财报页）已经不再有区分度（S6 的核心警告）。
5. 把解析器当不可信输入处理：MarkItDown 的安全段落（限制 URI scheme、私网地址、用最窄的 convert API）适用于所有转换工具；文档内容本身也是 prompt injection 载体，解析产物流入 LLM 前应与网页内容同等消毒〔经验，与 S5 官方建议同向〕。
6. 与已有知识网络衔接：本主题与既有笔记《Pandoc与通用文档转换》（2026-10-31-knowledge-p5j2vm4l-1）互补——pandoc 负责"语义清楚的格式"（DOCX/EPUB/HTML→AST→MD），本主题的管线工具负责"视觉重建的格式"（PDF）；RAG 场景下（另一篇 RAG 评估笔记）转换质量直接决定召回上限，表格/公式的损坏是检索失败的隐性来源。

附：检索记录

• WebSearch：PDF to Markdown conversion failure modes benchmark OmniDocBench Docling Marker MinerU document parsing
• webReader 逐篇抓取：arXiv 2408.09869（abs）、2412.07626（abs + html v2 全文含附录 S1–S6 表）、marker README（raw）、markitdown README（raw）、docling README（raw）、LlamaIndex 博客全文
• WebFetch 定向提取：Docling supported formats 页、arXiv 2410.21169（HTML 版在 Section 8 后截断，已如实标注）