愛作業(yè)是一款通過 AI 技術(shù)自動批改數(shù)學作業(yè)的 APP，上線一年來已經(jīng)積累超過千萬用戶， 幫助大量的老師和家長節(jié)約時間，提高效率。

在愛作業(yè) APP 里面有個功能叫 “口算同步練”，我們希望提供給小朋友一種輕量的方便的方法可以直接在手機上鞏固訓練口算。如下圖所示：

識別在屏幕上手寫的筆跡，我們最早使用的方法是追蹤書寫軌跡，這也是比較傳統(tǒng)和經(jīng)典的方法，這種方法依賴于規(guī)則，不需要大量的訓練數(shù)據(jù)。 但是經(jīng)過我們試驗，這種方法對于少量數(shù)字效果還不錯，對于位數(shù)比較多的數(shù)字，特別是數(shù)字之間還存在連寫，或者書寫順序不夠標準的情況， 識別效果就差強人意了。

這時候我們想到要使用 Deep Learning 來解決問題，然后我們需要解決訓練數(shù)據(jù)，模型， 和移動端部署的問題。

首先是訓練數(shù)據(jù)，這是深度學習繞不開的問題。為此，我們專門開發(fā)了一個小工具（iOS / Android），讓我們的標注人員可以方便的生成訓練數(shù)據(jù)。這個工具會隨機生成一些數(shù)字（包含小數(shù)點，分數(shù)），然后標注人員在屏幕中書寫提示的數(shù)字，然后可以方便的保存到我們的服務器。 我們就這樣收集到了第一批原始數(shù)據(jù)大概有 5000張訓練圖片左右。

然后是模型。由于模型需要在移動端運行，所以不管是圖片輸入大小和模型本身，都需要相對精簡。基于豎屏的比例，我們最終采用了將所有圖片預處理成 60x100(高x寬) 的大小。模型的整體方案是一個 seq2seq 的模型，這個框架最早是 Google 用于解決 NLP 相關的問題， 我們可以把它做一些調(diào)整來做圖像 OCR。

首先我們需要一個生成 feature 的基礎模型，最終我們采用了 MobileNet。 MobileNet 模型的核心就是將原本標準的卷積操作因式分解成一個 depthwise convolution 和一個 1*1 的卷積（文中叫 pointwise convolution）操作。簡單講就是將原來一個卷積層分成兩個卷積層，其中前面一個卷積層的每個 filter 都只跟 input 的每個 channel 進行卷積，然后后面一個卷積層則負責 combining，即將上一層卷積的結(jié)果進行合并。MobileNet 可以在基本保證準確率的前提下大大減少計算時間和參數(shù)數(shù)量。 正如這個命名，我們相信用這個作為基礎網(wǎng)絡可以在移動端有不錯的表現(xiàn)， 并且這個模型在 TensorFlow 的 model zoo 中有標準實現(xiàn)，并且提供了預訓練模型。豐富的模型實現(xiàn)也是我們當初選擇用 TensorFlow 來實現(xiàn)的重要原因之一。

在得到圖片 feature 以后，我們通過 LSTMRNN 進行一個標準的 Encoder->Decoder 過程，得益于 TensorFlow 的豐富實現(xiàn)，這整個過程只要調(diào)用 TensorFlow 中 seq2seq 相關接口就可以輕松實現(xiàn)。 不過 seq2seq 的接口在 TensorFlow1.0 以后有一些接口上的變化，我們使用了更新以后的接口。

接下來是如何把模型放到客戶端去運行，我們在這里面臨諸多選擇。 整體方案來看，我們需要選擇使用 TensorFlow Mobile 還是 TensorFlow Lite，另外在 iOS 端，我們需要考慮是否要將模型轉(zhuǎn)為 iOS 的 CoreML 模型。由于 CoreML 只從 iOS 11 開始支持，我們很快否掉了這個選項。我們在做這個功能的時候，TensorFlow 剛發(fā)布了 1.4（目前已經(jīng) 1.12 了），Lite 還是一個全新的東西， 最大的問題是對于各種 ops 支持不夠好，而且當時官方網(wǎng)站也是推薦在生產(chǎn)環(huán)境中使用 Mobile 版本， 所以盡管 Lite 有著各種優(yōu)點， 我們還是選擇了 Mobile。

