真实世界表格解析从诊断到纠正：评测指标、错误分析与工程改进

做文档智能、RAG 或知识图谱项目的工程师，大概率都经历过这个场景：一份几百页的 PDF，正文文本抽取得干干净净，一到跨页表格就全线崩溃。行错位、合并单元格丢失、表头被截断、无线表格直接被当成段落……更头疼的是，不同模型在不同类型的表格上表现差异巨大，上一个项目调好的方案，换一批合同文档又失灵了。

表格解析（Table Parsing）是文档理解里公认的硬骨头。它的目标很明确——把 PDF、图片、扫描件中的表格，转换成 HTML、JSON 或 Markdown 这样的结构化表示。但“真实世界表格”和“公开数据集表格”之间的差距，大到足以劝退初学者。更突出的问题在于：很多现有评测只给出一个总体分数，却无法告诉我们模型到底错在哪里、为什么错、以及怎样改才真正有效。

这正是“From Diagnosis to Correction: Benchmarking and Improving Real-World Table Parsing”这类工作试图回答的问题。它把表格解析评测从“跑个分数”推进到“诊断错误并纠正模型”的完整闭环。这篇文章会从三个层面展开：先解释表格解析的核心概念与真实难点，再拆解诊断阶段如何做错误分析与评测，最后落到纠正阶段如何用数据、模型和后处理手段进行针对性改进。无论你是做 RAG、OCR 还是企业级文档平台，这套思路都有直接参考价值。

1. 从诊断到纠正：这篇文章要解决的问题

表格解析并不是一个新鲜话题。表格检测、表格结构识别、表格内容提取，这些子问题在过去十年里都有大量工作。但真正让人困扰的不是“没有工具”，而是“工具在真实业务里为什么总是不稳定”。

先看一个典型的业务链路：用户上传一份扫描版财务报表，系统先做 OCR 文字识别，再做版面分析定位表格区域，然后解析表格结构，最后把结果写入数据库或导入 Excel。这个链条上任何一环出错，都会向下游传播。尤其糟糕的是，如果表格结构识别错了，哪怕 OCR 文字完全正确，最终数据也是错位的。

传统评测怎么处理这类问题？很多基准数据集只提供一个综合精度或 TEDS 分数。这个分数能告诉你模型平均水平不错，却回答不了下面这些问题：

• 模型在无线表格上的失败率，是不是远高于有线表格？
• 跨页表头重复时，模型会把重复表头识别成新数据行吗？
• 合并单元格场景下，结构预测的误差主要出在列划分还是行划分？
• 如果换一种 OCR 引擎，同一个表格模型的准确率会掉多少？

没有这些“诊断信息”，改进就只能是盲目调参。而“From Diagnosis to Correction”的核心思路，恰恰是把表格解析评测从一个打分环节，变成一个可以指导研发决策的分析系统：先用精细的评测找出错误分布，再根据错误模式制定修正策略，然后验证修正是否真的解决了问题，形成闭环。

这篇文章的价值就在于帮你把这个闭环搭起来。读完你会知道：表格解析的评测维度有哪些，真实场景的错误如何分类，从诊断结果到模型改进之间的路径是什么，以及在工程上如何落地一套可以持续迭代的表格解析能力。

2. 表格解析的核心概念与任务边界

在进入具体方案之前，先建立统一的概念体系。表格解析这个词在不同语境下有不同含义，有些文章说的是版面检测，有些说的是结构化输出，容易混淆。

2.1 表格解析包含哪三个子任务

一个完整的表格解析系统，通常由三个子任务串联而成：

表格检测（Table Detection）：在页面图像或版面中定位表格区域，输出表格的边界框。这是目标检测问题，类似通用检测里的行人和车辆检测。常见的做法是用目标检测模型（如 DETR、Faster R-CNN 变体）在版面分析阶段框出所有表格。

表格结构识别（Table Structure Recognition，TSR）：识别表格内部的行、列、单元格，以及单元格的合并关系、表头区域等。这一步的输出通常是 HTML 结构标签，比如<thead>、<td>、<td colspan="2">。

表格内容识别（Table Content Recognition）：把单元格内的图像或文字区域识别成可编辑文本。这里的难点往往不在于单个字符识别，而在于如何把 OCR 结果正确“填回”表格结构里，保持内容与行列关系一致。

