AI・機械学習を中心に

AI/機械学習/データ分析/子育て/日々の雑感

[翻訳] 機械学習のルール（１）概要～フェーズⅠ

翻訳

原文

Martin Zinkevich氏の記事より

developers.google.com

用語集

  • Instance（インスタンス）：あなたが予測を行いたいモノ。インスタンスの例としては、「猫に関係している」または「猫に関係していない」を判定するWebページ
  • Label（ラベル）：予測タスクからの回答。MLシステムから生成された回答または、学習データに付与されている正しい回答のいずれか。例えば、Webページ（インスタンス）に対するラベルは「猫に関係している」
  • Feature（特徴量）：予測タスクを行う際に使用されるインスタンスの性質。例えば、「Webページが”猫”という単語を含んでいる」など
  • Feature Column（）：関係する特徴量のセット。例えばユーザーが住んでいる可能性があるすべての国名など。feature columnには1つ以上のfeatureを含む可能性があります。この用語はGoogle特有の用語であり、"namespace"や"field"とVWシステム（Yahoo・Microsoft）では呼ばれます
  • Example（例）：特徴量を含むインスタンスとラベル
  • Model（モデル）：予測タスクの統計的表現。あなたはモデルを例を通して学習させ、予測を行うためにそのモデルを使用します
  • Metric（指標）：あなたが注目する数値。直接的に最適化される場合もあれば、そうでない場合もある
  • Objective（目的変数）：機械学習アルゴリズムが最適化する指標
  • Pipeline（パイプライン）：機械学習アルゴリズムにまつわるインフラストラクチャ（基盤）。フロントエンドからのデータ収集、学習データファイルへの変換、モデルの学習、稼働システムへのモデルのエクスポートなどを含む
  • Click-through Rate（クリック率）：Webページの訪問者のうち、広告をクリックした割合

概要

優れたプロダクトを作るためには、優秀な機械学習のエキスパートのようにではなく、優秀なエンジニアのように機械学習を用います。

直面する問題のほとんどは、実際にはエンジニアリングの問題です。優秀な機械学習のエキスパートのリソースを投入しても、機械学習から得られるメリットのほとんどは、優れたアルゴリズムではなく、優れた特徴量から得られます。したがって、基本的なアプローチは、

  1. パイプラインが最初から最後まで信頼性があることを確認する
  2. reasonableなobjectiveから始める
  3. 常識的な特徴量をシンプルな方法で追加する
  4. パイプラインが依然として信頼性があることを確認する

このアプローチは長期にわたってうまく機能します。さらに先に進むために、簡単なトリックが存在しない場合のみ、このアプローチから逸脱してください。複雑さを追加すると、将来的なリリースが遅くなります。

もしあなたが簡単なトリックを使い果たしてしまったら、最先端の機械学習のアプローチがあなたの未来を切り開くかもしれません。その場合、フェーズⅢの機械学習のセクションをご覧ください。

この記事は以下のように構成されています。

  1. 最初のパートは、機械学習システムを構築するのに適切な時期であるかどうかを把握するのに役立ちます
  2. 2つ目のパートは、最初のパイプラインのデプロイに関してです
  3. 3つめのパートは、パイプラインに新しい特徴量を追加しながらローンチとイテレーションを回すこと、モデルとtraining/serving skew（モデルの訓練時と推論時の環境の差異に起因して、モデルが不都合な振る舞いをしてしまうこと）の評価を行う方法についてです
  4. 最後のパートは、プラトー（高原状態）に達したときに何をすべきかについてです
  5. その後に、関連する作業リストと、このドキュメントでよく使用される事例の背景についてのAppendixがあります

機械学習の前に

ルール1：”機械学習ナシ”のプロダクトをローンチするのを恐れるな

機械学習はCoolですが、データが必要です。理論的にはデータ取得は別問題として、新プロダクトをローンチし、後からモデルを微調整することはできますが、これは基本的なヒューリスティクスを下回ることがあります。もしあなたが機械学習によって100%のブーストがかけられると考えるなら、ヒューリスティクによって50%獲得することができるでしょう。

例えばアプリのマーケットプレイスにて、アプリのランク付けをする場合、ヒューリスティックとしてインストール率やインストール数を使用することができます。スパム検出の場合には、ヒューリスティックとして以前にスパムを送信したことがある発行元を除外することができます。人間による編集も恐れずに使いましょう。連絡先をランキングする場合、最近使用したものを最も高くランク付けするでもよいでしょう（または、アルファベット順にランク付けします）。もしプロダクトに機械学習が必ずしも必要でない場合、データが得られるまで機械学習は使わないでください。

