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
300
型チェックのアノテーションによる保守・運用の改善
「日本ソフトウェア科学会第35回大会」で発表された資料です。
https://jssst2018.wordpress.com/program/
gree_tech
PRO
April 22, 2019
Tweet
Share
More Decks by gree_tech
See All by gree_tech
コミュニケーションに鍵を見いだす、エンジニア1年目の経験談
gree_tech
PRO
0
120
REALITY株式会社における開発生産性向上の取り組み: 失敗と成功から学んだこと
gree_tech
PRO
2
1.7k
『ヘブンバーンズレッド』におけるフィールドギミックの裏側
gree_tech
PRO
2
580
セキュリティインシデント対応の体制・運用の試行錯誤 / greetechcon2024-session-a1
gree_tech
PRO
1
580
『アナザーエデン 時空を超える猫』国内海外同時運営実現への道のり ~別々で開発されたアプリを安定して同時リリースするまでの取り組み~
gree_tech
PRO
1
550
『アサルトリリィ Last Bullet』におけるクラウドストリーミング技術を用いたブラウザゲーム化の紹介
gree_tech
PRO
1
630
UnityによるPCアプリの新しい選択肢。「PC版 Google Play Games」への対応について
gree_tech
PRO
1
1k
実機ビルドのエラーによる検証ブロッカーを0に!『ヘブンバーンズレッド』のスモークテスト自動化の取り組み
gree_tech
PRO
1
660
"ゲームQA業界の技術向上を目指す! 会社を超えた研究会の取り組み"
gree_tech
PRO
1
780
Other Decks in Technology
See All in Technology
united airlines ™®️ USA Contact Numbers: Complete 2025 Support Guide
flyunitedhelp
1
440
20250707-AI活用の個人差を埋めるチームづくり
shnjtk
6
4k
Zero Data Loss Autonomous Recovery Service サービス概要
oracle4engineer
PRO
2
7.8k
United airlines®️ USA Contact Numbers: Complete 2025 Support Guide
unitedflyhelp
0
330
AIの全社活用を推進するための安全なレールを敷いた話
shoheimitani
2
570
Operating Operator
shhnjk
1
620
Claude Code に プロジェクト管理やらせたみた
unson
7
4.7k
How Do I Contact HP Printer Support? [Full 2025 Guide for U.S. Businesses]
harrry1211
0
130
Getting to Know Your Legacy (System) with AI-Driven Software Archeology (WeAreDevelopers World Congress 2025)
feststelltaste
1
160
アクセスピークを制するオートスケール再設計: 障害を乗り越えKEDAで実現したリソース管理の最適化
myamashii
1
180
ポストコロナ時代の SaaS におけるコスト削減の意義
izzii
1
130
公開初日に Gemini CLI を試した話や FFmpeg と組み合わせてみた話など / Gemini CLI 初学者勉強会(#AI道場)
you
PRO
0
230
Featured
See All Featured
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
46
9.6k
The MySQL Ecosystem @ GitHub 2015
samlambert
251
13k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
251
21k
StorybookのUI Testing Handbookを読んだ
zakiyama
30
5.9k
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
3.9k
A better future with KSS
kneath
238
17k
Building Adaptive Systems
keathley
43
2.7k
Statistics for Hackers
jakevdp
799
220k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
30
2.1k
Principles of Awesome APIs and How to Build Them.
keavy
126
17k
Faster Mobile Websites
deanohume
307
31k
Rebuilding a faster, lazier Slack
samanthasiow
83
9.1k
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