機械学習をシステムに組み込むときに知るべき 機械学習の技術的負債 Googleの論文を紹介

今回紹介する内容 ● Machine Learning: The High-Interest Credit Card of Technical Debt ○ 機械学習: 技術的負債という高金利のクレジットカード ○ Sculley, David, et al. "Machine learning: The high interest credit card of technical debt." (2014). ● 高金利のクレジットカードのように、機械学習が技術的負債を蓄積していく

背景 ● ソフトウェアエンジニアは新しい製品やサービスを迅速に生成するという難題に直面 ● 実行速度とエンジニアリングの質のジレンマが存在 技術的負債 ● Ward Cunninghamが1992年に導入した概念 ● 意思決定のコストを定量化するための概念 技術的負債の解消方法 ● リファクタリング、ユニットテストのカバー範囲の拡大、使われなくなったコードの削除など 機械学習における技術的負債 ● 機械学習は通常のコードと同じ複雑性だけでなく、より大きなシステムレベルでの複雑性を持つ ○ 機械学習特有の技術的負債の様々なパターンを説明し、その対処などについて論じる 機械学習と複雑なシステム

● 複雑なモデルが境界を侵食 ○ もつれ ○ 隠れたフィードバックループ ○ 宣言されていない使用者 ● データ依存による負債 ○ 不安定はデータの依存関係 ○ 活用されていないデータの依存関係 ○ データの依存関係の静的分析 ○ 修正のずれ ● システムレベルのスパゲッティコード ○ Glue code ○ Pipeline Jungles ○ 使われなくなった実験コードパス ○ Configuration Debt ● 外部データの変更を扱う ○ 動的システムでの固定された閾値 ○ 相関関係が相関しなくなるとき ○ モニタリングとテスト ● 結論 Outline

● 複雑なモデルが境界を侵食 ○ もつれ ○ 隠れたフィードバックループ ○ 宣言されていない使用者 ● データ依存による負債 ○ 不安定はデータの依存関係 ○ 活用されていないデータの依存関係 ○ データの依存関係の静的分析 ○ 修正のずれ ● システムレベルのスパゲッティコード ○ Glue code ○ Pipeline Jungles ○ 使われなくなった実験コードパス ○ Configuration Debt ● 外部データの変更を扱う ○ 動的システムでの固定された閾値 ○ 相関関係が相関しなくなるとき ○ モニタリングとテスト ● 結論 Outline

従来のソフトウェアエンジニアリング ● カプセル化やモジュール設計などの抽象化 ○ 単独での変更や改良が容易で保守性が高いコードが実装可能 機械学習システム ● 厳密に抽象化することが難しい ○ 外部のデータに依存せずにロジックを実現することができない ● 技術的負債の増大 3つの課題 ● もつれ ● 隠れたフィードバックループ ● 宣言されていない使用者 複雑なモデルが境界を侵食

● 機械学習はデータソースを混合させるツールのため、もつれが生まれる ● CACE Principle ○ Changing Anything Changes Everything ○ 具体例) ■ x1 ~ xnの特徴量を例にあげると、x1の値の分布を変えるとそのほかのすべての特徴 量も変化 ■ 新しい特徴量xn+1の追加、ある特徴量xjの除外でも同様にそのほかのすべての特徴 量が変化 ● このようなもつれにより分離をして改善を行うことが事実上不可能になる ● 特徴量以外にもモデルの予測に影響を与えるもの ○ ハイパーパラメータ、正則化の強さ、学習設定、訓練データのサンプリング方法etc ● 緩和策 ○ モデルを分離してアンサンブルを実施 (scalabilityに課題あり) ○ 高次元可視化ツールによってモデルの予測の振る舞いに対して深い洞察を得ること ○ より複雑な正則化手法の使用 (新たな負債になる可能性もあるという課題) もつれ 機械学習システムのver1をリリースすることは用意だが、その後改善を行うことが困難

