「機械学習：技術的負債の高利子クレジットカード」のまとめ

「機械学習：技術的負債の高利子クレジットカード」のまとめ

1. 1. 「機械学習：技術的負債の高利子クレジッ トカード」のまとめ Yu Ishikawa
2. 2. 元の論文 ● Title: “Machine Learning: The High Interest Credit Card of Technical Debt” ● Authors: D. Sculley and Gary Holt and Daniel Golovin and Eugene Davydov and Todd Phillips and Dietmar Ebner and Vinay Chaudhary and Michael Young ● Year: 2014 ● Venue: SE4ML: Software Engineering for Machine Learning (NIPS 2014 Workshop) ● http://research.google.com/pubs/pub43146.html ● Abstract: Machine learning offers a fantastically powerful toolkit for building complex systems quickly. This paper argues that it is dangerous to think of these quick wins as coming for free. Using the framework of technical debt, we note that it is remarkably easy to incur massive ongoing maintenance costs at the system level when applying machine learning. The goal of this paper is highlight several machine learning specific risk factors and design patterns to be avoided or refactored where possible. These include boundary erosion, entanglement, hidden feedback loops, undeclared consumers, data dependencies, changes in the external world, and a variety of system-level anti-patterns. 2
3. 3. 要旨 ● 機械学習システムは，技術的負債を生みやすい o 「機械学習が悪い」と言いたいのではない！ ● 機械学習システムで技術的負債を可能な限りなくすアンチパターンを紹介 ● 論文のスコープ o 長期間運用される機械学習システムの開発ヒント  学術研究分野の新規アルゴリズム開発についての言及ではない！ 3
4. 4. 論文のハイライト ● CACE の原理: Changing Anything Changes Everything o 機械学習システムは何かを変更すればすべてが変更される ● モデルたちは切り離し，アンサンブルとして利用した方が良い ● 運用している機械学習システムには，隠れたフィードバックループがある ことを意識し，可能であれば取り除く ● 学習したモデルにとって不必要あるいは些細な変数は可能な限り取り除く ● ソースコードを静的解析するように，機械学習システムもデータ依存性ま で考慮した静的解析が望まれる ● 複雑なグルーコードやデータパイプラインを取り除く ● ソースコードだけでなく，設定コードのテストもカバーしよう ● 機械学習システムの技術的負債は，エンジニアと研究者の両者が協力して 取り組んだほうが良い 4
5. 5. 目次 1. 導入：機械学習と複雑なモデル 2. 複雑なモデルが引き起こすシステム境界の侵食 a. 「もつれ」 b. 隠れたフィードバックループ c. 宣言されていない消費コンポーネント 3. コードの依存より高負債のデータ依存 a. 不安定なデータ依存 b. 未活用のデータ依存 c. データ依存の静的解析の必要性 d. 補正の連鎖 4. システムレベルのスパゲティ a. グルーコード b. パイプラインジャングル c. 不要になった実験コード d. 技術的負債としての設定 5. 外部世界の変化を扱う a. 動的システムにおける固定値の危険性 b. 相関関係がなくなったとき c. モニタリングとテスト 5
6. 6. 1. 導入：機械学習と複雑なモデル ● ソフトウェアエンジニアは，新しいプロダクトやサービスを素早く生み出 そうとするとき，「品質」と「開発の素早さ」のジレンマに直面する ● すべての「負債」が悪いわけではないが，技術的負債は複利的に膨れる傾 向がある ● 負債の返済を怠ると，システムの脆性を生み出しイノベーションの機会を 減らしてしまう ● （長期間運用される）機械学習システムにおいては隠れた技術的負債がす ぐに膨らむ傾向 o 従来のソフトウェアエンジニアリングでは，リファクタリングや単体 テストのカバレッジ，不要になったコード，依存性の低減などの対応 をすることで技術的負債を解消するための知見がある o しかしソフトウェアエンジニアの知見だけでは足りない 6
7. 7. 目次 1. 導入：機械学習と複雑なモデル 2. 複雑なモデルが引き起こすシステム境界の侵食 a. 「もつれ」 b. 隠れたフィードバックループ c. 宣言されていない消費コンポーネント 3. コードの依存より高負債のデータ依存 a. 不安定なデータ依存 b. 未活用のデータ依存 c. データ依存の静的解析の必要性 d. 補正の連鎖 4. システムレベルのスパゲティ a. グルーコード b. パイプラインジャングル c. 不要になった実験コード d. 技術的負債としての設定 5. 外部世界の変化を扱う a. 動的システムにおける固定値の危険性 b. 相関関係がなくなったとき c. モニタリングとテスト 7
8. 8. 2. 複雑なモデルが引き起こすシステム境界の侵食 ● 従来のソフトウェアエンジニアリングは，システム境界面の強い抽象化や モジュール設計がコードのメンテナンス性を向上できることを示してきた o 厳密な抽象化境界は入出力の不変で論理的な一貫性の表現を助ける ● しかし，機械学習システムでは厳密な抽象化境界を作るのが難しい ● 機械学習システムにおける望ましい振る舞いは，外部データの依存なし にソフトウェアロジックを実装することができない！ ● その上でもデータの「癖」からの普遍的な振る舞いを抽象的に切り離す方 法がいくつかある o 「もつれ」 o 隠れたフィードバックループ o 宣言されていない消費コンポーネント 8
9. 9. 2.a. 「もつれ」 ● そもそも機械学習とは入力データを混ぜ込むツールであるので，データの 「もつれ」を生み，修正のための切り離しは効率的には不可能 ● CACE 原理：何かを変更すればすべてが変わる！ o 例えば，特徴量を加えたり減らしたり，あるいは分布が変わることに よって結果が変わってしまう o 本当に独立な入力データは存在しない！ ● 「もつれ」を解消するための３つのアプローチ o モデル郡を孤立化させ，アンサンブルとして利用 o モデル予測の振る舞いにおいて深い洞察を得る方法を確立 o より精巧な正則化法を使うようにする 9
10. 10. 2.b. 隠れたフィードバックループ ● 例：週次で変化するニュースサイトのCTR 最適化のためのレコメンドシ ステム o システム導入の最初の週は，それまで蓄積されたデータのみをただ利 用すれば良い o ２週目の最初の変更では，最初の週の自身のレコメンド結果による 影響が含まれてしまう ● このような隠れたフィードバックループは可能な限り排除する 10
11. 11. 2.c. 宣言されていない消費コンポーネント ● レコメンド本体とは別のシステムがレコメンドの入力データやレコメンド 結果に影響 o 例： 2.b のレコメンドシステムの結果を利用して，ニュースのタイト ルのフォントサイズを変えるようなシステムが別に存在 11
12. 12. 目次 1. 導入：機械学習と複雑なモデル 2. 複雑なモデルが引き起こすシステム境界の侵食 a. 「もつれ」 b. 隠れたフィードバックループ c. 宣言されていない消費コンポーネント 3. コードの依存より高負債のデータ依存 a. 不安定なデータ依存 b. 未活用のデータ依存 c. データ依存の静的解析の必要性 d. 補正の連鎖 4. システムレベルのスパゲティ a. グルーコード b. パイプラインジャングル c. 不要になった実験コード d. 技術的負債としての設定 5. 外部世界の変化を扱う a. 動的システムにおける固定値の危険性 b. 相関関係がなくなったとき c. モニタリングとテスト 12
13. 13. 3. コードの依存より高負債のデータ依存 ● 従来のソフトウェアエンジニアでは，依存の負債はコードの複雑さと技術 的負債の主な原因とされてきた o コードの依存性は静的解析やリンクグラフなどで相対的に簡単に特定 できる ● 機械学習システムでは，データの依存が同様の負債を生み出す原因である o データの依存についての静的解析ツールなどが求められる 13
14. 14. 3.a. 不安定なデータ依存 ● ほかのシステムによってつくりだされた入力データは，しばしば不安定 ● 不安定とは，ほかのシステムが運用されていく過程で質的に変化すること を意味する ● この不安定さを回避するために，入力データのバージョン化されたコピー を作っておく方法がある 14
15. 15. 3.b. 未活用のデータ依存 ● コードにおいては，未活用の依存はほとんど必要ないパッケージ ● 同様に，未活用のデータ依存は，特徴量であれデータであれ精度を向上 するという観点からは必要ない ● 未活用のデータ依存を機械学習システムから取り除くための方法 o Legacy Features：機械学習システムの運用初期に加えられた特徴量 は，運用するに連れてほとんど全く冗長になる o Bounded Features：締め切りなどに追われて，特徴量をきちんと分 離せずに「まとまって」運用してしまうことがある．このようなまと まりが本当に価値のある特徴量を隠してしまう o ε-Features：精度向上には少ししか貢献しないが，システムを複雑に してしまうような特徴量は使わない ● 理想的には，日々必要な特徴量を検査し，取り除くことが可能かどうかを 見直す 15
16. 16. 3.c. データ依存の静的解析の必要性 ● データ依存の主な問題のひとつは，静的解析の難しさにある o コードであれば，コンパイラやビルドシステムが依存性などの問題を 解決する機能を提供してくれる ● データの依存を追跡するためのツールが必要 o 多くのエンジニアがいるようなチームでは，人手で入力データの状態 を管理することはほとんど不可能 ● cf. Ad Click Prediction: a View from the Trenches o http://research.google.com/pubs/pub41159.html 16
17. 17. 3.d. 補正の連鎖 ● 今直面している問題A’ のためのモデルa’ が欲しいが，問題A のためのも 出るa が存在するようなときがある ● このようなとき，問題A’ のためのモデルa’ を作るのではなく，a’(a) とし てモデルa を問題A’ に適用するよう補正を掛ける運用がある ● しかし，このような補正に夜モデルは，モデルa に対するシステムの依存 が作り，モデルの修正を分析することが非常に困難にしてしまう 17
18. 18. 目次 1. 導入：機械学習と複雑なモデル 2. 複雑なモデルが引き起こすシステム境界の侵食 a. 「もつれ」 b. 隠れたフィードバックループ c. 宣言されていない消費コンポーネント 3. コードの依存より高負債のデータ依存 a. 不安定なデータ依存 b. 未活用のデータ依存 c. データ依存の静的解析の必要性 d. 補正の連鎖 4. システムレベルのスパゲティ a. グルーコード b. パイプラインジャングル c. 不要になった実験コード d. 技術的負債としての設定 5. 外部世界の変化を扱う a. 動的システムにおける固定値の危険性 b. 相関関係がなくなったとき c. モニタリングとテスト 18
19. 19. 4. システムレベルのスパゲティ ● 機械学習が含まれたシステムは，高負債なデザインパターンになる羽目 ● リファクタリング可能にするためのアンチパターンを４つ紹介 19
20. 20. 4.a. グルーコード ● 機械学習の研究者は，必要な物がすべてそろった汎用的な解決手法を開発 しがちである ● しかしこのようなアプローチは，グルーコードのシステムのデザインパタ ーンに陥りる ● グルーコードパターンは長い目で見れば高コストである ● 問題独自の機械学習システムは問題独自の知識による微調整が可能なので， 汎用的なものではなく問題独自の機械学習システムを構築した方が良い ● グルーコード o コンピュータプログラミングにおいてプログラムの要求仕様の実現に は一切寄与しないが、もともと互換性がない部分同士を結合するため だけに働くコード[wikipedia より] 20
21. 21. 4.b. パイプラインジャングル ● グルーコードの一例として，パイプラインジャングルがデータを準備する ときに見られる o 機械学習の入力データを用意するためには，データをそぎ落とし，結 合して，サンプリングするような過程が必要 ● データの収集と特徴量抽出について全体的に考えることのみが，パイプ ラインジャングルを避ける方法 ● 注目されるのは，グルーコードとパイプラインジャングルが「研究者」と 「エンジニア」の役割を分ける根本原因である統合に関する問題の前兆で あるである ● Google ではエンジニアと研究者を一緒のチームにすることで，著しい不 和をソースから減らすことにしている 21
22. 22. 4.c. 不要になった実験コード ● 開発過程などで使ったが不要になった実験的コードは削除する 22
23. 23. 4.d. 技術的負債としての設定 ● 機械学習の設定も重体な技術的負債の温床になり得る ● 多くのエンジニアは，設定をあとからの思いつきで扱うかもしれない o プロダクションコードの抽象化や単体テストを熱心に考えるが… ● 例：このような乱雑さが設定を正しく変更することを困難にする o 特徴量Aは9/14 ~ 9/17 のログが正しくない o 特徴量Bは10/7 前は利用できない o 特徴量Cを計算するコードは11/1 前後で変更 ● しかし設定の誤りは損失が大きいかもしれない o 時間の重体なロス o 計算機資源の無駄な消費 ● 設定の不変についての表明は誤りを防ぐことに批判的かもしれないが， どのような表明が役に立つかを考慮することは必要 23
24. 24. 目次 1. 導入：機械学習と複雑なモデル 2. 複雑なモデルが引き起こすシステム境界の侵食 a. 「もつれ」 b. 隠れたフィードバックループ c. 宣言されていない消費コンポーネント 3. コードの依存より高負債のデータ依存 a. 不安定なデータ依存 b. 未活用のデータ依存 c. データ依存の静的解析の必要性 d. 補正の連鎖 4. システムレベルのスパゲティ a. グルーコード b. パイプラインジャングル c. 不要になった実験コード d. 技術的負債としての設定 5. 外部世界の変化を扱う a. 動的システムにおける固定値の危険性 b. 相関関係がなくなったとき c. モニタリングとテスト 24
25. 25. 5. 外部世界の変化を扱う ● 機械学習システムを魅惑的にすることのひとつは，外部世界と直接相互作 用をすることである ● しかし外部世界が安定していることは稀であり，世界の変化が機械学習シ ステムにおける技術的負債の起源のひとつである ● 世界の変化も考慮した機械学習システムを構築する必要がある 25
26. 26. 5.a. 動的システムにおける固定値の危険性 ● email がスパムかどうかを判定するような分類器では，決定しきい値を固 定する必要がしばしばある ● このような固定値を利用すると，世界に変化があったときに対応すること ができない ● 対応策としては，決定しきい値を学習するための仕組みを組み込む o cf. Detecting Adversarial Advertisements in the Wild  http://research.google.com/pubs/pub37195.html 26
27. 27. 5.b. 相関関係がなくなったとき ● 機械学習システムは，相関関係の特徴量の効果を区別することにしばしば 苦しむ o 例：２つの特徴量があり相関関係を持っているが，実際には１つの特 徴量が本当に起因しているような場合 ● しかしこの２つの特徴量に相関関係が突然なくなったときに，機械学習シ ステムの振る舞いに誤りを生むかもしれない 27
28. 28. 5.c. モニタリングとテスト ● 単体テストやエンドツーエンドテストは価値があるが，外部世界の変化に 対しては十分なテストにはなりえない ● 運用中の機械学習システムをモニタリングすることで，外部世界の変化に 対するシステムの振る舞いを検証する ● Prediction Bias o 観測されたラベルの分布と予測したラベルの分布が等しいか監視 o 決して包括的なテストではないが，非常に役に立つ診断方法 ● Action Limits o サニティチェックとして，アクションの上限を設定 28
29. 29. 論文のハイライト ● CACE の原理: Changing Anything Changes Everything o 機械学習システムは何かを変更すればすべてが変更される ● モデルたちは切り離し，アンサンブルとして利用した方が良い ● 運用している機械学習システムには，隠れたフィードバックループがある ことを意識し，可能であれば取り除く ● 学習したモデルにとって不必要あるいは些細な変数は可能な限り取り除く ● ソースコードを静的解析するように，機械学習システムもデータ依存性ま で考慮した静的解析が望まれる ● 複雑なグルーコードやデータパイプラインを取り除く ● ソースコードだけでなく，設定コードのテストもカバーしよう ● 機械学習システムの技術的負債は，エンジニアと研究者の両者が協力して 取り組んだほうが良い 29