Googleの研究者が教える、良い機械学習プロダクトを実装するための43のルール

Google のリサーチ・サイエンティストである Martin Zinkevich 氏によって書かれた、機械学習を使った良いプロダクトを開発するためのコツを集めた記事。エンジニアが良い機械学習プロダクトを作るには、機械学習の専門知識が無いことに苦心するのではなく、得意なエンジニアリングの技術を活かすことが重要、というのが主な趣旨です。

紹介記事：Rules of Machine Learning: Best Practices for ML Engineering

• はじめに

  • ほとんどの問題はエンジニアリングに関する問題である
  • 性能向上は、良い機械学習のアルゴリズムではなく、良い素性によってもたらされる

• 機械学習の前に

  • ルール1. 本当に必要になるまで機械学習を使わない
  • ルール2. まず指標を設計、実装する
  • ルール3. ヒューリスティックが複雑になりすぎる前に、機械学習に移行する

• フェーズI: 最初のパイプライン

  • ルール4. 最初のモデルはシンプルに。インフラをまず整える
  • ルール5. インフラを機械学習とは独立にテストする
    • 素性は正しく計算できているか。モデルは訓練環境とテスト環境で同じ値を返すか。
  • ルール6. パイプラインをコピーする場合は、欠損データに気をつける
  • ルール7. ヒューリスティックを素性に変換するか、外部的に扱う

• モニタリング

  • ルール8. モデルの即時性に関する要求を把握する
    • 例：広告やランキングに関するモデルはすぐに古くなる
  • ルール9. モデルをデプロイする前に問題を検出する
  • ルール10. 「無症状の故障」に気をつける
    • 例：素性を計算するための統計が古い場合、性能が除々に低下する
  • ルール11. 素性グループにオーナーを割り当て、ドキュメントを整える

• 最初の目的関数

  • 指標：システムが報告する何らかの数値
  • 目的関数：機械学習が最適化しようとしている指標
  • ルール12. 何を目的関数とするか考えすぎない
  • ルール13. 単純で、観察可能な、真の目的関数に帰着可能な指標を選ぶ
    • 良い例：リンクのクリック率　悪い例：アクティブユーザーの数
  • ルール14. 解釈可能なモデルから始め、デバッグを簡単にする
    • 例：線形・ロジスティック・ポワソン回帰
  • ルール15. スパムフィルタとランキングをポリシー層で分ける
    • ポリシー層：機械学習に、（単純な）ロジックを追加する層

• フェーズII: 素性エンジニアリング

  • ルール16. ローンチして、改善する
  • ルール17. 学習された素性ではなく、直接観測・報告可能な素性からはじめる
  • ルール18. 複数の状況に対して一般化できる素性を試す
  • ルール19. 可能なら、非常に特定的な素性を使う
  • ルール20. 人間に解釈可能な方法で素性を変換・結合する
    • 例1. 離散化 → 年齢から年齢層に変換
    • 例2. 直積 → 素性どうしのデカルト積　性別ｘ国
  • ルール21. 線形モデルで学習可能な素性の数は、データ量に比例
    • 例：1000インスタンス→10数個の素性
    • 例：1000万インスタンス→10万素性
  • ルール22. 使用されていない素性は削除する

• 人間による分析

  • ルール23. あなたは典型的なエンドユーザーではない
    • 必ずユーザーテストか、実ユーザーで実験する
  • ルール24. モデルの「差分」をまず測定する
  • ルール25. 予測性能より、実用的な性能を考えてモデルを選ぶ
  • ルール26. 誤りパターンを良く観察し、新しい素性を作る
  • ルール27. 望まない振る舞いに対しては、定量化してから最適化する
  • ルール28. 短期的な振る舞いが同じでも、長期的な振る舞いが同じだとは限らない

• 訓練時と提供時の歪み

  • 提供時：モデルの訓練が終わって、その予測をサービス上で実際に使っている時
  • ルール29. 訓練時と提供時を同じにするには、提供時に素性をログに出力することで解決
  • ルール30. 訓練時にデータを適当に取捨選択するのではなく、重要度サンプリングを使う
  • ルール31. テーブルをジョインしている場合は、データが変化する
  • ルール32. 訓練パイプラインと提供時のパイプライン間で、なるべくコードを再利用する
  • ルール33. モデルを訓練した時に使ったデータよりも新しいデータでテストする
  • ルール34. 性能を少し犠牲にしても、綺麗な訓練データを作る
    • 例：スパムフィルタで、1% を held-out にして必ずユーザーに提示
  • ルール35. ランキング問題に内在する歪みに注意する
  • ルール36. 位置素性に関するフィードバック・ループに注意
  • ルール37. 訓練・提供時の歪みを測定する

• フェーズIII: 鈍化する成長、最適化、複雑なモデル

  • ルール38. もし目的関数が合っていないのなら、新しい機能に時間を割かない
  • ルール39. ローンチするかの決定は、プロダクトの長期的な目標に合わせる
    • ローンチの決定が簡単なのは、全ての指標がよくなった時だけ
    • 自分が最適化できる指標だけ最大化して満足しない
  • ルール40. アンサンブルモデルは、シンプルに
  • ルール41. 性能向上が頭打ちになったら、質的に異なる情報源を探す
  • ルール42. コンテンツの人気度と、検索結果の多様性・パーソナリゼーション・関連性には関連があると思わない
  • ルール43. ユーザーの友人関係・振る舞いはサービス間で似ているかもしれないが、興味はそうでもない
    • パーソナリゼーション素性を異なるプロダクトに持って行ってうまく行ったことがない

用語

英語	日本語
heuristics	ヒューリスティック (答えを導くための割と簡単な方法)
fancy	(手法、モデルなどが) 凝った
sanity check	正しさのチェック
feature column	(Google 独自用語) 素性グループ
proxy	代替物 (ここでは、真の目的関数ではないが、それに十分近い指標)
serve	提供する (訓練した機械学習モデル・システムの予測を実際にプロダクトで使うこと)