表格解析这个方向，我前后折腾了快两年，从最开始被各种合并单元格折磨到想摔键盘，到后来慢慢摸到门道，再到这次工作被接收，算是把这个“小领域”的坑基本踩了一遍。这篇东西就是想把StrucTab这套方案从思路到落地完整梳理一遍，特别是“为什么非要先看懂结构、再去做答案生成”这个核心设计，以及我们在数据、训练、推理里踩过的一堆坑。如果你正在做文档理解、版面分析、表格抽取或者表格问答相关的工作，这篇文章应该能帮你省掉几个月的摸索时间。
先说清楚这工作解决什么问题。表格问答这类任务，输入是一张表格图片（或者扫描件里的表格区域），输出是对自然语言问题的答案。听起来不复杂，但实际做过的都知道，复杂报表里的跨行跨列、嵌套表头、单元格里塞好几行文字，这些能把纯粹靠文本生成答案的模型直接搞懵。我们的思路很简单却有效：先让模型把表格的完整结构（行、列、合并范围、层级关系）恢复出来，再基于结构化的表格内容生成自然语言答案。整套方法最后在几个公开的表格理解和问答基准上都有明显提升，也因此拿到了ECCV 2026的接收。下面全是实操细节。
1. 项目整体设计与核心思路拆解
1.1 为什么“先结构、后答案”能成立
先想一个问题：当你人眼看一张复杂表格时，是怎么回答“西南地区第二季度销售额是多少”的？你大概率不是直接从像素里找答案，而是先分辨出这张表有几行几列、表头在哪、哪个单元格属于第二季度、哪个单元格属于西南地区，然后才做运算。StrucTab就是把这条人类认知路径搬进模型。
结构信息对答案生成的价值，实验上验证得非常明显。我们在初期用纯端到端的图像到答案模型做了一版基线，那种模型在简单表格上还能蒙对几个，但一旦表格出现跨行合并、多层表头，准确率直接腰斩。原因不难理解：跨行合并的单元格在图片上占据的是多行的纵向空间，但语义上只是同一个内容；多层表头则意味着列名不是顶层就能拿到的，可能藏在第二层甚至第三层。图像编码器面对这些情况时，很难自动把“视觉元素”和“语义单元格”对应起来。
结构先行等于先把这张表翻译成一种无歧义的规范表达，告诉后续模块“这个单元格覆盖了哪几行、几列”。下游生成答案时，只需要在这个已经理顺的空间里做信息检索和推理，难度显著降低。我们的消融实验里有一个很直观的数据：把结构识别结果当作额外输入注入问答模型，比直接用视觉特征做跨模态注意力，准确率能高出十几个点。这印证了核心判断——模型不需要从零去隐式猜测表格布局，它只需要学会基于显式结构做推理解读。
1.2 两阶段方案 vs 端到端方案：选型背后的辩论
内部讨论时，有同学主张一步到位做端到端，认为反正有注意力机制，模型自己会学会对齐。这个观点不能说错，但工程现实告诉我们，端到端方案在表格任务上有三个绕不开的硬伤。
第一是序列化顺序问题。表格本质是二维的，但生成式模型只能用一维序列输出。不同单元格的扫描顺序（按行扫描还是按列扫描）会深刻影响模型的理解难度。纯端到端模型为了生成答案，必须隐式地死记“这张表大概是什么扫描顺序”，一旦表格排版复杂，这种隐式建模就很容易出错。第二是文本与结构纠缠。一个单元格既包含文字内容，又包含位置语义，如果模型不显式分离两者，生成的答案往往在“看起来合理”但定位错误的地方翻车。第三是可解释性差。端到端模型给不出任何中间产物，出错时你根本不知道是图像识别错了、文字理解错了还是推理错了，排查成本极高。
两阶段方案虽然在延迟和显存上多付出一点代价，但换来了清晰的中间产物和可插拔的调试点。我们在实际操作中可以把结构识别模块单独评测、单独优化，也可以单独替换文本识别模型，这种模块化对工程排错非常友好。而且表格问答本身对实时性要求不高，多在离线批量场景，多花的几十毫秒完全可以接受。所以最终选择了“结构识别 + 结构感知问答”的两阶段路线。
1.3 结构中间表示与视觉特征提取的全局设计
确定了整体路线后，最需要敲定的就是“结构上做哪种级联”。我们前前后后对比过三种结构中间表示：检测式（直接回归每个单元格的边界框和行列属性）、图式（把表格建模成图结构，节点是单元格，边是行列关联）、生成式（把表格转成一种轻量标记语言序列）。检测式的长处是定位精确，但很难表达跨单元格的层级关系；图式表达能力强，但训练和推理的复杂度都更高，且后续问答模块用起来不够方便；生成式虽然在像素定位上稍弱，但胜在格式通用，后续模块可以直接解析序列，不需要额外做图遍历。
最后我们选了“标记语言序列 + 单元格边界框”的混合表示：主干输出一段跟表格结构一一对应的序列，序列里每个单元格token旁边附带着它的归一化坐标。之所以保留坐标，是因为问答阶段经常需要回答“位置相关”的问题，比如“哪个产品在表格的最右边一列”，没有坐标就完全没法答。序列部分负责逻辑结构，坐标部分负责空间定位，两者互补。
视觉特征上，我们用的是常规的视觉backbone加多尺度特征。这里有个关键经验：表格图像和自然图像的分布差异很大，直接用预训练好的视觉模型也能跑，但在表格数据上做几轮微调再进主网络，效果提升非常可观。因为表格图像的边缘信息、文本纹理占比高，模型需要适应这种“信息密度极高但类目单一”的画面。
2. 结构表示与关键模块设计
2.1 结构解析的中间表示：从表格到坐标
StrucTab的表格结构识别头输出的是这样一个序列结构：先把表格拆成行，每行里按顺序列出单元格，如果某个单元格跨越了多行或多列，序列里会用特殊token标记跨度。例如一个3行4列表格，第一行第二个单元格跨了两行，那么序列会是：表头标记、行开始标记、单元格tokens、列跨度标记、行跨度标记……每个单元格token后面还会附带一个bounding box，表示它在图像上的归一化范围。
这个表示形式有一个好处：下游问答模型可以直接把它当作文本序列“读”进去，不需要额外设计复杂的结构化编码器。劣势在于，当表格非常大（比如几十行几十列）时，序列会特别长，Transformer的显存压力很大。针对这个问题，我们在训练时会做随机裁剪，推理时则走“切块-局部识别-全局拼接”的路子，这部分细节留在后面章节展开。
坐标部分我们做了归一化处理，统一除以图像宽高。实际操作中，坐标必须跟视觉特征对齐，所以坐标分支的监督信号来自单元格标注的边界框，而不是OCR出来的文本框。两者有本质区别：标注框代表的是语义单元格范围，OCR框是文字块的外接矩形。一开始我们图省事用过OCR框做监督，结果模型学到的是“漂浮的文字碎块”，结构识别一塌糊涂，后来强制切回标注框才正常。
2.2 结构感知编码器怎么融合图像与文本
很多做表格任务的同行喜欢把OCR结果直接拼成字符串塞给模型，这种做法的天花板很低，因为文字顺序一乱，结构就全乱了。我们做的是把视觉特征、文本特征和结构token三者做交叉注意力，保证文字信息只有在“知道自己在哪个单元格”的前提下才会被激活。
具体来说，视觉backbone抽出的特征会经过一个可变形注意力层，结合一组“单元格查询”来预测每个单元格的存在性和坐标。这些单元格查询不直接由文本驱动，而是由视觉特征驱动，确保模型先去图像里找“这块区域像一个表单元格”的证据，再去读里面的文字。得到单元格候选后，我们再组装成结构序列，送入一个双向编码器做上下文增强。
有一个环节容易被忽略：时序位置编码。表格结构本身没有天然的顺序，但序列化后必须给每个token一个位置。我们试过一维正弦位置编码，也试过二维相对位置编码，后者更贴合表格的二维本质。实验数据显示，二维位置编码能明显减少跨行跨列时的混淆错误，尤其对“同样两行，先左后右和先上后下”的歧义有很好的消解效果。如果你复现时发现结构识别结果老是张冠李戴，优先检查位置编码是不是被省掉了。
2.3 生成答案时，结构信息怎么“用起来”
结构识别完只是走完一半，另一半是把结构信息注入答案生成。这里我们踩过一个弯路：一开始把结构序列和问题、图像特征全部拼在一起，让解码器自己决定用哪些信息。结果发现解码器很容易被长结构序列带偏，注意力分散在无关单元格上，答案反而变差。
后来我们改用一种更“霸道”的注入方式：先生成一个结构感知的全局内存向量，这个向量聚合了各个单元格的语义，再让答案解码器只跟内存向量做交叉注意力。简单理解就是让结构信息先被压缩成一份“表格摘要”，解码器在这份摘要上找答案，而不是在庞大的原始结构序列里翻找。测试下来，答案准确率又涨了一截，而且收敛速度快了很多。
此外，答案生成的解码策略我们选了beam search，beam size设为4，长度惩罚调成1.2。这个组合在多个表格QA场景里表现最稳定。调大beam size反而会出问题，因为表格答案通常很短，候选越多样越容易混入“看起来流畅但内容错误”的句子。如果你是做表格问答的，建议在答案长度上卡一个上限，比如不超过30个token，能有效减少幻觉。
3. 数据准备与实操全流程
3.1 训练数据构建：从公开资源到可用样本
数据这块是表格解析最苦的环节，没有之一。我们用的数据有几个来源：一个是公开的表格结构识别数据集，里面每张表格图片都带着标注好的HTML/XML结构；另一个是公开的表格问答数据集，有natural language question和gold answer。问题在于这两类数据集的图像风格和表格复杂度差别很大，结构识别数据里的表格大多是纯表格渲染图，而问答数据里的表格往往嵌在PDF或扫描件里，带着边框噪声和透视形变。
我们的做法是混合训练，但做了大量清洗。第一步是剔除坏样本，包括标注缺失的、图像分辨率过低的、表格内容跟标注对不上的。第二步是做数据配比，结构识别类样本和问答类样本大致控制在2:1，因为问答样本里有独立的答案标注，配对效果好，但结构识别样本越多，模型对复杂版式的鲁棒性越好。第三步是合成数据增强，我们写了一个脚本，把一批公开表格数据重新渲染成不同样式、不同背景色、不同字体的图片，相当于无成本扩充了一倍训练集。
这里给大家一个非常具体的建议：表格数据最好不要全用渲染图，一定要混入一部分拍照/扫描的仿真样本，否则模型在真实场景上的退化非常快。我们专门用图像处理库对表格图片做了随机透视变换、高斯噪声和亮度扰动，模拟手机拍照和扫描仪的降质效果。
3.2 文本检测与识别：如何对齐到单元格
StrucTab的结构识别不依赖外部OCR结果，但问答阶段需要读取单元格里的具体文字，所以文本识别是绕不开的环节。业界常见方案是外挂一个文本检测+识别模型，把识别出的文本按坐标映射到结构识别出的单元格框内。
这里有一个非常隐蔽的坑：检测模型返回的文本行坐标和单元格坐标不是一套坐标系。前者是图像原分辨率的像素坐标，后者是归一化坐标，对齐前必须统一。我们统一先还原到原图坐标，再判断某个文本行是否落在某个单元格框内。判断条件不能只看中心点是否在框内，还要看文本行的IoU——因为跨行单元格里的文本可能很长，中心点在框内但文字已经溢出了。
对齐之后还要做一个后处理：如果一个单元格里检测出多个文本块，需要按阅读顺序拼接。阅读顺序的判断我们直接用了空间位置规则，从上到下、从左到右，特殊情况下用启发式规则修正（比如同一行内左侧优先）。这个后处理在简单表格里足够用，但遇到“一个单元格内有两栏文字”这种排布就会出错。目前我们还没有更好的办法，只能在数据标注阶段尽量避开这种极端样本，或者把这类样本留给未来的端到端方案去解决。
3.3 训练策略：学习率、损失权重与batch size
模型分两条分支：结构识别分支和答案生成分支。损失是多项加权和，包括结构序列交叉熵、边界框回归损失（用Smooth-L1）、单元格存在性置信度损失，以及答案生成的交叉熵。四个loss的权重我们调了很久，最后定为1:0.5:0.3:1。结构序列的监督权重最大，因为后续所有环节都依赖它的准确性；bbox回归损失权重次之，坐标太差会直接污染到问答阶段的文本对齐。
优化器用AdamW，初始学习率放在3e-4，warmup步数是总训练步数的10%，然后按cosine schedule衰减到1e-5。视觉backbone用较小的学习率，比如1e-5，因为它是预训练的，权重稍微动一点就容易灾难性遗忘。batch size方面，受限于显存我们只能用单卡16，但配合了梯度累积到等效64的效果。这里有个经验：表格结构识别任务对batch size极其敏感，大的有效batch size可以显著提升收敛稳定性。如果显存不够，优先累积梯度而不是妥协batch。
混合精度训练我们开了，但结构序列生成的那部分分支保留FP32。原因很直接：交叉熵损失对数值精度比较敏感，FP16在小数值上容易出现梯度消失，导致结构序列的token分布坍缩在几个高频token上。混合精度开完，loss曲线会变得非常平稳，训练速度也快不少。
3.4 推理部署与性能优化
推理时我们先做表格结构识别，再做文本定位，最后走答案生成。整个pipeline里最耗时的是结构识别，因为它要跑视觉backbone加解码器。我们在部署时把视觉backbone切换为TensorRT加速，推理一张512×512的表格图，整体耗时从原来的400ms降到150ms左右，其中结构识别占100ms，答案生成占50ms。
长表格是性能优化的重点。我们的结构识别模型设置了最大序列长度，超过长度极限的表格会被切掉。因为表格切成两张图会丢失跨页的行列关系，我们做了一个小设计：切块时允许一定的行重叠，并在恢复阶段用规则合并重合的单元格。这个方案不是完美的，但在工程上已经足够支撑绝大部分真实报表。
一个值得分享的细节是，推理时解码的beam search和训练时的teacher forcing差别很大。我们在推理阶段做过一个校验：把beam search产生的候选答案拿去重新评分，用长度归一化后的分数做最终排序。这个“二次重排”机制几乎不用额外成本，能稳定提升1-2个点的答案准确率。
4. 常见问题与排查技巧实录
4.1 显存不足与长表格崩溃
问题描述：输入一张行数超过40的长表格，显存直接溢出。
排查步骤：
- 先确认序列长度上限，检查是不是输入分辨率太高导致视觉特征图过大。
- 如果结构序列本身超过2000个token，建议做切块，而不是无限放宽序列上限。
- 切块时优先按行切，并保留重叠两行作为上下文，避免跨块单元格被硬生生拆开。
- 如果切块后两块之间的单元格对不上，可以在后处理阶段用边界框匹配做合并。
这个方案我们在实际调用中表现比较稳。我不建议直接把输入分辨率压到256×256以下，那会严重损失表格线细节，结构识别准确性会掉得厉害。
4.2 跨行跨列单元格识别错乱
问题描述：凡是有跨两行以上的合并单元格，模型就漏掉，或者把跨列识别成跨行。
原因分析：跨行跨列的标注在序列里是一对跨度token，但模型在自回归生成序列时往往只生成了第一个跨度token，可能因为第二个token的出现概率分布不够突出。我们用的缓解办法是给跨度token组合做一个规则约束解码：生成时如果第一个跨度token出现，强制把对应的第二个跨度token加入候选集，让解码器必须在两者都出现的情况下才算完成。这属于后处理干预，但非常有效，漏检率降了大概三成。
4.3 训练不收敛或loss突然升高
问题描述：训练到中期loss突然飙升，或从头就不下降。
排查顺序：
- 先看数据标签是不是有NaN或者文本序列里有非法字符。表格数据标注里经常会出现全角半角混用、空格错位这种脏数据，需要用脚本清洗一遍。
- 检查学习率是否过高。表格结构生成任务对输出分布稳定性要求高，lr超过5e-4很容易飞。
- 看是不是梯度累积造成有效batch突变。累积梯度时如果中间有几步跳过优化，容易造成loss抖动，建议每步都做梯度裁剪，max_norm设为1.0。
- 如果还是不收敛，把损失权重里的坐标项先降为0，只保留序列损失，等序列损失下降后再把坐标权重拉回去。这种分阶段训练法在我们实验里比直接联合训练更稳定。
4.4 评测指标很好但实际体验差
表格结构识别领域常用的一个评测指标是树编辑距离（TEDS），它衡量模型生成的结构跟标准结构之间的相似度。但这玩意儿有个众所周知的“空子”：TEDS对XML标签的文本内容非常宽容，只要结构对，文本错几个字也能拿高分。这就导致有些团队用合成数据刷指标，真实场景却一塌糊涂。
我们在内部单独加了一套指标，叫“单元格内容命中率”：把结构还原后，检查每个单元格里的文字是否和标准答案完全一致。这个指标更接近实际使用体验。如果出现“TEDS很高、命中率很低”的情况，基本可以断定模型的文本读取环节出问题了，优先检查OCR模型的准确性，而不是调整结构识别模块。
注意：评测指标是手段不是目的，一定要建立一套跟真实业务场景挂钩的验收标准，否则容易出现“自欺欺人”的benchmark结果。
5. 实验效果与经验复盘
5.1 对比实验：结构信息带来的提升到底有多大
结构化信息能否带来持续提升，我们做了三组对比：
- 纯图像直接生成答案：只有视觉特征，没有结构序列。
- 图像+OCR文本拼接生成：把OCR文本按阅读顺序串起来，不做结构建模。
- 图像+OCR文本+StrucTab结构序列：完整方案。
结果非常清晰：方案三在表格问答准确率上比方案一高出约18个点，比方案二高出约7个点。这证明了结构信息不是锦上添花，而是决定性因素。另一个值得注意的现象是，方案三对长尾复杂表格（跨行跨列多、嵌套表头）的提升幅度最大，这类样本在简单表格上的差距只有几个点，在复杂表格上能拉出接近二十个点的差距。说明结构建模解决的核心瓶颈正是复杂表格的表达能力。
5.2 我们踩过的一些坑和复盘心得
第一条心得是别在端到端方案上死磕太久。我们前前后后花了将近四个月在端到端方案上尝试各种trick，最后换到“先结构后答案”路线只用六周就达到了更好的效果。任务拆解带来的模块化收益，在这个领域远大于一个“更聪明的端到端结构”。
第二条心得是结构模块和问答模块最好是联合微调，而不是各自训练完再硬凑。我们开始是分开训练的，结构识别准确率很高，但接上问答模块后效果一般。后来用低学习率把两模块一起微调，问答准确率立刻涨了几个点。原因是问答阶段对单元格的语义理解会反哺结构模块的特征表示，让结构识别更关注“对问答有用的单元格”。
第三条心得是后处理规则很重要，但不要贪多。表格领域的后处理规则可以写很多条，比如“列宽度优先”“表头优先级高”“跨行单元格不允许拆分”，每一条都能修掉一些badcase，但规则越多越难维护，也容易让系统在意外情况上炸掉。我们最终精简到七条核心规则，全部放在解码输出之后统一应用，既不侵入模型，也便于线上问题排查。
提示：后处理规则一定要做日志记录。每次规则生效的位置都要能追踪，否则线上出现怪异行为时，你没法判断是模型改错了还是规则互相冲突。
5.3 这个方向下一步还能怎么扩展
StrucTab目前还是聚焦在单张表格图上，但实际业务里大量场景是“跨页表格”和多表关联，比如整份财报里的多张报表互相引用。下一个阶段我们会尝试把结构识别扩展到文档级别，先做版面切分再逐表解析，最后跨表做聚合问答。这中间面临的最大难点是表格的关联referencing如何建模，目前的序列化方法还表达不了这种跨表的关系。
另一个可行的扩展方向是把结构序列直接作为prompt的一部分喂给大语言模型。现有通用大模型在表格问答上表现不好的核心原因就是拿到的表格输入往往是“拍扁的文本”，结构信息荡然无存。我们把StrucTab的结构序列转化成一种接近“带坐标的Markdown表”格式再喂给大模型，小规模实验已经显示出不错的效果。这条路径的想象空间很大，相当于给大模型配备了一个“视觉结构前置处理器”，说不定能顺带解决一部分Agent工具调用里的表格理解难题。
最后再分享一个小经验：做这类表格结构工作，想象力不如动手快——你在纸面上再怎么看都觉得方案是可行的，但一落到真实数据上就会冒出各种反例。我们给模型准备了一套可视化调试工具，把结构识别出的单元格边界框直接叠画在原始表格图上，肉眼一扫就能定位到问题样本。这个工具最大的价值不是给我自己看，而是让团队里不直接写模型的同学也能参与数据分析和规则制定。如果你也打算做表格解析方向，我强烈建议第一周就花时间把可视化调试工具搭好，后面会感谢这个决定。
