Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
型チェックのアノテーションによる保守・運用の改善
Search
gree_tech
PRO
April 22, 2019
Technology
0
190
型チェックのアノテーションによる保守・運用の改善
「日本ソフトウェア科学会第35回大会」で発表された資料です。
https://jssst2018.wordpress.com/program/
gree_tech
PRO
April 22, 2019
Tweet
Share
More Decks by gree_tech
See All by gree_tech
REALITY株式会社における開発生産性向上の取り組み: 失敗と成功から学んだこと
gree_tech
PRO
2
200
『ヘブンバーンズレッド』におけるフィールドギミックの裏側
gree_tech
PRO
2
150
セキュリティインシデント対応の体制・運用の試行錯誤 / greetechcon2024-session-a1
gree_tech
PRO
1
150
『アナザーエデン 時空を超える猫』国内海外同時運営実現への道のり ~別々で開発されたアプリを安定して同時リリースするまでの取り組み~
gree_tech
PRO
1
130
『アサルトリリィ Last Bullet』におけるクラウドストリーミング技術を用いたブラウザゲーム化の紹介
gree_tech
PRO
1
160
UnityによるPCアプリの新しい選択肢。「PC版 Google Play Games」への対応について
gree_tech
PRO
1
260
実機ビルドのエラーによる検証ブロッカーを0に!『ヘブンバーンズレッド』のスモークテスト自動化の取り組み
gree_tech
PRO
1
190
"ゲームQA業界の技術向上を目指す! 会社を超えた研究会の取り組み"
gree_tech
PRO
1
240
Jamstack でリニューアルするグリーグループのメディア
gree_tech
PRO
2
400
Other Decks in Technology
See All in Technology
事業貢献を考えるための技術改善の目標設計と改善実績 / Targeted design of technical improvements to consider business contribution and improvement performance
oomatomo
0
150
組み込みアプリパフォーマンス格闘記 検索画面編
wataruhigasi
1
140
Wantedly での Datadog 活用事例
bgpat
2
690
.NET 9 のパフォーマンス改善
nenonaninu
0
1.3k
5分でわかるDuckDB
chanyou0311
10
3.3k
ずっと昔に Star をつけたはずの思い出せない GitHub リポジトリを見つけたい!
rokuosan
0
160
継続的にアウトカムを生み出し ビジネスにつなげる、 戦略と運営に対するタイミーのQUEST(探求)
zigorou
0
830
Oracle Cloud Infrastructure:2024年12月度サービス・アップデート
oracle4engineer
PRO
1
270
非機能品質を作り込むための実践アーキテクチャ
knih
5
1.6k
pg_bigmをRustで実装する(第50回PostgreSQLアンカンファレンス@オンライン 発表資料)
shinyakato_
0
110
2024年にチャレンジしたことを振り返るぞ
mitchan
0
150
組織に自動テストを書く文化を根付かせる戦略(2024冬版) / Building Automated Test Culture 2024 Winter Edition
twada
PRO
18
5.6k
Featured
See All Featured
Put a Button on it: Removing Barriers to Going Fast.
kastner
59
3.6k
Bootstrapping a Software Product
garrettdimon
PRO
305
110k
Principles of Awesome APIs and How to Build Them.
keavy
126
17k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
127
18k
Designing Experiences People Love
moore
138
23k
The Web Performance Landscape in 2024 [PerfNow 2024]
tammyeverts
2
290
Designing Dashboards & Data Visualisations in Web Apps
destraynor
229
52k
Product Roadmaps are Hard
iamctodd
PRO
50
11k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
111
49k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
226
22k
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
656
59k
Embracing the Ebb and Flow
colly
84
4.5k
Transcript
型チェックのアノテーション による保守・運用の改善 橋本順之(グリー株式会社) 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. <tf.Tensor 'cnnt/BiasAdd:0' shape=(7, 10) dtype=float32> 9. #関数の出力する期待値デー タでshapeのところで次元がチェックできる. 10. """ 11. 関数本体が続く 18
提案手法#振りかえり • cnn_modelの実行とその次元の型のチェックができている • Tensorflowの実装に依存し過ぎている • 期待値がある一例しか表せていない ーー前頁のテストの抜粋ーー 7. >>>
cnn_model({'x':xdat}) 8. <tf.Tensor 'cnnt/BiasAdd:0' shape=(7, 10) dtype=float32> 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