前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >一个OCR场景的参考落地姿势

一个OCR场景的参考落地姿势

原创
作者头像
粥沫补枸丸
发布2023-07-28 16:00:21
2850
发布2023-07-28 16:00:21
举报
文章被收录于专栏:数据转录

我是一个全栈开发工程师,侧重于Python,过去三年的工作经验完全集中于各种业务场景的OCR识别。

虽然最近已经开始了自己的新旅程,不过突然看到腾讯云的有奖征稿,诶嘿嘿(๑*◡*๑)万一能用之前的经验白嫖一波奖励呢。

个人经验包,存在视角偏差和理解不足,仅供参考,敬请斧正ヾ(◍°∇°◍)ノ゙【叠甲】

=====================================废话分割线======================================

主要问题

1、OCR项目不只是OCR

很多时候,OCR只是OCR项目里一个技术组件,甚至可能不是必要组件。

OCR项目的核心需求是数据转录,OCR可能只是业务方恰好发现的,一个貌似能实现它需求的技术手段。

在数据转录过程中,识别不是唯一关键的步骤,对数据的校验、重构,往往也是终端需求方的核心诉求。绝多数情况下,业务心里的OCR和研发心里的OCR,往往只是两个存在交集的不同概念。

2、OCR项目涉及的岗位链很长

常见的岗位链条:业务实际需求方【笼统】-> 业务方项目经理 -> 开发方项目经理 -> 开发方产品经理 -> 开发方前端开发 -> 开发方后端开发 -> 开发方算法开发。链条上跨3个岗位以后,端头和端尾的沟通就基本上是鸡同鸭讲了。原因是:

  1. 不同岗位对需求的理解程度不同,都会弱化自己难理解的,强化自己熟悉的。
  2. 不同岗位对结果的关注点不同,都会强调对自己有利的,掩盖对自己不利的。 造成的结果就是,沟通内容在传递时,会丢失信息、增加信息、改变信息。导致需求每过一个岗位就改一点,结果每过一个岗位就变性一点。 需求是职,结果是责。这两个在一连串的变化后,相邻的岗位都觉得自己接受传递的没问题。但最后,端头的需求方就会觉得端尾的算法工程师在睁眼说瞎话,端尾的算法工程师觉得端头的需求方在异想天开。

为了大家可以有效沟通,大家可以对齐一些共同的先验。