ルール2：まず、Metric（指標）をデザインし実装しろ

機械学習システムが何をするかを決める前に、現在のシステムを可能な限り追跡調査しましょう。これは以下の理由からです。

  1. 早い段階の方がシステムのユーザーから（指標の実装の）許可を得るのが簡単だから
  2. もしあなたが将来それがどうなるか気になることがあるならば、それの過去データを今取得するのがよいから
  3. 指標の実装を念頭においてシステムをデザインすると、将来ものごとがうまく運びます。ログの文字列をgrepして指標を確認するようなことはしたくないでしょう！
  4. あなたは現行システムの何が変わり、何が変わらないかを認識することができるでしょう。例えばあなたは、1日のアクティブユーザーを直接的に最適化したいとします。しかしながら、システムの初期の段階では、ユーザーエクスペリエンスの劇的な変更を行っても、この指標が大きく変わることはないことに気づくでしょう

Google Plusのチームは、read毎のexpand（記事の展開）、read毎のreshare（再共有）、read毎のplusone（プラスワン≒いいね）、コメント数、ユーザー毎のコメント数、ユーザー毎のreshare（再共有）などを測定します。それらにより、サービス提供時における投稿の"良さ"を計算します。また、ユーザーをグループに分割し、実験結果の統計値を集計できるような、実験のフレームワークも有効です。（ルール12）

より様々なmetric（指標）を収集することで、あなたのシステムの全体像をより幅広く把握できます。問題に気づいたら？それを追跡調査できる指標を追加しましょう！前回のリリースでの定量的な変化に興奮しましたか？それを追跡調査するための指標を追加しましょう！

ルール3：複雑なヒューリスティックより、機械学習を選択しろ

シンプルなヒューリスティクスはプロダクトを送り出すことができますが、複雑なヒューリスティクスはメンテナンスができません。もしデータを持っていて、あなたが達成しようとしている基本的なアイディアが掴めたら、機械学習に進みましょう。ほとんどのソフトウェアエンジニアリングタスクと同様に、ヒューリスティクだろうが機械学習モデルだろうが、コンスタントにあなたのアプローチを更新することが必要です。そして、機械学習モデルは更新とメンテナンスが簡単であることに気づくでしょう。（ルール16）

機械学習フェーズⅠ：最初のパイプライン

あなたの最初のパイプラインにおけるsystem infrastructureに焦点を合わせます。これからつくる機械学習について想像を膨らませることは楽しいことですが、あなたの最初に作るパイプラインが信頼できないと、何が起きているのかわからなくなってしまいます。

ルール4：最初のモデルはシンプルにとどめ、infrastructureを適切に作れ

最初のモデルはあなたのプロダクトに最も大きなブーストを与えるので、凝ったものにする必要はありません。しかし、あなたが予想するよりはるかに多くのinfrastructureの問題が発生します。誰もがあなたの素晴らしい機械学習システムを利用できるようになる前に、あなたは以下のことを決定する必要があります。

  • どのようにexample（例、学習アルゴリズムに与える形式のデータ）を取得するか
  • A first cut as to what "good" and "bad" mean to your system.
  • モデルをアプリケーションに統合するための方法。モデルをライブで適用するか、もしくはオフラインでモデルで処理した結果をテーブルに保存するといったことができます。例えば、Webページは事前に分類した結果をテーブルに保存しておけますが、チャットメッセージなどはライブで分類を行いたいといったことがあります。

シンプルな特徴量を用いることで、以下のことを確かめることが容易になります

  • 特徴量が学習アルゴリズムで正しく機能していること
  • モデルが妥当なウェイトを学習していること
  • The features reach your model in the server correctly.

これら3つを確実に実行できるシステムができたら、あなたの作業はほとんど完了したようなものです。このシンプルなモデルは、より複雑なモデルをテストするためのベースラインとなるmetric（指標）と振舞いを提供します。”ニュートラルな”スタートを狙っているチームもあります。つまり、機械学習によるメリットを意図的に下げて、本質的なメリットから気が逸れないようにするということです。

ルール5：機械学習とは別にinfrastructureをテストせよ