● 現実世界の行動から学ぶシステムはフィードバックループの一部になる ○ 具体例) ■ CTR予測ではユーザのクリックを訓練用のラベルとして依存 ■ 訓練用のラベルが以前の予測に依存 ■ 予測結果が新たな予測結果に影響する ● フィードバックループによってシステムの性能の分析が困難になる 隠れたフィードバックループ 隠れたフィードバックループを探して可能なかぎり取り除くことが望ましい

● 機械学習モデルからの予測は多種多様なシステムからアクセス可能 ● 古典的なソフトウェア工学では可視性の負債と呼ばれる ● アクセス制御が行われていない場合、使用者の一部が宣言されていない使用者になる ○ ある予測モデルの出力をシステムの別のコンポーネントの入力として使用する可能性 ● 宣言されていない使用者が存在すると、モデルが変更されたときにほかの部分にも影響をおよ ぼし、想定外の影響が生じる可能性がある ● CTRの例では、フォントサイズを決定するコンポーネントがモデルの予測値を入力として使用 するとフォントサイズが大きくなり続けるなどの結果になりうる 宣言されていない使用者

● 複雑なモデルが境界を侵食 ○ もつれ ○ 隠れたフィードバックループ ○ 宣言されていない使用者 ● データ依存による負債 ○ 不安定はデータの依存関係 ○ 活用されていないデータの依存関係 ○ データの依存関係の静的分析 ○ 修正のずれ ● システムレベルのスパゲッティコード ○ Glue code ○ Pipeline Jungles ○ 使われなくなった実験コードパス ○ Configuration Debt ● 外部データの変更を扱う ○ 動的システムでの固定された閾値 ○ 相関関係が相関しなくなるとき ○ モニタリングとテスト ● 結論 Outline

従来のソフトウェアエンジニアリング ● 依存関係の負債がコードの複雑さや技術的負債の主な原因 機械学習システム ● データ依存が技術的負債になる ● コード依存性を特定するツールは存在する一方でデータ依存性の特定ツールはほとんどない ● 大規模なデータ依存関係の連鎖を構築し、ときほぐすことが困難になる データ依存による負債 ● 不安定なデータの依存関係 ● 活用されていないデータの依存関係 ● データの依存関係の静的分析 ● 修正のずれ データ依存による負債

不安定なデータの依存関係 ● 入力信号の中には不安定なものもあり、時間とともに行動を変化させる ○ 別の機械学習モデルの予測値やデータ依存の参照テーブルから入力を受け取る場合に発生する 可能性 ○ 「入力信号のエンジニアリングオーナー」が「モデルのエンジニアリングオーナー」と別であ る場合、どのような影響が生じうるかを考えずに入力信号の変化が起き続ける可能性 緩和策 ● 入力信号のバージョン管理 ● 具体例) ○ 単語とトピッククラスタのセマンティックマッピングの凍結バージョンの使用 ■ 更新バージョンは使用して問題がないと判断されてから使用 課題 ● 複数のバージョンの維持が技術的負債になりうる

活用されていないデータの依存関係 ● 活用されていないコード依存が大抵必要のないものであるのと同様に、活用されていないデータ依 存は精度向上のための増分価値がほとんどない入力機能や信号が含まれる ● 活用されていないデータ依存関係はシステムが変更に対して不必要に脆弱になる 機械学習モデルに侵入する活用されていない依存関係 ● 古い特徴量 ● 絡み合った特徴量 ● 微小な特徴量 ○ 取り除いても精度に影響は出づらいと考えられるが、 システムはこれらの不必要な機能の変更に対して脆弱」 緩和策 ● 特定のモデルからここの機能を削除した場合の効果を定期的に評価 ● より広い対策として、未使用の依存関係をクリーンアップすることの メリットの周知も重要