还有一种更高层的任务叫表格语义理解，比如回答“2023 年营收最高的部门是哪个”。这通常需要把表格转成数据库或语义图再处理，不属于最基本的“解析”范畴，但好的结构化输出能为这类任务提供基础。

2.2 物理结构、逻辑结构与语义结构

理解表格解析的难点，需要先分清三种“结构”：

• 物理结构：表格在页面上的视觉呈现，包括边框线、单元格位置、行列坐标。PDF 中的表格本质上只有这个层面的信息。
• 逻辑结构：表格的语义组织方式，如表头、数据区、合并单元格、嵌套关系。HTML 表格表达的就是逻辑结构。
• 语义结构：表格数据对应的业务含义，比如“单价”这一列代表的业务字段。语义结构通常需要结合业务知识才能得到。

表格解析算法真正要解决的问题是“从物理结构推断逻辑结构”。这一步难就难在：视觉上有边框不等于逻辑上有行列关系，逻辑上是同一个单元格的内容在视觉上也可能被拆成多行。

2.3 模型输入输出的常见表示

从模型角度来看，表格结构识别现在主流是“编码器-解码器”架构。输入是表格区域图像，输出是一段包含文本占位符的 HTML 序列。比如：

<table> <thead> <tr> <td>项目</td> <td>2023</td> <td>2024</td> </tr> </thead> <tbody> <tr> <td>营收</td> <td>100万</td> <td>120万</td> </tr> </tbody> </table>

模型学的实际上是一个“图像到序列”的映射。这种方式的好处是自由度大，不需要预设行列数上限；坏处是序列生成过程中容易出现标签结构错误，比如标签不闭合、行列数量不一致。

另一种做法是“检测 + 分类”的组合：先用目标检测找出所有单元格，再预测单元格之间的行、列归属和合并关系。这种方式结构更可控，但对单元格检测的准确率要求很高。

表格解析输出的 JSON 也是常见格式，尤其适合工程对接。下面是一个规范的结构化输出示例：

{ "table_id": 0, "bbox": [120, 300, 780, 560], "num_rows": 3, "num_cols": 3, "cells": [ { "row_start": 0, "row_end": 0, "col_start": 0, "col_end": 0, "content": "项目", "role": "header" }, { "row_start": 0, "row_end": 0, "col_start": 1, "col_end": 1, "content": "2023", "role": "header" } ] }

在工程系统里，这个 JSON 可以继续被转换为 Excel、数据库表或数据集。需要记住的是：无论中间用什么格式，最终评价一个表格解析系统的标准，是逻辑结构是否正确，而不只是“像素级还原得好不好”。

3. 真实世界表格解析的难点分析

为什么真实世界的表格比公开数据集难这么多？从工程视角看，主要有三个层面的差距。

3.1 公开数据集与真实业务的差距

公开数据集如 PubTabNet、TableBank 等，通常来自论文、百科、财报等相对规范的文档。这些样本有三个特点：一是表格边界清晰，二是印刷质量好，三是版式相对统一。

真实业务里的表格则完全不同：

• 扫描件有倾斜、阴影、折角、模糊。
• 表格可能由 Excel 导出成 PDF 后边界线丢失，变成只有对齐关系的“无线表格”。
• 表格单元格里可能混着图片、公式、签署区域。
• 表格会跨页，而且表头不一定在每页重复。
• 同一个业务的不同批次文档，表格风格也可能完全不同。

从材料看，真实业务表格的解析失败，很多时候并不是模型能力不够，而是训练数据分布与真实分布发生了明显偏移。模型在规范数据上学到的“表格长什么样”的假设，在真实样本里不成立。

3.2 高频难点清单

结合常见业务场景，下面这些难点出现频率最高：

这些难点叠加起来，会导致模型输出出现典型的“结构性错误”：多了一行、少了一列、两个单元格合并关系预测错误。这类错误很难靠简单的后处理自动修复，因为模型已经丢失了真实的表格关系。

3.3 值得关注的表格类型

从商业文档角度，有几类表格值得优先关注：

1. 财务报表：行和列数量多，合并单元格频繁，数字对齐要求高。
2. 合同发票表单：版式复杂，字段和值对应关系是核心，表格起到“字段-值对”的作用。
3. 科研论文表格：表头层级深，单元格内容长，经常换行。
4. 电子票据：虽然视觉上不像“大表”，但本质是行列关系非常强的结构化信息。