infrastructureがテスト可能であること、およびシステムの学習部分がカプセル化され、その周辺の全ての機能がテストできるようになっていることを確認してください。特に、

  1. アルゴリズムへデータを提供する機能をテストします。入力されるべき特徴量が入力されていることを確認します。プライバシーが許されるなら、学習アルゴリズムへのインプットを手動で確認します。可能なら、別の場所で得られたデータからの統計値と、パイプライン内のデータの統計値を比較して確認します。
  2. 学習アルゴリズムからモデルを提供する機能をテストします。学習環境のモデルが、本番環境のモデルと同じスコアを与えることを確認します（ルール37）

機械学習には予測不能な要素があるため、学習用/本番用の例を作成する部分をテストすることと、稼働環境で学習環境と同じのモデルを使用できることを確認してください。また、データを理解することも重要です。大規模で複雑なデータセットの分析に関する実用的なアドバイスを参考にしてください。

ルール6：パイプラインのコピーの際、dropされるデータに気をつけろ

多くの場合、既存のパイプラインをコピーしてパイプラインを作成します（例：カーゴ・カルト・プログラミング）。過去のパイプラインは、新たに作成するパイプラインに必要なデータをdropしてしまうことがあります。例えば、"Google Plus What's Hot"のパイプラインは、古い投稿を削除します（新しい投稿をランク付けしようとしているため）。このパイプラインは、Google Plus Streamで使用するためにコピーされました。その場合には古い投稿には意味がありましたが、そのパイプラインは古い投稿を削除していました。

ルール7：ヒューリスティクスを特徴量に変換せよ、またはそれを外部で処理せよ

たいていの場合、機械学習が解決しようとしている問題は全く新しいものではありません。ランキング、分類、その他あなたが解決しようとしている問題には既存のシステムがあるでしょう。すなわち、そこには多数のルールやヒューリスティックがあるということです。この同じヒューリスティックは、機械学習に適用した場合にも同様に効果を発揮することができる可能性があります。

ヒューリスティックは、２つの理由から、どんな情報であっても、マイニングする必要があります。1つ目は、機械学習を適用したシステムへの移行がスムーズになるからです。2つ目は、たいていの場合ルールには、あなたが放棄したくないと考えるであろうシステムに関する多くの直感が含まれているからです。既存のヒューリスティックを使用するのに、4つの方法があります。

  • ヒューリスティックを前処理に使用します。特徴量が極めて優れている場合には、これ一択です。例えば、スパムフィルタにおいて、送信者がすでにブラックリストに載っているなら、メッセージをブロックしてください。このアプローチは二値分類タスクでとても理にかなっています。
  • 特徴量を作成します。ヒューリスティクから特徴量を直接作るのは非常に良いことです。例えば、あなたがヒューリスティックを使用して問い合わせに対する関連性スコアを計算している場合、そのスコアを特徴量として含めることができるでしょう。のちにあなたは、機械学習のテクニックを使用してその値を調整したいと思うかもしれません（例えば、その値を離散化したり、他の特徴量と組み合わせたりするなど）。しかし、まずはヒューリスティックにて得られる生の値を使用してください。
  • ヒューリスティックに対する生データをマイニングする。例えば、インストール数/テキスト内の文字数/曜日を組み合わせたヒューリスティックがある場合、まずはこれらを分解して、個別に機械学習に提供するようにしてください。アンサンブルに適用されるいくつかのテクニックがここでも使用できます（ルール40）
  • ラベルを書き換える。これは、ヒューリスティックが現在のラベルに含まれていない情報を捉えていると思われる場合における選択肢です。たとえば、あなたがダウンロード数を最大化しようとしているが、quality contentも必要な場合、おそらく解決策は、ラベルにアプリの平均の星の数を掛けることです。これについては様々な自由度があります。"Your First Objective"を参照してください。

機械学習システムでヒューリスティックを使用する場合、複雑さが増すことに注意してください。新しく作る機械学習アルゴリズムで過去のヒューリスティックを使用すると、スムーズな移行に役立ちますが、よりシンプルな方法で同じ効果が得られる可能性も検討してください。

モニタリング

アクションにつながるアラートを出力したり、ダッシュボードページを作るなどにより、適切な監視状態を構築してください。

ルール8：あなたのシステムのfreshness requirements（鮮度要件）を知る