データの依存関係の静的分析 ソフトウェアエンジニアリング ● コンパイラとビルドシステムによって静的解析が可能 機械学習システム ● データ依存の負債の主要な問題は静的分析の実施が難しいこと ● データ依存はさらなる追跡ツールが必要 ● すべての人がすべての個々の特徴量の状況を知っているわけではない ○ 例) 辞書のアップデート、ある特定の信号の計算の停止 ○ ->利用するすべての人を見つけて対応することは困難 ● 自動化ツールを用いずに安全な変更を行うことは困難 緩和策 ● データソースと特徴量をアノテーションする特徴量管理ツールの導入 ● Googleのチームでは以下を達成 ○ 1クオーターにつき何千行もの特徴量に関するコードを安全に削除 ○ ヴァージョン確認とそのほかの問題を自動化

修正のずれ ● 問題Aに対するモデルaは存在するがAと少し異なる問題A'に対する解決策が必要な場合 ○ 例) CTRを最大化する問題Aに対するモデルaとCVRを最大化する問題A'に対するモデルa’ ● 問題Aを入力として小さな修正を学習するモデルa’を学習したい ● 既存のaを微修正したver1の作成は簡単 課題 ● 補正モデルはaにシステム依存していて、 モデルを改善するための解析コストが高くなる 緩和策 ● 様々なユースケースを区別するための特徴を追加 ● 同一のモデル内で直接補正を学習可能

● 複雑なモデルが境界を侵食 ○ もつれ ○ 隠れたフィードバックループ ○ 宣言されていない使用者 ● データ依存による負債 ○ 不安定はデータの依存関係 ○ 活用されていないデータの依存関係 ○ データの依存関係の静的分析 ○ 修正のずれ ● システムレベルのスパゲッティコード ○ Glue code ○ Pipeline Jungles ○ 使われなくなった実験コードパス ○ Configuration Debt ● 外部データの変更を扱う ○ 動的システムでの固定された閾値 ○ 相関関係が相関しなくなるとき ○ モニタリングとテスト ● 結論 Outline

システムレベルのスパゲッティ ● 機械学習を取り入れたシステムが高い負債を抱えるデザインパターンになってしまうことはよく起き る ● システムデザインのアンチパターンを列挙 システムデザインのアンチパターン ● Glue code ● Pipeline Jungles ● 使われなくなった実験コードパス ● Configuration Debt

Glue Code ● 機械学習研究者は自己完結型のパッケージを開発する傾向 ● 自己完結型のソリューションはデータを出し入れするために大量のサポートコードが必要になる ○ このようなコードシステムをGlue codeという 課題 ● Glue codeはある特定のパッケージの特質性に対してシステムをフリーズさせる ● 結果的にGlue codeはほかの機械学習のアプローチを伴う実験を難しくする 緩和策 ● Glue code削減のためには特定のアルゴリズムをシステムの中で再実装することが必要 ○ 機械学習システムのコードのうち実際に機械学習を行っているのはごく一部。 システムにつなぎ込むためのAPIなどはGlue codeになる ○ RやMATLABの機械学習パッケージを使うよりも、C++やJavaで 再実装する方がいい戦略

Pipeline Jungles ● Glue codeの特別な場合としてパイプラインジャングルが存在 ○ スクレイプ、結合、サンプリングなどがジャングルのように入り組んだ状態 ● これらのパイプラインの管理エラーの検出、障害からの回復は困難かつ高コスト ● パイプラインジャングルのテストのためにはend-to-endな統合テストが必要になることもある 緩和策 ● データ収集と機能抽出を総合的に考えて回避 ● パイプラインジャングルを破棄して 最初から設計し直すというアプローチ 根本原因 ● 研究とエンジニアリングの役割が過度に分離されている ● 役割が分離されていることによりデータ収集や機能抽出などを 総合的に考えることが難しくなっている ○ エンジニアと研究者が同じチームで取り組むとよい

使われなくなった実験コードパス ● Glue codeやパイプラインジャングルが強固なものになると、条件分岐として実験的なコードパ スを実装して代替アルゴリズムなどを実装したくなる ● 時間とともにコードパスが蓄積されて負債が増える ○ 旧式の実験的コードパスが大きな損失を招いた事例: KnightCapital社のシステム障害 ● 実験的なブランチを定期的に再検討し、取り除けるものを確認