每一类表格对错误容忍度的侧重点不同。财务表错一行数据可能就导致对账错误，合同表单则更关心关键字段是否有值、是否对齐。诊断阶段如果能按表格类型拆分指标，会比只看一个总体分数有用得多。

4. 诊断：评测指标、错误分类与最小评测脚本

“诊断”是“From Diagnosis to Correction”里的第一步，也是最容易被跳过的一步。很多团队拿到模型第一件事就是上线，结果出了问题才回头查。如果先把诊断做扎实，后续改进效率会高很多。

4.1 评测指标怎么选

表格解析的评测可以拆成三个层次。

表格检测阶段，最常用的是目标检测指标 IoU（Intersection over Union）和 AP（Average Precision）。IoU 衡量预测框和真值框的重合度，一般设置阈值为 0.5 或 0.75 判断是否正确检测到表格。

表格结构识别阶段，常用指标是 TEDS（Tree Edit Distance based Similarity）。它的思路是：把表格的 HTML 表示转成树结构，再计算预测树和真值树之间的编辑距离相似度。TEDS 越高，结构越接近。这个指标比较严格，一个表格标签错误就会显著拉低分数。

表格内容识别阶段，可以用字符错误率（CER）、单词错误率（WER）或单元格级精确率。但应该注意：在表格解析里，“内容放在正确位置”比“内容识别正确”更重要。一个数字 OCR 对了一半，但行号列号错了，业务上等于没用。

4.2 错误分类与分析框架

拿到指标分数之后，不能只看数字，还要做错误归因。一个简单好用的错误分类体系是“三段式”：

检测阶段错误：

• 漏检：表格存在但模型没有找到。
• 误检：非表格区域被当成表格。
• 定位偏差：框到了表格但边界不准。

结构阶段错误：

• 行列数错误：预测的行数或列数和真值不一致。
• 合并关系错误：rowspan/colspan 预测错误。
• 表头区域错误：表头和数据区的边界划错。
• HTML 结构非法：标签不闭合、嵌套关系错误。

内容阶段错误：

• 单元格内容缺失。
• 单元格内容串位。
• 内容识别对了，但被放到错误单元格。

在诊断报告中，建议按照“错误类型 × 表格类型 × 版面特征”三个维度做交叉统计。比如：无线表格中的行列数错误占比最高；跨页表格的表头重复导致内容串位；扫描倾斜导致的检测偏差集中在低分辨率样本。这种分析才能直接指导后续修正。

4.3 一个最小可用的评测脚本

下面用 Python 写一个极简的表格结构评测脚本，用于统计 HTML 标签层面的结构错误。它不能完全替代 TEDS，但能快速帮你看清模型输出里的结构问题。

# 文件路径：table_eval_debug.py from html.parser import HTMLParser from collections import Counter VALID_TAGS = {"table", "thead", "tbody", "tr", "td", "th"} class StructureParser(HTMLParser): def __init__(self): super().__init__() self.tag_stack = [] self.tags = [] self.errors = [] def handle_starttag(self, tag, attrs): if tag in VALID_TAGS: self.tags.append(tag) self.tag_stack.append(tag) def handle_endtag(self, tag): if tag not in VALID_TAGS: return if self.tag_stack and self.tag_stack[-1] == tag: self.tag_stack.pop() else: self.errors.append(f"mismatched_end_tag: {tag}") def analyze_table_structure(html_str): parser = StructureParser() parser.feed(html_str) tag_count = Counter(parser.tags) return { "tr_count": tag_count.get("tr", 0), "td_count": tag_count.get("td", 0), "th_count": tag_count.get("th", 0), "tag_errors": parser.errors, "is_valid": len(parser.errors) == 0 } # 示例：预测输出 pred_html = "<table><thead><tr><td>项目</td><td>收入</td></tr></thead><tbody><tr><td>A</td><td>100</td></tr></tbody></table>" result = analyze_table_structure(pred_html) print(result)

这个脚本的核心思想是：在进入语义级评测之前，先做结构合法性检查。如果模型生成的 HTML 本身标签不闭合，后面的行列对齐分析就没有意义。实际项目中，可以在评测流水线里增加三个检查点：

1. HTML 结构合法性检查。
2. 单元格坐标与行列索引一致性检查。
3. 合并单元格坐标重叠检查。

只有这些检查全部通过，才进入 TEDS 或单元格 F1 计算。否则先修结构化问题，再谈准确率。

5. 纠正：数据、模型与后处理的改进路径

