型チェックのアノテーション による保守・運用の改善 グリー株式会社 橋本順之 rev0.1

説明の流れ 1. 保守運用の問題 2. 機械学習のソフトの問題 3. 改善したい問題 4. 既存の手法の確認 5. 提案手法 6. まとめと今後の課題

保守運用の確認 ● 目的 ○ 既存のソフトを長期的に安定利用 ● 保守 ○ ハードウェア、OS、セキュリティ、ライブラリの都合でバージョン アップが必要（EOL迎えたとか、python2->3にしたい） ○ 開発のときのように工数がない ○ 人の入れ替えも発生 ● 運用 ○ 毎日繰り返し同じプログラムを動作 ○ 機械の故障や不正入力などの問題の切り分け必要 ○ 問題特定のデバッグ＆修正必要

機械学習のソフトの問題 ● 動的型付け言語を使用 ● データの型が検証できない ● 扱うデータが行列やテンソルで、次元や扱う数の精度がコードに明示さ れてない ● 引数の値によってテンソルの次元が変化 ○ 例、TensorflowのLSTMの関数は引数でbatchの次元が入れ替わる ● クラスを利用したデータ構造では管理できない。 ○ 例、5x3の行列を15x1にしてまた5x3に戻すとか ● LINTつかえない

改善したい問題 ● コードの可読性を向上したい ○ 保守や運用を行う上でデバッグやコードのレビューやテストが必要 ○ 機械学習のソフトの型の問題のためコードの可読性が悪くレビューで きない ○ コードの引継ぎが困難 ● ライブラリや保守対象のプログラムのAPIやインターフェースの検証をした い。

既存の手法の確認 ● テンソルの次元を言語で管理 ○ 型に値を利用できる依存型を利用 ○ 型の例、 Tensor [3,2,2] Float(型名 次元 数値の型) ○ Pros: コード分かりやすい ○ Cons: 既存の資産が使えない、開発は遅くなるかも。 ● 型アノテーションを付ける(mypy) ○ Pros: 既存の資産が使え、コード分かりやすい。 ○ Cons: テンソルの次元が扱えない。

提案手法 ● 関数など検証したい対象に型のチェックをいれる ○ doctestを用いてチェックを入れる。 ○ doctest: ドキュメント中に検証可能なコードを埋め込む。 ○ 書き方の例は次のスライド ● Pros: ○ 既存の資産が使える。 ○ 実際の計算を行わなければ高速に検証できる ● Cons: ○ 網羅的にチェックはできない。 ○ 書き方が自己流すぎる。（引継ぎが困難）

提案手法例 #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") #関数の出力する期待値デー タで次元（shape）がチェックできる． """ 関数本体が続く

まとめと今後の課題 ● 問題 ○ 機械学習のソフトのAPIやインターフェースが難読 ○ レビューが難しく保守運用が困難 ● 案 ○ APIやインターフェースをわかりやすくするためにドキュメン ト中に型のテストをするのはどうか ● 課題 ○ 網羅的にチェックはできない。 ○ 書き方が自己流すぎる。（引継ぎが困難）