機械学習：技術的負債の高金利クレジットカード

Posted on 2018-05-04(金) in Machine Learning

Google で機械学習システムの開発に携わる D. Scully 氏らによる

Machine Learning: The High-Interest Credit Card of Technical Debt (機械学習：技術的負債の高金利クレジットカード)

という論文。機械学習は、複雑なシステムを素早く開発するにあたって非常に強力なツールとなるが、それと同時に、大きな技術的負債（メンテナンスコスト）を抱えるリスクがある。そのリスク要因と対処法についてまとめたのが本論文。

発表当時、日本でも少し話題になったので、日本語で検索するといくつか翻訳を目にすることができますが、ここでは、あらためて抄訳を試みるとともに、読む上で重要となる単語・表現を最後に紹介したいと思います。

概要

機械学習は、複雑なシステムを素早く開発するにあたって非常に強力なツールとなるが、これらのメリットがタダで享受できると考えるのは危ない。機械学習を使う場合、システムのレベルで非常に大きな技術的負債（メンテナンスコスト）を抱えるリスクがある。

機械学習と複雑なシステム
- 機械学習パッケージは、通常のコードとして複雑さの問題をはらんでいるのと同時に、システムレベルで「隠れた」技術的負債を抱える恐れがある。
- 本論文では、機械学習のコードと、大きなシステムレベルとの間の相互作用に焦点を当てる。ここに隠れた技術的負債が溜まりやすい。
境界
- 機械学習を使うそもそもの理由は、ソフトウェアのロジックが外部データに依存しているから
- → 抽象的な振る舞いをデータから分離することができない
2.1 もつれ
- CACE (Change Anything, Change Everything) の原則：特徴量を変更・追加すると全てが影響を受ける
- 特徴量だけではなく、ハイパー・パラメータ（正則化、学習の設定、訓練時のサンプリング等）にも言える
- 解決法
  - アンサンブル学習を使う
  - 高次元可視化ツールなどを使い、モデルの予測を観測する
  - より高度な正則化法を使う
- ある程度の「もつれ」は、アルゴリズムに関わらず、機械学習に内在的なもの
2.2 隠れたフィードバック・ループ
- ユーザーの行動等、実世界のデータから訓練された機械学習システムが、実世界に影響を与えること
- 例：CTR (クリック率) の予測モデル
- もし、「ユーザーが、先週にクリックしたニュース見出しの数」が特徴量に入っていると・・・。
- 注意深く観察し、このようなループを除去すること
2.3 宣言してない使用者
- 知らないうちに、機械学習システムの予測を他のシステムが利用していることがある
- システムに変更を加えるのがとたんに難しく、コストがかかるようになる
- 隠れたフィードバック・ループを作り出してしまうことも
データの依存性
- ソフトウェア開発では、依存性が、コードの複雑さを増大させ、技術的負債を作り出す
- 機械学習では、データの依存性が負債を作り出す
- データの依存性は、静的解析などによる検出が難しい
3.1 不安定なデータの依存性
- 機械学習システムの入力が、時間が経つにつれて質的に変化することがある
- 上記 CACE の原則の通り、機械学習システムに対して、診断しにくい、ときに重大な影響を及ぼす
- 解決法: データのコピーにバージョン番号を振り管理する
3.2 十分に活用されていないデータの依存性
- 機械学習システムの精度にたいしてほとんど貢献していない入力や特徴量
- 例: 古くなった特徴量、特徴量グループ、ε特徴量 (複雑さに対して精度の向上が小さい特徴量)
- 解決法: 各特徴量を除去した場合の影響を定期的に評価する
3.3 データ依存性の静的解析
- 静的解析ツールの例 (論文) データ源と特徴量にアノテートでき、依存関係の木構造を分析できる
3.4 修正の伝搬
- 問題 A に対してモデル a が存在するとき、類似した問題 A' に対して、a を入力として a' を手っ取り早く作る
- a' は a に依存しているため、将来、モデルの改善を分析するのが難しくなる
- a → a' → a'' と何重にもなっている場合、事態はより深刻になる
- 解決策: a に特徴量を追加して、修正を直接学習する
システムレベルのスパゲティ
- 機械学習システム設計における避けるべきパターン
4.1 グルーコード
- 機械学習の汎用パッケージを使うために、入力・出力のために大量のグルーコードが必要になる
- パッケージには利点もあるが、成熟したシステムにおいては、問題空間の構成そのものをリファクタリングしたほうがメリットが大きい
- 解決策: システムと同じ言語で、機械学習アルゴリズムを再実装する
- 機械学習システムでは、実際に「機械学習」をしている部分は非常に小さい (5%)
4.2 パイプラインのジャングル
- 機械学習のデータを準備するパイプラインが、スクレイパー、結合、サンプリング、中間ファイルなどで乱雑になり、管理・エラー検出・修正などが大変になる
- 解決策: データ収集、特徴量抽出に対して、大域的な目で考える。時には、一から再設計することも。
- 組織の「研究」と「エンジニアリング」職が離れすぎているのが根本的な原因のことも。
- Google では、エンジニアと研究者を同じチームに「埋め込む」ハイブリッド型研究モデルが、このような技術的負債を未然に防いでいる
4.3 古くなった実験的コード
- アルゴリズムなどを、プロダクションコードに対する条件付きブランチとして実験
- 一つ一つの変更は、低コストだが、後方互換性の維持などによって、次第に技術的負債となる
- 定期的に、削除できないかどうか見直す
- そもそも、実験用のコードはプロダクションコードとは隔離されるべき。再設計・実装が必要かどうか定期的に検討する
4.4 設定負債
- どの特徴量・データを使うか、アルゴリズムの設定、前処理、後処理などの設定に負債が溜まる。プロダクションコードに比べ、厳密にテストされてない
- 設定不変条件に対するアサーションが役立つことも。２つの設定の diff を左右に並べて表示するツールも役に立つ。
外部世界の変化