诊断完成的下一步是“纠正”。这里的纠正并不仅仅是“再训练一个更大的模型”，而是系统性地针对诊断出的错误模式做调整。通常有三条路径：数据侧、模型侧和后处理侧。

5.1 数据侧改进

如果诊断发现模型在无线表格上严重退化，优先怀疑训练数据中无线表格比例太低。公开数据集往往以有线表格居多，而业务里的报销单、银行流水、审批表单中无线表格比例可能超过一半。

数据侧改进有几种常用手段：

困难样本挖掘：从诊断结果中筛选失败样本，加入训练集。这种方式针对性最强，但要注意防止模型在特定批次的样本上过拟合。

合成数据增强：生成大量带有无边框、合并单元格、倾斜变换、跨页模拟的合成表格图像。方案上可以基于规则生成 HTML 表格并渲染成图像，再叠加噪声和形变。

重新标注：大量数据标注不准确时，模型会被噪声带偏。比如合并单元格的 rowspan/colspan 标注错误，会让模型学到错误的边界。定期抽检标注质量是必要投入。

数据侧的改进原则是：先按错误模式切分统计，再决定优先补充哪一类样本，而不是盲目增加数据总量。

5.2 模型侧改进

模型侧改进取决于基础架构。当前表格结构识别有两类主流路线：

端到端序列生成：典型代表是基于多模态 Transformer 的 image-to-html 模型。它对复杂表格和合并单元格的表达能力强，但当表格宽度超过训练分布时，行列对齐容易出现系统性偏差。

两阶段检测 + 结构重建：先对每个单元格做目标检测，再根据单元格的几何位置关系重建行列结构。这类方法结构可控，但对合并单元格、重合单元格的处理更复杂。

如果诊断发现“行数对但列数错”的情况多，可以优先检查解码阶段的长度预测是否稳定。如果发现“单元格检测准确但行列归属混乱”，则重点优化结构重建模块，从几何约束角度修正行列对齐。

另外，两个值得关注的方向是：在预训练阶段引入更多表格类数据，以及在训练损失中提高结构一致性项的权重，让模型在生成 HTML 时更关注标签闭合和行列数量一致性。

5.3 后处理与规则修正

后处理是“纠正”中见效最快的一环。它不改变模型权重，但在输出端修复那些明显的结构错误。常见后处理策略包括：

• 行列对齐修正：根据单元格的坐标中心点，重新计算行列归属。
• 合并单元格冲突消解：当预测的 rowspan/colspan 与单元格坐标不一致时，以坐标为准做校正。
• 表头识别规则：如果第一行全部单元格属于同一列且文本类型接近，可标记为表头。
• 重复表头去重：跨页表格中，后一页顶部出现与前一页底部相同的表头时，自动去除重复行。

下面是一个简单的“按坐标中心点重排行列”的后处理示例：

# 文件路径：postprocess_reorder.py def reorder_cells(cells, x_tol=10, y_tol=10): """ cells: list of dict, 每个元素包含 x_center, y_center, row, col 根据几何坐标重新计算行、列索引。 """ cells = sorted(cells, key=lambda c: (c["y_center"], c["x_center"])) rows = [] current_row = [] last_y = None for cell in cells: if last_y is None or abs(cell["y_center"] - last_y) <= y_tol: current_row.append(cell) else: rows.append(current_row) current_row = [cell] last_y = cell["y_center"] if current_row: rows.append(current_row) for row_idx, row_cells in enumerate(rows): row_cells = sorted(row_cells, key=lambda c: c["x_center"]) for col_idx, cell in enumerate(row_cells): cell["row"] = row_idx cell["col"] = col_idx return cells

这段代码的思路很直接：先按 y 坐标分桶成行，再在每一行内按 x 坐标排序成列。它不能解决所有结构错误，但能有效修复因模型输出顺序混乱导致的行列错位问题。在真实项目中，这类几何后处理往往能提升 2% 到 5% 的结构准确率，而且成本极低。

5.4 完整改进闭环示例

结合“诊断到纠正”的思路，一个完整改进闭环可以这样执行：

