團隊博客

人工智能實戰團隊做業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最多，一個是由於神經網絡模型訓練的很差，一個是由於對於識別邏輯沒有考慮充分，致使存在未考慮過的狀況出現，好比分式識別錯誤。