機械学習システムに潜む技術的負債

とある理由で要約する必要があったので、ついでに雑に訳してみました。

固有名詞はあまり訳さずそのまま記載しています。

論文本体はこちら

よく理解できなかった部分は(ちょっとよくわからない)と書いてあります。なんでわかんねーの雑魚だなと思われる方はご教授いただけると幸いです。

introduction

  • MLシステムの開発とデプロイは比較的(おそらく過去との対比)早く、安くできるが、そのメンテナンスは難しく、費用が掛かる
  • これはWard Cunninnghamが1992年に提唱した技術的負債として理解できる
  • 技術的負債はリフファクタリングやユニットテストの充実、依存関係の解消などを通して改善できる
  • 技術的負債の解消は新しい機能を追加することではないが、将来の機能追加やエラーの減少、メンテナンス性の向上が期待できる。
  • 技術的負債の返済を先送りするとコストが嵩む
  • MLシステムの技術的負債はコードレベルでなくシステムレベルに存在するので検知することがムズカシイ。
  • MLシステムはデータによってそのふるまいが変わるので、コードレベルでの技術的負債の返済では不十分
  • MLパッケージはブラックボックスとして扱われることがあり、それに起因してその周辺にglue codeやcalibration layerがたくさん作られ、外乱に弱くなってしまう。
  • ちゃんと設計しないと、挙動を監視することすらムズカシイ

2 Complex Models Erode Boundaries

  • 従来のsoftware engineeringの手法では、カプセル化とモジュール設計により強力に抽象化でき、保守性が保たれる
  • Strict abstraction boundariesにより、与えられた入力とそれに対応する出力の関係の普遍性と論理的一貫性を担保する。
  • MLは外部データに依存するので、従来のような抽象化はムズカシイ

Entanglement(絡み合い、もつれ)

Change Anything Change Everything(CACEの原則) 入力特徴量のうちの一つを変えた場合でも、他の特徴量の重要度や重みがすべて変わってしまう可能性がある。ハイパーパラメータやデータのサンプリング方法も同様。

Correction Cascades

  • ある問題Aに対するモデルmをよく似た問題A'に適用し追加学習のうえ新しいモデルｍ’を得る。この場合、m'はmに対してシステムレベルでの依存性が発生する。
  • 個々のコンポーネント(モデル)の精度を向上させると、他のシステムに影響を及ぼし、デッドロックが発生する可能性がある。
  • Mitigation Strategies → A'にモデルmを適用する場合に追加の特徴量を用いる、もしくはA'用のモデルを改めて構築すること。

Undeclared Consumers

  • ある機械学習モデルmの出力は多くのシステムに利用される
  • 途中経過や、ファイルに出力されたもの、そのログ等
  • visibility debt
  • Undeclared Cunsumersは良くて高価、最悪の場合危険
  • モデルmとの依存関係を秘匿し、mへの変更が意図しないものになったり、モデルmへの不理解の原因になったり、とにかく有害になりうる
  • feed back roopも隠蔽する
  • (多分これはsoftware的な依存以外(他部署との業務インターフェイス等)も含んでいる。)
  • アクセス制限など、Undeclared Consumersを防ぐように機械学習システムが設計されていないと防ぐことはムズカシイ。

Data Dependencies Cost More than Code Dependencies

  • コードの依存は静的解析で識別できるけど、データの依存はムズカシイよね、というお話

Unstable Data Dependencies

  • 機械学習モデルやa data-dependent lookup table(TF/IDFやsemantic mapping)を入力に使う時、入力は暗黙的にその挙動を変える。
  • 入力側のシステムが別のエンジニアリンググループの責任範囲である場合、入力側の改善が陽に機械学習モデルに影響を与える。
  • このような不安定なデータへの依存関係の緩和には、入力シグナルのバージョニングが良く用いられる。ただし、バージョニングに伴うコストは増加する。

