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. 要旨
● 機械学習システムは,技術的負債を生みやすい
o 「機械学習が悪い」と言いたいのではない!
● 機械学習システムで技術的負債を可能な限りなくすアンチパターンを紹介
● 論文のスコープ
o 長期間運用される機械学習システムの開発ヒント
学術研究分野の新規アルゴリズム開発についての言及ではない!
3
5. 目次
1. 導入:機械学習と複雑なモデル
2. 複雑なモデルが引き起こすシステム境界の侵食
a. 「もつれ」
b. 隠れたフィードバックループ
c. 宣言されていない消費コンポーネント
3. コードの依存より高負債のデータ依存
a. 不安定なデータ依存
b. 未活用のデータ依存
c. データ依存の静的解析の必要性
d. 補正の連鎖
4. システムレベルのスパゲティ
a. グルーコード
b. パイプラインジャングル
c. 不要になった実験コード
d. 技術的負債としての設定
5. 外部世界の変化を扱う
a. 動的システムにおける固定値の危険性
b. 相関関係がなくなったとき
c. モニタリングとテスト
5
7. 目次
1. 導入:機械学習と複雑なモデル
2. 複雑なモデルが引き起こすシステム境界の侵食
a. 「もつれ」
b. 隠れたフィードバックループ
c. 宣言されていない消費コンポーネント
3. コードの依存より高負債のデータ依存
a. 不安定なデータ依存
b. 未活用のデータ依存
c. データ依存の静的解析の必要性
d. 補正の連鎖
4. システムレベルのスパゲティ
a. グルーコード
b. パイプラインジャングル
c. 不要になった実験コード
d. 技術的負債としての設定
5. 外部世界の変化を扱う
a. 動的システムにおける固定値の危険性
b. 相関関係がなくなったとき
c. モニタリングとテスト
7
8. 2. 複雑なモデルが引き起こすシステム境界の侵食
● 従来のソフトウェアエンジニアリングは,システム境界面の強い抽象化や
モジュール設計がコードのメンテナンス性を向上できることを示してきた
o 厳密な抽象化境界は入出力の不変で論理的な一貫性の表現を助ける
● しかし,機械学習システムでは厳密な抽象化境界を作るのが難しい
● 機械学習システムにおける望ましい振る舞いは,外部データの依存なし
にソフトウェアロジックを実装することができない!
● その上でもデータの「癖」からの普遍的な振る舞いを抽象的に切り離す方
法がいくつかある
o 「もつれ」
o 隠れたフィードバックループ
o 宣言されていない消費コンポーネント
8
9. 2.a. 「もつれ」
● そもそも機械学習とは入力データを混ぜ込むツールであるので,データの
「もつれ」を生み,修正のための切り離しは効率的には不可能
● CACE 原理:何かを変更すればすべてが変わる!
o 例えば,特徴量を加えたり減らしたり,あるいは分布が変わることに
よって結果が変わってしまう
o 本当に独立な入力データは存在しない!
● 「もつれ」を解消するための3つのアプローチ
o モデル郡を孤立化させ,アンサンブルとして利用
o モデル予測の振る舞いにおいて深い洞察を得る方法を確立
o より精巧な正則化法を使うようにする
9
10. 2.b. 隠れたフィードバックループ
● 例:週次で変化するニュースサイトのCTR 最適化のためのレコメンドシ
ステム
o システム導入の最初の週は,それまで蓄積されたデータのみをただ利
用すれば良い
o 2週目の最初の変更では,最初の週の自身のレコメンド結果による
影響が含まれてしまう
● このような隠れたフィードバックループは可能な限り排除する
10
12. 目次
1. 導入:機械学習と複雑なモデル
2. 複雑なモデルが引き起こすシステム境界の侵食
a. 「もつれ」
b. 隠れたフィードバックループ
c. 宣言されていない消費コンポーネント
3. コードの依存より高負債のデータ依存
a. 不安定なデータ依存
b. 未活用のデータ依存
c. データ依存の静的解析の必要性
d. 補正の連鎖
4. システムレベルのスパゲティ
a. グルーコード
b. パイプラインジャングル
c. 不要になった実験コード
d. 技術的負債としての設定
5. 外部世界の変化を扱う
a. 動的システムにおける固定値の危険性
b. 相関関係がなくなったとき
c. モニタリングとテスト
12
13. 3. コードの依存より高負債のデータ依存
● 従来のソフトウェアエンジニアでは,依存の負債はコードの複雑さと技術
的負債の主な原因とされてきた
o コードの依存性は静的解析やリンクグラフなどで相対的に簡単に特定
できる
● 機械学習システムでは,データの依存が同様の負債を生み出す原因である
o データの依存についての静的解析ツールなどが求められる
13
15. 3.b. 未活用のデータ依存
● コードにおいては,未活用の依存はほとんど必要ないパッケージ
● 同様に,未活用のデータ依存は,特徴量であれデータであれ精度を向上
するという観点からは必要ない
● 未活用のデータ依存を機械学習システムから取り除くための方法
o Legacy Features:機械学習システムの運用初期に加えられた特徴量
は,運用するに連れてほとんど全く冗長になる
o Bounded Features:締め切りなどに追われて,特徴量をきちんと分
離せずに「まとまって」運用してしまうことがある.このようなまと
まりが本当に価値のある特徴量を隠してしまう
o ε-Features:精度向上には少ししか貢献しないが,システムを複雑に
してしまうような特徴量は使わない
● 理想的には,日々必要な特徴量を検査し,取り除くことが可能かどうかを
見直す
15
16. 3.c. データ依存の静的解析の必要性
● データ依存の主な問題のひとつは,静的解析の難しさにある
o コードであれば,コンパイラやビルドシステムが依存性などの問題を
解決する機能を提供してくれる
● データの依存を追跡するためのツールが必要
o 多くのエンジニアがいるようなチームでは,人手で入力データの状態
を管理することはほとんど不可能
● cf. Ad Click Prediction: a View from the Trenches
o http://research.google.com/pubs/pub41159.html
16
18. 目次
1. 導入:機械学習と複雑なモデル
2. 複雑なモデルが引き起こすシステム境界の侵食
a. 「もつれ」
b. 隠れたフィードバックループ
c. 宣言されていない消費コンポーネント
3. コードの依存より高負債のデータ依存
a. 不安定なデータ依存
b. 未活用のデータ依存
c. データ依存の静的解析の必要性
d. 補正の連鎖
4. システムレベルのスパゲティ
a. グルーコード
b. パイプラインジャングル
c. 不要になった実験コード
d. 技術的負債としての設定
5. 外部世界の変化を扱う
a. 動的システムにおける固定値の危険性
b. 相関関係がなくなったとき
c. モニタリングとテスト
18
23. 4.d. 技術的負債としての設定
● 機械学習の設定も重体な技術的負債の温床になり得る
● 多くのエンジニアは,設定をあとからの思いつきで扱うかもしれない
o プロダクションコードの抽象化や単体テストを熱心に考えるが…
● 例:このような乱雑さが設定を正しく変更することを困難にする
o 特徴量Aは9/14 ~ 9/17 のログが正しくない
o 特徴量Bは10/7 前は利用できない
o 特徴量Cを計算するコードは11/1 前後で変更
● しかし設定の誤りは損失が大きいかもしれない
o 時間の重体なロス
o 計算機資源の無駄な消費
● 設定の不変についての表明は誤りを防ぐことに批判的かもしれないが,
どのような表明が役に立つかを考慮することは必要
23
24. 目次
1. 導入:機械学習と複雑なモデル
2. 複雑なモデルが引き起こすシステム境界の侵食
a. 「もつれ」
b. 隠れたフィードバックループ
c. 宣言されていない消費コンポーネント
3. コードの依存より高負債のデータ依存
a. 不安定なデータ依存
b. 未活用のデータ依存
c. データ依存の静的解析の必要性
d. 補正の連鎖
4. システムレベルのスパゲティ
a. グルーコード
b. パイプラインジャングル
c. 不要になった実験コード
d. 技術的負債としての設定
5. 外部世界の変化を扱う
a. 動的システムにおける固定値の危険性
b. 相関関係がなくなったとき
c. モニタリングとテスト
24