[翻訳] 機械学習の問題構造化入門
原典
キーワード
- Problem (for machine learning) : (機械学習で取り組むべき）問題
- Problem Framing: 問題の構造化
- Goal: MLモデルの活用により目指す姿
- Outcome: 成果
- Success / Failure Metrics : 成果の定量指標と、成功/失敗と判断するための閾値
- Output: 出力
- Example Output: MLモデルに学習させる例としてのOutput
- pseudocode：模擬的なソースコード
- Objective: 目的変数
以下のセクションでは、機械学習（ML）で取り組むべき問題を構造化する前に考えるべきいくつかのことを整理します。
明白かつシンプルにスタートする
MLモデルに何をしてもらいたいか、簡単な表現で書いてください。
例：MLモデルに、アップロードされたばかりの動画がどれだけ人気になりそうかを予測してもらいたい
この時点では、文章は定性的で構いません。しかし、間接的なゴールではなく、直接的なゴールを捉えていることに気を付けてください。
理想のOutcome（成果）は何ですか？
あなたのMLモデルを、システムに追加することで、望ましいOutcome（成果）が生み出されるはずです。このOutcome（成果）は、モデルの質の評価指標とは異なります。
例：Transcoding（トランスコーディング）
私たちの理想的なOutcome（成果）は、人気ではない動画をトランスコーディングするリソースを削減することです。
※ トランスコーディングとは、ユーザーがアップロードしたコンテンツをYouTubeで表示する上でより効率的なフォーマットに変換することです。1/3以上のYoutubeにアップロードされた動画が、10回未満しか再生されません。もし、そういった動画を特定し、それらに対しては低解像度の動画だけを用意するといったことができれば、多くのリソースを節約することができます。
例：動画レコメンド
私たちの理想的なOutcome（成果）は、ユーザーにとって役に立つ/面白い/見るに値する動画を提案することです。
→どちらの例も、”アップロードされた動画がどれだけ人気になりそうか”を予測するMLモデルのOutcome（成果）になり得る
★ポイント：私たちは、同じMLモデルからの予測値を異なる使い方をすることで、異なるOutcome（成果）を得ることができます。そのため、私たちはプロダクト（MLモデル）に関し、どのようなことが大事なのかについて定義するOutcome（成果）を確認しておくことが必要なのです。
プロダクト（MLモデル）において、これまでよく追及されるようなメトリックに囚われず、その外側にある、あなたのプロダクト/サービスのより大きな目的に照準を当ててください。
Success/Failure Metrics（成功/失敗の判断基準）
定量化しましょう！
あなたのシステムが成功である/失敗であるとどのように判断しますか？
成功/失敗の判断基準は、precision/recall/AUCなどのモデル評価指標とは別に記述する必要があります。代わりに、予想されるOutcome（成果）で記述してください。
例：トランスコーディング
Success Metric（成功の判断基準）はCPUリソース使用率です。成功はトランスコーディングにかかるCPUコストを35%まで減らすことを意味し、Failure Metric（失敗の判断基準）はCPUコスト削減量がモデルの学習とサービス提供にかかるコスト未満になることを意味します。
例：動画レコメンド
Success Metric（成功の判断基準）はモデルにより適切に予測された人気動画の数です。成功はアップロードされてから20日以内の総再生時間で測定した最も人気のある動画の95%をMLモデルが予測することを意味し、Failure Metric（失敗の判断基準）は、正しく予測された動画の数が、現在のヒューリスティックスよりも優れていないことを意味します。
判断基準は測定可能ですか？
”測定可能”な判断基準があることで、現実世界の栄光ある評価のための情報となります。例えば、果樹園の木の健康をモニタリングするシステムの場合、病気で枯れてしまう木の割合を減らしたいとします。しかし、もしあなたが病気の木の数を計測できないならば、それは役に立つ判断基準にはなりません。
以下のような質問を投げてみてください。
- どのように、あなたはその判断基準を測りますか？
- いつ、あなたはその判断基準を測ることができますか？
- あなたのMLシステムが成功か、失敗かを判断するためにどのくらいの時間がかかりますか？
理想的には、あなたは早めに失敗したいはずです。シグナルが弱すぎたり、データが予測にほとんど使えない、といったことに注意してください。早く失敗することで、早く仮説を修正でき、時間ロスを防ぐことができます。
例：あなたはユーザーの位置情報から、どの動画が見られるかを当てることができると考えています。それは可能かもしれません。しかし、実際にそれを試してみるとシグナルが弱すぎたりノイズが大きすぎてうまくいきません。どのくらい長くあなたはその仮説に固執しますか？
長期的なエンジニアリングやメンテナンスコストを考慮してみてください。
他の失敗のシナリオ
成功の判断基準とは関係のない失敗にも注意してください。例えば、”クリックベイト”（ウェブ上の広告や記事などに、ユーザーの興味を引いて閲覧者数を増やすため、煽情的なタイトルをつけること）動画ばかりをレコメンドするシステムは、質の高い視聴体験を提供する上で成功であるとは言えないでしょう。
どのようなOutput（出力）をMLモデルで生成したいですか？
数値/ラベル/クラスター/他、あなたはどのような種類のOutput（出力）を必要としていますか。
★ポイント：あるタイプのOutputでは失敗となるが、別のタイプのOutputでは成功するようなML問題もあります
良いOutputのProperties
Outputは機械で生成できるよう、明確な定義に基づき定量化できることが必要
例：ユーザーは動画を見て楽しんだか？ vs ユーザーは動画をシェアしたか？
ユーザーに質問しない限り、ユーザーが動画を楽しんだかどうかはわかりません。もしユーザーに質問ができないのなら、あなたにはproxy label、つまり真の事象の代替となるラベルが必要です。ユーザーがどのくらいその動画をシェアしたかは非常に良いproxy labelとなります。確かに、動画をシェアすることはユーザーが楽しんだかどうかの完璧な近似にはなりません（例えば、その動画を馬鹿にするためにシェアするといったこともあります）。しかし、シェアは定量的で、トラッキング可能で、ちゃんとした予測のためのシグナルを提供します。
Output（出力）は、理想的なOutcome（成果）と繋がっていることが必要です
MLモデルはOutput（出力）を最適化します。したがって、そのOutputが本当にあなたにとって大事なものであることを確かめてください。理想的なOutcomeを直接図ることはできないことが多いので、proxy labelは頻繁に必要になります。しかし、proxy labelと本当のOutcomeとの関係性が強いほど、私たちは正しい事象を最適化していると自信を持つことができます。
OutputとOutcomeの間に強い関連性があることを確かめてください！
学習データとして利用できるExample Outputsを入手できますか？
何のデータソースからどのように？
教師あり学習はラベル付けされたデータに依存しています。もし、Example outputs（例としての出力）を手に入れることができないのなら、前の段階に立ち戻って機械学習の問題（problem）と目指す姿（goal）を再定義する必要があります。outputはエンジニアリングされる必要があるケースがあります。例えば、上の例では視聴時間をパーセンタイル値に変換しています。
Outputを使う
モデルは次の二つの方法で予測を出力することができます。
- ユーザーの行動に反応して、リアルタイムに（online）
- バッチ実行して、キャッシュ化（offline）
どのようにあなたのプロダクトは使用されますか？いいですか？私たちはMLをdecisionを生むために使用します、予測のためではありません。どのようにあなたはモデルにより予測されたoutputをdecisionに変換しますか？
例：
新しい動画がアップロードされたとき、その動画がどのくらい人気になるかを予測します。そのOutputは動画のトランスコーディングのアルゴリズムの決定（decision）に役立てられます。
実装が擬似的なコードでどのようになるかを考えてみてください。例えば、ユーザーがアプリから送信された通知をクリックする可能性を予測するモデルを構築していて、クリックする可能性のあるユーザーのみに通知を送信したいとします。擬似的なコードは以下のようになるでしょう。
click_probability = call_model(user)
if click_probability > 0.05:
send_notification(user)
上記のステップを行うことは、モデルの予測をdecisionに変換することを考えることに役立つでしょう。
次に、上の擬似的コードが実装されるアーキテクチャがどこか考えましょう。これは次のような重要な問いに答えることにつながります。
- モデルを呼び出す必要がある時に、そのコードはどんなデータにアクセスができますか？
- レイテンシー（通信の遅延時間）に関する要件は何ですか？UI上での遅延を避けるように素早く実行される必要がありますか？それともユーザーの行動を待たずに実行しておくことができますか？
上記の問いに答えることで発見される要件は、あなたのMLモデルが使用できる特徴量に大きな影響を与えます。あなたがMLモデルを呼び出すときに使用できる特徴量でのみ学習できます。そうでなけば、せっかくMLモデルが知識を学習してもサービス提供時に利用できません。さらに、レイテンシー要件を満たす範囲で特徴量が取得できることを確認してください。外部サービスからのデータを使用することはレイテンシーの観点からは、その特徴量は割高になってしまう可能性があります。例えば、現在の気象情報をカメラアプリの中で特徴量として使用したい場合、現在の気象情報を取得するまでの待ち時間が長すぎて、アプリで許容できない速度低下が発生するかもしれません。
最後に、古いデータの使用に注意してください。学習データが数日前のものである場合があることに注意してください。ライブトラフィックで処理している場合には、使用したいデータがまだ取得できない場合があります。おそらくデータベースは30分ごとにユーザーの履歴を更新するので、予測を行うときにユーザーの最新データにアクセスすることはできません。
不適切なObjective（目的変数）
正しくセットアップされたら、MLシステムは目指すObjective（目的変数）を追求していく上で非常に優れています。反対に、MLシステムは間違ったObjectiveが与えられた場合には、意図しない結果を生み出す可能性があります。したがって、システムの目的がどのように、あなたの問題を解決するために機能するかを慎重に考えてください。
先ほどのYouTubeで次に見る動画を予測するモデルのケースを再度考えてみましょう。
- クリック率を最大化する
- ユーザーはクリックはしますが、長く動画を視聴することはないでしょう。これは”クリックベイト”を最適化してしまいます。別の方法を試した方がいいでしょう
- 視聴時間を最大化する
- セッション視聴時間を最大化する
- このモデルも依然として長い動画を選びがちであり、これは問題です。このモデルは、特定の関心を非常にうまく掘り下げます。例えば、ユーザーがLeBron Jamesのダンクシュートの動画を見ると、システムは全てのLeBron Jamesのダンクシュートのビデオを表示します。この動画レコメンデーションシステムはセッション視聴時間を最大化するのは本当に得意ですが、ユーザーエクスペリエンスは低下します。
- 多様性を増やし、セッション視聴時間を最大化する
- このObjectiveからはどのような問題が発生すると思いますか？「計測結果が目標になると、その計測自体が役に立たなくなる」というグッドハートの法則を常に留意してください。
ヒューリスティックス（経験則）
もしMLを使わないなら、どのように問題を解決しますか？もし、あなたが明日プロダクトを納品しなくてはならず、ビジネスロジックをハードコーディングする時間しかないとします。その場合、あなたは次のようなヒューリスティックス（非MLソリューション）を試すことができます。
例：過去に人気動画をアップロードした人による新しい動画も人気になると想定します
このヒューリスティックスは、正解で最高のヒューリスティックスではないかもしれませんが、ベースラインを提供します。ヒューリスティックスに勝てないような、MLモデルは決して使ってはなりません。ヒューリスティックスを作るエクササイズは、MLモデルにおける良いシグナルを特定するのに役立つ場合があります。
非MLソリューションは、MLソリューションより保守が簡単な場合があります。
