论文接收通知弹出来的时候我刚把手头最后一版表格纠错脚本跑完。回想这个项目从想法到定稿的过程最核心的那句话其实就是标题里写的先看懂结构再生成答案。StrucTab 这套方法最终被 ECCV 2026 接收但它在我的实操中真正解决的问题不是又刷高了一个指标而是把表格问答从黑盒猜答案变成了有据可查的结构化推理。如果你正在做文档理解、表格抽取、PDF知识库问答或者只是被从截图里问表格问题这件事折磨过下面这些内容大概率会戳中你。这篇博文我会从动机、模型设计、训练细节、实验结果、落地踩坑到后续方向全部摊开来讲。不吹方法论的花哨程度只讲哪些设计是真的有用哪些地方我们返工了不止一次。1. 表格解析为什么难从看到到看懂之间隔着一个结构1.1 表格的二维性把一维模型的底裤全掀了文本的阅读顺序是线性的从左到右、从上到下Transformer 处理起来天然顺手。但表格是二维信息载体信息藏在行列交叉和表头层级里而不是藏在某一个 token 的上下文里。举个例子一个销售报表里有季度区域销售额三列下面若干行其中季度单元格跨了两行。这种跨行合并在视觉上是一个大格但在文本序列化之后它会被表示成季度、Q1、Q1之类的重复文本模型根本不知道这三个 token 其实共同属于某一个原始单元格。你做问答时问Q1 华北的销售额是多少模型可能在序列里找到华北销售额然后生成了一个看似合理的数字但它并不知道自己引用的到底是哪个单元格、这个数字对不对齐。这就是我常说的表格问答的问题一半以上不是语义理解的问题而是结构定位的问题。1.2 端到端生成式方案的典型翻车现场我们在项目早期踩过一条弯路直接用多模态模型输入表格截图和问题输出答案。效果不能说完全不能用但翻车的姿势极其统一答案引用错位问2023 年毛利率最高的区域模型答华北实际上答案是华东因为模型把表头第二行的区域名和第三行的数值错位对齐了数字张冠李戴问研发费用占营收的比例模型把利润表里的数字当成研发费用因为序列化之后研发和费用两个词出现在同一个上下文窗口里但它们的结构归属完全不同合并单元格语义丢失跨两行的表头模型读了上半部分就忽略了它覆盖的所有行答案对但过程不可信偶尔模型答对了但你追问这个数字来自哪一行哪一列它完全说不出来。这在金融、医疗场景里是不能接受的。这些现象背后的原因其实挺简单端到端模型把定位结构和语义推理揉成了一个隐式过程但它既没有显式的行列概念也没有强制性的单元格对齐约束。模型只是学会了看起来像答案的文本延续而不是真的从表格里查到了答案。1.3 一个反直觉但极其重要的实验观察让我们真正转向先结构、后答案路线源于一个中间实验。我们把一个已训练好的端到端问答模型做了个改动不直接输入原始表格而是先把表格解析成带行列标签的结构化表示再喂给模型。结果非常直观——答案准确率直接涨了近 10 个百分点。这个实验强烈暗示了一件事模型其实具备一定的语义推理能力它缺的不是理解问题的能力而是知道数据在哪里的能力。换句话说只要把结构信息显式喂进去它能更好地发挥自己的推理能力。由此StrucTab 的核心设计定了下来两阶段。第一阶段做结构归纳Structure Induction把表格还原成一张结构图第二阶段做有据可答的答案生成Grounded Answer Generation模型必须看着结构图、引用具体单元格来回答。2. StrucTab 的建模路线先把表格还原成一张可查询的图2.1 表格结构图的定义不止是行列我们最初的想法很简单把表格提成行 列就够了。但真正做了才发现真实表格远比理想模型复杂——跨行合并、跨列合并、三层表头、表头在中间、斜线单元格。于是我们把结构表示升级成了一张有向图节点每个视觉上的单元格包括合并后的整体大格是一个节点带边界框和文本内容同行关系同属一行的单元格之间连边同列关系同属一列的单元格之间连边覆盖关系Span如果某单元格跨越了多行或多列它和它覆盖的所有单元格之间建立从父格到子格的边表头归属某些单元格在语义上是表头节点它覆盖下方若干数据行。这张图并不复杂但它把表格最关键的三种信息都装进去了物理位置、行列归属、合并结构。有了它一个模型就可以很自然地回答Q1 华北的销售额这类问题——先通过覆盖关系找到 Q1 对应的行集合再通过同列关系定位销售额列最后在交叉点找到数值单元格。从工程角度说图表示还有一个隐藏优势它可以把表格的视觉形态和语义内容解耦。视觉上有线框还是没有线框不影响图结构同一张表的不同排版版本只要内容一样结构图就一样。这让模型在一个来源上学到的表结构能迁移到另一个来源上。2.2 两阶段管线结构先于语义StrucTab 不做端到端的图像到答案而是分成明确的两步阶段一结构归纳。输入是表格图像和 OCR 出来的文本 token每个 token 带二维坐标输出是上面说的表格结构图。这一步本质上是看懂表格长什么样——预测每个单元格的边界框预测单元格之间的同行/同列/覆盖关系。阶段二有据答案生成。结构图连同原始图像特征、OCR 文本一起送入一个解码器。模型在生成答案的每一步都可以选择复制图中某个单元格的内容或者参考某几个单元格的结构关系做推理。最终输出的必须是一个指向真实单元格的答案——它不仅要生成文本还要顺带生成答案对应的单元格引用。为什么坚持两阶段而不是一个模型全干了我们评估过端到端的联合训练方案效果其实也不差但它有两个致命短板第一中间结构不可见模型答错了你不知道是结构错了还是推理错了第二没法做人工干预——结构错了你不能只修正结构只能从头重跑。两阶段方案在这两个问题上天然友好结构阶段模型输出的东西可以直接可视化人工瞄一眼就知道表格是不是被理解对了。2.3 为什么不直接用表格转 Markdown/HTML 喂大模型可能有人会说把表格序列化成 Markdown 或 HTML然后喂给大语言模型不是更省事吗坦白说这条路我们在项目早期试过效果差距很大。问题出在序列化本身是有损的。Markdown 表格要求每个单元格都有文本但真实表格里大量单元格是空的跨行合并的单元格在 Markdown 里根本表达不了三层表头序列化之后层级关系全靠缩进猜测。HTML 稍好一点但 OCR 出来的文本明显错位时HTML 的行列结构也会跟着错。更重要的是序列化之后的表结构是隐式的——模型得自己从文本里重新推断行列关系。而 StrucTab 的结构图是显式的——每个单元格、每条关系都是模型明确预测出来的。显式结构的容错性高得多因为你可以对结构做后处理修正再丢给生成阶段。3. 核心模块与实现细节结构头、关系预测、对齐解码3.1 输入编码图像特征和文本特征怎么融合很多失败的表格模型问题出在输入侧把图像和文本分开处理只在最后简单拼接。我们这里做了一个关键处理给每个 OCR 文本 token 附加二维位置嵌入。每个 token 的特征由三部分组成文本编码器输出的语义向量、归一化后的坐标 [x1, y1, x2, y2] 映射成的位置向量、所在视觉区域的图像特征。三者融合后输入交叉注意力层和全局视觉特征反复交互。这个设计的直观含义是模型在阅读一个 token 时始终知道这个字在图像的哪个位置从而能建立文本-位置-视觉三者对应。这个设计的直接收益是处理合并单元格时模型有了依据。合并单元格虽然只有一个文本但它的边界框覆盖了多行多列视觉特征里天然包含了大范围空白区域。模型结合大边界框和区域视觉特征更容易判断出这是一个 span 节点。3.2 结构预测头的设计检测、关联、回归结构阶段我们用了三个并行头单元格检测头基于融合特征预测每个单元格的边界框。我们用了类似无锚框的检测方式直接预测中心点加宽高。单元格目标本身就比通用目标检测简单因为表格里大多数格子排列规整这个头收敛得很快关系分类头对候选单元格对做关系预测。不是全图两两配对——那计算量太大——而是先用强先验缩小范围边界框在垂直或水平方向重叠的才做配对。每个候选对预测三种关系概率同行、同列、覆盖坐标回归头处理扫描件里的轻微倾斜和形变对边界框做精细化回归。结构损失是检测损失和关系分类损失的加权和。我们实验中发现关系分类损失的权重可以稍微调大一点因为最终对问答质量影响最大的是关系判断对错而不是边界框差一两个像素。# 伪代码StrucTab 结构预测与答案生成主流程 def stractab_inference(table_image, ocr_tokens): # 阶段一结构归纳 visual_feats vision_encoder(table_image) text_feats text_encoder(ocr_tokens, token_positions) fused_feats cross_attn(visual_feats, text_feats) cell_boxes cell_detection_head(fused_feats) cell_pairs build_candidate_pairs(cell_boxes) # 用重叠先验剪枝 row_rel, col_rel, span_rel relation_head(cell_pairs, fused_feats) table_graph build_table_graph(cell_boxes, row_rel, col_rel, span_rel) # 阶段二基于结构生成答案 graph_feats graph_encoder(table_graph, fused_feats) answer grounded_decoder(graph_feats, question_embedding) return answer, table_graph, cell_boxes3.3 解码器的看结构机制让答案扎在单元格上答案生成阶段我们最看重一件事生成的答案必须可以追溯到具体单元格。为此在解码器里加了一个结构感知的指针机制每个生成步解码器可以决定从结构图里复制某个单元格的文本还是生成一个常规 token当选择复制时模型会额外输出一个单元格索引这就是答案的引用位置训练时我们要求答案里涉及的每一个关键数值都要存在对应的单元格引用否则这个样本算错。刚开始我们只做了复制机制但发现有些问题是需要多步推理的——比如求两个区域销售额之和答案不是任何一个单元格的文本。后来我们放开成混合生成允许模型先引用相关单元格再做简单算术生成一个新 token 序列。效果比纯复制或者纯生成都好因为模型有了稳定的抓手。3.4 训练策略先结构后问答合成数据打底训练上有两个经验非常关键。第一两阶段训练比联合训练稳定得多。我们先单独训练结构阶段直到收敛——通常两三个 epoch 就够——然后把结构头固定再训练答案生成阶段。如果一开始就联合训练结构阶段还没学好的时候生成阶段会疯狂根据错误结构猜答案两边的梯度相互干扰收敛很慢。第二合成数据是结构阶段的主力。真实标注表格结构非常贵——一个合并单元格复杂点的表格人工标注就要几分钟。我们写了一个表格渲染器随机生成各种结构随机行列数、随机合并、随机表头层级用 HTML 渲染成图像再加随机字体、边框样式、纸张噪声、透视扰动。这样一天能生成几万张带精确标注的表格图。效果上结构阶段在合成数据上训练完迁移到真实扫描表格时已经能到可用的水准之后再用几千张真实标注微调就能稳定上去。4. 实验设置与结果解读结构带来的提升到底有多大4.1 评测基准怎么选我们用了两类公开基准来验证结构识别基准包含大量带行列表格、合并单元格、多层表头的表格图像指标是单元格检测 F1 和结构关系准确率表格问答基准给定表格图像和自然语言问题要求输出答案并给出答案对应单元格。我们额外加了一个评测维度——引用准确率即答案引用的单元格是否真的包含了答案内容。这个指标是很多同类工作不报的但恰恰是落地时最需要的。为了让评测更狠我们自己构建了一个困难子集专门挑有合并单元格、表头跨行跨列、表格内嵌图像的样本。目的就一个别让模型在简单表格上刷分复杂表格上翻车。4.2 主要结果对比摘录几个代表性的数字与我们自己的复现基线对比方法结构 Cell F1答案 EM答案引用准确率基线A端到端多模态生成未建模76.8无法计算基线B表格序列化喂语言模型未建模81.238.5StrucTab无引用模块92.385.9—StrucTab完整版92.389.484.7表格序列化方案比端到端强一点但引用准确率只有三成多这意味着它答对的答案里有一大半根本不知道出处。StrucTab 的答案引用准确率能做到 84.7%这个数字对实际业务来说才是能用的模型告诉你答案同时告诉你答案在哪一格用户可以一键跳过去复核。4.3 消融实验每一项设计都在干什么我们做了几组消融结果挺有意思去掉结构阶段恢复端到端答案 EM 掉了大约 9 个点。这就是前面说的核心观察——直接生成答案结构信息确实会被模型隐式学到一点但学得远远不够去掉视觉特征只用 OCR 文本和坐标结构 Cell F1 掉了大约 5 个点集中体现在合并单元格和无线框表格上。视觉特征对判断哪些格子是一个整体帮助极大去掉引用约束答案 EM 掉了 2-3 个点引用准确率掉了近 20 个点。引用约束不仅仅是可解释性的加分项它像一个正则化器逼着模型在生成每个关键数字时找到结构依据反而提升了准确性。4.4 效率与部署成本结构阶段和生成阶段加起来单张表格在单卡上约 1.2 秒完成解析和回答。结构阶段本身只需要 0.4 秒这给了工程上一个很重要的操作空间同一张表格的多轮问答结构只解析一次不同问题共享同一张结构图。实际问答系统里用户常常连续问好多个问题这时候首问 1.2 秒、后续每问 0.8 秒的体验会好很多。模型规模上我们控制了结构阶段在十亿参数以内生成阶段也做了量化整体可以单卡部署。5. 复现与落地中踩过的坑三个真实问题5.1 合并单元格结构图里最容易翻车的地方合并单元格是几乎所有表格模型的天敌我们也不例外。初期版本里跨两行的父格总会漏掉子格的关联导致Q1 华北销售额这类问题完全找不到 Q1 对应的行集合。排查之后发现问题出在边界框标注上。人工标注时有人把父格标注成一个大框有人把父格拆成两个虚拟小框。两种标注语义不一致模型直接学乱。我们的解决方法统一标注规范父格只允许标注为一个整体节点子格保留自己的独立节点父格和子格的关系在建图时自动生成。这个规则一固定模型的学习目标就清除了相关错误降了一半以上。经验是结构标注的一致性比标注数量还重要。宁可少标不可标乱。5.2 长表格跨页切片切不好结构全乱真实业务里很多表格一页放不下会跨页打印或截图分割。直接切图的话切在数据行中间上半部分和下半部分的行关系就断了模型无法判断这个数字属于哪一行。我们的做法是分级处理先做全局版面分析判断哪些区域是同一张表格的分页然后对每一页单独做细胞识别但行关系从全局页面上继承——也就是说跨页的行不会被强制合并但列关系可以跨页对齐。同时把表头信息在跨页时冗余传给生成阶段即使第二页没有表头模型也知道当前列的语义。工程上我们做了一个表格状态保持机制处理完第一页后把表头和列结构缓存起来第二页进来时先做结构对齐再走答案生成。实测跨页表格的答案准确率从 61% 提到了 82%。5.3 扫描噪声和无线框表格别让模型依赖分隔线扫描件里的表格线框可能是断的、有污渍、有阴影也有很多表格是无线框的只有留白分隔。初期模型很依赖视觉上的分隔线一旦线框断裂就疯狂漏检。解决思路是把分隔线作为辅助特征而不是必要条件。我们做数据增强时随机擦除一部分线框、加入噪声、模拟印章遮挡让模型学会用文本的位置分布和留白来判断单元格边界。另外把纵向和横向的空隙特征显式编码进结构头——两个文本块之间空白很大大概率是不同列的边界。实测带这类增强的模型在无线框表格上的 Cell F1 涨了约 7 个点。5.4 几个可以少走弯路的工程建议先可视化结构图再谈优化。结构阶段每一步都要输出结构图可视化肉眼检查比任何指标都更快发现问题后处理规则不能省。例如答案引用的单元格必须存在于结构图中如果不存在模型输出直接拒绝跨行表头在生成答案前自动把覆盖关系展开到对应行输出校验做成硬约束。金融、医疗场景里模型答错问题比不答更危险。我们最终版本里只要答案的单元格引用缺失就把答案标为不确定宁可拒答也不硬猜。6. 落地之后的个人体会与后续想法这个项目做到后期最大的体会不是模型结构有多精巧而是显式结构这个概念的价值被完全释放出来了。结构阶段让错误变得可见模型答错了你看一眼结构图就知道是行列关系错了还是推理错了修起来有方向。这在面对客户或业务方时尤其重要——你可以指着结构图说模型在这里把行对齐弄错了我们改训练数据就行而不是一句模型不太行。后续方向我比较期待三个跨表推理多张表格联合回答比如A表里的客户名单在B表里对应的销售额总和这需要表格图之间建立实体对齐关系表格与自由文本混排版面里表格周围还有文字说明问题可能既涉及表格又涉及文字结构和文本的联合推理目前做得还不够手写表格手写单元格的边界和内容都更模糊结构预测和 OCR 得联合优化。如果看到这里你也想动手我的建议很简单先别急着做问答找一批多样化的表格图像把结构预测这件事做到稳定再往上加问答。结构是地基地基稳了后面所有功能都踏实。实测下来这一步也是最值得花时间的。
