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.

Hidden technical debt in machine learning systems(日本語資料)

1,429 views

Published on

機械学習の技術的負債に関する資料

Published in: Data & Analytics
  • Be the first to comment

Hidden technical debt in machine learning systems(日本語資料)

  1. 1. Hidden Technical Debt in Machine Learning Systems
  2. 2. Table of Contents 1. 関係論文 2. 背景 3. 複雑なモデルのシステム境界侵食 4. データの依存性コストはコード依存性コストより高い 5. フィードバックループ 6. 機械学習アンチパターン 7. 設定ファイル負債 8. 外部世界の変化を扱う 9. 他の領域での機械学習の負債 2
  3. 3. 関係論文 3
  4. 4. 機械学習のシステムの難易度について述べた論文 ▸ 機械学習:技術的負債の高利子クレジットカード ▹ Sculley D, Phillips T, Ebner D, Chaudhary V, Young M. Machine learning: The high-interest credit card of technical debt. ▹ 下記の資料と重なっている点が多い ▹ https://www.slideshare.net/recruitcojp/ss-42745505 4 :
  5. 5. 機械学習のシステムの難易度について述べた論文 ▸ 今回、紹介する論文 ▹ Sculley D, Holt G, Golovin D, Davydov E, Phillips T, Ebner D, Chaudhary V, Young M, Crespo JF, Dennison D. Hidden technical debt in machine learning systems. InAdvances in neural information processing systems 2015 (pp. 2503-2511). ▹ NIPS 2015の論文 5 :
  6. 6. 背景 6
  7. 7. 技術的負債について ▸ 技術的負債によってコードのメンテナンス 性が低下し、品質と速度が低下する ▸ 全ての技術的負債が悪いのではない ▹ 致命的なエラーを解消するためのモンキーパッチ など ▹ 一時的な対応のためのハードコーディング 7 :
  8. 8. 技術的負債について ▸ ソフトウェアの側面で技術的負債を防ぐ ▹ リファクタリング、ユニットテスト、使用してい ないコードの削除、依存性の低減、APIの強化、 ドキュメンテーションの充実 ▸ 機械学習には上記で解決できない別の問題 が存在 ▹ データに対する依存性が存在するため 8 :
  9. 9. モデルの複雑なシステム境 界侵食 9
  10. 10. ソフトウェアシステム ▸ 独立した変更と改善を容易にする ▹ カプセル化とモジュール設計による抽象境界 ▹ コンポーネントからの入力、出力の不変、一 貫性を担保 10 :
  11. 11. 機械学習システム ▸ データに対する依存性が存在 ▹ 絡み合い ▹ 誤り訂正 ▹ 宣言されていない消費 11 :
  12. 12. 絡み合い ▸ CASE(Changing Anything Changes Everything) ▹ 少し変わると全て変更される ▹ 入力特徴量が変更される(削除、増加、変化 etc) -> モデルの重みが全て変更される ▹ 重みだけでなく、ハイパーパラメータ、学習設定なども 変更される 12 :
  13. 13. 絡み合いの対策 ▸ 対策1: ▹ マルチクラスの予測のようなケースではモデルを クラスごとに孤立させ、アンサンブルで学習(ク ラスごとに相関がないことを仮定) ▸ 対策2: ▹ 入力が変わることによる予測の変化を可視化して 対応 13 :
  14. 14. 誤り訂正 ▸ 下記のような現象 ▹ 問題Aを解決するようなモデルmAが存在 ▹ モデルmAを改善して少し異なる問題A’を解決す るモデルm’Aを作成 ▹ モデルmAに対する依存が発生 14 :
  15. 15. 誤り訂正の対策 ▸ 対策1: ▹ ケースを識別する特徴量を追加 ▸ 対策2: ▹ 問題ごとに個別にモデルを作成 15 :
  16. 16. 宣言されていない消費 ▸ モデルの出力結果のアクセス制御していな いと他のシステムから参照可能になる ▹ 隠れたフィードバックループになりうる ▹ アクセス制限していない限り検出が難しい 16 :
  17. 17. 宣言されていない消費者の対策 ▸ 対策: ▹ リソースのアクセス制限 17 :
  18. 18. データの依存性コストはコ ード依存性コストより高い 18
  19. 19. データ依存性 ▸ 不安定なデータ依存 ▸ 十分活用されていないデータ依存 ▸ データ依存性の静的解析 19 :
  20. 20. 不安定なデータ依存性 ▸ 不安定にデータが変化する ▹ 量もしくは質 ▹ 入力される値が別の機械学習モデル ▹ TF-IDFのようなデータに依存するスコアリン グ 20 :
  21. 21. 不安定なデータ依存性の対策 ▸ 対策 ▹ データのバージョン管理 21 :
  22. 22. 十分活用されていないデータ依存 ▸ コードでは使用していないパッケージは必 要ない ▸ データでも同様: ▹ 例:システム移行 ▹ 古いシステムに依存しているモデルがある場 合、古いシステムが止まると悪影響が発生 22 :
  23. 23. 十分活用されていないデータ依存の傾向 ▸ 傾向1: ▹ Legacy Features: 開発初期の特徴は運用するに連 れて冗長になる ▸ 傾向2: ▹ Bundled Features: 適切に分離されていない特徴。 ほぼ値がないものや値が存在しない特徴が混ざる 可能性がある ▸ 傾向3: ▹ ε-Features: 精度向上のわずかに影響もしくはモデ ルの複雑性を向上させても精度向上させている 23 :
  24. 24. 十分活用されていないデータ依存の傾向 ▸ 傾向4: ▹ Correlated Features:2つの特徴量が強く相関して いるケースが多くある。これらは直接的な因果関 係がある。 ▹ 因果関係があるので片方の特徴量が変更され ると相関関係の強い特徴量も変更されるため 外界の変化に弱いモデルになる 24 :
  25. 25. データ依存性の静的解析 ▸ データの依存性は静的解析が難しい ▸ コードはコンパイラやビルドシステムによ って依存性の問題を解消している 25 :
  26. 26. データ依存性の静的解析の対策 ▸ データの依存性解析ツールについて ▹ スケールするシステム対象 ▹ データが欠損するとアラートが上がる。 ▹ 異なる学習システムでもインターフェースは共通 ▹ 欠損データは追跡可能 ▹ 欠損データの補完可能 ▹ 特徴量のホワイトリストを作成し、不要な特徴量は削除 ▹ 特徴量の削除はリソースの消費を抑える 26 :
  27. 27. データ依存性の静的解析の対策 ▸ データの依存性解析ツールの詳細 ▹ McMahan, H. Brendan, et al. "Ad click prediction: a view from the trenches." Proceedings of the 19th ACM SIGKDD international conference on Knowledge discovery and data mining. ACM, 2013. ▹ https://static.googleusercontent.com/media/research.google.com /en//pubs/archive/41159.pdf 27 :
  28. 28. フィードバックループ 28
  29. 29. フィードバックループ ▸ 直接的なフィードバック ▹ モデルの結果が将来的な学習データに影響を及ぼ す可能性がある ▸ 隠れたフィードバック ▹ 2つのシステムが間接的に影響を与える ▹ 例:週次のレコメンドシステム ▹ 2週目から1週目のレコメンドの結果の影響が含まれる 29 :
  30. 30. フィードバックループの対策 ▸ 直接的なフィードバック ▹ 探索と活用を混ぜたバンデットアルゴリズムの使用 ▹ ランダムな要素を混ぜる ▹ データの特定部分をモデルの影響を受けないように分離 ▸ 隠れたフィードバック ▹ レコメンドシステムのように明確な場合はレコメンド候補は学習 データから除くなどの処理をする 30 :
  31. 31. 機械学習アンチパターン 31
  32. 32. フィードバックループの対策 ▸ グルーコード ▸ パイプラインジャングル ▸ 不要になった実験コード ▸ 抽象化の欠如 ▸ 上記に共通する匂い 32 :
  33. 33. グルーコード ▸ 1つのパッケージで完結可能なコードを研 究者は書きがち ▹ 汎用的なコードとデータのやりとりを行うコード が混ざっている ▸ 成熟したシステムでは機械学習のコードが 5%、グルーコードが95% 33 :
  34. 34. グルーコードの対策 ▸ パッケージを共通のAPIとしてまとめる 34 :
  35. 35. パイプラインジャングル ▸ グルーコードの特殊ケース ▹ データ準備によく現れる ▹ 機械学習のデータを用意する際に結合、サン プリング、削除などで中間ファイルを作成 35 :
  36. 36. パイプラインジャングルの対策 ▸ データの収集と特徴量抽出を包括したアー キテクチャ ▸ エンジニアと研究者を同一チームにする 36 :
  37. 37. 不要になった実験コード ▸ 実験コードを条件付きでプロダクションコ ードにする ▹ パイプラインジャングルやグルーコードの温床に なる ▹ 例:Knight Capitalのシステムが45分で4億6,500 万ドルの損失 37 :
  38. 38. 不要になった実験コードの対策 ▸ 実験コードをプロダクションコードに使用 しない ▹ プロダクションで使用可能な形に変更する 38 :
  39. 39. 抽象化の欠如 ▸ 機械学習は抽象化が難しい ▸ 抽象化が難しい故にコンポーネント間の明 確な責任分解も難しくなる 39 :
  40. 40. 共通する匂い ▸ Plain-Old-Data Type Smell ▹ 浮動小数点や整数などのデータが存在 ▹ ログの乗数、閾値が存在 ▸ Multiple-Language Smell ▹ 複数の言語で記述されている ▸ Prototype Smell ▹ 抽象化されていない、インターフェースがない、 モジュール化されていないなど 40 :
  41. 41. 設定ファイル負債 41
  42. 42. 設定ファイル負債 ▸ 機能、データの選択、アルゴリズムの設定 、前処理、後処理などの構成オプションが ある ▸ 成熟したシステムではこれらはコードの行 数を超える可能性がある 42 :
  43. 43. 設定ファイル負債 ▸ 例: ▹ 特徴量A: 9/14-9/17のログが正しくない ▹ 特徴量B: 10/7前は使用できない ▹ 特徴量C: 11/1以降はログフォーマットが変更 ▹ 特徴量D: プロダクションで使用不可なので代わり のD’とD’’を使用 ▹ 特徴量Z: 効率化のためルックアップテーブル用の 余分なメモリを割り当て 43 :
  44. 44. 設定ファイル負債の対策 ▸ 変更の特定が容易にするため変更は小さく ▸ 自動チェックなどでマニュアルエラー、見落とし、省略を難しくする ▸ 設定ファイルの違いをモデルで明確に分かるようにする ▸ 設定ファイルの基本的な事実(特徴量の数など)は自動チェックを行 う ▸ 冗長かつ使用していない設定は削除する ▸ プロダクションに入る設定ファイルもレビューを受けるべき 44 :
  45. 45. 外部世界の変化を扱う 45
  46. 46. 外部世界の変化を扱う ▸ 外部世界は安定していないのでそれに伴っ て変化が必要 ▹ 動的システムの固定値の危険性 ▹ モニタリングとテスト 46 :
  47. 47. 動的システムの固定値の危険性 ▸ 電子メールのスパム判定などに固定値を設 定することがある ▸ 多数のモデルに対して手動で固定値を指定 するのは危険 47 :
  48. 48. 動的システムの閾値の危険性の対策 ▸ 検証データで自動的に閾値を設定する仕組 みを作る 48 :
  49. 49. モニタリングとテスト ▸ 単体テストやend-to-endテストは外部世界 の変化に対して十分なテストになり得ない ▹ 外部世界のモニタリングが必要 ▹ Prediction Bias ▹ Action Limits ▹ Up-Stream Producers 49 :
  50. 50. Prediction Bias ▸ 予測ラベルの分布と観測ラベルの分布を観 測 ▹ 包括的なテストではない ▹ 外部世界の変化を捉えることは可能 50 :
  51. 51. Action Limits ▸ 行動に制限をかける ▹ メッセージのスパム振り分けや入札など ▹ 許容する範囲は大きくとる ▹ 許容範囲を超える場合は明らかな異常としてチェ ックする 51 :
  52. 52. Up-Stream Producers ▸ 機械学習に入力されるデータはあらゆるア ップストリームから入力される ▹ これらのアップストリームは監視、テスト、定期 的な機械学習の要件を満たしたデータかをチェッ クする必要がある 52 :
  53. 53. 他の領域での機械学習の負債 53
  54. 54. 他の領域での機械学習の負債 ▸ Data Testing Debt ▸ Reproducibility Debt ▸ Process Management Debt ▸ Cultural Debt 54 :
  55. 55. Data Testing Debt ▸ データのテストを行う ▹ データの単純なサニティチェック ▹ データの入力分布の変化をモニタリング 55 :
  56. 56. Reproducibility Debt ▸ 厳密な再現性は不可能 ▹ ランダムアルゴリズム ▹ 初期設定 ▹ 外界との相互作用 56 :
  57. 57. Process Management Debt ▸ 多数のモデルを扱う場合 ▹ モデルを安全かつ自動的に更新 ▹ モデル間のリソースの割り当て ▹ データフローの可視化、異常の検出 ▹ モデル作成に失敗した場合の復旧、回避 57 :
  58. 58. Cultural Debt ▸ 機械学習とエンジニアリングの両立は難し い ▹ チームカルチャーを醸成するのも重要 ▹ エンジニアと研究者の両方の強みをもつチームを 作ることがカルチャーを作るのにも繋がる 58 :
  59. 59. 結論 59
  60. 60. Measuring Debt and Paying it Off ▸ 技術的な負債を抱えないために効果的な5 つの質問があります。 ▹ 新しいアルゴリズムを簡単にフルスケールでテストできますか ▹ 全てのデータの依存関係は把握可能か ▹ システムへの新しい変化の影響をどれだけ正確に測定できますか ▹ 1つのモデルの改善が他のモデルをどれだけ劣化させるか ▹ 新規メンバーが入った時にどれだけ早くスピードを上げられるか 60 :
  61. 61. 参考 61
  62. 62. References 62 ▸ Sculley D, Holt G, Golovin D, Davydov E, Phillips T, Ebner D, Chaudhary V, Young M, Crespo JF, Dennison D. Hidden technical debt in machine learning systems. InAdvances in neural information processing systems 2015 (pp. 2503-2511). ▸ 「機械学習:技術的負債の高利子クレジットカー ド」のまとめ ▹ https://www.slideshare.net/recruitcojp/ss- 42745505

×