1. 用当前模型对 5000 张真实业务表格做推理。
2. 计算整体 TEDS 和单元格级 F1，并按照表格类型、有无边框、是否跨页拆分统计。
3. 抽样 100 个失败样本，标记出错误类型（检测漏检、结构错位、内容串位）。
4. 根据统计结果确定优先级：比如“无线表格错位占 60%”，则优先扩充无线表格合成数据并添加后处理重排逻辑。
5. 重新训练或微调模型，加入后处理，再跑同一批测试集。
6. 检查改进是否集中在目标错误类型上，同时确认没有在其他类型上产生明显回退。

这个流程可以每两周迭代一次，逐步积累出一套针对自己业务数据的表格解析评测集。这个评测集本身，就是团队最宝贵的资产之一。

6. 从模型到系统的完整闭环示例

这里用一个最小工程示例把前面的内容串起来。假设我们已有一个表格结构识别模型，现在需要搭建一个评测和纠错流水线。

6.1 实验环境与依赖

建议环境如下，版本以实际项目为准：

python >= 3.9 pip install torch torchvision transformers pip install opencv-python pillow lxml pip install pandas tabulate

如果不想自己训练模型，也可以直接使用 Hugging Face 上已有的表格结构识别模型作为基线，先跑通评测流程，再逐步替换。

6.2 目录结构与数据约定

一个清晰的目录结构能显著降低迭代成本：

table_parse_project/ ├── data/ │ ├── raw/ # 原始PDF和扫描件 │ ├── annotations/ # 真值标注（HTML/JSON） │ ├── train/ # 训练集 │ └── test/ # 测试集 ├── models/ # 模型权重 ├── outputs/ # 模型预测结果 ├── eval/ │ ├── analyze_errors.py │ ├── metrics.py │ └── postprocess.py └── config.yaml

annotations目录下建议每个表格一个 JSON 文件，格式如下：

{ "image_path": "data/raw/contract_001_page3.png", "bbox": [120, 200, 800, 540], "html": "<table><thead><tr><td>序号</td><td>金额</td></tr></thead><tbody><tr><td>1</td><td>1000</td></tr></tbody></table>" }

这个真值格式同时兼容视觉坐标和逻辑结构，方便下游做检测和结构两个层面的评估。

6.3 流水线运行步骤

第一步，准备测试集。对每张页面图像运行表格检测模型，得到表格边界框；第二步，对每个边界框内的区域运行表格结构识别模型，输出 HTML；第三步，对每个单元格区域运行 OCR，将文本填入 HTML 对应位置；第四步，统一调用评测脚本输出诊断报告。

下面是一个简化的流水线调用脚本：

# 文件路径：run_pipeline.py import json from eval.metrics import compute_teds, compute_cell_f1 from eval.postprocess import reorder_cells def run_single_table(image, model, ocr_engine): # 1. 表格检测（此处假设已经得到bbox） bbox = model.detect_table(image) # 2. 表格结构识别 html_pred = model.recognize_structure(image, bbox) # 3. 单元格OCR与内容回填（伪代码，实际需要做坐标对齐） cell_texts = ocr_engine.recognize_cells(image, bbox) html_filled = fill_cells_with_text(html_pred, cell_texts) # 4. 后处理重排行列 cell_list = html_to_cell_list(html_filled) reorder_cells(cell_list) return html_filled def evaluate_batch(test_set, model, ocr_engine): total_teds = 0 for sample in test_set: pred_html = run_single_table(sample["image"], model, ocr_engine) teds = compute_teds(pred_html, sample["html"]) total_teds += teds return total_teds / len(test_set)

这个示例的关键点是“把模型输出和评测逻辑解耦”。模型可以换，OCR 引擎可以换，后处理规则可以开关，但评测标准保持稳定。这样每一次改进的效果都能被准确衡量。

6.4 如何判断改进是否有效

判断一次改进是否有效，不能只看 TEDS 有没有提升。建议同时看三个维度：

1. 结构化指标：TEDS 是否提升，HTML 非法输出比例是否下降。
2. 业务指标：单元格内容与行列坐标对齐的准确率是否提升，下游导入数据库的成功率是否提升。
3. 错误分布变化：目标错误类型占比是否下降，是否引入了新的错误类型。

如果 TEDS 提升但业务导入成功率下降，很可能是评测与实际使用之间的口径不一致，比如评测是按 HTML 序列对比，但业务中更关注单元格坐标和文本对应关系。这种时候应该把业务指标纳入评测体系，而不是只信模型分数。

7. 常见问题与排查思路

表格解析流水线在实际使用中会遇到很多问题，下面按经验整理一份高频排查表。

