金融表格抽取为何难？图神经网络GFTE如何破解结构关系难题

1. 金融表格抽取：看着简单，做起来头疼

1.1 为什么金融表格比想象中难

做文档智能的同学应该都有体会：文字抽取、关键字段抽取，现在用大模型或者成熟OCR工具都能跑个大概，真正让人夜不能寐的往往是表格。尤其是金融场景下的表格——财报附注、招股书、审计报告、信贷审批材料、估值模型底稿——这些东西的版式精密，数字密集，一个单元格错位，后面整条数据分析链路全废。Graph-based Financial Table Extraction（GFTE）这个名字，最早是我在一个模拟项目X里给整套表格解析方案起的代号，后来发现这个思路比我想象中通用，于是整理成了一套可以复用的方法。

为什么金融表格这么难？第一，来源太杂。同样是三大报表，有的来自PDF电子版，有的来自扫描件，有的来自Excel导出后转图片的版本。第二，样式太多。明明是一张利润表，有的带合计行，有的带跨页重复表头，有的把"营业收入"拆成"主营业务收入"和"其他业务收入"两个子行，还有的把多个年份并列排放。第三，数字信息密度极高，一个解析错误会直接被下游财务模型放大。你抽一段文字抽错了，人一眼能看出来；你抽一张表错了一个单元格，监控不仔细的话，这个错误可能一直潜伏到最终报告里。

更麻烦的是，表格的语义不是靠"看到什么字"就能确定的。表格里每个单元格的位置、它和表头的关系、它属于哪个行/列分组、它是不是合并单元格的一部分，这些信息全藏在排版结构里。传统的OCR只能给文本框和置信度，给不出单元格之间的关联。GFTE要解决的，恰恰就是这个"藏在排版结构里的关系"。

1.2 GFTE解决的核心矛盾：表格是关系，不是像素

我们一开始也走过弯路：试图用规则去匹配表格线，用模板去对齐固定版式。规则方案在某个单一版式上可以做到很高的准确率，但一旦换一家券商、换一份招股书、换一个年份的披露格式，规则就崩了。原因很简单：规则描述的是"某个版式长什么样"，而不是"表格是什么"。

后来我们发现，与其死磕版式，不如换个角度：表格本质上是一个由单元格节点和有向关系边组成的结构。行关系、列关系、合并关系、层次关系，都是边；单元格里的文本、坐标、字体、跨行跨列信息，都是节点属性。如果能把表格抽取转换成"预测单元格节点之间的关系"的图学习问题，那么版式差异就只是特征差异，而不是规则差异。

这就是GFTE的核心思路。它跟普通表格识别最大的区别在于：不是先画格子，再去填格子里的字；而是先检测文本区域，再用图神经网络判断哪些文本区域应该组成一个单元格、哪些单元格属于同一行/同一列、哪些单元格之间有父子层级关系。这个思路对金融表格特别有用，因为金融表格经常没有完整的表格线，而是靠缩进、字体、对齐方式来暗示结构。图模型天然容忍这种"弱版面约束"。

2. 先想清楚：表格在计算机里到底是什么

2.1 表格结构的三层拆解

要设计一个表格抽取模型，首先得明确输出什么。我习惯把表格结构拆成三层：

• 内容层：单元格里的原始文本，包括数字、金额、百分比、注释。
• 几何层：每个单元格在页面上的边界框，以及跨行跨列的合并信息。
• 关系层：单元格与单元格之间的行列归属、父子层级、表头与数据体的对应关系。

很多OCR系统做到了内容层和几何层就收工了，给出一堆带坐标的文本框。但在金融场景下，关系层才是最有价值的。一个财务分析师要的不是"页面上第320像素到450像素之间写着净利润"，而是"净利润这个指标，对应2023年这一列，数值是1.2亿，指标层级位于利润表第二层，其上一级是营业利润"。如果没有关系层，前面的坐标和文本就是散沙。

GFTE的输出形式我一般定义为：以单元格为节点、以关系为边的表格图，再从这个图无损还原成HTML表格、Markdown表格或者 DataFrame。这样做的好处是，下游系统拿到的始终是结构化对象，而不是"看起来像表格"的OCR结果。

2.2 表格抽取的常见基线方法及短板

为了说明GFTE的定位，先列出几类常见方案，以及我在实践中感受到的短板。

模板匹配在金融数据抽取里仍然大量存在，因为很多系统只处理固定的几家机构、固定的报表模板。但它的天花板很明显：模板本质上是一种人工特征工程，遇到新型披露格式就得重新写规则。分割方法的问题在于，它把表格当作像素问题，单元格合并信息（rowspan/colspan）经常被忽略，模型看到的是一堆"网格"，但真实表格往往不是规整网格。序列生成方法我也试过，短表格效果不错，但金融表格动辄二十列、四十行，序列化之后标记很长，一旦中间错一个标签，后面全乱。