Configuration Debt ● Configurationにまつわる負債 ○ どの特徴量を使用するか、どのようにデータを選択するか、アルゴリズム特有の学習設定etc ● コード抽象化やユニットテストなどは行われてもConfigurationは後回しにされやすい ● 成熟したシステムでは実際に機械学習を行っているコードよりもConfigurationのコードの方がはるか に多い場合もある 緩和策 ● 設定の不変性に関するAssertion ● 2つのConfigurationに関する差分を表示するツールの使用 ● コードレビュー

● 複雑なモデルが境界を侵食 ○ もつれ ○ 隠れたフィードバックループ ○ 宣言されていない使用者 ● データ依存による負債 ○ 不安定はデータの依存関係 ○ 活用されていないデータの依存関係 ○ データの依存関係の静的分析 ○ 修正のずれ ● システムレベルのスパゲッティコード ○ Glue code ○ Pipeline Jungles ○ 使われなくなった実験コードパス ○ Configuration Debt ● 外部データの変更を扱う ○ 動的システムでの固定された閾値 ○ 相関関係が相関しなくなるとき ○ モニタリングとテスト ● 結論 Outline

外部データの変更を扱う ● 機械学習が魅力的である理由の一つとして外部の世界と関わっている点があげられる ● 外部のデータは安定していない 現実世界での変化 ● 動的システムでの固定された閾値 ● 相関関係が相関しなくなるとき ● モニタリングとテスト

動的システムでの固定された閾値 ● 閾値の決定方法 ○ いくつかの閾値の集合から選択 課題 ● 閾値は手動で決定される ○ 新しいデータを学習してモデルがアップデートされても手動で設定した閾値は妥当でなく なる 緩和策 ● ホールドアウトした検証データで評価することで閾値を決定

相関関係が相関しなくなるとき ● 機械学習システムでは相関のある特徴量の影響を見分けることが難しい ● 機械学習モデルが2つの強い相関をもつ特徴量のどちらに対しても重みを与えてしまう 課題 ● 2つの特徴量が相関していたものが突然相関しなくなると、予測行動が大きく変わりうる ○ 例) ある商品のCTRとCVR。クリックされやすい商品は予約もされやすい可能性が高いが、 商品の在庫が切れるとクリックはできるが予約はできなくなるため、CTRとCVRが相関し なくなる可能性がある

モニタリングとテスト ● ユニットテストやend-to-endなテストでは不十分 ○ システムをリアルタイムでモニタリングすることが重要 何をモニタリングするのか ● 予測バイアス ○ 予測ラベルが観測ラベルの分布と等しくなっているか ● システムの行動制限 ○ システムの健全性を確かめるために行動制限を設定して実施することが有効 ■ 例) ポイント付与アルゴリズムなどで想定外にユーザにポイントを付与しすぎてい ないか ○ システムが特定の行動に対して限界に達した場合にアラートを作動

● 複雑なモデルが境界を侵食 ○ もつれ ○ 隠れたフィードバックループ ○ 宣言されていない使用者 ● データ依存による負債 ○ 不安定はデータの依存関係 ○ 活用されていないデータの依存関係 ○ データの依存関係の静的分析 ○ 修正のずれ ● システムレベルのスパゲッティコード ○ Glue code ○ Pipeline Jungles ○ 使われなくなった実験コードパス ○ Configuration Debt ● 外部データの変更を扱う ○ 動的システムでの固定された閾値 ○ 相関関係が相関しなくなるとき ○ モニタリングとテスト ● 結論 Outline

結論 ● 機械学習が技術的負債を生み出す多くの領域をまとめた ○ 機械学習が悪いということではなく技術的負債を認識して負債が管理できなくなるま えに対処することが重要 ● 技術的負債はエンジニアと研究者の両方が認識すべき課題 ○ わずかな精度向上のためにシステムの複雑性を大幅に向上させることは賢明ではない ● 技術的負債を返済することはイノベーションの重要な一部であり、機械学習システムのため の全体的でエレガントなソリューションの開発は深くやりがいのある仕事