团队博客

人工智能实战团队做业Beta展现 + Postmoterm报告

Beta展现——算术字符识别工具

1.背景介绍

如何在计算机上辅助计算公式？目前的方案主要包括mathOCR、爱做业、做业帮等表明，以下：

它们的缺点主要包括：

不支持手写字符输入、
不支持复杂题型、
不支持题库外的式子等等，
对于复杂的公式难以识别，对于简单的公式则应用场景很少。

所以咱们但愿解决上述痛点，加强产品功能。
此类产品主要针对有辅助计算需求的学者和论文写做者，但还有一个基本的要求是近年来不断升级的验证码识别，以算术形式出现的验证码每每由被修改过的字符以异常的形式排列，所以不要求识别工具对于复杂式子的识别，但有对识别准确率的要求。算式识别工具能够做为API借口提供服务，便于爬虫等须要自动访问网页的工具调用，提升对算术验证码的识别、经过能力。

2. 架构设计

识别目标：对于四则运算+-*/ 和分式具备识别和计算能力
架构设计：
接收用户输入 -> 图片预处理 -> CNN识别 -> 得到算术字符流 -> 序列分析 -> 数学计算题解析树 -> 求解并返回结果
架构设计图示：

3. 系统实现

图片预处理
图片预处理以OpenCV做为主要工具。预处理的主要目的是把图片中的字符切割出来，同时避免无关变量对字符识别的影响。
主要步骤包括：灰度化、二值化、高斯滤波、字符切割与细化

工具介绍：

1. 卷积神经网络模型（CNN）
   不须要提取字符特征值
   图像识别精确度高
2. 国际数学公式识别比赛数据集（CROHME）
   海量字符集图片
   与实际输入类似
   

具体步骤：

结构分析：

• 数据结构：数据结构是研究数据在计算机怎么表示的问题。而数学计算题也能够抽象成一种数据类型。
• 编译原理：编译原理是一门讲解一种语言如何翻译成另一门语言的过程。
• 树结构：树能够很方便地表达数学计算式这种具备嵌套关系的数据。
• 文法：文法能够用来解析数学计算式，将其转换成一颗语义树。
• 分治算法：能够将一个大的数学计算式分红比较小的表达式，分而治之。
• 特征值法：对于字符间的空间关系，能够提取两个字符之间的一些特征，再根据这些特征判断它们的空间关系。

项目重要文件介绍：

1. 项目配置文件：

   待补充

操做说明：

1. 运行程序：

   待补充

2. 在界面左边输入手写字符
3. 右侧显示识别结果，界面上端显示计算结果
4. 点击Solve按钮：展现结果

5. 点击Clear按钮：清楚输入状态

4. 实验结果

识别正确率

测试样例：

5. 总结

> 优势
 - 提出了可行的通常化的手写作题系统算法框架。
 - 使用卷积神经网络模型识别字符，精度高，适应性强。
 - 拓展了属性文法，使其适用于数学计算题的自动求值。


> 缺点
 - 缺少更为普遍的测试。
 - 在设计逻辑上，前面环节的错误会致使后面环节的错误。

Postmoterm报告

总述

<成员> 每一个成员在beta阶段更加积极配合完成任务，因为课业影响，整个项目执行期较短，但成员基本都能加急完成分配的任务，并致力于找bug和debug。
<吸取教训> 在alpha和beta阶段的时间安排都不算很合理，不过beta阶段的预备时间比alpha阶段多了50%以上，算是作了必定的准备工做。其次因为目标更为清晰，beta阶段的构建过程更加顺利。
<开发评价> 咱们主要是大教堂的开发模式，由于前期感受没有太多能够展现的项目代码。后续功能完善，或者在其余更为大型的项目中将考虑转向市集模式。整个开发周期较长，但实际项目推动的时间较短，一方面说明项目安排是存在问题的，执行力度不足；一方面说明开发资源没有充分利用，团队成员能力应该高于开发此项目所需最低需求，项目能够更快更好地完成。

设想和目标

咱们的软件要解决什么问题？是否认义得很清楚？是否对典型用户和典型场景有清晰的描述？

• 咱们但愿设计一个支持算术字符识别的工具，它是一个客户端，可以接收用户输入的算术字符，而后返回计算过程和结果。工具主要针对验证码识别，以及简单的手写识别。在验证码识别中，只需将验证码图片导入便可。

咱们达到目标了么（原计划的功能作到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)

• Alpha版本实现了对单个数字的识别，Beta版本实现了手写算式识别。基本按照预约时间交付。暂未推向市场，未得到用户。

和上一个阶段相比，团队软件工程的质量提升了么？ 在什么地方有提升，具体提升了多少，如何衡量的？

• 咱们在代码质量上有所提升，具体是计算核心算法被更新，UI被重写。

有什么经验教训? 若是历史重来一遍, 咱们会作什么改进?

• 咱们实行计划的时间有点赶，没有明确团队成员的任务就开始执行项目，主要仍是靠大佬hold住。

计划

是否有充足的时间来作计划?

• 是的。

团队在计划阶段是如何解决同事们对于计划的不一样意见的？

• 微信在线讨论。

你原计划的工做是否最后都作完了? 若是有没作完的，为何?

• 咱们原计划的工做基本完成，但未实如今验证码工具上的完整应用程序，暂未将识别范围拓展至更多类型的算式。

是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为何没有估计到?

• 出现了分式识别的bug，分式的识别准确率较低。由于没有对分式的识别进行单独测试。

咱们学到了什么? 若是历史重来一遍, 咱们会作什么改进?

• 咱们将调整项目进度安排，并对更多类型的计算进行实现和测试。

资源

咱们有足够的资源来完成各项任务么?

• 是的。该项目的硬件需求较低，人员充足。

测试的时间，人力和软件/硬件资源是否足够? 对于那些不须要编程的资源 (美工设计/文案)是否低估难度?

低估了UI设计的难度，致使UI改进程度不大。

变动管理

每一个相关的成员都及时知道了变动的消息?

• 是的。

咱们采用了什么办法决定“推迟”和“必须实现”的功能?

• 取决于当时全部人员的空闲状况，以及交付的紧急程度。

成员是否可以有效地处理意料以外的工做请求？

• 目前都已处理。

设计/实现

设计工做在何时，由谁来完成的？是合适的时间，合适的人么？

• 是在项目的启动阶段，由团队讨论完成。

设计工做有没有碰到模棱两可的状况，团队是如何解决的？

• 好比对于产品功能的定位，最初的设计意见不一，最终讨论决定先作稳一点的验证码识别工具。

什么功能产生的Bug最多，为何？在发布以后发现了什么重要的bug? 为何咱们在设计/开发的时候没有想到这些状况?

• 字符识别功能Bug最多，一个是由于神经网络模型训练的很差，一个是由于对于识别逻辑没有考虑充分，致使存在未考虑过的状况出现，好比分式识别错误。