underutilized Data Dependencies

  • underutilized dependencies → impot ないしはinstallされているがほとんど使われていない、必要のないパッケージ
  • underutilized data dependencies → 入力特徴量として用いられているが、モデルの改善に僅かにしか寄与していないモノ
  • underutilized Data Dependenciesがあることに依ってMLシステムは変化に対してときには壊滅的に脆弱になる。
  • Legacy Features
  • 開発初期に用いられていたが、後で追加された特徴量と冗長になり、寄与しなくなった特徴量
  • Bundled Features
  • 僅かなもしくはほとんど改善に寄与しない特徴量が含まれる可能性がある特徴量群
  • $\epsilons$-Features
  • 僅かな性能向上にしかつながらないもしくは複雑さのオーバーヘッドが改悪されるかもしれないがモデルを改善しようとすること
  • 研究者にありがち
  • Correlated Features
  • 強い相関がある2つの特徴量のうち、片方が教師値と因果関係にある場合でも、一般的なML手法ではそれ(片方の因果性)を検知することは難しく、往々にして因果関係がない方を入力特徴量として採用してしまう。
  • Underutilized Dependenciesはleave-one-feature-out evaluationを定期的に実施することで検知できる。

Feedbak Loops

  • MLシステムの出力が最終的に自身の挙動に影響を与える
  • モデルが頻繁に更新されている時、feedback loopはいろんなかたちで現れる
  • ただし、その影響が徐々に現れる場合は検知することがムズカシイ

Direct Feedback Loops

  • MLモデルの出力が、将来の学習データに直接影響を与える場合がある
  • 誰にDMを送ったかなど
  • 教師あり学習が一般的に用いられるが、理論的にはバンディットアルゴリズムを使用するほうが正しい
  • ただし、バンディットアルゴリズムにはthe size of action spaces(ちょっとよくわからない)のスケーリングができないという問題もある。 この問題を緩和する方法としてはrandomaizationなどがある。

Hidden Feedback Loops

  • Direct Feedbackは解析するのにコストは掛かるが、その問題は顕在化しやすい
  • 2つのシステムが互いに影響を与えあっているようなhidden feedback loopはその問題を検知することがムズカシイ
  • 一例として、2つのシステムが独立してあるウェブページのファセットをそれぞれ決定するような場合が挙げられる
  • 片方が提示する商品を決定し、もう片方がそれに係るレビューを表示する、など
  • 2つ以上の企業が運用している株価予測モデルなどもhidden feedback loopsを含みうる。

ML-system Anti Patterns

  • MLの学習や推論処理に相当するコードはシステム全体から見るとごくわずかである

  • much of the remainder(おそらくML以外の部分)は"plumbing"とも呼ばれる

  • このsectionでは、いくつかのsystem-design anti-pattersを検討する。

Glue code

  • generic packege(sklearnとかgensimとか？)を使う場合、データをpackegeの内外とやり取りするために大量のsupporting codeを記述したglue codeになる傾向がある
  • glue codeは特定のpackageに依存する傾向があり、長期的にコストが嵩む
  • 成熟したシステムにMLを載せる場合、95%はこのようなglue code担ってしまうので、a clean native solution(多分MLを用いないルールベースのアルゴリズムなど)を用いるほうがコストが掛からない
  • 共通のAPIでブラックボックス部分をラップしてしまうことが解決策の一つ

Pipeline jungles

  • data preparation部分によく見られ、新しい入力を増やした際に有機的に進化する。
  • スクレイピング、join操作、サンプリングや中間ファイルへのアウトプットのジャングル

  • このようなパイプラインのテストにはコストがかかるend-to-end integration testが必要

  • Pipeline janglesを避けるには全体を俯瞰したデータ収集と特徴抽出プロセスの設計が必要である。

  • 1から作り直すことは非常にコストが係るが、ランニングコストや将来のイノベーションのスピード向上に寄与する。
  • Glue codeとPipeline jangles は"reserch"と"engineering"の役割が分かれているという根本原因によるintegration issue
  • EngineersとReserchersが同じチームで仕事をするか、一人が両方の役割を果たすことがこれを軽減する

Dead Experimental Codepaths

  • Pipeline janglesやglue codeの結果として、新たな手法の実験がしたくなってくる。
  • 個別の実験自体のコストはそれ単体では比較的低い
  • ただし、時間が立つと実験コードの蓄積は後方互換性(backward compability)の維持を難しくし、循環的複雑度(cyclomatic complexity)を指数関数的に増加させる。
  • 実験コードを放置したことにより $465 millionの損害が45分間で発生した事例もある

Abstraction Debt

  • これまでに列挙した問題により、MLシステムをサポートするための抽象化に明確な欠如があることがわかる
  • 特に分散学習(distributed learning)については広く受け入れられている抽象化はまだ現れていない。
  • 標準的な抽象化概念がないと、簡単にコンポーネント同士の境界線がぼやけてしまう。

Common Smells

