“深度评测官”——记2020BUAA软工软件案例分析作业

简介

• 安装(上手)的简易程度
• 识别正确率
• 识别速度
• 可扩展性
• BUG 比较

安装(上手)的简易程度

1. 对于 MicroSoft 的OCR识别表单软件，有以下使用方式：
   1. 项目测试 站在线使用
   2. 使用官方提供的docker镜像
   3. 下载Github上源代码并在本地编译安装使用
      后两种安装方式需要一定的计算机能力，具体安装步骤可参考MisTariano的博客

踩坑细节

MicroSoft-OCR

1. 其次，无论是 页版还是本地软件都是要通过 Azure 的云服务来实现进行文件操作的，这一点也是困扰了我和另外尝试的同学很久的点，Azure 的国际注册需要绑定 VISA 或 Master 来避免机器人注册或滥注册，所以这一步是不可跳过的，对于大部分没有这两种卡的学生而言，是一道门槛。在咨询 Azure 客服，告知我的目的之后，客服建议我在中国国内的Azure服务上进行注册，https://www.azure.cn/，国区的Azure支持支付宝，有一元体验活动。
2. 但是，Azure 的配置稍微有点繁琐，包括 blob storage 和开通 OCR 服务等，比较难以找到，所以又是一个巨大的挑战。在这里感谢邹欣老师给我们几位测试同学提供的各种资料是我们免去了自己的配置工作，使得测试得以展开。~~这里立一个Flag，在测试完成之后，笔者将探索一下如何使用自己的账户进行配置，将在一周内进行答复(即：2020年03月27日前)。~~笔者和几位一同测评的同学都没有找到在国内的Azure开通MS的OCR的方法，在此希望尝试成功的读者能在评论下留言～

ouyanghuiyu-chineseocr_lite

1. 源代码的生产和测试环境应该是在 linux 下进行的，所以笔者在 windows 下部署的时候遇到了一些问题，其中以下问题都可以在这个博客中找到答案，强烈推荐按照这个博客的流程走：
2. 遇到 等 web.py 相关的问题的时候，大多数是因为版本装错了，可以先卸载当前的web 并装上固定的版本
3. 另外，该轻量级ocr是直接在本地进行利用神经 络做出预测，所以有一块GPU图形显卡是最好的，时间上会快很多。
4. Windows 下 命令无法找到：这是由于make下载下来的时候叫做 ，只要找到自己的环境变量下的这个文件，将其复制改名为 然后重新打开 即可。
5. make 的时候找不到 ，这是由于自己的Python安装有遗漏，具体开源上 搜索解决方案，我这里是利用 Windows 下的 WSL2 进行 make， WSL2 中的 Ubuntu 直接 和 即可保证安装完所需的python模块，第二条语句的 是具体的python版本，比如我的是 则执行 即可，注意：编译时的python和后续运行的python最好版本 相同，具体不同会怎么样我也没有尝试过，欢迎留言告诉我。

使用方式

MicroSoft-OCR

