我是一个全栈开发工程师，侧重于Python，过去三年的工作经验完全集中于各种业务场景的OCR识别。
虽然最近已经开始了自己的新旅程，不过突然看到腾讯云的有奖征稿，诶嘿嘿(๑*◡*๑)万一能用之前的经验白嫖一波奖励呢。
个人经验包，存在视角偏差和理解不足，仅供参考，敬请斧正ヾ(◍°∇°◍)ﾉﾞ【叠甲】
=====================================废话分割线======================================
主要问题
1、OCR项目不只是OCR
很多时候，OCR只是OCR项目里一个技术组件，甚至可能不是必要组件。
OCR项目的核心需求是数据转录，OCR可能只是业务方恰好发现的，一个貌似能实现它需求的技术手段。
在数据转录过程中，识别不是唯一关键的步骤，对数据的校验、重构，往往也是终端需求方的核心诉求。绝多数情况下，业务心里的OCR和研发心里的OCR，往往只是两个存在交集的不同概念。
2、OCR项目涉及的岗位链很长
常见的岗位链条：业务实际需求方【笼统】-> 业务方项目经理 -> 开发方项目经理 -> 开发方产品经理 -> 开发方前端开发 -> 开发方后端开发 -> 开发方算法开发。链条上跨3个岗位以后，端头和端尾的沟通就基本上是鸡同鸭讲了。原因是：
- 不同岗位对需求的理解程度不同，都会弱化自己难理解的，强化自己熟悉的。
- 不同岗位对结果的关注点不同，都会强调对自己有利的，掩盖对自己不利的。 造成的结果就是，沟通内容在传递时，会丢失信息、增加信息、改变信息。导致需求每过一个岗位就改一点，结果每过一个岗位就变性一点。 需求是职，结果是责。这两个在一连串的变化后，相邻的岗位都觉得自己接受传递的没问题。但最后，端头的需求方就会觉得端尾的算法工程师在睁眼说瞎话，端尾的算法工程师觉得端头的需求方在异想天开。
为了大家可以有效沟通，大家可以对齐一些共同的先验。
基础信息收集
- 数据源的文件格式：数据源是图像、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很难在一般质量的图像上保持稳定的极高正确率。但是这类样本，往往又是业务认为是应该解决的。原因是，在特定的工作环境里，这种错误偏差是稳定的。例如“入口”，“人口”非常像，即使图像有所模糊，也很容易通过和周围文本块的联合概率猜测出正确的字符。人很容易通过先验知识修正，模型也很容易通过微调优化。
不过真正的问题并不在调优，而在哪来的数据调优。一个简单的方案，就是中介一个的识别结果审核系统。拦截识别的结果，通过人工审核，标注错误数据，产出微调用的训练数据。通过几轮迭代，逐渐撤出审核系统。٩(๑>◡<๑)۶