图方法的直觉是：表格里的单元格自然就是节点，而"同一行""同一列""合并""父子"这些关系就是边。这种表示不依赖表格线是否完整，也不要求表格是矩形网格，更接近表格的语义本质。

2.3 为什么图模型适合表格：单元格天然是节点

我最早对图模型有顾虑：金融表格的单元格数量通常只有几十到几百个，图神经网络是不是有点"杀鸡用牛刀"？后来实测下来，反而觉得刚刚好。

考虑一个简单的场景：一张损益表，第一行是"营业收入"，下面四个子行分别列示主营业务收入、其他业务收入、营业成本、税金及附加。其中"营业收入"这个单元格在视觉上是合并单元格，纵向跨了四行。在像素视角下，它是一个不规则的矩形；在序列视角下，它对应的文本和子行文本的对应关系很难准确建模；但在图视角下，这只是一个边关系：定义"营业收入"节点与四个子行节点之间的"包含"边，以及"营业收入"与同行年份列单元格之间的"对齐"边。

还有一类很常见的情况：表格里某些单元格是空的，但空单元格不是"没有信息"，而是"继承上方或左方的语义"。比如资产负债表里的"流动资产合计"，下面常常是空行占位，后面才出现细分项。图模型处理这种结构比较自然，因为空单元格可以被建模成孤立节点或者与相邻节点存在空间邻近边，后续由后处理规则解释，而不是像序列模型那样必须生成一个标记。

从实现角度讲，图模型还有一个隐藏优势：方便融合不同模态的特征。文本特征可以来自OCR结果，坐标特征可以来自版面分析，字体、是否加粗、是否缩进，都可以作为节点属性拼接在一起。多模态特征融合是图模型天然擅长的操作，这一点在后面构建特征时体现得很明显。

3. GFTE的系统设计与关键模块

3.1 整体管线：从PDF到结构化数据

GFTE的完整管线可以概括为四个阶段：文档预处理、单元格检测与OCR、图构建、关系推理与表格还原。

预处理阶段处理的是PDF或扫描图片的物理问题：页面旋转、插值、灰度化、倾斜校正、去噪。金融扫描件经常有印章、折痕、手写批注，这些噪声如果不过滤，很容易在后续OCR中被误识别成文字。OCR阶段不仅要输出文本，还要输出每个文本行的精确坐标和置信度。单元格检测阶段需要判断哪些文本行应该属于同一个逻辑单元格——这在无边框表格里尤其重要，后面我会专门展开。图构建阶段是GFTE的中间产物：每个节点对应一个逻辑单元格，边则由空间相邻关系、同行同列先验、版面分割线等启发式信息初始化。推理阶段使用图神经网络从初始边出发，预测最终的单元格关系矩阵，再解码成表格结构。

听起来流程很长，但在工程实现上，每个模块都有成熟组件可以替换。GFTE的重点不在某一单独模块，而在"如何把表格结构建模成图，并让模型学会关系推理"。

3.2 单元格检测与文本识别

金融表格里的"单元格"和PDF里"文本框"不是一回事。很多时候，一整个单元格的内容会被OCR拆成三四个文本框，比如"营业收入（万元）"在扫描件里可能被识别成两个文本块；反过来，一个文本框也可能跨越两个逻辑单元格。所以我把单元格检测定义为"对OCR文本框做聚类，聚成逻辑单元格"。

聚类依据有哪些？第一，坐标距离。相邻文本框在垂直方向距离很小、水平方向有重叠，大概率属于同一单元格。第二，字体特征。同一单元格内的文本通常字体大小、颜色、字重接近。第三，阅读顺序。考虑到中文金融表格常见的纵向表头、横向表头交叉，单纯从左到右、从上到下排序是不够的，要结合表格语义。第四，置信度。OCR置信度低的区域需要更保守的聚类，避免把噪声并进单元格。

这个阶段我踩过最大的坑是：表格里的合并单元格在视觉上是一个大矩形，但里面的文本可能横跨在中间偏左位置，周围大片空白。如果聚类逻辑只按坐标距离，很容易把合并单元格里空白的部分当成"无文本区域"，从而忽略这个单元格的存在。所以在聚类时，我会额外使用版面分析中检测到的分隔线、底色块、边框信息，作为辅助信号。这些信号在金融表格里很常见，不能浪费。

