Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Machine Learning : The high interest credit card of technical debt

1,377 views

Published on

社内勉強会資料.英語あまり得意ではないので鵜呑みにせずに眺めていただけると助かりますw

Published in: Engineering
  • Hello there! Get Your Professional Job-Winning Resume Here! http://bit.ly/topresum
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

Machine Learning : The high interest credit card of technical debt

  1. 1. The High-Interest Credit Card of Technical Debt 新技術研究会 Yuichi Yoshida Chief engineer, DENSO IT Laboratory, Inc. #20150220 @sonson_twit © 2015 DENSO IT Laboratory, Inc., All rights reserved. Redistribution or public display not permitted without written permission from DENSO IT Laboratory, Inc. Machine Learning:
  2. 2. Machine Learning: The High-Interest Credit Card of Technical Debt
  3. 3. はじめに • technical debt • 1992 Ward Cunninghamによって提唱 • 負債,全部が悪い訳じゃないが,どんどん複雑化する • 特に機械学習では,コードが複雑になる • ライブラリ整理→無駄 • ユニットテスト→無駄 • リファクタリング→無駄無駄無駄無駄無駄無駄!
  4. 4. この論文で議論すること • データ使い回すよね? • パッケージをブラックボックスにするよね? • パッケージ間のglue code書くよね? • 学習してもなかなかうまくいかないよね? • 色々やっちゃって,わけわからなくなるよね? • こういう問題をクリアにしても論文にならないよね? • こういう問題,テクでなんとかしちゃうよね?
  5. 5. • それはダメです!!!!!!
  6. 6. Complex Models Erode Boundaries • Entanglement • データがぐちゃぐちゃ • Hidden Feedback Loops • 周期が長い,可視化しにくいループ • Undeclared Consumers • 開発するときに使われているデータはどれ?
  7. 7. Entanglement • 特徴量を一つ増やしても,減らしても,すべての結果は変わる • CACEの原理 - Change anything, change everything • 対策1 モデルを分ける • そんなに綺麗にわかれないような • 対策2 可視化ツールを作る • 多次元,学習時間とか考えたら無理じゃない・・・? • 対策3 最強の正則化ツールを作る • アホか(ry • この問題は回避しようがない面がある • 開発のデッドラインよりもこれについて議論しよう
  8. 8. Hidden Feedback loop • 1週間のページビューを入力として学習する場合 • それに気付くのが難しい • 評価が難しい まめにチェックして取り除く・・・?除けるか?
  9. 9. Undeclared Consumers • 可視化の負債 • 誰が使っているか不明 • 例えば • フォントサイズとCTR これの防御はかなり難しい
  10. 10. Data Dependencies Cost More than Code Dependencies • Unstable Data Dependencies • データがちょくちょく変わる場合 • Underutilized Data Dependencies • 使われていない(なくなった)データ対策 • Static Analysis of Data Dependencies • データの依存関係を静的に分析する • Correction Cascades • ちょっとしたモデルやデータの流用はやめれ

  11. 11. Underutilized Data Dependencies • 使われなくなったデータ • 古い特徴量 • パッケージになった特徴量 • 自己満足系の特徴量 • 対策 • こういうのはとにかく削除する文化を作る • 削除した影響を評価するツールを作る
  12. 12. Static Analysis of Data Dependencies • コードの静的解析は一般的になったが・・・ • 大きな会社で,データの辞書をアップデートしないといけないと きに,その辞書を使っている人を突き止める方法は? • ある特徴量が計算効率を上げるために計算する必要がなくなった とき,それをすべての人が実装できる? • 利用中のソースコードが依存するデータへのリファレンスがない とき,システムはずっと古いデータを使い続けるのか? • 対策 • 静的解析しないと,これらを安全に実行するのは難しい. • Googleはすんげーツールを持ってるぜ.
  13. 13. Correction Cascades • この問題の意味 • 問題Aをとくためにモデルaがあります • Aに似たA’があります. • A’をとくために,aをちょこっと改造してa’を作りました. • ・・A’に似たA’’があります・・・a’を改造して・・・・ • こういうことが続くともう何がなんだがわからなくなるよ • この問題は割と根深い • ある問題なんとかするために,あるモデルに特徴を追加して,学 習することはいいのか?
  14. 14. System-level Spaghetti • Glue Code • ライブラリ,パッケージ,データのためのコードのこと • Pipeline Jungles • 複雑に込み入ったデータフローのこと? • Dead Experimental Codepaths • 使われなくなった?データセットの取り扱い • Configuration Debt • コンフィグファイルに気をつけろ
  15. 15. Glue code • みんな使うよね? • オープンソース - mloss.org • in-houseコード • 製品パッケージ • クラウドベースのサービス • RやMATLABで書かれたコードはC/C++,Javaに移植だ! • 長い目でみれば得だよ? • 研究フェーズではちょっと関係ないかな・・・?
  16. 16. Pipeline jungles • データ処理 • 特徴量 • 元データ • 中間ファイル • 注意すること • engineeringとresearchが乖離している兆候らしい • なるべくチームを密に連携させよう • これを取り除くのはいろんな意味でいいよ
  17. 17. Dead Experimental Codepaths • 使われなくなったデータ?の取り扱い • 昔のデータセット • 今のデータセット • そのデータ同士が依存したり・・・・ • 組み合わせがあったり・・・・ • 恐ろしい実例 • Knight Capitalがテストデータを間違えたために4600億円の損失 • 対策 • Googleはがんばってこれを除去している • 研究・イノベーションのためにも古いデータは除去しよう
  18. 18. Configuration Debt • 汝,コンフィグを侮ることなかれ • コンフィグがコード量を超えることもある • エンジニアが適当にコンフィグを作ると・・・・ • 例 • Aは,9/14-9/17の間に間違って収集された特徴で,Bは10/7までは 使えない特徴で,特徴Cを計算するコードは11/1までは使えない が,それ以降はフォーマットを変更して使え,特徴Dは,プロダク ションでは使えないが・・・・ • 対策 • 変更箇所をわかりやすくするツールとか • コードを変えるのと同じくらい慎重に作業しよう • コードレビューと同じようにコンフィグレビューをしよう
  19. 19. Dealing with Changes in the External World • Fixed Thresholds in Dynamic Systems • 閾値は動的に変わるから考えて作ろう • When Correlations No Longer Correlate • 相関があると仮定してたのになくなることもある • ここで議論するにはスペースが足りない • Monitoring and Testing • 観測結果と予測結果の比較 • 予測によってとった行動の回数でアラートあげよう
  20. 20. Conclusion • 機械学習がダメと言ってるわけじゃない • researcher, engineerの両方が取り組む必要がある • 定理の証明や手法の発見に比べればおもしろくないが,エレガント なシステムを設計することは何よりも称賛されるべき仕事だ

×