票据 OCR 方案选型：开源模型与云服务怎么取舍
刚开始接触票据识别时，我把「发票识别」和「小票识别」当成同一个问题，结果方案选型直接走错方向。这两类场景的技术难度、验收标准、甚至商业方案的价格结构都不一样，搞清楚差别是选型的第一步。
先分清两类票据
增值税发票是标准版式。版式固定，字段位置相对稳定，甚至有官方的版式规范。识别这类票据，只要检测定位准确，剩下的近于模板填充，工程难度低，市面上成熟方案很多。
购物小票完全相反。不同商超、不同收银系统、不同热敏打印机，出来的版式千差万别。有的把商品名和价格分两列，有的合成一行；有的带税号，有的没有；有的用中文，有的中英混排。更麻烦的是热敏纸本身——放久了字迹会变淡，折痕处会断字。
一个直观的判断题：如果打印这张票据的模板只有几种，走模板化提取；如果模板不可穷举，就必须走通用识别加后处理。小票属于后者。
开源路线能走到哪一步
开源方案目前主流是 PaddleOCR 这一类检测加识别的两阶段模型。实际用下来的判断：
- 检测和单行识别已经够用。中文场景的行检测准确率不错，倾斜、轻微畸变的票据也能框出来。
- 结构化要自己写。模型只给你一堆带坐标的文本行，从文本行到「商户名、时间、总金额、商品明细」这层结构，开源方案不给，得靠自己写规则或训练小模型。
- 推理成本可控。本地部署，一次投入算力，后续按量不花钱。量大的时候这是决定性优势。
代价是调优周期长。图像预处理、后处理规则、异常兜底，每一项都要自己填坑，前期投入的时间成本比调用接口高一个量级。
云服务路线省在哪、亏在哪
各家云厂商都有票据识别接口，按调用次数计费。优点很明确：
- 接入成本几乎为零，传图拿结构化结果，一天能跑通。
- 对标准票据（发票、火车票、行程单）效果通常不错，因为这些是厂商重点优化的版式。
- 免运维，不用管模型版本、显存、并发。
但有几个地方要想清楚：
- 非标准小票的效果不保证。接口文档里写的支持品类，往往不包含「任意商超小票」这种开放场景。实际效果得自己拿样本压测，别信宣传页。
- 出了问题改不了。识别错了某个字段，你没有调整空间，只能反馈等厂商优化。开源方案至少能改后处理规则。
- 数据要出本地。小票上有消费明细、时间、部分还有会员号。把这些图传给第三方，等于把用户消费行为数据交出去，涉及个人信息处理的合规问题，得先想明白再决定。
我目前的取舍
基于上面的判断，我的路径是先开源跑通，再决定是否上云：
- 用开源模型搭一条最小链路：图像预处理 → 检测识别 → 字段后处理，先把端到端跑通。
- 自建一批样本，按字段统计准确率，找出错误集中的环节。
- 如果某个环节优化成本高于调用云服务的费用，再把这一环节换出去，而不是整体切换。
这样做的理由是：选型的答案取决于你自己的样本分布，不取决于别人的评测报告。同样是「小票识别」，便利店的小票和餐厅的结账单，错的地方可能完全不同，先有自己的数据再谈方案。
← 返回首页