表格与公式还原能力横向评测：文档解析工具怎么选

👁 67 次阅读

为什么表格与公式是文档解析的硬骨头

普通 OCR 的目标是把图片里的字变成可检索文本，但表格与公式要求的是结构还原：表格要保留行列关系、合并单元格、表头层级、跨页续表和脚注；公式要保留符号层级、上下标、分式、根式、矩阵、积分与希腊字母。只识别字符远远不够，因为下游要检索、计算、入库或重新排版。一个看似整洁的预览结果，如果把合并单元格拆散、把多级表头压平，后续数据治理成本会迅速放大。
表格的难点在二维甚至三维结构：视觉上相邻不代表语义同列，空白可能是合并、缺失或留白；跨页时表头是否重复、续表是否继承列宽，需要模型判断。公式难点在语义歧义：同一个字形可能是字母、运算符或变量；手写与扫描噪声会破坏包围关系。评测必须把字符识别准确与结构可用分开看。

评测维度：从字符识别到结构语义

• 表格结构完整度：行列数、合并单元格、表头层级、跨页续表、空单元格与脚注归属。
• 公式语义完整度：上下标、分式、根式、矩阵、积分限、括号层级、公式编号与行内行间区分。
• 版面与阅读顺序：双栏、侧栏、页眉页脚、图注、表题、脚注和参考文献是否按语义顺序输出。
• 扫描件适应力：倾斜、阴影、印章、折痕、低分辨率与手写批注下的稳定性。
• 输出可用性：Markdown、HTML、LaTeX、JSON、Office 等格式是否保留结构，是否便于二次开发。
• 集成与维护：API 易用性、私有化能力、批处理效率、人工校正界面和长期维护成本。

这些维度中，表格和公式的验收方式不同。表格可用单元格坐标、合并关系、表头路径来检查；公式则要看能否编译、符号是否保留、行内行间是否区分。只看截图预览很容易被排版外观骗过，导出到下游后问题才暴露。

参评方案与观察口径

本文把常见方案归为五类：公式优先型、版面还原型、开源解析框架、云文档智能服务、通用大模型文档 API。观察对象包括 Mathpix 类公式优先工具、ABBYY 类版面还原工具、Adobe Acrobat 类通用 PDF 工具、MinerU 与 Marker 等开源解析框架、主流云厂商文档智能服务、LlamaParse 类大模型文档 API，以及部分垂直文档处理产品。不同版本与配置会改变结果，因此本文不做绝对排名，只讨论能力结构与适用边界。
需要说明的是，厂商演示通常选择版面干净、字体规范的样本，而真实业务文档常混有扫描页、批注、跨页表和手写公式。对无法复现的单一指标应保持保留，对普遍反映的短板则应重点验证。选型时最好用自己的文档做小批量 A/B，而不是只看宣传材料。

多维对比表：五类方案的能力差异

从表中可以看出，公式优先型在公式语义上优势明显，但表格和版面常需补位；版面还原型在复杂表格和扫描件上更稳，但公式可能只被当作图片或普通文本；开源框架灵活、可私有化，但需要工程投入；云服务上手快，适合批量和 API 集成；大模型文档 API 在自然语言与结构化抽取上更灵活，但稳定性和可审计性要重点验证。

表格还原：合并单元格、跨页与隐式表头

表格评测最容易只看行列是否对齐，实际业务更关心语义关系。常见失败包括：多级表头被压成一行，合并单元格拆散后重复填充，跨页续表被当成新表，脚注混入单元格，空单元格被错误补零，左侧行标题在转换中丢失。对财务、审计、招投标和科研数据而言，合并单元格和表头路径决定后续能否正确查询。
一个可用的表格输出应至少保留单元格坐标、合并范围、表头层级和续表关系；如果只导出 Markdown，复杂表格会退化成简单网格，阅读尚可，计算和入库不可靠。测试时可以准备这些样本：多级表头加合并单元格、跨页长表、带脚注的统计表、左侧行标题与右侧数值混排、扫描倾斜表、带印章遮挡的审批表。验收时不要只看整表截图，要抽查具体单元格的坐标与表头路径。

公式还原：从图片文字到可编辑语义

公式识别不是把符号逐个认出来。常见问题包括上下标归属错误、分式横线丢失、括号层级混乱、矩阵分隔符缺失、积分上下限错位、多行公式对齐关系被破坏、公式编号被并入公式或丢失。对论文、教材和技术文档来说，公式输出必须可编辑、可检索、可编译，否则只能算图片转文字。
一个实用的验收方法是把输出粘贴到公式编辑器，看能否一次编译；检查行内公式是否保持行内，行间公式是否独立；检查多行对齐环境是否保留；检查编号是否可单独提取。公式优先工具通常以 LaTeX 或 MathML 为主要输出，适合论文与教材；通用文档解析工具若只能输出图片，知识库检索会丢失公式语义。混合文档更现实的方案是版面分析负责定位，公式专用模型负责语义，再由规则或人工做结构校验。