3.3 图构建：节点特征、边关系与邻接矩阵

这是GFTE最核心的环节。

节点特征我通常拼接以下几类：

• 文本特征：单元格文本经过编码器得到的向量。金融数字很多，建议在词表中保留数字模式，或将数字归一化为特殊标记。
• 几何特征：归一化中心坐标、宽高、上下左右边界与页面边界的距离。
• 版面特征：是否加粗、是否含货币符号、是否含百分号、文字数量、平均字号。
• 上下文特征：同一页中前后节点的文本嵌入，用来辅助判断表头语义。

边关系分为两类。第一类是空间邻近边：每个节点连接自己周围K个最近邻节点。这是图计算的基础边集，保证信息能够在局部传播。第二类是结构化先验边：比如同一检测行内左右相邻的节点、同一检测列内上下相邻的节点、被表格线分隔但纵向对齐的节点。结构化先验边可以看成是弱规则注入，帮助图网络更快收敛。

这里给出一个简化的图构建伪代码，思路比代码本身更重要：

import torch from torch_geometric.data import Data def build_table_graph(cells): num_nodes = len(cells) edge_index = [] edge_type = [] for i, a in enumerate(cells): for j, b in enumerate(cells): if i == j: continue # 空间近邻：中心欧式距离小于阈值 if a.center_distance(b) < spatial_threshold: edge_index.append([i, j]) edge_type.append(0) # 同行先验：垂直中心接近，水平不重叠 if a.same_row_bias(b): edge_index.append([i, j]) edge_type.append(1) # 同列先验：水平中心接近，垂直不重叠 if a.same_col_bias(b): edge_index.append([i, j]) edge_type.append(2) return Data( x=torch.tensor([cell.feature for cell in cells]), edge_index=torch.tensor(edge_index, dtype=torch.long).t().contiguous(), edge_type=torch.tensor(edge_type) )

边类型非常重要，因为"同行关系"和"同列关系"在金融表格中语义完全不同，不能混在一起让模型自己猜。金融表格经常出现数字对齐、跨列合并，如果不区分边类型，模型很可能把水平相邻的单元格之间的关系和垂直相邻的关系搞混。

3.4 图神经网络的推理与单元格合并预测

在这个阶段，模型要做三件预测任务：节点属性预测、边类型预测、合并单元格预测。

我采用的骨干网络是一个异构图注意力网络，根据边类型聚合邻居信息。每一层会分别聚合空间近邻、同行边、同列边的消息，再通过注意力机制融合。这样做的好处是，模型对"行的语义"和"列的语义"分别建模。金融表格中，表头通常在列方向扩张，指标名通常在行方向展开，二者通过交叉位置形成数值单元格。如果不区分行列聚合，这种交叉语义很难学出来。

边类型预测是GFTE的关键输出。对于任意两个节点，模型输出它们属于"同一单元格内部""同一行""同一列""父子包含"或"无关系"的概率。其中"父子包含"这个关系对金融表格的层级结构非常重要，比如"流动资产合计"包含"货币资金、应收账款"等子项。这个关系不能单靠文本判断，有时候"货币资金"在缩进上比"流动资产合计"多两个字符，有时候完全靠字体大小区分，图模型可以通过节点上下文特征学到这种隐含规则。

合并单元格预测上，我用的是"单元格边界框回归+合并标签分类"的组合。具体来说，模型对每个节点预测它向右合并的宽度、向下合并的高度，以及是否作为合并单元格的左上角起点。这个设计参考了目标检测里的anchor思想，但把anchor换成了"合并偏移量"，对金融表格常见的跨行表头特别有效。

3.5 解码输出：把图还原成表格

模型预测得到的是概率矩阵，还不能直接当表格用。解码阶段的思路是：先根据"同一行/同一列"的预测边，把节点聚类成行列分组；再根据"父子包含"边，在行分组内部构建层级树；最后结合合并单元格偏移量，还原每个节点的rowspan和colspan。

解码时我强烈建议做一步"行列坐标排序"而不是单纯按置信度取边。金融表格的行列顺序本身是有语义的，表头的出现顺序、指标的顺序都不能乱。我们会用拓扑排序，把同行节点按照从左到右排序，同列节点按照从上到下排序，再根据父子层级关系决定谁是一级表头、谁是二级表头。排序完成后，表格就可以无损转换成HTML字符串或者DataFrame。

解码这一步看着简单，实则是错误高发区。最典型的问题是：预测边带出现互相矛盾，比如A和B预测为同行，B和C预测为同列，形成冲突。我的处理方式是引入一个简单的规则层：优先保留置信度最高的边，同时在行列冲突时参考几何位置，如果两个节点的中心坐标几乎重合，则优先认为是同一单元格内部关系而不是同行关系。这个规则层能过滤掉大约百分之十几的明显噪声，大大减少下游表格错乱。

