【論文紹介】Machine Learning: The High-Interest Credit Card of Technical Debt

はじめに

機械学習を含むシステムを運用するうえでの、開発時の注意事項やアンチパターンについてまとめた論文です。

論文リンク

Machine Learning: The High Interest Credit Card of Technical Debt – Google AI

著者/所属機関

投稿日付

  • 2014

1. 概要

ソフトウェア開発では、技術的負債という概念が提唱されており、リリースを優先するあまり、品質をおろそかにする(≒借金)と、保守コストが複利的に膨らむ(≒利子)。借金は、リファクタリング単体テストカバレッジ、文書の整備などを行うことで清算可能である。機械学習を扱うシステムは、複雑さが増す分、隠れた負債が発生し得るので、注意しなければならない。その例として、以下のようなものを挙げている。

  • 境界の浸食 boundary erosion
  • データ依存 data dependencies
  • スパゲッティシステム System-level Spaghetti
  • 外部環境の変化 changes in the external world

2. 境界の浸食 Complex Models Erode Boundaries

従来のソフトウェア開発では、機能ごとにモジュール化するなど、境界を設けることが、保守の観点で有用だったが、機械学習を用いたソフトウェアでは、それが難しい。そもそも機械学習を導入する動機が、所望の振る舞いがif-then ロジックで記述できないからであり、外部データに依存せざるを得ない。

2.1 絡み合い Entanglement

一つでも特徴量や重み、ハイパーパラメータを変更すると、すべての予測結果が変わる (CACE : Changing Anything Changes Everything)。回避策としては、① モデルを独立化させる、または、アンサンブルにする、②モデルの振る舞いを深く理解する、③予測性能の変化がコストとなるように学習する。絡み合いは、機械学習においては先天的な特性であり、Version 1.0のリリースよりも、その後の改善の方が難しいので、注意が必要。

2.2 隠れたフィードバックループ Hidden Feedback Loop

繰り返し外界の振る舞いを学習するシステムは、フィードバックループの中にいることになる。例えば、ウェブサイトで Click Through Rate を予測するシステムで、過去の週のユーザのクリック数を特徴量としていた場合。モデルを改善すると、結果的にクリック数も上昇して、予測結果が変わる、というフィードバックループが生じる。徐々に変化するようなケースは、効果があったかどうかの分析も難しくなる。こうした隠れたフィードバックループはできる限り避けるべき。

2.3 想定外のユーザ Undeclared Consumers

機械学習モデルの出力に対してアクセス制限を設けずに、他のシステムのインプットとして使われる場合も注意が必要。 機械学習モデルの変更が、他のシステムに影響する。また、他のシステムの出力が機械学習モデルの入力に使われていると、隠れたフィードバックループを生じさせるリスクもある。 他のシステムに対して適切なアクセス制限を設けておくこと。

3. データ依存 Data Dependencies Cost More than Code Dependencies

いわゆるコード間依存の静的解析ツールがないため、気づかないうちに巨大で複雑なデータ依存を作ってしまうことがある。

3.1. 不安定なデータ

別のシステムの出力を機械学習システムの入力データとして使用する場合、別のシステムの変更により入力データが定量的に変わってしまうことがある。 対策としては、入力データのバージョンコピーを取っておくこと。

3.2. 使われていないデータ Underutilized Data Dependencies

入力特徴量を含む使われていないデータを残しておくのは、変化に対して不必要に脆弱になるので、コストがかかる。 使われていない特徴量には、以下のようなものがある。

  • 開発初期に使われていたが別の特徴量の追加で冗長になったもの
  • 個別に検証されずに複数まとめて導入されたもの
  • 精度改善にごくわずかしか寄与していないもの

対策としては、定期的に個々の特徴量の影響を評価し、特徴量を見直すこと。不要な特徴量の除去による長期的なメリットをチーム内に周知すること。

3.3. データ依存性の静的解析 Static Analysis of Data Dependencies