5.1 固定されたしきい値
- メールがスパムかどうか、広告を表示するかどうかなど、モデルから何らかの決定をする場合、精度・再現率などのトレードオフを考慮しながら、手動で設定
- モデルが更新された場合、そのしきい値が無効になる
5.2 相関関係の変化
- 因果関係にはないが相関関係にある特徴量が、時間が経つにつれ相関関係が無くなると、機械学習システムの予測の振る舞いが変わる
- 因果関係ではない相関関係は、隠れた負債となり得る
5.3 監視とテスト
- 単体テストとシステムテストは大切だが、それだけでは不十分。システムの振る舞いをリアルタイムで監視することが必要。
- 何を監視するか
  - 予測バイアス。予測ラベルと実際のラベルの分布を比べる
    - 完璧ではない。実際のラベルの平均値を出力するだけのベースラインモデルでも、この分布は同じになる
    - 実際にはとても役に立つ。何かの問題を示唆する場合も。
  - 行動制約
    - 実世界で何かの行動を起こす場合、監視のため、その行動に制約を設けることが有効なことも
負債の支払い
- 機械学習そのものが悪いとか、何としても技術的負債を防ぐべき、と言っているわけではない
- 技術的負債は、エンジニアと研究者の両方が意識すべき問題。精度の向上幅は小さいが、システムの複雑性を大幅に増大させるような研究的な解放は、賢い方法だとは言えない
- 複雑な機械学習システムに対し、全体的な視野を持ち、エレガントな解法を解決するのは、とても見返りの大きい仕事である

私の所属する組織でも、研究者とエンジニアが同じチームに所属しながら、機械学習をプロダクションに導入していく埋め込みモデルを採用しています。今のところ、素早いスピードで機械学習をサービスに活かせており、うまく機能しています。

技術的負債を考える際にも、それをそもそも増大させないための組織論から考えるのが大事ということですね。「システムのデザインは、その組織のコミュニケーション構造を反映する」という趣旨のコンウェイの法則にも通じるところがありますね。

英語	日本語
debt	負債、借金 ("b" を発音しないことに注意)
incur	(コストなどを) 被る
compound	悪化する
invariant	不変条件
net	(ここでは) 正味の、最終的な
mitigation	緩和
deleterious	有害な
sought	seek の過去・過去分詞形
holistic	全体的な
holistically	全体的に
root cause	そもそもの原因
tease apart	紐解く、抽出する
sanity check	整合性などのチェック
pay off / pay down	(負債を)返す