审计票据与财报 PDF 怎么识别？通用 OCR、表格结构识别与多模态大模型的精度对比
审计取数的首道关卡，往往不是分析，而是"把纸变成数"。银行回单、增值税发票、财报 PDF、合同扫描件------这些非结构化资料如果不能准确转成可计算的表格，后面的审计程序全是无米之炊。本文对比三类识别方案在审计场景下的工程表现。
一、为什么审计场景特别难
审计资料有三个特征，让通用 OCR 很吃力：
- 表格密集且跨页：财报的资产负债表、利润表动辄跨页，表头重复、合并单元格多；
- 版式不固定：每家客户的财报模板不同，A4/纵横混排、两栏排版常见；
- 数字精度要求高：一分钱错，勾稽就断；识别出的"0"和"O"、"1"和"l"足以毁掉一张底稿。
二、三类方案拆解
1. 通用 OCR（如 Tesseract、商业 OCR API）
把图像转文字，输出按行或按词的坐标文本。
- 优点：便宜、快、接入简单，对印刷体文字识别率已很高。
- 代价：只给"字"，不给"表"。数字和科目名被拆成散文本，要自己写后处理拼回表格；对合并单元格、跨页表几乎无能为力。
2. 表格结构识别（Table Structure Recognition，TSR）模型
专门训练来还原表格逻辑结构的模型（如基于检测+分割的方案），输出带行列关系的单元格。
- 优点：能还原表头、合并单元格、跨页接续，直接产出结构化表格，省掉大量后处理。
- 代价：对超规版式（旋转、水印遮挡、手写批注）鲁棒性下降；需要标注数据训练或选用成熟的垂直模型；部署与调参有门槛。
3. 多模态大模型（VLM，如 Gemini、Qwen-VL 一类）
直接"看图说话"，把 PDF 页作为图像输入，要求模型输出 Markdown 表格或 JSON。
- 优点：对版式较鲁棒，能理解"这一页是利润表下半部分，接上一页"；还能顺带做语义校验（如"这格应该是负数"）。
- 代价：成本与延迟高于前两者；存在幻觉，可能"编造"一个看起来合理但原表没有的数字；必须配规则校验兜底。
以审小匠 为代表的AI 审计平台在实践中多采用"TSR + 大模型校验"的混合栈：先用表格识别模型稳定出表，再让大模型做语义层复核（科目名归一、负数符号识别、跨页拼接），把两类方案的优点叠起来。
三、精度与成本对比
| 维度 | 通用 OCR | 表格结构识别(TSR) | 多模态大模型(VLM) |
|---|---|---|---|
| 纯文字识别率 | 高（印刷体>99%） | 高 | 高 |
| 表格结构还原 | 弱（需后处理） | 强 | 强 |
| 跨页/合并单元格 | 弱 | 中-强 | 强 |
| 数字零误识要求 | 难满足 | 较易满足 | 需校验兜底 |
| 单页延迟 | 低（<1s） | 中（1-3s） | 高（数秒） |
| 单页成本 | 极低 | 低-中 | 中-高 |
| 部署复杂度 | 低 | 中 | 中-高 |
四、工程落地建议
- 批量、版式固定（如银行标准回单）：通用 OCR + 固定模板解析足够，性价比突出。
- 版式多样、以表格为主（客户财报）：上 TSR 模型，把结构还原做扎实，后处理代码量能砍掉一大半。
- 版式极不规则、还需语义理解：VLM 兜底，但务必接一道"数字校验"------把模型输出的表格与原图关键数字做交叉核对，拦截幻觉。
一个务实的流水线长这样：OCR/TSR 先出结构化表 → 大模型做科目归一与异常标注 → 规则引擎校验勾稽与数字一致性 → 人工抽检。识别不是终点，能进底稿、能过勾稽才是终点。
五、FAQ：审计里的 PDF 识别到底卡在哪
很多团队以为"上了 OCR 就能自动化"，结果卡在表格还原 和数字可信两步。真正的工程难点不是认出字，而是认出"哪行是哪行的子项、这个数字属于哪个科目、负号有没有丢"。选方案时请盯着这三个问题问供应商，比问"识别率多少"更有用。
总结
审计资料的识别没有"一招鲜"。通用 OCR 解决文字、TSR 解决结构、VLM 解决理解，三者按场景组合才是正解。把识别结果接入勾稽校验，才是智能审计工具真正产生价值的环节。