前回、前々回から引き続き、植物の写真から病気を判別するサイト(http://www.plant-check.jp/)を作ったときのまとめ。今回はWEBサイトを構築したときのまとめ。
WEBサイトの概要
リンクにあるとおり、WEBサイトはシンプルな作りとなっている。大きなユースケースは下記の2つ。そしてやることはほとんど同じ。
- ユーザがサイトの「写真を撮影」ボタンを押すと、自分のスマホから写真を撮ることが出来る。次に「病気をチェック」ボタンを押すと、取った写真の植物が病気か判定される。
- ユーザがサイトの「写真を選択」ボタンを押すと、自分のPC/スマホから写真を選択することが出来る。次に「病気をチェック」ボタンを押すと、選んだ写真の植物が病気か判定される。
HTML部分
スマホ経由で写真を取らせるにはcapture=”camera”を使えばOK。
<input type="file" accept="image/*" capture="camera" id="camera" style="display:none;" name="upload" />
それ以外の部分として、labelタグを使ってボタンを隠したり、若干JavaScriptでボタンの活性・非活性を切り替えたりしているが特殊なことはやっていない。
サーバ部分
サーバ部分の構成は次の通りで、こちらも特殊な構成ではない。
- sakuraのVPS（ubuntu 16.04 LTS）
- Docker
- nginx
- uwsgi
- Pythonのアプリ
- bottleを利用してモデル部分（keras + tensorflow）とWEBアプリ部分をつなげた。
uwsgiとnginxのつなぎはSocketを使用した。（nginx側 uwsgi_pass unix:/path_to/uwsgi.sock、uwsgi側 socket = /path_to/uwsgi.sock ）良くわからない場合は、公式サイトのサンプルを見ながら書くのが一番だった記憶がある。
Pythonのアプリ部分はbottleを用いて書いた。毎回毎回モデルをロードするアプローチはさすがに富豪過ぎるので、起動時に判別モデル（植物か否か、病気か否か）をロードしてそれを使いまわすようにしている。
一点はまった点としてuwsgi.confでthreads = 1、enable-threads = falseとしないと動作しなかった。当時forumを確認した感じではkerasのpredict処理がマルチスレッドに対応していないのが原因だったと記憶している（が、モデル読み込み時にフリーズしたような記憶もある）。それと、bottleの制約のようだが、巨大ファイルをアップロードされた場合の対策（chunkごとに読みこんで、一定以上のサイズの場合は処理を停止）を自分で書かないといけないのが面倒だった。
まとめ
モデル構築部分のコード行数は約100行（×2）、サーバ部分のコード行数は約200行だった。「AI（人工知能）が病気を診断！」というサイトがこの程度の行数で書けてしまうのは、便利なライブラリが整備されたおかげで、作者に感謝である。もっとも、モデル構築部分はノウハウ含めて自動化されていくはずで、大手各社もAutoML、Azure Machine Learning、・・・と言った名前でそのような環境をリリースしている。
AIやら人工知能やら何やらの主戦場は、結局何するの？という方向か、ほんまに使えるの？という方向になる気がしていて、クロスバリデーションベースのモデル精度を競っても無意味な時代になりつつあるんだろうなーと思う。（ということで私は自動化大歓迎、その他の思いはその他へ）
今後、情熱が復活すれば他の病気への対応を行う予定。もう少し実験したいことがあるので、コードを公開するのはその後になる見込み。
その他
データ収集 ～ AI（人工知能）の構築 ～ それを使うWEBアプリ作成という一連の流れに加えて、環境構築やデプロイまでを一人でやってみたわけで、これでstakaは”ふるすたっくえんじにあ”であると胸を張って言えるはず（ハードウェア、ネットワーク、DBは今回入っていないけど）。
それはおいておいて、2年に1回くらいの割合で起きる衝動のもとサイトを作ってみた。一連の流れを自分でやってみると本当に勉強になる。仕事を忘れて好き放題にアプローチやライブラリを選ぶのも楽しい。
前回も書いた通り、現時点では「ある目的のために構築すべきAI」を正しく設計するのは人間の仕事である。本件だと、何をやりたいのか？AIにどういった動きを期待するのか？どういったモデルを作るのか？どういったデータが必要なのか？データのバイアスはどう取り扱うのか？どういった技術を選ぶのか？どうやって実装するのか？どうやって検証するのか？どうやって運用するのか？などなど、色々決める必要がある。（なんとなくフローチックに書いているが、実際は多くの手戻りや再検討が発生する）
上記に加え、最近は説明可能性、信頼性、公平性といったことも考える必要がでてきている。GDPR 2018（https://ja.wikipedia.org/wiki/EU%E4%B8%80%E8%88%AC%E3%83%87%E3%83%BC%E3%82%BF%E4%BF%9D%E8%AD%B7%E8%A6%8F%E5%89%87#%E8%B2%AC%E5%8B%99%E3%81%A8%E8%AA%AC%E6%98%8E%E8%B2%AC%E4%BB%BB）とか規制もある。GDPR2018の内容は個人的（モデルを作る人目線を外すと）には、まーそうだよねー、といったモノだが、モデルを作る人・使う人目線だと、ハードル高いなーという印象を受ける。Partnership on AI(https://www.partnershiponai.org/)みたいな業界団体が出来たり、fairness-awareなデータマイニング手法や機械学習手法が研究されていたり、XAI（Explainable Artificial Intelligence）をキーワードとする研究がなされていたり、と上記に対応する動きはあるにはあるのだが、テクノロジーとしてこれでOKみたいな方法は今のところ無い。（もっともテクノロジーで解決可能な問題なのか？と言う疑問はあるが・・・。）
せっかくのAIブームなので、リソースが大量にかけられる今こそ「AIと倫理」のように難しい部分の議論が進んでほしいなー（進めたいなー）と思う今日この頃。
0 Comments.