作成後1日経過したモデルは、パフォーマンスがどの程度低下しますか？1週間ならば？3カ月ならば？この情報は、モニタリングの重要性を理解することに役立ちます。もしモデルを1日更新しないと製品の品質が大幅に低下してしまう場合、エンジニアに継続的に監視してもらうほうが良いでしょう。ほとんどの広告配信システムには、毎日処理する新しい広告があり、毎日更新する必要があります。例えば、Google Play検索のMLモデルが更新されない場合、1か月以内に悪影響が発生する可能性があります。Google PlusのWhat's Hotのモデルのいくつかには、post identifier（投稿ID）がないため、頻繁にモデルを更新することができないでしょう。一方、post identifier（投稿ID）を持つモデルは、はるかに頻繁に更新されます。また、特に特徴量列がモデルに新たに追加された/削除された場合などを含め、鮮度要件も時間とともに変化していく可能性があることに注意してください。

ルール9：モデルをエクスポートする前に問題を検知する

多くの機械学習システムは本番環境に向けたモデルをエクスポートする段階があります。もしそのエクスポートされたモデルに問題があれば、それはユーザーが問題に直面することになります。

モデルをエクスポートする直前に、モデルが健全化どうかをチェックします。具体的には、hold-outされたデータに対するモデルのパフォーマンスが妥当であることを確認してください。また、もしデータに対し、lingering concernsがある場合には、モデルをエクスポートしないでください。モデルを継続的にデプロイしている多くのチームは、エクスポートする前にROC曲線（またはAUC）をチェックしています。エクスポートされていないモデルによる問題に対してはメールアラートが必要ですが、ユーザー向けモデルにおける問題ではページ（Webページ？）が必要になる場合があります。したがって、ユーザーに影響を与える前に、待って確認をすることをおすすめします。

ルール10：silent failure（無音の失敗）に気をつけろ

これは特に他のシステムよりも機械学習システムにおいて発生する問題です。結合される特定のテーブルのデータが更新されなくなったとします。機械学習システムはそれにアジャストし、パフォーマンスは適度に良く、徐々に減退していきます。時に、テーブルが1週間更新されていないことに気づき、単純にテーブルを更新するだけで、他のどんなモデル更新よりもパフォーマンスが向上する、といったことがあります。implementation changesにより特徴量のカバー率が変化することがあります。例えば、a feature column could be populated in 90% of the examples, and suddenly drop to 60% of the examples. Google Playは過去に一度、6カ月前のテーブルを使用していたことがあり、そのテーブルをリフレッシュするだけで2%インストール率が向上したといったことがありました。もしデータの統計量をトラックしていれば、もしくは時々手作業でデータをチェックしていれば、こういった失敗を減らすことができたでしょう。

ルール11：特徴量カラムにオーナーとドキュメントを付けよ

もしシステムが大きく、たくさんの特徴量カラムを含むとき、各カラムを誰が作成しメンテナンスしているかを把握しておきましょう。もし特徴量カラムについて知っている人がいなくなっていることに気づいたら、だれか他の把握している人を確認しましょう。特徴量カラムが分かりやすい名前を持っていたとしても、その特徴量が何なのかの詳細な説明、どこから来たか、どのように働くと期待されるかについての詳細な説明（ドキュメント）を持っておくとよいでしょう。

最初の目的変数

あなたは、システムに関する注視すべきたくさんの指標（metric）や計測値を持っているでしょう。しかし、機械学習アルゴリズムはたった一つの目的変数（objective、アルゴリズムが最大化しようとする数値）を必要とします。私は目的変数（objective）と指標（metric）を区別しています。指標（metric）はシステムがレポーティングする数値であり、重要であるものもあればそうでないものもあります。ルール2も見てください。

ルール12：直接最適化する目的変数を考えすぎない

あなたはお金を稼ぎたい、ユーザーをハッピーにしたい、もしくは世界をより良くしたいと思っているでしょう。気になる指標はたくさんあるでしょうし、それらを全て測定する必要があります（ルール2）。しかし、機械学習プロセスの早い段階においては、直接的に最適化されていないものも含め、全ての指標が改善していることに気づくでしょう。例えば、クリック数とサイト滞在時間に関心があるとします。クリック数を最適化すると、サイト滞在時間も増える可能性があります。したがって、全ての指標を容易に改善できるような場合は、シンプルに考え、あまりさまざまな指標のバランスをとることをについて考えすぎないでください。ただし、このルールを行き過ぎないでください。目的変数とシステムの究極の健全性を混同しないようにしましょう（ルール39）。そして、もし最適化した指標を改善できてもローンチできないという判断になった場合、目的変数の修正が必要かもしれません。

ルール13：最初のObjectiveとして、シンプル、観測可能でattributableな指標を選択する