基础信息收集

  • 数据源的文件格式:数据源是图像、PDF、甚至还是Excel、Word、PPT、邮件等等,亦或是混合的各种格式数据。
  • 数据类型:是电子数据,还是影印数据。简单的判断依据是,能否用鼠标右键选中并复制出来你的数据。如果可以就是电子数据,如果不可以就是影印数据。
    • 对于PDF、Word,它们甚至可能在一份文件里既有电子数据,又有存在于背景图像上的影印数据。
  • 数据质量:这一点主要针对的是影印数据,常见的质量判断依据点有:
    • 图像清晰度。简单的定性可以是,人能不能在不凭借业务背景知识修正的情况下,直接认出文字。
    • 是否有水印、图章一类的半遮盖或干扰内容。
    • 是否存在文字变形,或者排版变形。比如拍照角度相对纸面有倾角,拍出梯形等形变。或者拍摄内容本身不平整,像是卷起来的纸,展开后拍出的带蜷曲的照片。
    • 主体内容的旋转程度。
  • 目标字段
    • 尽量没有任何歧义的确认业务期望的识别内容。比如,增值税发票编号是,No110119,那么识别要的是No110119还是110119?毕竟你也不想因为No两个花体字再给自己排期一个花体字识别的任务,对吧(ૢ˃ꌂ˂⁎)【夸张夸张】
    • 区别字段重要性:为不同的字段标记上不同的业务重要级别。不同字段对业务的重要程度是有差异的,这个差异会直接导致之后大家对结果的解读不同。业务评价往往是一种基于体感和经验的评价,实质是一种加权指标,提前对齐权重,可以省去后续很多重构的麻烦。例如,金额可能错个标点,对业务都是不能容忍的,但是对备注识别的结果,可能要求是,不影响人理解就行。【当然你还需要把一个业务的定性权重=>定量权重】
  • 数据规模:确定可以提供多少数据用于开发,多少数据用于测试。不用指望精确的结果,但是至少应该获知一个量级,十、百、千、万。因为不同量级可能对应了不同方案、也对于了不同成本(*・ω< ) 
  • 数据敏感性:请求一个明确的数据脱敏准则。开发其实很难判断业务数据的重要性,正如业务也很难认同代码复用的必要性。ლ(´ڡ`ლ)没有脱敏准则,那是马赛克像素点,有脱敏准则,那是不能给人看的马赛克像素点。
  • QPS:如果业务要很离谱的实时性,但又很难做到,可以尝试沟通下能否转化成任务队列。业务的实时性要求,很可能只是希望自己不要被完全阻塞空等待,而是可以在等待过程中继续工作。

对齐业务的评价依据

  • 样本质量分级评价:
    • 基于业务直觉下的粗分类。绝多数情况,开发过程一定会对涉及样本分而治之,业务层面的粗分类是对齐业务期望的有效参照物。如果没有它,emmm,之后讨论结果时候基本就是田忌赛马,业务侧会拿最差的一批样本的最好情况施压,研发侧用最好的一批样本的最差情况反击。这种争论,谁胜谁负,对项目落地都没有好处。
    • 用简单的数据指标,对齐业务体感描述。这个简单的数据指标,甚至可以就是一个正误数据统计,比如20份样本,全对10份,错1-5个8份,错5-10个2份,错5-10个就会有什么后果。人和人的悲欢真不想通,能做的就是找到最合适的沟通媒介(つД`) 学术指标虽然严谨、全面,但是并不适合和业务沟通。
  • 字段重要性分级评价:对齐业务重要性分配自己工作的优先级以及投入程度,并且为为结果指标加权。大家都希望在最重要的事情上投入最多的时间。
    • 比如之前的例子:金额,只有十几个数字的识别。备注,可能有几百字的字符。金额已经有了98%的完全正确率。但是备注只有50%的完全正确率【毕竟就算是99.99%的字符级正确率,几十次方后,正确率也会骤降】这种情况下,如果没有字段重要度的指导,很显然去提升备注的完全正确率,对整体指标提升而言收益更大。但是这个提升,对整个项目落地而言是虚的。
  • 一个合适的验收基线:避免越高越好这种基线,这是共同的愿望,但多数情况真的落不了地。过度的验收基线,只会导致漂亮的验收结果和糟糕的运营结果。
    • 这条绝对不是说摆烂呗╮( ̄▽ ̄)╭,而是说,如果验收基线无法顺畅达成共识,说明当前项目很可能就是一个需要迭代前进的的项目。

构建迭代回路

通用OCR很难在一般质量的图像上保持稳定的极高正确率。但是这类样本,往往又是业务认为是应该解决的。原因是,在特定的工作环境里,这种错误偏差是稳定的。例如“入口”,“人口”非常像,即使图像有所模糊,也很容易通过和周围文本块的联合概率猜测出正确的字符。人很容易通过先验知识修正,模型也很容易通过微调优化。

不过真正的问题并不在调优,而在哪来的数据调优。一个简单的方案,就是中介一个的识别结果审核系统。拦截识别的结果,通过人工审核,标注错误数据,产出微调用的训练数据。通过几轮迭代,逐渐撤出审核系统。٩(๑>◡<๑)۶

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 主要问题
    • 1、OCR项目不只是OCR
      • 2、OCR项目涉及的岗位链很长
      • 基础信息收集
      • 对齐业务的评价依据
      • 构建迭代回路
      相关产品与服务
      数据脱敏
      数据脱敏(Data Masking,DMask)是一款敏感数据脱敏与水印标记工具,可对数据系统中的敏感信息进行脱敏处理并在泄漏时提供追溯依据,为企业数据共享、迁移、分发提供安全保护措施。
      领券
      问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档