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

発表の流れ ● 目的 ● 保守運用の問題 ● 機械学習のソフトの問題 ● 改善したい問題 ● 既存手法の確認 ● 提案手法 ● まとめと今後の課題 2

目的 ● 既存の機械学習のアルゴリズムやシステム ○ 長期的に安定して利用したい ○ 保守運用を適切に行いたい 3

保守の課題の確認 ● 常に使えるようにしておく必要がある。 ● バージョンアップの必要性 ○ EOL：定期的にハードウェア、OS、ライブラリのEOL の都合で仕方なくバージョンアップが必要となる。 ● 工数 ○ 開発のときのように工数がかけられない。 ● 人的リソース ○ 人の入れ替えへの対応 ○ ドキュメンテーション 4

保守の問題：バージョンアップの例 ● ライブラリのバージョンアップへの追従の必要性 ○ EOL、バグフィックス、実行環境の変化、セキュリティ ○ 枯れていると思っていてもバグが見つかる（OpenSSL） ● 変わるもの ○ パッケージの場所 ○ 関数名、変数名、引数の名前、引数の順番 ■ 次元のパラメータ ○ 関数の挙動 ● Tensorflow 0.x -> 1.xの場合 ● chainer の場合 5

保守の問題：不十分なドキュメント ● ドキュメントが不明慮でAPIの使い方がわからない。 ○ 値から値を返す関数なのか、関数を返す関数なのか？ ○ APIの仕様がわからないと自分たちのプログラムはメンテナンスできない ● 例1、tensorflowのLSTMCell ○ 関数を返す関数 ○ https://www.tensorflow.org/api_docs/python/tf/contrib/rnn/LSTMCell#__call__ ○ 入力のパラメータによって出力の型が変わる ● 例2、tensorflowのdynamic_rnn ○ time_majorパラメータで出力のテンソルに転置が起こる。 ○ https://www.tensorflow.org/api_docs/python/tf/nn/dynamic_rnn ○ バグ ○ https://github.com/tensorflow/tensorflow/commit/916fcfb39a23afd96893bf85cb6f29c71a483 642#diff-9d717423e6d3f4359151c45dfaa554b6 6

運用の課題の確認 ● 毎日繰り返し同じプログラムを動作。 ● 動作不良の改善と切り分け ○ 機械の故障 ○ 不正な入力 ○ リソースのあふれ ○ バグ？ ● 問題の特定 ○ 不正な動作か、正常動作の問題の切り分け。 ○ ログの解析 ○ デバッグコードを直して修正の確認が必要 7

機械学習のソフトの問題 ● ITのソフト ○ 静的型付け言語・動的型付け言語 ○ 扱うデータがクラス単位 ○ 文字列・数字・クラスのデータ型で足りる場合が多い ● 機械学習ソフト ○ 動的型付け言語 ○ 扱うデータが行列やテンソル ■ 次元や扱う数の精度がコードに明示されていない ■ ドキュメントまたはコードの精読必要 ○ 引数の値によってテンソルの次元が変化するものもある ○ ベストプラクティスが確立してない 8

ITのソフトの場合 ● 例：データをAWSのS3にアップロードする場合 ○ 静的型付け言語 ■ typescript ○ 入力データ（キーとデータを指定する） ■ bucket: 文字列 ■ key: 文字列 ■ body: Buffer|Uint8Array|Blob|string|Readable ○ リンク ■ https://github.com/aws/aws-sdk-js/blob/master/clients/s3.d.ts ● APIの入出力が定義されているので間違えるところはあまりない。 ○ ユーザーはシステム構築に集中できる。 9

機械学習のソフトの場合 ● 例1：a * b (要素ごとの掛け算) ○ 動的型付け言語 ■ python ○ スカラ * スカラ = スカラ ○ 行列 * スカラ = 行列 ○ 行列 * 行列 = 行列 ○ 入出力にスカラを期待していない場合に問題が検出できない ● 例2：c ? a : bのような条件分岐を入れた場合 ● APIが期待と異なる型を容易に入出力できる ○ 些細な問題で躓く ○ ユーザーはシステム構築に集中できない 10

改善したい問題 ● ライブラリ ○ API のバージョンアップによる非互換を機械的にチェックできない ○ API のインターフェースの仕様が容易にわからない ○ ドキュメントとコードの動作の不一致があっても検出できない ● 保守対象のコード ○ コードの関数・ブロック単位でのレビューが難しい 11

既存の手法の確認 ● 依存型を用いてテンソルの次元を型で管理 ○ データ型に数字のリストなどの値を記述できる ○ 型の例、 Tensor [3,2,2] Float(型名 次元 数値の型) ● 型アノテーションを付ける(mypy) ○ 関数のコメント部のようなところに型を書く ○ 型の例、 np.ndarray（テンソルの型） 12