Plain-Old-Data Type Smell

  • ロバストなシステムではモデルのパラメータがlog-odds multiplier(ちょっとよくわからない)なのか決定境界であるのかを知っている必要がある
  • 予測結果がどう使われるのか、また予測結果を作ったモデルそのものの理解も必要

Muitiple-Language Smell

  • 便利なライブラリがあるからというような理由で、局所的に他の言語が使われている場合、テストのコストや、引き継ぎの難しさが増大する

Prototype Smell

  • プロトタイピング環境であたらいいアイデアをテストすることは、full-scall systemの脆弱性や変更の難しさを示すindicatorになり得る
  • 加えて、抽象化の恩恵にも授かれる
  • ただし、それ自体の運用コストが係ることや、時間のプレッシャーなどからプロトタイプをそのままプロダクション環境へデプロイする危険性もある。
  • また、プロトタイプ環境での検証による知見はプロダクション環境のそれを反映していることはまれである

Configuration Debt

  • MLシステムの設定はresercherからもengineerからも軽視されがちであり、設定ミスの可能性は往々にしてある。
  • 設定ミスにより、時間や計算資源をロスしてしまう可能性がある。

Dealing with changes in the Extarnal World

  • 現実世界の状態が安定していることはまれであるため、それに追従するためのメンテナンスコストが発生する。

Fixed Thresholds in Dynamics

  • 決定境界は主観によって決定され、それが固定のままで利用されることが起こりうる。
  • シンプルなHold-hout validationにより決定境界を学習させる手法によりこれを軽減する戦略が提案されている。

Monitoring and Testing

  • ユニットテストとintegrationテストは独立したコンポーネントが正常に動作していることを確認するのに役に立つが、MLシステムにおいて入力データの内容が変動しうる場合は十分でない。
  • この論文では以下の項目をモニターすることを提案している。

Prediction Basis

  • 入力と出力の教師値分布が等しいことを確認する。

Action Limits

  • 回帰問題などで、モデルが出力する値の上限下限を決め、その制限を超えた場合に警告を発する。

Up-Stream Producers

  • 入力データを供給しているシステムかの動作が正常で意図しているものであることを確認する。
  • 上流のFailureは下流に通知する。

Other Areas OF ML-related Debt

他の領域の負債について言及

Data Testing Debt

  • データがMLシステムのコードを置き換え、そのコードがテストされるべき場合(ちょっとよくわからない)、ある程度のテストを入力データに実施する必要がある。
  • この場合はsanity checkのような簡単なテストでも十分である。

Reproducibility Debt

  • 再現性の負債
  • 再現性を保証することは難しい。

process Management Debt

  • 複数のモデルを運用する場合、それらのメンテナンスや運用が困難になる。
  • 複数のプロセスに共通な手作業がある場合、この負債の匂いがする。

Cultual Debt

  • MLのresearchとengineeringの間には溝があることがしばしばあるが、これは長い目で見るとシステムの安定性に悪影響が出る。
  • 特徴量の数を削減する、モデルの複雑さを軽減する、再現性や安定性、監視の質を向上させるようなチームの文化には価値がある。
  • 経験上、これ(負債なのか上述の文化なのか曖昧、、)は、研究とエンジニアリングのそれぞれに強みを持ったresearcherとengineerが所属している チームでしばしば発生する。

Conclusions: Measuring Debt and Paying it Off

  • チームがまだ素早く行動できていること自体は負債が少ないことの証拠にはならない。
  • 負債は長い時間をかけて現れる。
  • 素早い行動(Moving quickly)は結果としてさらなる負債を引き起こす
  • 負債が溜まっていないかどうか、以下の質問を検討する
  • どれだけ簡単に新しいアルゴリズムとそれに付随するユーティリティをフルスケールでテストできるか
  • データ依存の推移閉包(transitive colsure)はどれか？(ちょっとよくわからない)
  • 変更による影響がどれだけ正確に測定できるか
  • 一つのモデルや入力シグナルの改善が他のモデルに悪影響を与えるか
  • 新しいメンバーが どれだけ早くキャッチアップできるか
  • おそらくいちばん大切なのは、MLシステムの負債についてengineerとresearcherの療法が気づくこと

  • 僅かな性能向上に多大なコストを掛けることが懸命な判断になることは稀である。

  • MLに関連する技術的負債を返済するには特別なコミットメントが必要であり、それが文化として根付くことによって達成される。