1. 登陆在线测试 站或登陆本机部署 站
   [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-mdycvG2g-1648546112870)(https://i.niupic.com/images/2020/03/20/73S3.png)]
2. 上一步中对每一份的标签打完之后点击左侧的 Train 进行模型的训练
   [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-n1X2mON2-1648546112873)(https://i.niupic.com/images/2020/03/20/73S2.png)]
   可以看到这里在我们提供的5份训练样本中达到了每一项都100%的最佳效果

本轮结果

识别正确率

对于OCR软件而言，正确率无疑是重中之重，没有优秀的识别率无论多么美观都是纸糊的，所以首先测试一下识别率。

MicroSoft-OCR

对于上传的pdf而言，MS的OCR会先进行一个全文档的识别，然后按照空白符进行单词的分割，分割的粒度表现很好，如下图所示：

本轮结果

不需要列出比较的表格了，可以说是MS家的完胜，至于这个chineseocr-lite我也不知道是出了什么状况，是训练不到位吗br> MS家的能识别手写的英文字体令人非常佩服，毕竟很多签名有大量的连笔和变形在里面。
至于算得上是 chineseocr-lite 的特色的身份证和火车票识别也没有表现出众，这种排布非常规范化的识别场景完全可以交由 MicroSoft的OCR 来做，和合同中的标记一样，在特定的位置标记上想要的文字，就可以直接输入新的样本来进行预测了。

识别速度

有人认为识别速度是在识别准确率能够达标的基础之上的，也有人认为为了识别的速度牺牲一点准确率也无可厚非，这一点上大家求同存异，抛开准确率来测试一下。

MicroSoft-OCR

首先这是一款部署在国外的在线测试 站，所以有延迟是很正常的，亲测这样一张A4纸的内容翔实的合同从点击到识别完成里面的全部内容大概需要 10s~1min 不等，波动较大：
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-J6iQTXQi-1648546112876)(https://i.niupic.com/images/2020/03/20/73VK.png)]

在训练阶段则是非常迅速，因为不需要用 络加载图像，所以实测在13s左右就可以训练完成返回训练结果：
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-qjJYSuUm-1648546112877)(https://i.niupic.com/images/2020/03/20/73VD.png)]
注：训练集大小是5个文件各有14个tag

ouyanghuiyu-chineseocr_lite

在不考虑正确性的情况下，我使用的是电脑自带的 Nvidia 1050Ti 的GPU显卡进行加速，识别同样大小同样内容的A4合同的时间只需要4s，对于简单的截图识别都在1s左右，由于是本地运行的原因所以不用考虑 络的环境延时。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-WSXwJ8uS-1648546112877)(https://i.niupic.com/images/2020/03/20/73VX.png)]

本轮结果

考虑到 络延时的因素，其实这样的对比并不是非常公平，要是使用的是腾讯云、阿里云等国内的服务器，可能二者的差距就没有那么明显了。

可扩展性

MicroSoft-OCR

对于微软的OCR识别而言，只要提前做好标记便可以做到“查用户想查”。比如在轻量级OCR中的身份证识别，微软OCR只需要5张的身份证照片做训练集，在需要的信息后面进行标注tag即可做到对应信息的提取。同理，火车票可以看作是也是规范布局的表单，只需要定位相应的信息，通过训练一个新的模型就可以实现信息的提取。甚至如果需要识别所有文字的情况下，只需要新建一个比如叫做 “all” 的 tag，然后训练样本上全选，那么测试样本上也会选中所有的文本。

对于测试的样本，既可以是pdf格式，也可以是图片的格式，非常灵活。

ouyanghuiyu-chineseocr_lite

可以进行文字方向检测，由于手头上没有竖版文字的图片所以借用了项目中的GitHub的README中的样例图：
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Quxls4Pg-1648546112878)(https://i.niupic.com/images/2020/03/21/73Yk.png)]

本轮结果

MS的OCR可以覆盖到轻量级OCR的两个特殊场景检测——身份证和火车票，但是不能做到轻量级OCR的文字方向检测，但鉴于文字方向检测和单行文字识别这两个功能的利用率可能1%都不到，所以还是微软的OCR更胜一筹。

Bug 寻找

这个环节对于选择其他软件进行分析的同学来说是非常痛苦的，因为像是VSCode和MSVS这种由专门的开发团队定时进行迭代的开源生产力项目，加上微软内部的“自己的狗粮自己吃”的测试理念，能被人发现的bug已经很少了，但是对于我今天测评的两款软件来说，还在开发测试阶段，所以很容易就能发现一些端倪。

MicroSoft-OCR

1. 首先是 tutorial 的缺乏，这一点不算是 technical bug，而算是广义的bug。不知道是不是这款开源软件仍处于测试阶段的原因，进入 站完全找不到任何tutorial教学，完全是自己摸索，这一点对于同学们还好，但对于有一定年纪的不是经常捣鼓电脑的人来说，相当吃力。就算是我们计算机专业在读每天接触各种软件和代码的同学来说，也不免地遇到了一些麻烦。
   比如我在进行tag标记的时候，由于 络延时的原因，电话 码被我选择之后没有立刻投放到电话 码的tag里面，而是跟着后面选择的邮寄地址一同分类到了邮寄地址的tag中，这时候我想删除里面的电话 码但是发现找不到一个删除内容的键，迫不得已只能删除整个tag之后重新加入tag。后来邹欣老师告诉了我解决方案是选中要删除的内容，然后按删除键(del)，在这里分享给找不到删除键的朋友们。这种删除的方式就特别像是一个人的个人习惯，就像是让新手退出vim一样困难，我好几次遇到要删除的问题的时候都没有想到删除键，这一点没有告诉给使用者确实有点令人费解。我觉得对于这种增删改查的操作，在有实体按键的前提下加上键盘上就能操作的快捷键是再好不过了，就像PhotoShop一样顺手。

其他方面感觉都非常不错，预测出来的14个tag除了重复数字的bug之外都是全对的，就连手写字体识别也准确地“一字母不差”。
测试识别效果：

本轮结果

两款OCR软件都有一定的BUG存在，但是相对于微软OCR的识别正确了但重复了的BUG而言，轻量级OCR的识别错误且混乱带来的用于体验和效果更差，所以这一轮还是微软OCR胜出。

个人使用体验

本章节仅代表个人的使用感受，大家看看就好。
非常荣幸在邹欣老师提供的帮助下完成了本次的软件对比测评，之前的时间一直在做前期准备——收集清晰度不同的pdf文档进行对照，但是知道真正上手的时候才知道自己准备的文档并没有什么用处，测评路上的艰难险阻太多了。
光是登陆一个Azure账户就被VISA卡的认证卡住，有的人进行学生认证也被卡住，最终在Azure的客服的见一下在国内的Azure 站注册后又被不熟悉的Blob Storage卡住，最后还是邹欣老师给我们提供了API和URI才使得测试得以进行下去。在测试轻量级ocr的时候也遇到了一些环境上的配置问题，也是查阅了很多博客才得以解决，不过上午中午配置完之后下午得以有时间好好玩一下两个软件。
其实刚开始拿到这个作业的时候挺吃惊的，腾讯云、阿里云还是很有厂商都已经推出了成熟的OCR的API接口，要这个微软的开源项目有什么用呢/strong> 但是直到上手之后才发现 “术业有专攻”。
微软的这一款开源项目是专门针对表单识别的，就像是我贴出来的测试中的各种银行的表单，上面可能有开户人的姓名、联系电话、联系地址、邮政编码、个人签名等等，而且表单的形式带来的是更复杂的识别场景，是普通的OCR不能应对的。就像是上面出现的表格等内容，很容易被普通的OCR识别得一团糟。其次，微软的OCR是可定制的，这里就和轻量级OCR表现出了明显的不同，两者都可以提取识别的文字信息，但是微软OCR确定了识别的文字的具体位置和内容，甚至你在创建tag的时候还可以选择存储的类型——是字符串字期至是时间与之相比是轻量级OCR的自动分割，这种分割效果需要大量的样本的训练，甚至因为语义上的分割还需要学习自然语言之间的联系，什么时候该短句么时候是同一个意群些其实远超了OCR自身识别的需要了。
使用这两款软件给我最大的感受就是——微软的OCR是toB的，是成熟的、投入市场中可以使用的，而轻量级OCR更像是一个深度学习入门的小白的一个玩具，两者其实在最开始就不应该放在一起进行比较，以至于出现了比较中经常看到的“降维打击”。微软的OCR在很多商业的场景下会被使用到，比如上面提到的银行业务，很多都是先让你填写表单，然后打印签字，抑或是邮政业务，打印带有收件人信息和寄件人信息的寄送单并让收件方签字等等，在这种情况下，所有的待识别的文档都具有一个固定的格式，只要填写在 “Email Address” 的后面，就一定是个人的电子邮箱，都有固定的位置进行相应的信息的提取，也正是因为微软OCR的这种 “用户可定制性” ，使得轻量级OCR的特色功能也相形见绌，只要提供给微软OCR几张身份证照片和火车票样张并加上tag进行训练，微软OCR完全可以hold住这种信息量少而且规范格式的特定场景识别。
微软OCR的toB其实也可以从识别文件的输入输出方式看出，在 页端是无法进行训练集的上传的，训练集中的文档都是存储在 Azure 的 storage 特定的文件夹中，只能使用 Azure 客户端、 页端进行管理或使用 Azure storage explorer 进行管理，更加规范，并且格式都是标准的pdf文件格式而不是图像，这也符合规范的商业表单都是pdf整理的特点，最后微软的OCR还提供了 JSON格式的输出，可以直接将结果导出进行成分分析，在商业中可能经过一个python文件处理，表单中的信息就进入到数据库中了，实现了完全的自动化。
轻量级OCR在这次的测试中令人比较失望，可能是因为没有自己本地进行训练的原因，但和GitHub主页上的3.1k赞也大相径庭，在轻量级OCR的README中给的样例都是字体特别大的而且分割开的，准确率确实不错，但是在测试中对于同学们一个正常的识别知识点和题目的场景下都不能表现出色实在令人匪夷所思，可能是因为其重点在于“轻”而不在于“准”所导致的。就像我前面说的，它更像是一个MNIST手写字体识别一样，是深度学习入门的人的一个玩物，大家可以对照着它“轻量级”的代码仓库进行学习，还可以加上自己的个性化定制，比如改变里面的lstm 络等等，学习意义大于使用意义。
听邹欣老师说后面将会提供中文的表单识别，让我们拭目以待。

作业第二部分：分析

预估完成项目所需时间

使用此服务的所有功能，估计这个软件/ 站/服务做到这个程度大约需要多少时间(团队人数6人左右，计算机大学毕业生，并有专业UI支持)。

对于轻量级OCR而言，难点在于保持准确度的情况下压缩模型到项目README中所说的

“轻量的backone检测模型 psenet（8.5M, crnn_lstm_lite(9.5M) 和行文本方向分类 络（1.5M）”

同时还要加上特殊的任意方向文字检测，识别时判断行文本方向的功能。
所以在 团队人数6人左右，计算机大学毕业生，并有专业UI支持 的前提条件下，全身心投入大概需要花半个月的时间就能够实现。

但是对于微软的OCR表单识别而言，需要达到细粒度的单词的划分和手写字体识别的准确性，加上在 Azure 上进行部署提供测试 站使用，全身心投入的话保守至少在1个月以上到两个月的时间。

分析这个软件目前的优劣

对于轻量级OCR而言，个人认为学习的意义大于实际使用的意义，因为实际的识别准确率从今天的多种测试结果来看都惨不忍睹，远不如我手机上的OCR软件，所以 在教育意义上排名靠前，在实用意义上几乎垫底。

对于微软的OCR表单识别而言，首先这是一种比较新颖的OCR文本识别的方向——标记tag，训练模型，对同一种样式的表单进行持久的预测，其次是软件的可定制能力强大，对于待识别的样本，可以自定义想要什么部分，丢弃什么部分，只提供用户希望得到的值的预测结果，最后是识别准确率相当之高，所以在同类的产品中可以排到前列。

作业第三部分：建议和规划

这里只讨论微软的OCR，因为轻量级的OCR从各个角度而言都太不成熟了，不适合讨论一下的具体发展的问题。
现在假设我是微软OCR开源软件的PM，在微软中PM是Program Manager，这里可以重温一下Program Manager的定义和任务：

• 一句话来讲：
  做开发和测试之外的所有事情
• 展开来讲：
  1. 和客户交谈，组织用户调查，发现用户需求
  2. 了解和比较竞争对手的产品
  3. 怎么让软件变得可用（Usable）、有用（Useful）
  4. 怎么改进团队的流程
• 对比来讲：
  
• 比喻来讲：
  PM就是龙舟队里面的舵手，掌控着龙舟前进的方向，如果舵手也参与到划船中，可能小船的速率会快一些，但是小船的方向、稳定性会出问题。

市场有多大在的用户有多少/h3>

微软OCR面向的是生活中的一切要用到规范化的表单的地方，无论是政府机构签署协议还是金融机构签署成交单，只要有表单出现的地方都可以使用，市场需求极大，潜在的客户极多。

同类产品比较

这里拿阿里云市场中的一个OCR表单识别服务进行比较，可以看出：

1. 首先阿里云提供的是接口服务，需要有计算即能力的人进行编程和API的配置，但微软OCR提供线上的 站使用，无需配置API，只需要存放文件到 Azure 并进行 站上的配置。
   微软在线使用 站：
   [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-OsVJnfwJ-1648546112880)(https://i.niupic.com/images/2020/03/20/73S3.png)]
   阿里云市场售卖的API：
   [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-xhcziheB-1648546112880)(https://i.niupic.com/images/2020/03/21/73Yt.png)]
2. 其次，微软OCR支持自定义识别区域，得到想要的，丢弃无用的，无需进行表单的裁剪，直接选择即可，返回得到的结果都存放在tag内，以JSON文件形式输出，可以提供给python直接进行数据处理；但阿里云市场提供的API服务一次识别一个表单，不能设置需要的内容，只能全部返回，并且使用前需要对待识别表单进行裁剪，返回的是识别的所有文字进行简单的换行分割的结果，需要人工选取里面的有效数据。
3. 最后，微软OCR可以识别手写字体；阿里云市场提供的OCR服务只能识别印刷文字表格，功能较为单一薄弱。

产品的核心用户群定位

个人认为，微软OCR是一款toB的开源软件，主要还是提供给商业用途。用户画像为成熟的商业客户，需要处理大量的同等样式的表单文件，需要此服务进行自动化的有效信息提取并整理。
潜在需求可能是希望能够再提供一个直接连接数据库的功能，识别完成后直接将对应的信息存至云端(如Azure)的数据库的各个对应字段中。

设计功能

• 目前认为最需要的功能是提供多元的云端存储服务，而不是仅限于Azure一家，但这其实也是自家的产品竞争力的体现，如果开通了腾讯云和阿里云等国内的云服务厂商，用户数量虽然会增加，但是无法带动微软自身的云服务的兴起，是需要权衡的一个点。
• 还有就是上面所说的再提供一个optional的数据库连接接口，使得整套 表单识别-信息提取-数据存储 一条龙服务，实现完全自动化，不需要用户手动处理JSON文件的识别结果。
• 最后一个也是比较难实现的——表单预提取，意思是在遇到一个表单中的表格时，预先将表格中可能出现的tag 和对应的 value 提取出来直接供用户勾选需要的 tag-value，这样可以使得标签的制作更加高效。我自己在尝试制作标签的时候就发现，其实微软的OCR自己是已经看到表格的，看到表格之后其实就可以根据空格和换行和横竖线进行每一个小块的文字的提取了，一般而言，tag在前，value在后，中间用空格或冒 进行分割，我认为其实已经可以做到了。
  [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-LQyJi2oh-1648546112880)(https://i.niupic.com/images/2020/03/21/73Yw.png)]

团队规划

如果你有钱可以招聘6个人，有4个月的时间，你作为项目经理，应该如何配置角色(开发，测试，美工等等)述你的团队在16周期间每周都要做什么，才能在第16周如期发布软件的改进版本，并取得预想中的成绩。

这个问题我有些不好回答，因为我确实没有团队开发的经历，在这里回答也只是天马行空，没有背后的经验作为支撑，言论不堪一击，所以我希望老师和助教能够在这道题上给我一些启发和建议，也让我在后期的团队任务中能够亲身经历和践行。

参考连接

1. MicroSoft | 智能表单信息抽取识别
2. 智能表单信息抽取识别在线测试 站
3. ouyanghuiyu | 超轻量级中文ocr
4. MisTariano | OCR-Form-Tools项目本地试玩记录
5. CSDN | Python构建快速高效的中文文字识别OCR
6. cnblogs | python3使用web.py遇到的找不属性的错误解决
7. 阿里云 | OCR表单识别(愚公OCR)

文章知识点与官方知识档案匹配，可进一步学习相关知识Java技能树首页概览91318 人正在系统学习中