真の目的変数が分からないことはしばしばあります。機械学習の目的変数は、測定することが容易であり、”真の”目的変数の代替（proxy）である必要があります。実際には、”真の”目的変数は存在しません（ルール39参照）。従って、シンプルな機械学習の目的変数を使用して学習し、後から追加のロジック（できれば非常にシンプルなロジック）を加えられる”ポリシーレイヤー”を配置することを検討してください。

モデル化するのが最も簡単なのは、システム内における、直接的に観察されたユーザーの振る舞いです。

  • このリンクはクリックされたか
  • このオブジェクトはダウンロードされたか
  • このオブジェクトは転送/返信/メール送信されたか
  • このオブジェクトは評価されたか
  • このオブジェクトはスパム/ポルノ/攻撃的とマークされたか

最初は間接的な効果のモデリングは避けてください。例えば：

  • ユーザーから翌日訪問があったか
  • ユーザーはどのくらいの間サイトに滞在したか
  • 日次アクティブユーザーはどの程度か

間接的な効果はとてもよい指標となり、ABテストやローンチ判断の際に役立ちます。

最後に、機械学習には次のようなことfigure outさせようとしないでください。

  • ユーザーは製品を満足して使用しているか
  • ユーザーは体験に満足しているか
  • 製品はユーザーの全体としての健康状態を改善しているか
  • その仕組みは会社全体の健康にどのように影響するか

これらは非常に重要ですが、計測することは極めて困難です。その代わり、代替（proxy）を使用してください。例えば、もしユーザーが満足していれば、彼らはサイトに長く滞在するでしょう。もしユーザーが体験に満足したら、彼らは翌日も訪問してくれるでしょう。幸福と会社の健康に関係する限り、機械学習の目的変数と、販売しようとしている製品の性質や事業計画とを結び付けるには、人間の判断が必要になるでしょう。

ルール14：解釈可能なモデルから始めることで、デバッグが容易になる

線形回帰、ロジスティック回帰、ポワソン回帰は、確率モデルによって直接motivateされます。各予測は、確率または期待値として解釈できます。その結果、分類精度やランク付けのパフォーマンスを直接最適化しようとする目的変数（0-1損失やさまざまなヒンジ損失）を用いるよりもデバッグが容易になります。例えば、予測された確率が学習時の確率から大きく逸脱していた場合、そのことによって問題があきらかになる可能性があります。

たとえば、線形、ロジスティック、ポワソン回帰の場合、there are subsets of the data where the average predicted expectation equals the average label (1- moment calibrated, or just calibrated). This is true assuming that you have no regularization and that your algorithm has converged, and it is approximately true in general. If you have a feature which is either 1 or 0 for each example, then the set of 3 examples where that feature is 1 is calibrated. Also, if you have a feature that is 1 for every example, then the set of all examples is calibrated.

シンプルなモデルの場合、フィードバックループを回すのが容易です。多くの場合、確率的予測を使用して私たちは判断します：期待値の降順で投稿をランク付けするなど。しかし、使用するモデルの選択の場面では、モデルから与えられるデータよりも意思決定が重要であることを忘れないでください。

ルール15：Policy Layerでスパムフィルタリングとクオリティランキングを切り分ける

クオリティランキング（質の高いもののランキング）はファインアート（芸術的価値を追求するもの）ですが、スパムフィルタリングは戦いです。高品質な投稿を判別するために使用するシグナルは、システムのユーザーにより明らかにされ、そういった高品質な投稿の性質を持たせるように彼らの投稿は調整されていきます。したがって、クオリティランキングは、誠意のある投稿コンテンツをランキングすることに焦点を当てる必要があります。スパムを上位にランキングさせるようなクオリティランキングを軽視してはなりません。

扇情的なコンテンツはクオリティランキングとは別に対処する必要があります。スパムフィルタリングは別の問題なのです。あなたが生成すべき特徴量は常に変化していくと想定する必要があります。

たいていの場合には、システムに適用できる明白なルールがあります（スパム報告が3件以上ある投稿は表示しない、など） Any learned model will have to be updated daily, if not faster. The reputation of the creator of the content will play a great role.

あるレベルにおいて、これら２つのシステムの出力を統合する必要があります。検索におけるスパムフィルタリングは、Eメールのスパムフィルタリングよりaggressiveであることに注意してください。 This is true assuming that you have no regularization and that your algorithm has converged. これはおそらく一般的に事実です。また、クオリティの予測器に与える学習データからスパムを除外するのが標準的なプラクティスです。

 

フェーズⅡ以降は（２）に分け、別途記述します。