TensorFlow Mobile 的文檔也算是相對豐富的，我們在部署的過程中并沒有遇到太大的障礙。有一點需要注意的是，需要使用 print_selective_registration_header 這個小工具來分析模型中真正使用到的算子，從而大大減少生成的運行庫的大小。

就這樣我們第一個版本順利上線并穩(wěn)定運行，但我們依然關注著 Lite 的動態(tài)。 在經(jīng)過一些考慮后，特別是在 2018 年 10 月的谷歌開發(fā)者大會上聽到了更多 TensorFlow Lite 的介紹，我們決定用Lite 替換掉 Mobile 版本，主要基于以下幾個考慮：

更小的運行庫體積， 通過 TensorFlow Lite 生成的運行庫體積很小，去掉了很多不必要的依賴。比如模型采用新的更輕量級 FlatBuffers 格式，而之前使用的 protobuf 需要很多的依賴庫。同時 TensorFlow Lite 以更加輕量級的方式實現(xiàn)了原來 TensorFlow 中的核心算子， 也有效降低了運行庫的體積。

更快的運行速度。 TensorFlow Lite 很多核心算子是專門為移動平臺優(yōu)化過的，同時通過NNAPI 能夠透明的支持 GPU 加速，在一些老設備上能夠自動回滾到 CPU 計算。

TensorFlow Lite 的模型量化功能，將模型量化到 int8，在幾乎不怎么損失計算精度的情況下把模型變?yōu)樵瓉淼?1/4 大小。

但是我們?nèi)匀挥龅搅撕芏嗬щy。主要是：

TensorFlow Lite 尚不支持 controlflow，意味著 TensorFlow 新 seq2seq 接口中的 dynamic_decode不能正確導出執(zhí)行。

TensorFlow Lite 中對于 LSTM 的支持不夠完善，比如 forgetbias 參數(shù)并不支持。

我們所使用的部分 operators 在 TensorFlow Lite 中還不支持，比如 GatherTree等等。

在 TensorFlow Lite 中實現(xiàn) controlflow 并不是件容易的事情，并不能直接通過 customop 來實現(xiàn)，最終我們把動態(tài)解碼變成了靜態(tài)展開，稍微損失了一些性能但是解決了這個問題。 對于 forget bias 的問題， 我們?nèi)∏傻脑趨?shù)恢復的時候把 forgetbias 加在 LSTMforgetgate 的 bias 上，這樣就不用修改 TensorFlow Lite 的代碼了。對于其他問題，都可以通過 customop 來實現(xiàn)，相對容易一些。

最終我們通過 toco 把 graphpb 導出成 TensorFlow Lite 格式，接下來就是要集成到手機上運行。在這一步上我們并沒有遇到太多阻礙。因為有了之前集成 TensorFlowMobile 的經(jīng)驗，我們很快完成了集成。 我們在具體實現(xiàn)的時候把識別接口做了封裝，這樣在我們從 TensorFlowMobile 遷移到 TensorFlowLite 的時候，客戶端開發(fā)的同事幾乎不需要改動代碼就可以使用新的接口。

在完成 TensorFlow Mobile 到 TensorFlow Lite 的遷移以后，我們單次 inference 的速度提高了20%，模型大小減少了 75%，可以說是非常有吸引力的。

隨著手機端計算能力的不斷增強，越來越多的深度學習模型可以在手機端運行。 目前TensorFlow Lite 也在快速開發(fā)迭代中，相信 TensorFlow Lite 會在更多實踐中越來越好。

感謝 TensorFlow Lite 團隊在我們的開發(fā)過程中給予的支持，特別是顧仁民和劉仁杰兩位技術(shù)專家給我們提供了很多有幫助的資料和參考，希望將來有更多的合作機會。