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
320
型チェックのアノテーションによる保守・運用の改善
「日本ソフトウェア科学会第35回大会」で発表された資料です。
https://jssst2018.wordpress.com/program/
gree_tech
PRO
April 22, 2019
Tweet
Share
More Decks by gree_tech
See All by gree_tech
LLM翻訳ツールの開発と海外のお客様対応等への社内導入事例
gree_tech
PRO
0
460
ヘブンバーンズレッドのレンダリングパイプライン刷新
gree_tech
PRO
0
470
ヘブンバーンズレッドにおける、世界観を活かしたミニゲーム企画の作り方
gree_tech
PRO
0
460
「魔法少女まどか☆マギカ Magia Exedra」のグローバル展開を支える、開発チームと翻訳チームの「意識しない協創」を実現するローカライズシステム
gree_tech
PRO
0
460
「魔法少女まどか☆マギカ Magia Exedra」での負荷試験の実践と学び
gree_tech
PRO
0
470
「魔法少女まどか☆マギカ Magia Exedra」の必殺技演出を徹底解剖! -キャラクターの魅力を最大限にファンに届けるためのこだわり-
gree_tech
PRO
0
470
ヒューリスティック評価を用いたゲームQA実践事例
gree_tech
PRO
0
450
ライブサービスゲームQAのパフォーマンス検証による品質改善の取り組み
gree_tech
PRO
0
460
コミュニケーションに鍵を見いだす、エンジニア1年目の経験談
gree_tech
PRO
0
140
Other Decks in Technology
See All in Technology
エラーとアクセシビリティ
schktjm
0
610
iPhone Eye Tracking機能から学ぶやさしいアクセシビリティ
fujiyamaorange
0
410
【Grafana Meetup Japan #6】Grafanaをリバプロ配下で動かすときにやること ~ Grafana Liveってなんだ ~
yoshitake945
0
220
AI エージェントとはそもそも何か? - 技術背景から Amazon Bedrock AgentCore での実装まで- / AI Agent Unicorn Day 2025
hariby
3
650
進捗
ydah
2
230
【初心者向け】ローカルLLMの色々な動かし方まとめ
aratako
7
2.8k
AI時代に非連続な成長を実現するエンジニアリング戦略
sansantech
PRO
3
960
データアナリストからアナリティクスエンジニアになった話
hiyokko_data
2
370
Kiroと学ぶコンテキストエンジニアリング
oikon48
6
7.7k
Kubernetes における cgroup driver のしくみ: runwasi の bugfix より
z63d
2
120
絶対に失敗できないキャンペーンページの高速かつ安全な開発、WINTICKET × microCMS の開発事例
microcms
0
370
Figma + Storybook + PlaywrightのMCPを使ったフロントエンド開発
yug1224
10
3.7k
Featured
See All Featured
Site-Speed That Sticks
csswizardry
10
810
The Illustrated Children's Guide to Kubernetes
chrisshort
48
50k
The World Runs on Bad Software
bkeepers
PRO
70
11k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
252
21k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
139
34k
Writing Fast Ruby
sferik
628
62k
Bootstrapping a Software Product
garrettdimon
PRO
307
110k
Bash Introduction
62gerente
614
210k
Designing for Performance
lara
610
69k
Thoughts on Productivity
jonyablonski
69
4.8k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
111
20k
How to train your dragon (web standard)
notwaldorf
96
6.2k
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