版面与阅读顺序：决定后处理成本

表格和公式不是孤立的。双栏论文、报告侧栏、页眉页脚、图注、表题、脚注、参考文献都会影响阅读顺序。阅读顺序错误的典型表现是：表题跑到上一页，公式解释与公式错位，脚注插入正文中间，双栏内容被左右串读。版面分析强的工具能保留区块类型与顺序，输出结构化 JSON 或 HTML，便于后续规则校验。
如果下游是知识库问答，阅读顺序错误会直接导致引用错位；如果下游是出版排版，顺序错误会增加大量人工返工。因此评测时要把版面阅读顺序单独打分，而不是把它混在字符识别里。

扫描件、手写与低质文档的现实考验

真实文档往往有倾斜、阴影、印章、折痕、低分辨率和手写批注。云服务通常在扫描件增强和版面检测上积累较多，适合批量档案；开源框架需要自行做预处理和阈值调参，但可私有化；公式优先工具对手写公式可能更友好，但复杂表格仍是短板。版面还原型工具在扫描表格上较稳，但公式区域常被当作普通图像处理。
需要提醒：版本更新会改变表现，任何选型都应以自己的样本复测。对低质文档，预处理质量往往比模型名称更关键，去噪、纠偏、二值化和分辨率提升都会影响最终结构还原。

输出格式与生态：Markdown、HTML、LaTeX、JSON 怎么选

输出格式决定可用性。Markdown 适合知识库与轻阅读，复杂表格和公式容易降级；HTML 对表格结构更友好，适合网页展示与结构化抽取；LaTeX 适合公式与学术排版，但表格处理需要额外校验；JSON 适合 API 流水线，便于保存单元格坐标、区块类型和阅读顺序；Office 格式适合交付，但自动生成后仍需人工检查。
如果下游是检索与问答，优先保留结构化 JSON 或 HTML；如果下游是排版与出版，优先 LaTeX 与 Office；如果只是人工阅读，Markdown 足够。不要只看预览是否漂亮，要看机器可读结构是否完整。

成本、速度与隐私的权衡

成本不能只看单页调用价格。人工修正、系统集成、模型部署、数据合规都是成本。表格和公式的校正往往比普通文本更耗时，所以一个便宜但结构差的接口，总成本可能高于单价更高但输出更稳的方案。速度分交互式和批处理：交互式更看重响应，批处理更看重吞吐与失败重试。隐私分公有云与私有化：合同、财务、病历等敏感材料更适合本地化或专有云，公开论文和批量资料则可用云 API 快速上线。

场景推荐：按任务选工具而不是按榜单选工具

场景推荐不是品牌推荐。公式密集的文档不要指望通用表格工具顺手解决公式语义；表格密集的文档也不要只看公式工具的宣传页。混合文档更应采用组合式流水线：版面分析负责区块与顺序，表格模型负责单元格关系，公式模型负责 LaTeX 或 MathML，最后由规则做结构校验。

结论与可执行建议

没有一款工具能在表格和公式上同时做到无条件领先。公式密集场景优先选公式优先型，并用版面工具补表格；表格密集场景优先选版面还原型或云文档智能，并对公式区域单独处理；混合文档采用组合流水线；高隐私场景选本地开源；高吞吐场景选云 API。选型的关键不是找榜单第一名，而是找与业务返工点最匹配的组合。

1. 建立黄金样本集：用真实文档覆盖多级表头、合并单元格、跨页长表、行内公式、矩阵、扫描件和手写批注，规模不必大，但要能暴露短板。
2. 分开验收表格与公式：表格看单元格坐标、合并关系、表头路径和续表；公式看可编译率、符号保留、行内行间区分与编号提取。
3. 记录人工返工点：让校对人员标注错误类型和修正耗时，比单看识别率更接近真实成本。
4. 先小批量 A/B 再采购：同一批文档跑两到三种方案，比较输出结构、集成难度和失败重试成本。
5. 把校正界面纳入选型：表格与公式很难完全免校正，好的校正界面能显著降低长期成本。

先做小范围验证，再决定采购或自建。如果团队没有工程维护能力，优先选择输出结构清晰、文档完善的云服务；如果文档敏感且批量稳定，优先考虑可私有化的开源框架，并预留人工抽检与规则校验环节。