💡 一句话总结：这篇论文把“公开基准高分但真实复杂表格仍翻车”的问题拆开诊断，再用 DEC 在不重训解析器的前提下做拆表、增强、修正和回滚；它不是万能 OCR 升级，但给冻结模型和闭源解析器提供了一条很工程化的补丁路线。
🎯 导语：你的 pipeline 可能不是读不懂，是读漏了
先问一个可能戳到你的问题：你的文档抽取 pipeline 里，最怕的是 PDF 没文字，还是表格明明在眼前，模型却把第三列接到了第五行？
做 RAG、财报抽取、合同结构化、报告入库的人，多半都遇过第二种。表格看起来是“结构化数据”，但对视觉模型来说，它是分辨率、行列对应、合并单元格、公式、弱边框和长输出的组合题。哪一步撑不住，下游都会拿到一份漂亮但错位的 HTML。
更麻烦的是，公开基准可能已经给了你虚假的安全感。论文开头提到，在 OmniDocBench v1.6 上，PaddleOCR-VL-1.6 和 MinerU2.5-Pro 的表格 TEDS 分别有 94.76 和 93.42。听起来很强。可是作者审计 MinerU 社区反馈和真实输出后，仍然看到大表缺内容、重复输出、行列错位、合并单元格错误这些老朋友。
这就是这篇论文的起点：不是再造一个更大的 OCR 模型，而是先搞清楚“高分解析器到底在哪儿摔”，再决定“能不能在不重训的情况下扶一把”。
想自己动手试？
- 📄 论文：arXiv 2608.09842
- 📄 PDF：arXiv PDF
🧩 这篇论文到底想解决什么问题？
论文《From Diagnosis to Correction: Benchmarking and Improving Real-World Table Parsing》做了两件互相咬合的事：先造诊断基准，再做修复框架。
诊断基准叫 TableParseMap。它收集了 916 张真实复杂表格，并从两个视角打标签：一个是“输入为什么难”，另一个是“输出怎么错”。这两个视角很重要，因为它们回答的是不同问题：前者帮你预测风险，后者帮你定位修复方向。
“输入为什么难”包括五类：
- 📋 大表：行列太多、太密，超过模型可靠处理范围；
- 🫥 弱视觉证据：模糊、低分辨率、压缩、背景干扰；
- 🧠 隐式语义表：边框不完整，要靠空白、对齐和语义推断结构；
- 🔁 高同质表：相邻行、列或空白长得太像，容易数错；
- 🌀 不规则表：复杂表头、嵌套、子表和奇怪的合并单元格。
图说：这张图是论文的“病历模板”，左边回答“症状是什么”，右边回答“什么环境容易诱发”。
“输出怎么错”分成九类，其中结构错误包括错位、漏内容、冗余、重复、合并单元格错误；文本错误包括公式、特殊符号、普通文本和换行。标注时采用结构优先规则：如果结构错了导致文字也丢，就算结构错误，而不是把它拆成两个问题。
为什么这个基准有杀伤力？因为最强直接解析器 MinerU2.5-Pro 在 TableParseMap 上也只有 85.03 TEDS。TEDS 可以粗暴理解为“表格还原准确度”，同时看结构和内容，满分 100，越高越好。也就是说，在故意挑出来的复杂样本上，高分模型并没有真的通关。
我的读法是：TableParseMap 不是要证明这些模型不行，而是要证明“平均分”掩盖了失败模式。你在生产里遇到的往往不是平均表格，而是那几张跨越多页的财务大表、无框线的研究报告附表、扫描得有点糊的统计年鉴。平均分救不了你，分类诊断才有用。
🛠️ 它的思路是什么？
修复框架叫 DEC，全称 Decompose–Enhance–Correct。它的核心姿态很工程：冻结解析器，外挂控制器。
也就是说，MinerU、PaddleOCR-VL、GLM-OCR 还是负责它们擅长的表格识别；通用视觉语言模型不接管识别，而是当“工头”，决定要不要干预、怎么拆、用哪个工具、什么时候接受修改、什么时候回滚。
图说：看懂这张图的关键是“识别执行器”和“控制策略”分离；左边还是原来的解析器，右边才是 DEC 的附加值。
DEC 的流程可以拆成五步：
- 先路由：VC-Gate（Visual Consistency Gate，视觉一致性门）把原始表格图像和解析结果的 HTML 渲染图放在一起比较。看起来已经可信，就直接返回；可疑，才进入后续流程。
- 拆大表：Decompose 找结构安全边界，把大表切成局部块，避免把一行、一个单元格或跨行跨列区域拦腰切断。
- 增强证据：Enhance 保留一张不可变的 Reference View，同时编辑一张 Working View；可以做表格区域裁剪、对比度归一、语义 scaffold、单元格锚点，然后让冻结解析器重新读。
- 修残差：Correct 把原图、工作图、当前 HTML 和渲染图放在一起，让 VLM 先诊断差异，再生成候选修复。
- 验收回滚：VC-Ranker（Visual Consistency Ranker，视觉一致性排序器）比较当前结果和候选结果。候选分数没有明显高于当前结果，就不采纳。
这里面最值得学的不是某个工具，而是两条状态设计。
第一条是 Reference View / Working View 分离。原图永远不动，作为裁判基准；增强后的图只用来帮解析器看清证据。这样避免一个常见事故：图像越增强越“好看”，但你已经不知道它和原始证据差多远了。
第二条是 候选更新必须带安全边际。论文的接受规则是候选结果的视觉一致性分数要比当前结果高出 0.05 才采纳，否则保留旧结果。这个设计很像数据库事务：agent 可以提议修改，但不能悄悄污染一个还不错的 baseline。
图说：这张图展示了 DEC 真正下手的三类场景：不是泛泛地“多想一会儿”，而是针对规模、证据和一致性做不同操作。
为什么这个路线对开发者有意思？因为很多生产系统根本不敢动底层模型。你用的是闭源 API、固定版本服务、客户内网部署，或者只是不想为了几类表格失败重新标注一批数据。DEC 的假设正好是：参数拿不到没关系，输入图像和输出 HTML 还在你手里，那就有机会在推理时做控制。
📈 效果到底怎么样？
论文构造了一个更难的 Consensus-Hard Set：从 4,556 张候选表里，保留至少被两个异构解析器都判为困难的 1,977 张。这个筛选比“某一个模型失败”更严格一些，也更不容易只针对单一模型的短板调参。
在这个硬案例集上，DEC 用 Qwen3.5-397B 做控制器，三个冻结解析器的结果是：
- MinerU2.5-Pro：70.92 TEDS 提升到 72.18，增加 1.26；
- PaddleOCR-VL-1.6：67.50 提升到 69.41，增加 1.91；
- GLM-OCR：69.13 提升到 70.68，增加 1.55；
- 三者平均：提升 1.57 TEDS。
如果你只看 Overall，会觉得这是小提升。但换到 TableParseMap 的大表子集，三个解析器分别提升 6.02、5.02、5.94，平均 5.66 TEDS。这更符合 DEC 的设计逻辑：它不是全面提升所有 OCR 能力，而是对“规模不匹配”这类结构性失败下手。
还有一个很关键的反例：MinerU2.5-Pro 在文本错误组从 86.13 降到 85.89 TEDS，公式、普通文本和换行也有轻微回退。这个结果反而让我更相信报告的诚实度。DEC 不是万能修正器，它更像结构修复器；原本文本识别已经很强的模型，被 agent 改来改去未必有收益。
消融实验也值得看。对 51 张大表，固定切分会把 TEDS 从 82.565 拉低到 81.960，而 agent-guided split 提到 87.268。也就是说，“把表切开”本身不是收益，切对地方才是收益。
Enhance 同理：所有增强工具无差别全开，TEDS 从 67.791 掉到 65.980；选择性使用则提升到 68.323。这很符合工程直觉：对比度、裁剪、scaffold 都是带副作用的手术刀，不该当成每天必用的保养品。
图说：这张图回应了 agent 框架最常见的问题：会不会每次都跑满预算？论文的答案是，大多数时候不会。
效率上也有个亮点：在 4,556 张表的完整池子里，VC-Gate 只让 43.0% 的输入进入 DEC，却保留了 Always-on DEC 约 97.5% 的 TEDS 增益；平均额外 parser calls 从 0.924 降到 0.487。换句话说，它确实把算力花在更可疑的表上，而不是每张表都大动干戈。
💡 为什么你要关心？
如果你做的是文档解析、RAG、数据抽取或任何把 PDF 表格变成结构化记录的系统，这篇论文至少有三个可以直接借鉴的点。
- 🧭 给解析结果加渲染验收：把预测 HTML 渲染回图片，再和原图比较。这比只看文本相似度更贴近表格的空间结构，也可以作为线上 hard-case 路由信号。
- 🔒 给 agent 加安全边际和回滚：任何 LLM 修改都先形成候选，再由独立验收器决定是否提交；低于旧结果就回滚。这个模式比“让它自我反思三轮”更适合生产。
- 🧩 把失败类型接到工具上：大表走拆分，弱证据走增强，渲染不一致走诊断修正。不是所有失败都该丢给同一个“再想一想” prompt。
换个角度看，这篇论文也在提醒我们：文档智能的瓶颈正在从“平均准确率”转向“失败模式管理”。平均分解决的是模型排行榜，失败模式解决的是生产可用性。后者才是接入 RAG、审计、财务和知识库时真正让人加班的东西。
不过我也倾向于把它理解成一个架构参考，而不是立刻可复用的开源组件。论文版本还没有公开代码和数据；你要复现完整 DEC，需要 VC-Gate、VC-Ranker、渲染器、工具实现和 prompt 细节，这些都不是看流程图就能拼齐的。
🤔 理性看待
这篇的评估集刻意偏向困难样本，所以不能把 1.57 或 5.66 的提升直接换算成自然业务分布下的收益。它能说明 DEC 在 hard case 上有效，但不能说明你的日常文档池也会稳定提升这么多。
另一个需要保留的地方是同源风险：TableParseMap 来自作者对多个解析器失败的审计，DEC 的工具与失败分类又面向这些问题设计，而 Consensus-Hard Set 也包含 602 张 TableParseMap 样本。论文做了阈值前置、训练评估不重叠、跨解析器验证，这些都能缓解偏差，但更稳的证据仍然需要完全外部的生产集测试。
最后，论文没有和 ParseFixer、OCR-Agent 这类外部 agentic baseline 做头对头比较，也没有报告置信区间或多次重复实验。对内部 baseline 和消融来说，证据相当扎实；对“当前最佳 agentic 文档解析方案”这种说法，现在还不到下结论的时候。
作者：lusca
版本：lusca-paper-blog v1.5.0
出处：https://github.com/yjmm10/lusca-skill/tree/main/skills/lusca-paper-blog
