![氛围图](https://developer.qcloudimg.com/http-save/8729876/51167df4e372317fc782f2f2bc494c4a.jpg)

> 💡 **一句话总结**：这篇论文把“公开基准高分但真实复杂表格仍翻车”的问题拆开诊断，再用 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](https://arxiv.org/abs/2608.09842)
> - 📄 PDF：[arXiv PDF](https://arxiv.org/pdf/2608.09842)

## 🧩 这篇论文到底想解决什么问题？

论文《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 的流程可以拆成五步：

1. **先路由**：VC-Gate（Visual Consistency Gate，视觉一致性门）把原始表格图像和解析结果的 HTML 渲染图放在一起比较。看起来已经可信，就直接返回；可疑，才进入后续流程。
2. **拆大表**：Decompose 找结构安全边界，把大表切成局部块，避免把一行、一个单元格或跨行跨列区域拦腰切断。
3. **增强证据**：Enhance 保留一张不可变的 Reference View，同时编辑一张 Working View；可以做表格区域裁剪、对比度归一、语义 scaffold、单元格锚点，然后让冻结解析器重新读。
4. **修残差**：Correct 把原图、工作图、当前 HTML 和渲染图放在一起，让 VLM 先诊断差异，再生成候选修复。
5. **验收回滚**：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



💡 一句话总结：这篇论文把“公开基准高分但真实复杂表格仍翻车”的问题拆开诊断，再用 DEC 在不重训解析器的前提下做拆表、增强、修正和回滚；它不是万能 OCR 升级，但给冻结模型和闭源解析器提供了一条很工程化的补丁路线。

DEC：别急着重训，先让表格解析器再检查一遍

人工智能

开发工具

后端

论文针对公开基准高分但真实复杂表格解析仍失败的问题，提出诊断基准TableParseMap与修复框架DEC，在不重训解析器前提下，通过路由、拆表、增强、修正及回滚机制，有效提升MinerU等模型在困难样本上的表格结构还原准确率。

结构化数据

数据库

路由

Agent

2026上云采购 | AI焕新·智启新局

documentocr

lexiang

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

DEC：别急着重训，先让表格解析器再检查一遍-腾讯云开发者社区-腾讯云

DEC：别急着重训，先让表格解析器再检查一遍

DEC：别急着重训，先让表格解析器再检查一遍

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