型チェックのアノテーションによる保守・運用の改善

「第1回機械学習工学ワークショップ（MLSE2018）」で発表された資料です。
https://mlxse.connpass.com/event/83360/

Transcript

1. 型チェックのアノテーション による保守・運用の改善 グリー株式会社 橋本順之 rev0.1
2. 説明の流れ 1. 保守運用の問題 2. 機械学習のソフトの問題 3. 改善したい問題 4. 既存の手法の確認 5. 提案手法 6. まとめと今後の課題
3. 保守運用の確認 • 目的 ◦ 既存のソフトを長期的に安定利用 • 保守 ◦ ハードウェア、OS、セキュリティ、ライブラリの都合でバージョン アップが必要（EOL迎えたとか、python2->3にしたい） ◦ 開発のときのように工数がない ◦ 人の入れ替えも発生 • 運用 ◦ 毎日繰り返し同じプログラムを動作 ◦ 機械の故障や不正入力などの問題の切り分け必要 ◦ 問題特定のデバッグ＆修正必要
4. 機械学習のソフトの問題 • 動的型付け言語を使用 • データの型が検証できない • 扱うデータが行列やテンソルで、次元や扱う数の精度がコードに明示さ れてない • 引数の値によってテンソルの次元が変化 ◦ 例、TensorflowのLSTMの関数は引数でbatchの次元が入れ替わる • クラスを利用したデータ構造では管理できない。 ◦ 例、5x3の行列を15x1にしてまた5x3に戻すとか • LINTつかえない
5. 改善したい問題 • コードの可読性を向上したい ◦ 保守や運用を行う上でデバッグやコードのレビューやテストが必要 ◦ 機械学習のソフトの型の問題のためコードの可読性が悪くレビューで きない ◦ コードの引継ぎが困難 • ライブラリや保守対象のプログラムのAPIやインターフェースの検証をした い。
6. 既存の手法の確認 • テンソルの次元を言語で管理 ◦ 型に値を利用できる依存型を利用 ◦ 型の例、 Tensor [3,2,2] Float(型名 次元 数値の型) ◦ Pros: コード分かりやすい ◦ Cons: 既存の資産が使えない、開発は遅くなるかも。 • 型アノテーションを付ける(mypy) ◦ Pros: 既存の資産が使え、コード分かりやすい。 ◦ Cons: テンソルの次元が扱えない。
7. 提案手法 • 関数など検証したい対象に型のチェックをいれる ◦ doctestを用いてチェックを入れる。 ◦ doctest: ドキュメント中に検証可能なコードを埋め込む。 ◦ 書き方の例は次のスライド • Pros: ◦ 既存の資産が使える。 ◦ 実際の計算を行わなければ高速に検証できる • Cons: ◦ 網羅的にチェックはできない。 ◦ 書き方が自己流すぎる。（引継ぎが困難）
8. 提案手法例 #CNNのモデルを生成する関数 def cnn_model(features,mode,name=None): #関数と入力変数の宣言 """Model function for CNN. #関数のドキュメント兼テスト #変数の宣言 >>> batch = 7 >>> xdat = tf.zeros([batch,784],name="x") #関数の実行 >>> cnn_model({'x':xdat},tf.estimator.ModeKeys.TRAIN,"cnnt") <tf.Tensor 'cnnt/BiasAdd:0' shape=(7, 10) dtype=float32> #関数の出力する期待値デー タで次元（shape）がチェックできる． """ 関数本体が続く
9. まとめと今後の課題 • 問題 ◦ 機械学習のソフトのAPIやインターフェースが難読 ◦ レビューが難しく保守運用が困難 • 案 ◦ APIやインターフェースをわかりやすくするためにドキュメン ト中に型のテストをするのはどうか • 課題 ◦ 網羅的にチェックはできない。 ◦ 書き方が自己流すぎる。（引継ぎが困難）