既存の手法の確認#依存型 ● テンソルの次元を型として扱う ○ Tensor [3,2,2] Float(型名 次元 数値の型) ● Haskellで実用化されつつありtensorflowのAPIも開発中（tensorflow-haskell-deptyped） ● tensorflowの大部分はpythonで書かれており、モデルや最適化のアルゴリズ ムは非対応なものが多い。 ● 下記例（擬似コード) 1. a :: Tensor [2,4] Float 2. a = <中身> 3. b :: Tensor [4,2] Float 4. b= <中身＞ 5. c :: Tensor [2,2] Float 6. c = a `matmul` b 13

既存の手法の確認#型アノテーション ● 型のアノテーション ○ 実際の動作とは関係なく、コメントのようなところに型を付与する。 ○ 型が間違っていても動作する。型の検証は別途行う。 ● 動的型付け言語でも利用できる。 ● 下記の例のようにint(整数)、np.ndarray(テンソル)の型を引数や戻り値に付与 する。(numpy stub) 1. #整 数 型 の ア ノ テ ー シ ョ ン 2. def int func (x : int ) −> int : 3. return x 4. #行 列 型 の ア ノ テ ー シ ョ ン 5. def ndarray func (x : np. ndarray) -> np. ndarray: 6. return x 14

既存の手法の確認 ● 依存型を用いてテンソルの次元を型で管理 ○ 型の例、 Tensor [3,2,2] Float(型名 次元 数値の型) ○ Pros: コード分かりやすく、動作との矛盾・乖離がない ○ Cons: 既存の資産が使えない、型の演算と実際の処理の両方が必要 ● 型アノテーションを付ける(mypy) ○ 型の例、 np.ndarray（テンソルの型） ○ Pros: 既存の資産が使え、コード分かりやすい ○ Cons: テンソルの次元が扱えない 15

改善したい問題 ● ライブラリ ○ API のバージョンアップによる非互換を機械的にチェ ックできない ○ API のインターフェースの仕様が容易にわからない ○ ドキュメントとコードの動作の不一致があっても検出 できない ● 保守対象のコード ○ コードの関数・ブロック単位でのレビューが難しい 16

提案手法#1 ● doctestに検証したいAPIやインターフェースの型をいれ検証 ● doctest: ドキュメント中に検証可能なコードを埋め込む。 ----doctestの例--- 1. def func（x,y） 2. ``` x + yを計算する関数 #コメント部 3. >>> func ( 1, 2 ) # テスト 4. 3 # 期待値 5. ``` 6. return x+y #実装 17

提案手法#2 1. def cnn_model(features): #関数と入力変数の宣言 2. """Model function for CNN. #関数のドキュメント兼テスト 3. #変数の宣言 4. >>> batch = 7 5. >>> xdat = tf.zeros([batch,784],name="x") 6. #関数の実行 7. >>> cnn_model({'x':xdat}) 8. 9. #関数の出力する期待値デー タでshapeのところで次元がチェックできる． 10. """ 11. 関数本体が続く 18

提案手法#振りかえり ● cnn_modelの実行とその次元の型のチェックができている ● Tensorflowの実装に依存し過ぎている ● 期待値がある一例しか表せていない ーー前頁のテストの抜粋ーー 7. >>> cnn_model({'x':xdat}) 8. 9. #関数の出力する期待値デー タでshapeのところで次元がチェックできる． 19

提案手法#改善 ● 型のチェックの可読性の改善 ーーーー 7. >>> batch = 7 8. >>> inout_eq(cnn_model, ¥ 9. in_shape=[batch,784],in_type=tf.float32 ¥ 10. out_shape=[batch,10],out_type=tf.float32)) 11. True 20

提案手法#改善 ● 型のパラメータ（batch）を自動生成してある程度網羅的に繰り返しテスト して入出力の型をチェックするのはどうか。 ーーーー 7. >>> prop_int(lambda batch: ¥ 8. inout_eq(cnn_model, ¥ 9. in_shape=[batch,784],in_type=tf.float32 ¥ 10. out_shape=[batch,10],out_type=tf.float32)) 11. True 21

提案手法#テストの網羅性の担保 ● 問題 ○ 型を入れていない関数があるのではないか？ ● 解決方法 ○ 実行環境の関数を列挙が容易にできる。（inspect） ○ doctestのコメント部を検査して検証漏れを検出 22

まとめと今後の課題 ● 問題 ○ 機械学習のソフトのAPIやインターフェースがわかりにくく、レビュー が難しく保守運用を困難にしている。 ● 案 ○ APIやインターフェースをわかりやすくするためにドキュメント中に型 のテストをするのはどうか。 ■ 機械的にAPIを検証し、ドキュメントに矛盾がない ■ 入出力がわかりやすくレビューしやすくなった ● 課題 ○ 書き方が自己流すぎる。（引継ぎが困難） ○ 依存型を用いたケースよりチェックの粒度が荒い ○ 他のパッケージとの相互運用（使うAPIすべてを検証するのか？） 23

ご清聴ありがとうございました。 24