4. 数据、训练与评估里的那些坑

4.1 训练数据标注与合成策略

GFTE需要训练数据包含三个层面的标注：单元格边界框、单元格文本、单元格关系图。纯人工作业成本极高，一张复杂表格标注半小时是常态。我的经验是三层结合：真实数据精标、半自动预标注、合成表格补充。

半自动预标注可以这样做：先用成熟OCR工具抽文本，再用简单行列聚类生成一个初始表格，标注员只需要修正关系和合并单元格，而不是从零开始画框。这种模式能让标注速度提升两到三倍。合成表格方面，因为金融表格的格式规律性较强，可以基于少量真实表格模板，自动改变行列数、文本长度、数字分布、合并方式，批量生成带精确标注的表格图片。合成数据不能替代真实数据，但可以让模型先学会大部分常见版面结构，真实数据用来适配金融领域的特殊表达。

还有一个容易忽略的点：表格数据集里的负面样本。模型需要知道哪些文本区域"不是表格"，比如页眉页脚、图片注释。如果训练数据里全是表格，模型在推理时会把页面上任何结构完整的东西都当成表格，导致输出一大堆垃圾。我会在训练集中混入比例大约10%的非表格页面片段，并要求模型对非表格区域输出"无表格"标记。

4.2 坐标归一化与数据增强

坐标特征如果不做归一化，模型基本学不出来。单据扫描的分辨率从72DPI到300DPI都有，同样的表格在不同DPI下坐标数值可能相差四倍。我常用的做法是，把所有坐标归一化到0到1区间，以页面宽高为基准，同时额外记录单元格相对邻近单元格的偏移量。相对偏移量对版面变化的鲁棒性远高于绝对坐标。

几何增强也是关键。表格虽然看起来是刚性结构，但扫描过程中会出现轻微旋转、透视变形、压边、裁切。数据增强时可以对渲染后的表格图片做随机小角度旋转、随机缩放、随机局部遮挡，同时同步更新坐标标注。注意遮挡增强要谨慎：金融表格里数字被遮挡一半，OCR可能识别出错误但置信度很高的文本，这属于不可恢复的噪声，模型更应该学习的是"识别不了就输出低置信度"，而不是强行猜测。

金融表格还有一类特殊的数据漂移：不同年份的报告，哪怕同一家机构，版式也会微调。所以训练集一定要覆盖多个年份、多种披露格式，否则模型很容易在时间维度上过拟合。我遇到过在2019到2022年数据上准确率很高、一测2023年新样式立刻掉10个点的情况，后来把跨年份样本均衡加入训练，才稳下来。

4.3 评估指标怎么定

评估表格抽取质量，只算"单元格文本准确率"是不够的。结构错了，文本再准也没用。我用一套三层指标来评估：

• 单元格级：预测单元格与真值单元格的IoU是否大于阈值，文本是否匹配。这是最基础的指标。
• 结构级：预测行列结构是否与真值一致，比如"这家银行共预测出12行8列，真值是13行8列"，这里错在合并单元格漏判。
• 图表级：将预测表格转换成HTML或DataFrame后，逐单元格比较文本与行列位置。只有三个层级同时达标，才算一条真正正确的抽取结果。

表格结构评估里有个著名的坑：必须使用"最小编辑距离"而不是逐单元格相等。因为一个合并单元格的rowspan预测错1，会导致其下所有单元格的行号整体偏移，如果逐格比对，误差会被重复计算成几十个错误，但本质上只是一个合并错误。我通常将预测表格和真值表格转成树结构，用树编辑距离来计算结构相似度，这样更接近真实业务影响。

4.4 实际评测中的常见失败模式

我记录了GFTE在真实金融样本上的主要失败模式，按频率排序：

• 表头合并单元格错位。跨页表格的表头在下一页被重复识别，模型经常把重复表头当成实际数据行，导致多出一行。
• 数字列对齐错误。有些表格的数字单元格右对齐但文本框本身有前后空格，聚类阶段没处理好，导致"2,000"和"2000"被分到不同单元格。
• 无框表格的隐性层级。靠缩进表达层级时，模型有时抓不到"缩进两个字符"这种弱信号，需要结合字体大小一起判断。
• 多行表头的顺序颠倒。横向表头分两行表达时，模型的拓扑排序偶尔会把二级表头放在一级表头前面。

