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
290
型チェックのアノテーションによる保守・運用の改善
「日本ソフトウェア科学会第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
550
セキュリティインシデント対応の体制・運用の試行錯誤 / greetechcon2024-session-a1
gree_tech
PRO
1
560
『アナザーエデン 時空を超える猫』国内海外同時運営実現への道のり ~別々で開発されたアプリを安定して同時リリースするまでの取り組み~
gree_tech
PRO
1
520
『アサルトリリィ Last Bullet』におけるクラウドストリーミング技術を用いたブラウザゲーム化の紹介
gree_tech
PRO
1
610
UnityによるPCアプリの新しい選択肢。「PC版 Google Play Games」への対応について
gree_tech
PRO
1
970
実機ビルドのエラーによる検証ブロッカーを0に!『ヘブンバーンズレッド』のスモークテスト自動化の取り組み
gree_tech
PRO
1
630
"ゲームQA業界の技術向上を目指す! 会社を超えた研究会の取り組み"
gree_tech
PRO
1
740
Other Decks in Technology
See All in Technology
Prox Industries株式会社 会社紹介資料
proxindustries
0
320
ひとり情シスなCTOがLLMと始めるオペレーション最適化 / CTO's LLM-Powered Ops
yamitzky
0
440
Snowflake Summit 2025全体振り返り / Snowflake Summit 2025 Overall Review
mtpooh
2
400
Кто отправит outbox? Валентин Удальцов, автор канала Пых
lamodatech
0
350
AIエージェント最前線! Amazon Bedrock、Amazon Q、そしてMCPを使いこなそう
minorun365
PRO
15
5.3k
AIのAIによるAIのための出力評価と改善
chocoyama
2
570
rubygem開発で鍛える設計力
joker1007
2
220
Yamla: Rustでつくるリアルタイム性を追求した機械学習基盤 / Yamla: A Rust-Based Machine Learning Platform Pursuing Real-Time Capabilities
lycorptech_jp
PRO
3
130
Fabric + Databricks 2025.6 の最新情報ピックアップ
ryomaru0825
1
140
【5分でわかる】セーフィー エンジニア向け会社紹介
safie_recruit
0
26k
2025-06-26_Lightning_Talk_for_Lightning_Talks
_hashimo2
2
100
MySQL5.6から8.4へ 戦いの記録
kyoshidaxx
1
260
Featured
See All Featured
Fashionably flexible responsive web design (full day workshop)
malarkey
407
66k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
138
34k
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
PRO
20
1.3k
Statistics for Hackers
jakevdp
799
220k
Java REST API Framework Comparison - PWX 2021
mraible
31
8.6k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
248
1.3M
Building a Modern Day E-commerce SEO Strategy
aleyda
42
7.3k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
331
22k
VelocityConf: Rendering Performance Case Studies
addyosmani
330
24k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
107
19k
Rails Girls Zürich Keynote
gr2m
94
14k
It's Worth the Effort
3n
185
28k
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