データ依存性は静的解析の実施が難しい(そうしたツールが普及していない)。Googleでは、こちらの論文にて紹介されている手法を採用している。

3.4. 修正のパッチワーク Correction Cascades

既存の問題Aに対するモデルaがあったときに、少し異なる問題A'に対して、モデルaを入力として差分のみを学習したモデルa'を得るという考えに陥ってしまいがち。しかし、このアプローチはモデルa'がaに依存することになり、長期的に見るとコストがかかる。対策は、特徴量を追加するなどして、モデルそのものを区別できるようにしておくこと。

4. スパゲッティシステム System-level Spaghetti

機械学習を含むシステムにおけるシステム設計上のアンチパターンについて記載する。

4.1 糊コード Glue Code

汎用的なパッケージを利用することが多く、そのためにたくさんの糊コードを書かなくてはならない。対策としては、汎用的なパッケージのうち、システムに本当に必要な機能の部分だけを再実装すること。

4.2 パイプラインジャングル Pipeline Jungles

新しいデータソースが後になって得られたりするうちに、パイプラインが増えて、ジャングル化する(糊コードの特殊ケース)。対策は、データ収集から特徴抽出までの全体を見渡して、再設計すること。糊コードやパイプラインジャングルの原因の一つに、研究とエンジニアリングで部門が分断されていることにある。Googleでは研究者とエンジニアリの両者が一緒になって、あるいは連携しながら、プロジェクトを進めるようにしている。

4.3 実験用コードの残骸 Dead Experimental Codepaths

別のアルゴリズムの検討などに用いられた実験用コードをそのまま残しておくと、負債につながる。使われなくなったコードや実験用コードは、システムから切り出して別に保存しておくこと。

4.4 設定 Config debt

機械学習ではたくさんの設定が必要なため、設定も負債となりうる。対応としては、設定にもアサーションを入れておくこと、設定の変更に対して視覚的に確認できるようにしておくこと、設定ファイルもコードと同様に慎重に扱い、レビューすること。

5. 外部環境の変化の扱い

機械学習の魅力の一つに外部環境と直接的に作用することができることがある。しかし、外部環境は不安定なことが多く、負債の原因となりうる。

5.1 動的システムにおける固定閾値 Fixed Thresholds in Dynamic Systems

機械学習システムには何らかの閾値を設けることはよくあるが、この閾値の値はマニュアルで決められることが多い。モデルを更新するたびに、これらの閾値も同時にマニュアルで更新する必要があり、保守の観点では手間となる。対策は交差検定の検証データから学習して閾値を決めるようにすること。

5.2 相関の消失 When Correlations No Longer Correlate

モデル作成時に相関のあった特徴量が、外部環境の変化により相関がなくなるとシステムの予測値は大きく異なるものとなる。また因果のない相関も負債の原因となりうるため注意すべきである。

5.3 モニタリングとテスト Monitoring and Testing

外部環境の変化の下では、単体テスト結合テストだけではシステムが意図通りに動作するかの検証には不十分でシステムのリアルタイム監視も必要となる。以下の2つの指標の監視から始めるとよい。

  1. 予測バイアス Prediction Bias システムが意図通りに動作している場合は、予測ラベルの分布と観測されるラベルの分布は等しくなるはずである。 いろいろな次元でのバイアスを得るのは、問題の特定に有効であるだけでなく、自動発報にも使える。

  2. 実行制限 Action Limits 何らかのアクションを実行するのにシステムが使われるような場合、アクションに制限を設けておく。 制限に引っかかった場合は、自動発報し、マニュアルによる調査を行うようにすると良い。

6. 結論: 清算

機械学習を否定するわけでもなく、技術的負債を何としても避けるべきものというつもりもない。ただし、負債が手に負えなくならないように、認識しておくべきである。重要な点は、技術的負債は研究者とエンジニアの両者が注意すべきものであるということである。技術的負債の清算は、新たな理論の証明のようにわくわくするものではないが、革新を起こすには必要不可欠である。