这些失败模式反馈到模型侧，改进方向不太一样。表头重复问题更适合在后处理阶段加规则：当前一页最后一行与下一页第一行文本高度相似时，自动合并。数字对齐问题应该在预处理阶段做文本标准化，统一全半角、去除千分位空格。隐性层级问题则需要加入更丰富的版面特征和更大比例的缩进样本。工程化过程中，模型、数据、后处理三者的迭代缺一不可。

5. 工程化落地的笔记：从Demo到生产

5.1 OCR误差如何传导，如何设计容错

GFTE这类图模型有一个绕不开的问题：误差传导。下游依赖上游的OCR结果，OCR一旦把"30,000"识别成"3000"，表格结构再准也救不了这个数字错误。尤其是在金融表格里，千分位分隔符、货币符号、负号括号表示，OCR经常出错。

我的容错设计分三层。第一层：文本后处理。针对金额数字做格式校验，比如检查千分位、括号负数、百分比范围，如果发现明显冲突，标记为低置信度字段，而不是直接丢弃或修复。第二层：模型输入置信度。把OCR置信度作为节点特征输入给图网络，让模型学会在低置信度区域降低结构预测的可靠性。第三层：人工复核批次。凡是表格结构置信度低或者关键金额字段异常，自动进入人工复核队列。在金融业务里，这个人工复核环节比算法优化更能快速止血。

同时，我强烈建议对OCR模型做针对性微调。通用OCR模型对连串数字、大写金额、财务术语的识别效果不佳，拿一小批金融表格文本做微调，对下游GFTE的收益非常明显。

5.2 模板表 vs 自由表的处理策略

很多人会问：GFTE会不会太复杂，是不是只需要做模板匹配就够了？我的答案是分场景。

如果业务固定在少量PDF模板上，模板匹配确实性价比最高。比如固定处理某一种标准化的监管报送表，模板匹配能做到接近满分，而图模型可能只有95%准确率，没必要为了技术而技术。但金融数据往往来自大量不同来源，一个机构可能要处理几百种格式的报表，模板维护成本根本不可控。这时候GFTE才有明显优势。

我在工程上采用混合架构：有一个轻量的模板检测模块，先判断当前文档是否命中已知模板；命中则走模板解析，快速且稳定；未命中则进入GFTE自由解析流程。这个架构既保留了高频表格的速度，又保证了长尾表格的覆盖率。模板检测本身不复杂，对页面的表格线样式、表头关键词做哈希比对即可。

5.3 性能优化与推理加速

GFTE每个阶段都有性能瓶颈，但核心瓶颈在图神经网络的推理。金融表格通常几百个节点，全连接边会爆炸，所以图构建时要用K近邻稀疏化，而不是全连接。在实验里，K取8到12时效果最好，再大边际收益很小，但显存占用会明显上升。

推理加速方面，我可以分享几个实用做法：

• 把OCR和单元格检测合并到一个模型里，避免两遍前向计算。
• 图神经网络层数不要贪多，两层到三层就够。表格的语义传播半径有限，太深反而过平滑，所有节点特征趋于一致。
• 批量推理时按表格页动态padding，不要统一padding到最大长度。
• 将预处理好的PDF页面缓存成结构化特征，二次解析时跳过OCR步骤。

实测下来，在一个标准CPU加单卡GPU的环境里，单页复杂财务报表的解析时间可以控制在1到2秒内。这个速度对批量离线处理完全够用，如果需要实时解析，则重点优化OCR部分的并发。

5.4 落地建议与个人体会

最后说一点实际的建议。表格抽取项目最怕的不是模型效果差，而是没有一套可靠的评估基准。建议项目一开始就建立"百页黄金测试集"，里面包含各类真实金融表格、各类已知难点，每次模型改动都在这个测试集上回归。没有回归基准的优化，很容易变成修好一个错误的同时引入两个新错误。

另一个体会是：不要把GFTE当成魔法。它解决的是"从版面到结构"的映射问题，但金融表格里的复杂语义，比如指标口径、会计科目之间的勾稽关系，还是要靠业务规则和人工校验来兜底。技术能做到的是把表格从图片变成可靠的结构化数据，而怎么解读这些数据，永远需要领域知识参与。

我在模拟项目X里用这套方案处理了几百份不同来源的财报和监管报表，总体结构级准确率从最初的70%多提升到接近95%，其中围绕图建模、数据增强和后处理规则这三块的迭代贡献最大。如果你手头也有金融表格抽取的难题，建议先别急着追最新模型，找一批代表性样本，把表格从像素到结构的每个环节都拆开看一遍，你会发现大多数瓶颈不在模型，而在数据质量和结构定义的清晰度上。