这些排查项共同指向一个结论：表格解析系统的稳定性，取决于有没有一套“能解释错误”的评测体系。遇到线上问题，先回到评测集和错误分类里找规律，比直接换模型要可靠得多。

8. 工程最佳实践与落地建议

如果要在生产环境落地一套表格解析能力，下面几条经验可以帮你少踩很多坑。

8.1 数据与标注规范先行

表格标注是这个领域最容易被低估的工作。同一个表格，不同人标注出的 HTML 可能差异很大。比如“表头单元格算不算 th”、“跨页重复表头是否需要单独标注”、“无边框表格的行列边界如何确定”，这些都需要在标注规范里写清楚。

建议采用“HTML 真值 + 单元格坐标真值”双轨标注。HTML 负责表达逻辑结构，坐标负责连接视觉信息。二者缺一不可，否则后续做结构和内容的对齐评估时，会缺少统一标准。

标注规范里至少包含：

• 表格完整边界定义，是否包含标题行和注释行。
• 合并单元格的 rowspan/colspan 书写规则。
• 跨页表格的处理方式：是分成多个表格标注，还是标注为一个完整表格。
• 表头区与数据区的划分逻辑。
• 无边框表格的行列划分依据。

8.2 模型选型与部署策略

模型选型没有绝对最优，只有适合场景。如果业务文档版式相对规整，端到端序列生成模型更容易调好；如果表格复杂且结构多变，两阶段检测加结构重建的方法更稳定。

部署时要特别关注推理耗时。表格结构识别模型在高分辨率图片上的推理时间通常不低，如果上游版面检测出一页有多个表格，需要在表格区域裁剪后适当缩放图像尺寸，在分辨率和识别精度之间做平衡。

多模型组合也是常见策略：先用轻量模型做版面分析，把不是表格的区域快速过滤掉，再用重模型处理真正复杂的表格区域。这个思路有点类似目标检测里的“粗筛 + 精排”。

8.3 质量监控与回归测试

表格解析上线后，监控不能只看平均准确率。建议增加几类“业务敏感”监控指标：

• 检测到表格数量与人工预期的偏差。
• 结构化表格中行列数为 0 或为 1 的异常比例。
• 单元格内容为空但视觉上明显有内容的表格数量。
• 同一份文档在两次运行中的结构差异（用于感知模型或环境变化）。

建一个固定的回归测试集，每次模型更新、OCR 引擎更换或后处理规则调整后，都跑一遍测试，并输出按错误类型拆分的报告。只要回归报告里没有出现新的系统性错误，就可以继续灰度发布。

8.4 安全与权限边界

表格解析往往涉及合同、财务、个人信息等敏感数据。在工程落地时，有几条红线需要提前确认：

• 在本地私有化环境部署模型，避免将企业文档发送到外部服务。
• 对包含敏感信息的表格图像做脱敏处理后，再进入评测或日志系统。
• 涉及数据库写入或批量数据更新的场景，先在小范围验证，保留回滚机制。
• 模型训练数据必须经过授权，尤其是从真实业务中采集的样本。

表格解析模型一旦被用于自动化决策（比如自动对账），还需要考虑人工复核环节。模型给出低置信度结果时，不应直接入库，而应进入人工审核队列。

9. 总结与后续学习方向

“From Diagnosis to Correction”提供的不是一个新模型，而是一套方法框架：先诊断，再纠正，形成迭代闭环。对实际工程来说，这套思路比追求某个单点指标更有价值。表格解析的难点从来不只是“模型不够准”，而是“不知道模型为什么错”以及“改进后如何验证真的有效”。

本文已经展开的核心内容包括：表格解析的三层任务定义、真实世界表格的难点清单、诊断阶段的指标与错误分类方法、纠正阶段的数据/模型/后处理三条路径，以及可落地的最小评测流水线。建议你先用自己业务里的 100 到 500 张真实表格构建一个小型评测集，跑通“评测——诊断——修正——回归”的完整流程，再逐步扩大规模。

后续值得深入的方向有三个：一是表格结构与版面上下文的联合建模，尤其是在复杂版式中的应用；二是多模态模型在表格内容理解方面的潜力，表格解析与表格问答的边界正在模糊；三是表格解析结果的可靠性评估，让模型能主动标出“这里我不确定”，对生产系统会更友好。表格解析远未到终点，但掌握“诊断到纠正”的工作方式，会帮你在每个阶段都走得更稳。