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
310
型チェックのアノテーションによる保守・運用の改善
「日本ソフトウェア科学会第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
130
REALITY株式会社における開発生産性向上の取り組み: 失敗と成功から学んだこと
gree_tech
PRO
2
1.8k
『ヘブンバーンズレッド』におけるフィールドギミックの裏側
gree_tech
PRO
2
600
セキュリティインシデント対応の体制・運用の試行錯誤 / greetechcon2024-session-a1
gree_tech
PRO
1
610
『アナザーエデン 時空を超える猫』国内海外同時運営実現への道のり ~別々で開発されたアプリを安定して同時リリースするまでの取り組み~
gree_tech
PRO
1
580
『アサルトリリィ Last Bullet』におけるクラウドストリーミング技術を用いたブラウザゲーム化の紹介
gree_tech
PRO
1
660
UnityによるPCアプリの新しい選択肢。「PC版 Google Play Games」への対応について
gree_tech
PRO
1
1k
実機ビルドのエラーによる検証ブロッカーを0に!『ヘブンバーンズレッド』のスモークテスト自動化の取り組み
gree_tech
PRO
1
690
"ゲームQA業界の技術向上を目指す! 会社を超えた研究会の取り組み"
gree_tech
PRO
1
820
Other Decks in Technology
See All in Technology
AWS表彰プログラムとキャリアについて
naoki_0531
1
140
Power Automate のパフォーマンス改善レシピ / Power Automate Performance Improvement Recipes
karamem0
0
270
20250728 MCP, A2A and Multi-Agents in the future
yoshidashingo
1
100
Kiro Hookを Terraformで検証
ao_inoue
0
140
会社もクラウドも違うけど 通じたコスト削減テクニック/Cost optimization strategies effective regardless of company or cloud provider
aeonpeople
2
370
OpenTelemetry の Log を使いこなそう
biwashi
5
1.1k
少人数でも回る! DevinとPlaybookで支える運用改善
ishikawa_pro
4
1.8k
[MIRU2025]Preference Optimization for Multimodal Large Language Models for Image Captioning Tasks
keio_smilab
PRO
0
110
ecspressoの設計思想に至る道 / sekkeinight2025
fujiwara3
12
2.1k
公開初日に個人環境で試した Gemini CLI 体験記など / Gemini CLI実験レポート
you
PRO
3
630
LLM開発を支えるエヌビディアの生成AIエコシステム
acceleratedmu3n
0
340
Railsの限界を超えろ!「家族アルバム みてね」の画像・動画の大規模アップロードを支えるアーキテクチャの変遷
ojima_h
4
520
Featured
See All Featured
GitHub's CSS Performance
jonrohan
1031
460k
Java REST API Framework Comparison - PWX 2021
mraible
31
8.7k
Imperfection Machines: The Place of Print at Facebook
scottboms
267
13k
Become a Pro
speakerdeck
PRO
29
5.4k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
53
2.9k
A better future with KSS
kneath
238
17k
It's Worth the Effort
3n
185
28k
Gamification - CAS2011
davidbonilla
81
5.4k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
357
30k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
10
1k
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
3.9k
Thoughts on Productivity
jonyablonski
69
4.8k
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