機械学習のルール:

ML エンジニアリングのベスト プラクティス

Martin Zinkevich 氏

このドキュメントは、ML の基本的な知識を持つユーザーが、Google の ML のベスト プラクティスを活用できるように支援することを目的としています。Google C++ スタイルガイドや他の実用的なプログラミング ガイドと同様に、ML のスタイルを提示します。ML のクラスを受講したことがある方、ML モデルを構築または作成した経験がある方は、このドキュメントを読むために必要な知識があります。

Martin Zinkevich 氏は、ML に関するお気に入りの 10 のルールを紹介します。以下に、43 のルールをご紹介します。

用語

効果的な ML の説明では、次の用語が繰り返し登場します。

  • インスタンス: 予測を行う対象。たとえば、「猫について」または「猫についてではない」として分類したいウェブページがインスタンスであるとします。
  • ラベル: 予測タスクに対する回答。ML システムによって生成された回答か、トレーニング データで指定された正解のいずれか。たとえば、ウェブページのラベルが「about cats」といった具合です。
  • 特徴: 予測タスクで使用されるインスタンスのプロパティ。たとえば、ウェブページに「猫」という単語を含む機能があるとします。
  • 特徴列: 関連する特徴のセット(ユーザーが居住する可能性のあるすべての国のセットなど)。1 つの例では、特徴列に 1 つ以上の特徴が存在する場合があります。「機能列」は Google 固有の用語です。特徴列は、VW システム(Yahoo/Microsoft)では「名前空間」、または「フィールド」と呼ばれます。
  • : インスタンス(特徴を含む)とラベル。
  • モデル: 予測タスクの統計的表現。サンプルでモデルをトレーニングし、そのモデルを使用して予測を行います。
  • 指標: 重要な数値。直接最適化される場合もあります。
  • 目標: アルゴリズムが最適化しようとしている指標。
  • パイプライン: ML アルゴリズムを取り巻くインフラストラクチャ。フロントエンドからのデータの収集、トレーニング データファイルへの配置、1 つ以上のモデルのトレーニング、本番環境へのモデルのエクスポートが含まれます。
  • クリック率: 広告内のリンクをクリックしたウェブページ訪問者の割合。

概要

優れた商品を作るには:

機械学習を優れたエンジニアのように行いましょう ご自身以外の優れた機械学習の専門家ではありませんが

直面する問題のほとんどは、実際にはエンジニアリングの問題です。優れた ML エキスパートのあらゆるリソースがあったとしても、多くのメリットは優れた機械学習アルゴリズムではなく、優れた機能から得られるものです。基本的なアプローチは次のとおりです。

  1. パイプラインがエンド ツー エンドで安定していることを確認してください。
  2. まずは合理的な目標を設定する。
  3. 常識的な特徴を簡単な方法で追加します。
  4. パイプラインが安定していることを確認します。

この方法は長期間有効です。この方法から離れるのは、さらに上を目指すための簡単なコツが他にない場合に限ります。複雑さが増すと、今後のリリースが遅くなります。

簡単な工夫をこなせば、実際に最先端の機械学習が使えるようになるかもしれません。フェーズ III の ML プロジェクトのセクションをご覧ください。

このドキュメントの構成は次のとおりです。

  1. 前半では、ML システムを構築するのに適時かどうかを判断します。
  2. 次のパートでは、最初のパイプラインをデプロイします。
  3. パート 3 では、パイプラインに新しい機能を追加しながら起動と反復処理、モデルの評価方法とトレーニング サービング スキューについて取り上げます。
  4. 最後のパートでは、プラトーに達したときにどのように対処するかについて説明します。
  5. その後、関連する作業のリストと、このドキュメントで例として一般的に使用されるシステムのバックグラウンドを含む付録を示します。

ML 導入前

ルール 1: 機械学習なしでプロダクトをリリースすることを恐れないでください。

ML は優れていますが、データが必要です。理論的には、別の問題からデータを取得して新しい商品に合わせてモデルを調整できますが、基本的なヒューリスティックheuristicsではパフォーマンスが低下する可能性があります。ML によって 100% のブーストが達成されると思われる場合は ヒューリスティックで 50%の確率で達成できます

たとえば、アプリ マーケットプレイスでアプリをランク付けする場合は、インストール率またはインストール数をヒューリスティックとして使用できます。スパムを検出した場合は、以前にスパムを送信したことがあるパブリッシャーを除外します。恐れずに人間が編集してください。連絡先をランク付けする必要がある場合は、最近使用した順を最高にします(またはアルファベット順にランク付けします)。ML がどうしても必要ないプロダクトでは データが手に入るまで使用しないでください

ルール 2: まず、指標を設計して実装する。

機械学習システムの動作を形式化する前に、現在のシステムでできる限りトラッキングします。これを行う理由は次のとおりです。

  1. 早い段階でシステムのユーザーから許可を得る方が容易です。
  2. 今後、なんらかの問題が生じるかもしれないと思われる場合は、今すぐ過去のデータを取得することをおすすめします。
  3. 指標のインストルメンテーションを念頭に置いてシステムを設計すれば、今後状況はより良くなります。特に、指標を計測するために、ログ内の文字列をグレッピングすることは望ましくありません。
  4. 何が変わって何が変わらないのかがおわかりいただけるでしょう。たとえば、1 日のアクティブ ユーザーを直接最適化するとします。ただし、システムの初期の操作では、ユーザー エクスペリエンスが大幅に変化しても、この指標はそれほど大きくは変わらないことに気づくかもしれません。

Google Plus チームは 1 読み取りあたりの拡張数、1 読み取りあたりの再共有数、1 読み取りあたりの 1 件あたりの合計回数、コメント数/読み取り数、ユーザー 1 人あたりのコメント数、ユーザー 1 人あたりの再共有数などを測定して、配信時の投稿の有効性を算出しています。また、ユーザーをバケットにグループ化し、テストごとに統計を集計できるテスト フレームワークも重要です。ルール 12 をご覧ください。

指標の収集に関する自由度を高めることで、システムの全体像を把握できます。問題が生じた場合は、追跡する指標を追加してください。前回のリリースで量的変化が見られる場合は、追跡する指標を追加してください。

ルール 3: 複雑なヒューリスティックではなく ML を選択する。

簡単なヒューリスティックで、製品を世に出すことができます。複雑なヒューリスティックは 維持できませんデータと目標について基本的な考え方がわかったら ML に進みますほとんどのソフトウェア エンジニアリング タスクでは、ヒューリスティック モデルでも ML モデルでも、アプローチを常に更新する必要があります。ML モデルの更新と保守が容易であることに気づくでしょう(ルール #16 を参照)。

ML フェーズ 1: 最初のパイプライン

最初のパイプラインはシステム インフラストラクチャに集中します。これから行う想像力豊かな ML について考えるのは楽しいものですが、パイプラインを最初に信頼しなければ、何が起こっているのかを理解することは困難です。

ルール 4: 最初のモデルをシンプルに保ち、インフラストラクチャを適切にする。

最初のモデルが最も効果を発揮するので、必ずしも新しいモデルにする必要はありません。しかし、予想以上に多くのインフラストラクチャの問題に直面します。この最新の機械学習システムを誰かに使用してもらうには、まず次のことを判断する必要があります。

  • 学習アルゴリズムに例を取得する方法
  • まず、システムにとって「良い」と「悪い」の意味を確認します。
  • モデルをアプリケーションに統合する方法モデルをライブで適用することも、オフラインでサンプルでモデルを事前計算して結果をテーブルに保存することもできます。たとえば、ウェブページを事前に分類して結果をテーブルに保存し、チャット メッセージをライブで分類する必要がある場合があります。

シンプルな機能を選択すると、次のことが簡単になります。

  • 特徴量が学習アルゴリズムに正しくリーチする。
  • モデルは妥当な重みを学習します。
  • 特徴量はサーバー内のモデルに正しく到達します。

この 3 つの処理を確実に実行するシステムを用意すれば、ほとんどの作業は完了です。単純なモデルから、より複雑なモデルをテストするために使用できるベースライン指標とベースライン動作が提供されます。チームによっては、「中立」な初回起動を目指しています。これは、集中できるように ML のメリットを明示的に下げる初回リリースです。

ルール 5: インフラストラクチャを ML から独立してテストする。

インフラストラクチャをテスト可能にして、システムの学習部分をカプセル化して、周囲にあるものをすべてテストできるようにします。以下にご紹介します。

  1. アルゴリズムへのデータの取り込みをテストします。データを入力すべき特徴列にデータが入力されていることを確認します。プライバシーが許す限り、トレーニング アルゴリズムへの入力を手動で検査します。可能であれば、パイプラインの統計情報を他の場所で処理された同じデータの統計情報と比較します。
  2. トレーニング アルゴリズムからのモデルの取得をテストします。トレーニング環境のモデルが、サービス環境のモデルと同じスコアを与えるようにします(ルール #37 を参照)。

機械学習には予測不可能な要素があるため、トレーニングとサービス提供でサンプルを作成するコードのテストを行い、サービス提供中に固定モデルを読み込んで使用できるようにしてください。また、データを理解することも重要です。大規模で複雑なデータセットの分析に関する実践的なアドバイスをご覧ください。

ルール 6: パイプラインをコピーする際はデータのドロップに注意してください。

多くの場合、既存のパイプラインをコピーしてパイプラインを作成します(カーゴカルト プログラミングなど)。古いパイプラインでは、新しいパイプラインに必要なデータが破棄されます。たとえば、Google Plus の「注目の投稿」のパイプラインでは、(新しい投稿をランク付けしようとして)古い投稿を削除します。このパイプラインは、Google Plus ストリーム用にコピーされました。このパイプラインでは、古い投稿も引き続き意味を持ちますが、古い投稿は除外されています。もう 1 つの一般的なパターンは、ユーザーが確認したデータのみをログに記録することです。特定の投稿がユーザーに表示されない理由をモデル化する場合には、ネガティブなサンプルがすべて破棄されているため、このデータは役に立ちません。Play でも同様の問題が発生しました。Play アプリのホームに取り組む際、新しいパイプラインが作成されました。このパイプラインには、Play ゲーム用のランディング ページの例も含まれており、各例の提供元を明確にする機能はありません。

ルール 7: ヒューリスティックを特徴に変換するか、外部で処理する。

通常、ML が解決しようとしている問題は、完全に新しいものではありません。ランキングや分類などの問題を解決するための既存のシステムがありますつまり たくさんのルールとヒューリスティックが ありますこれらと同じヒューリスティックにより、ML を調整することで効果が得られます。ヒューリスティックは、持っている情報に対してマイニングする必要があります。これには 2 つの理由があります。まず 機械学習システムへの移行が よりスムーズになります2 つ目は これらのルールには システムについての多くの直感が含まれており既存のヒューリスティックを使用するには、次の 4 つの方法があります。

  • ヒューリスティックを使用して前処理します。優れた機能の場合は このオプションを選択できますたとえば、スパムフィルタで送信者がすでにブラックリストに登録されている場合、「ブラックリスト登録済み」の意味を再確認しようとしないでください。メッセージをブロックする。このアプローチは、バイナリ分類タスクに最適です。
  • 特徴を作成します。このヒューリスティックから直接特徴を作成できるのは便利です。たとえば、ヒューリスティックを使用してクエリ結果の関連性スコアを計算する場合、スコアを特徴の値として含めることができます。その後、ML 手法を使用して値をマッサージする(たとえば、値を離散値の有限のセットのいずれかに変換したり、他の特徴と組み合わせたりする)こともできますが、最初にヒューリスティックによって生成された未加工の値を使用します。
  • ヒューリスティックの未加工の入力をマイニングする。インストール数、テキスト内の文字数、曜日を組み合わせたヒューリスティックがある場合は、これらの要素を分離し、これらの入力を別々に学習にフィードすることを検討してください。アンサンブルに適用されるいくつかの手法がここでも適用されます(ルール #40 をご覧ください)。
  • ラベルを変更します。現在ラベルに含まれていない情報がヒューリスティックによってキャプチャされると思われる場合は、このオプションを選択できます。たとえば、ダウンロード回数を最大化したいが、高品質のコンテンツも必要な場合は、ラベルにアプリが受けた平均のスター数を乗算することで解決できます。これにはかなりの余裕があります。 「最初の目標」をご覧ください。

ML システムでヒューリスティックを使用する場合は、複雑さが増すことに注意してください。新しい機械学習アルゴリズムで古いヒューリスティックを使用すると、スムーズな移行を実現できますが、同じ効果をできるだけ簡単に実現できる方法がないか検討してください。

モニタリング

アラートを実用的なものにしたり、ダッシュボード ページを用意したりするなど、アラートの健全性を維持することをおすすめします。

ルール 8: システムの鮮度の要件を把握する。

1 日前のモデルがある場合、パフォーマンスはどの程度低下しますか。1 週間前?4 年前?この情報は、モニタリングの優先度を理解するのに役立ちます。モデルを 1 日更新しないとプロダクトの品質が大幅に低下する場合は、エンジニアに継続的に監視してもらうことをおすすめします。ほとんどの広告配信システムでは、新しい広告が毎日処理されるため、更新は毎日行う必要があります。たとえば、Google Play 検索の ML モデルが更新されない場合、1 か月以内に悪影響が生じる可能性があります。Google Plus の「注目の投稿」のモデルの中には、モデルに投稿 ID が含まれていないものもあります。このようなモデルは、頻繁にエクスポートされないことがあります。投稿 ID を持つ他のモデルは、より頻繁に更新されます。また、特に特徴列がモデルに追加または削除された場合、更新頻度は時間の経過とともに変化する可能性があります。

ルール 9: モデルをエクスポートする前に問題を検出する。

多くの ML システムには、モデルをサービングにエクスポートするステージがあります。エクスポートされたモデルに問題がある場合は、ユーザーが直面する問題です。

モデルをエクスポートする直前にサニティ チェックを行います。具体的には、除外されたデータに対するモデルのパフォーマンスが妥当であることを確認します。データに関する懸念が長引く場合は、モデルをエクスポートしないでください。多くのチームは、モデルを継続的にデプロイして、エクスポート前に ROC 曲線(または AUC)の下の領域をチェックします。エクスポートされていないモデルに関する問題の場合はメール通知アラートが必要になりますが、ユーザー向けのモデルに関する問題の場合はページが必要になる場合があります。そのため、ユーザーに影響を与える前に確認することをおすすめします。

ルール 10: サイレント エラーに注意する

これは、他の種類のシステムよりも機械学習システムでよく発生する問題です。結合中の特定のテーブルが更新されなくなったとします。機械学習システムが調整され、動作はある程度良好で、徐々に減衰します。テーブルが何か月も前のものになっていることもありますが、その四半期にリリースしたどのリリースよりも、テーブルを更新するだけでパフォーマンスが向上することがあります。特徴のカバレッジは、実装の変更により変わる可能性があります。たとえば、特徴列が例の 90% に入力されたのに、その例の 60% に突然減少する可能性があります。かつて Play には 6 か月間古いテーブルがありましたが、テーブルを更新するだけでインストール率が 2% 上昇しました。データの統計情報を追跡し、随時手動でデータを検査することで、このような失敗を削減できます。

ルール 11: 特徴列にオーナーとドキュメントを付与する。

システムの規模が大きく、特徴列が多い場合は、各特徴列の作成やメンテナンスを誰が行っているかを把握します。特徴列を理解している人が離職していることが判明した場合は、その人が情報を持っていることを確認します。多くの特徴列にはわかりやすい名前が付けられていますが、特徴、その出所、用途はより詳しく記述することをおすすめします。

最初の目標

対象となるシステムに関する指標や測定値は数多くありますが、機械学習アルゴリズムで必要となるのは、アルゴリズムが最適化しようとしている数値である 1 つの目標です。ここで、目標と指標を区別します。指標は、システムが報告する任意の数値で、重要の場合と重要でない場合があります。ルール 2 もご覧ください。

ルール 12: どの目標を直接最適化するかを深く考えないでください。

お金を稼ぎ、ユーザーを幸せにし、世界をより良い場所にすることを目指しています。注目すべき指標は数多くあり、それらすべてを測定する必要があります(ルール 2 を参照)。しかし、機械学習プロセスの初期段階では、直接最適化していないものも含め、すべての最適化案が目に見えるようになります。たとえば、クリック数とサイトでの滞在時間を重視する場合を考えてみましょう。クリック数を重視して最適化すると、所要時間が増加する可能性があります。

したがって、すべての指標を簡単に増やすことができる場合は、シンプルに保ち、異なる指標のバランスについてあまり考えないでください。ただし、このルールは大まかに捉えないでください。目的とシステムの最終的な健全性を混同しないでください(ルール 39 を参照)。また、直接最適化された指標を増やしたにもかかわらず、リリースしないことにした場合は、目標の修正が必要になることがあります。

ルール 13: 最初の目標に対して、シンプルで観測可能でアトリビューション可能な指標を選ぶ。

多くの場合、本当の目的がわかりません。自分が何だろうと思っているけれども、古いシステムと新しい ML システムのデータと並べて分析を眺めていると、目的を微調整したいと思うことがよくあります。さらに、チームメンバー間で真の目標に同意できないことがよくあります。ML の目標は測定が容易で、「真の」目標の代用となるものでなければなりません。 実際には、多くの場合に「真の」目標はありません(ルール#39 を参照)。そのため、単純な ML の目標のトレーニングを行い、最終ランキングを行うためのロジック(できれば非常に単純なロジック)を追加できる「ポリシーレイヤ」を一番上に配置することを検討してください。

モデル化が最も容易なのは、直接観測され、システムのアクションに起因するユーザー行動です。

  • このランク付けされたリンクをクリックしましたか?
  • このランク付けされたオブジェクトはダウンロードされましたか?
  • このランク付けされたオブジェクトは転送/返信/メールで送信されましたか?
  • このランク付けされたオブジェクトは評価されましたか?
  • 表示されたオブジェクトは、スパム、ポルノ、不適切なコンテンツとしてマークされていましたか?

最初は間接効果のモデリングを避ける:

  • ユーザーは翌日訪問しましたか?
  • ユーザーがサイトにアクセスした時間
  • 1 日のアクティブ ユーザー数はいくつですか。

間接効果は優れた指標となり、A/B テスト中やリリース判断の際に使用できます。

最後に、ML に次の内容を理解させようとしないでください。

  • お客様はプロダクトの使用に満足していますか?
  • ユーザーはエクスペリエンスに満足しているか。
  • その製品によってお客様の全体的なウェルビーイングが改善されていますか?
  • これは会社全体の健全性にどのように影響しますか?

これらはすべて重要であるものの、測定が非常に困難でもあります。代わりにプロキシを使用します。ユーザーが満足すれば、サイトの利用時間が長くなります。満足していれば、ユーザーは明日またアクセスします。心身の健康と会社の健康については、機械学習の目標を販売している商品の性質やビジネスプランに関連付けるために、人間による判断が必要です。

ルール 14: 解釈可能なモデルで始めるとデバッグが容易になる。

線形回帰、ロジスティック回帰、ポアソン回帰は、確率論的モデルによって直接的に促進されます。各予測は確率または期待値として解釈できます。これにより、分類精度やランキング パフォーマンスを直接最適化しようとする目標(ゼロ 1 損失、さまざまなヒンジ損失など)を使用するモデルよりもデバッグしやすくなります。たとえば、トレーニングの確率が、左右に並んで予測された確率から逸脱している場合や、本番環境システムを検査することで、この偏差から問題が明らかになる可能性があります。

たとえば、線形回帰、ロジスティック回帰、ポアソン回帰では、平均予測期待値が平均ラベルに等しいデータのサブセット(調整済み 1 瞬間、または調整済み)があります。これは、正則化がなく、アルゴリズムが収束していることを前提としており、概ね当てはまります。各サンプルで 1 または 0 の特徴がある場合は、その特徴が 1 である 3 つのサンプルのセットが調整されます。また、すべてのサンプルで 1 の特徴がある場合は、すべてのサンプルのセットが調整されます。

単純なモデルにすると、フィードバック ループの処理が容易になります(ルール 36 を参照)。多くの場合、決定を下す際にこのような確率的予測を使用します。たとえば、期待値(クリックやダウンロードの確率など)の低下に関して投稿をランク付けします。ただし、使用するモデルを選択するときは、そのモデルに与えられたデータの可能性よりも、その決定が重要であることに注意してください(ルール #27 を参照)。

ルール 15: スパム フィルタリングと品質ランキングを 1 つのポリシー レイヤで分離する。

品質ランキングは特別な技術ですが、スパム フィルタリングは戦争なのです。高品質の投稿を判断するために使用するシグナルは、システムを利用するユーザーにとって明白で、こうした特性を持つように投稿を微調整します。したがって、品質ランキングでは、誠意をもって投稿されたコンテンツのランキングを重視する必要があります。スパム ランキングを上げるために品質ランキング学習者を過小評価しないでください。同様に、「際どい」コンテンツは、品質ランキングとは別に処理する必要があります。スパムフィルタは別の話です。生成する必要のある特徴は絶えず変化していくことを想定しておく必要があります。多くの場合、システムに組み込んだ明確なルールがあります(投稿に 3 件を超えるスパム投票がある場合は取得しないでください)。学習したモデルは、時間がかからなければ毎日更新する必要があります。コンテンツ作成者の評判が大きな役割を果たします

いずれかのレベルで、この 2 つのシステムの出力は統合する必要があります。検索結果のスパムフィルタは、メール メッセージのスパムフィルタよりも積極的に行ってください。また、品質分類器のトレーニング データからスパムを削除するのが標準的な方法です。

ML フェーズ 2: 特徴量エンジニアリング

ML システムのライフサイクルの最初のフェーズで重要な問題は、トレーニング データを学習システムに取り込んで、関心のある指標を計測できるようにすること、サービスを提供するインフラストラクチャを作成することです。エンドツーエンド システムが動作し、単体テストとシステムテストがインストルメント化されたら、フェーズ II が開始します。

第 2 フェーズでは、簡単に実現できる成果が多数あります。システムに組み込める明白な機能はさまざまです。したがって、ML の 2 番目のフェーズでは、できるだけ多くの特徴を取り込み、直感的な方法で組み合わせます。この段階では、すべての指標が上昇しているはずです。多くのリリースが予定されているため、これは、本当に優れた学習システムを構築するために必要なすべてのデータを統合できる、多くのエンジニアを採用する絶好のタイミングです。

ルール 16: リリースとイテレーションを計画する。

ここで作業しているモデルが最後のモデルになるとは限りません。また、モデルの起動がなくなるとも限りません。したがって、今回のリリースで複雑性が増すことで、今後のリリースが遅くなるかどうかを検討してください。多くのチームが、何年にもわたって四半期あたりまたはそれ以上のモデルを導入しています。新しいモデルをリリースする主な理由は 3 つあります。

  • 新しい機能を思い浮かべるかもしれません。
  • 正則化を調整し、古い特徴を新しい方法で組み合わせています。
  • 目標がチューニングされています。

いずれにしても、モデルに多少の配慮を与えることは良いことです。例にフィードされるデータを調べて、古いシグナルだけでなく、古いシグナルを見つける手がかりになります。モデルを構築する際は、特徴の追加、削除、再結合がどれほど簡単であるかを考えてみてください。パイプラインの新しいコピーを作成して正確性を検証することがいかに簡単か、考えてみてください。2 つまたは 3 つのコピーを並行して実行できるかどうかを検討してください。最後に、機能 35 の 16 がこのバージョンのパイプラインに含まれるかどうかについては、心配しないでください。次の四半期に提供されます。

ルール 17: 学習した特徴ではなく、直接観測および報告された特徴から始める。

これは物議を醸すポイントになるかもしれませんが、多くの落とし穴を防ぎます。まず、学習した特徴について説明しましょう。学習した特徴とは、外部システム(教師なしクラスタリング システムなど)または学習者自身(因数分解モデルやディープ ラーニングなど)によって生成される特徴のことです。どちらも役立ちますが、多くの問題がある可能性があるため、最初のモデルに含めないでください。

外部システムを使用して特徴を作成する場合は、外部システムには独自の目標があるので注意してください。外部システムの目標は、現在の目標との相関性が弱いだけです。外部システムのスナップショットを取得したら 最新でない可能性があります。外部システムから機能を更新すると、意味が変化することがあります。外部システムを使用して機能を提供する場合、この方法には細心の注意が必要です。

因数分解モデルとディープモデルの主な問題は、非凸型であることです。したがって、最適な解が近似または見出される保証はなく、各反復処理で見出される局所最小値は異なる場合があります。この変動により、システムに対する変更の影響が有意なものか、ランダムなものかを判断するのが難しくなります。深い特徴のないモデルを作成することで、優れたベースライン パフォーマンスを実現できます。このベースラインに達したら、より難解なアプローチを試すことができます。

ルール 18: 文脈をまたいで一般化されるコンテンツの特徴を使って探索する。

多くの場合、ML システムはより大きな全体像の小さな部分を占めます。たとえば、[注目の投稿] で使用される可能性のある投稿を思い浮かべると、多くの人が [注目の投稿] に表示される前に +1 したり、投稿を再共有したり、コメントにコメントしたりします。これらの統計情報を学習者に提供することで、最適化の対象となっているコンテキストで、データのない新しい投稿を宣伝できるようになります。YouTube の「次のおすすめ」では、YouTube 検索における視聴回数、または同時視聴(ある動画が別の動画が視聴された後に視聴された回数のカウント)を使用できます。明示的なユーザー評価を使用することもできます。最後に、ラベルとして使用するユーザー アクションがある場合、そのアクションを別のコンテキストのドキュメントに表示すると非常に便利です。これらの機能を使用して、新しいコンテンツをコンテキストに取り入れることができます。これはパーソナライズだけではありません。まず、このコンテキストでユーザーがコンテンツを好むかどうかを把握し、次に誰がそのコンテンツを高く評価するかを判断します。

ルール 19: 可能な限り具体的な機能を使用する。

大量のデータがある場合、何百万もの複雑な特徴を学習するよりも単純な特徴を学習する方が簡単です。取得されるドキュメントの ID と正規化されたクエリの識別子は一般化されませんが、ヘッドクエリのラベルに合わせてランキングが調整されます。したがって、各特徴がデータのごく一部にしか適用されないものの、全体のカバレッジが 90% を超えている特徴グループを気にしないでください。正則化を使用すると、少なすぎる例に適用される特徴を排除できます。

ルール 20: 既存の特徴を組み合わせて修正し、人間が理解できる方法で新しい特徴を作成する。

対象物を組み合わせたり変更したりするには、さまざまな方法があります。TensorFlow などの機械学習システムでは、変換を通じてデータを前処理できます。最も標準的なアプローチは、「離散化」と「クロス」の 2 つです。

離散化では、連続する特徴を取得し、それから多くの離散特徴を作成します。年齢などの連続的な特徴を考慮します。たとえば、年齢が 18 歳未満の場合は 1、年齢が 18 ~ 35 歳の場合は 1 の特徴を作成できます。これらのヒストグラムの境界を過度に考えないでください。基本的な分位数でほとんどの影響が生じます。

クロスは 2 つ以上の特徴列を結合します。TensorFlow の用語では、特徴列とは同種の特徴のセットです(例: {male, female}、{US, Canada, Mexico} など)。クロスは、{male, female} × {US,Canada, Mexico} のような特徴を持つ新しい特徴列です。この新しい特徴列には、特徴(男性、カナダ)が含まれます。TensorFlow を使用していて、TensorFlow にこのクロスを作成するように指示した場合、この(男性、カナダ)特徴は男性カナダ人を表す例に含まれます。3 つ、4 つ、またはそれ以上の基本特徴列のクロスを持つモデルを学習するには、膨大な量のデータが必要です。

非常に大きな特徴列を生成するクロスは過学習する可能性があります。たとえば、なんらかの検索を行い、クエリに単語を含む特徴列があり、ドキュメント内に単語を含む特徴列があるとします。これらをクロスと組み合わせることはできますが、多くの特徴を持つことになります(ルール #21 を参照)。

テキストを処理する場合、2 つの代替方法があります。最もドラコニアンはドット積です最も単純な形式のドット積は、クエリとドキュメントに共通する単語の数をカウントするだけです。この特徴は離散化できます。もう 1 つのアプローチは交差です。つまり、「pony」という単語がドキュメントとクエリの両方に存在する場合にのみ存在する特徴と、「the」という単語がドキュメントとクエリの両方に存在する場合にのみ存在する特徴があります。

ルール 21: 線形モデルで学習できる特徴量の重みの数は、持っているデータ量にほぼ比例します。

モデルの適切な複雑さのレベルに関する興味深い統計的学習理論の結果はありますが、基本的に知っておくべきルールはこのルールだけです。1,000 件の例から何かが学べることや、100 万件以上の例が必要になるはずの学習方法に行き詰まってしまうということに、多くの人が疑念を抱いていました。重要なのは、学習をデータのサイズに合わせて調整することです。

  1. 検索ランキング システムに取り組んでおり、ドキュメントとクエリに何百万もの異なる単語があり、1,000 個のラベル付きサンプルがある場合は、ドキュメントとクエリの特徴、TF-IDF、その他の 6 つの高度に人間が設計した特徴の間にドット積を使用する必要があります。1, 000 個の例、12 個の機能。
  2. 100 万個のサンプルがある場合は、正則化と場合によっては特徴選択を使用して、ドキュメントとクエリの特徴列を交差させます。これにより何百万もの特徴が得られますが、正則化によって得られるものは少なくなります。1, 000 万サンプル、おそらく 10 万特徴でしょう。
  3. 数十億または数千億のサンプルがある場合は、特徴選択と正則化を使用して、特徴列をドキュメント トークンとクエリトークンとクロスさせることができます。10 億個のサンプルと 1, 000 万個の特徴を使用できます。統計的学習理論で制約を受けることはほとんどありませんが、開始点に関する優れたガイダンスを提供します。

最終的には、ルール 28 を使用して、使用する機能を決定します。

ルール 22: 不要になった機能をクリーンアップする。

未使用の機能は技術的負担をもたらす。特定の機能が使用されておらず、他の機能と組み合わせても機能していない場合は、その機能をインフラストラクチャから削除します。有望な機能をできるだけ早く試すために、インフラストラクチャをクリーンな状態に維持する必要があります。必要に応じて、いつでも機能を追加し直すことができます。

どの機能を追加または残すかを検討する際は、カバレッジに留意してください。この機能の対象となるサンプルはいくつありますか?たとえば、パーソナライズ機能がいくつかあっても、パーソナライズ機能を備えたユーザーは全体の 8% のみの場合、それほど効果的とは言えません。

同時に、一部の機能は重量よりも大きくパンチすることもあります。たとえば、データの 1% のみをカバーする特徴があり、その特徴を持つサンプルの 90% が正例である場合は、追加すると効果的です。

人間によるシステムの分析

ML の第 3 フェーズに進む前に、どの ML クラスでも教えられていないこと、つまり、既存のモデルを見て改良する方法に焦点を当てることが重要です。これは科学というよりは技術なのですが、回避すべきアンチパターンがいくつかあります。

ルール 23: 一般的なエンドユーザーではない。

これが、チームが行き詰まる最も簡単な方法でしょう。fishfood(チーム内でプロトタイプを使用する)と dogfood(社内でプロトタイプを使用する)には多くのメリットがありますが、従業員はパフォーマンスが正しいかどうかを確認する必要があります。明らかに悪い変更は使用しないでくださいが、本番環境にかなり近いものに見えるものについては、クラウドソーシング プラットフォームで質問に答えてもらうために一般人にお金を払うか、実際のユーザーでライブテストを行うなどして、さらにテストする必要があります。

これには 2 つの理由があります。1 つ目はコードに近すぎることです投稿の特定の側面を求めている場合もあれば、単に感情的になりすぎている(確認バイアスなど)場合もあります。2 つ目は 自分の時間が貴重すぎるということです1 時間の会議に 9 人のエンジニアが参加した場合のコストを考慮し、クラウドソーシング プラットフォームで購入する契約中の人間のラベルの数について考えてみましょう。

ユーザーのフィードバックが本当に必要な場合は、ユーザー エクスペリエンスの手法を使用します。プロセスの早い段階でユーザー ペルソナを作成し(1 つの説明は Bill Buxton の Sketching User Experiences に記載)、その後ユーザビリティ テスト(1 つの説明は Steve Krug の Don’t Make Me Think に記載)を行います。ユーザーのペルソナでは 架空のユーザーを作成しますたとえば、チームの全員が男性の場合、(ユーザー機能を備えた)35 歳の女性ユーザー ペルソナを設計し、25 ~ 40 歳の男性向けの 10 件の結果ではなく、生成された結果を確認するとよいでしょう。ユーザビリティ テストで、(ローカルまたはリモートで)実際の人々にサイトに対する反応を見てもらっても、新しい視点を得ることができます。

ルール 24: モデル間の差分を測定する。

ユーザーが新しいモデルを確認する前に行うことができる最も簡単で便利な測定方法の一つが、新しい結果が本番環境とどのように異なるかを計算することです。たとえば、ランキングに問題がある場合は、システム全体でクエリのサンプルに対して両方のモデルを実行し、結果の対称的な差の大きさを調べます(ランキング順位によって重み付けします)。差が非常に小さい場合は、テストを実施しなくても、ほとんど変化がないことがわかります。差が非常に大きい場合は、変化が良好であることを確認する必要があります。対称的な差が大きいクエリを調べると、変更がどのようなものだったかを定性的に理解できます。ただし、システムが安定していることを確認してください。モデル自体と比較する場合、対称的な差異が小さく(理想的にはゼロ)ことを確認します。

ルール 25: モデルを選ぶ際、予測力よりも実用主義的な性能が優先されます。

モデルがクリック率の予測を試行する場合があります。ただし、結局のところ重要なのは、その予測をどう処理するかということです。ドキュメントのランク付けに使用する場合、予測自体よりも最終的なランキングの品質が重要になります。ドキュメントがスパムである確率を予測した後、何がブロックされるかがカットされる場合は、何が許可されるのかの精度がより重要になります。ほとんどの場合、この 2 つは一致している必要があります。同意しない場合、わずかに利益が得られる可能性があります。したがって、ログ損失は改善するものの、システムのパフォーマンスは低下するような変更があった場合は、別の機能を探します。これが増え始めたら モデルの目的を見直すときです

ルール 26: 測定された誤差のパターンを見つけ、新しい特徴を作成する。

モデルが「間違っている」トレーニング サンプルを見たとします。分類タスクでは、このエラーは偽陽性または偽陰性の可能性があります。ランキング タスクでは、ポジティブがネガティブよりも低くランク付けされているペアがエラーになることがあります。最も重要な点は、これは ML システムが問題を認識し、機会があれば修正するような例であるということです。モデルにエラーを修正できる特徴を与えると、モデルはその機能を使用しようとします。

一方、システムで誤りとして認識されないサンプルに基づいて特徴を作成しようとすると、その特徴は無視されます。たとえば、ユーザーが Play Apps 検索で「無料ゲーム」を検索するとします。たとえば、検索結果の 1 つに関連性が低いギャグアプリがあるとします。そこで、「ギャグアプリ」の機能を作成します。一方、インストール数を最大限に増やしても、ユーザーが無料ゲームを検索したときに gag アプリをインストールしてしまうと、「gag app」機能による効果は期待できません。

モデルに誤りがある例を特定できたら、現在の特徴セットにない傾向を探します。たとえば、長い投稿の順位が下がっていると思われる場合は、投稿の長さを追加します。追加する機能は 細かくなりすぎないでください投稿の長さを追加する場合は、長さを推測しようとせず、10 個の特徴を追加して、それらを使用してモデルに処理を任せます(ルール #21 を参照)。それが、求めている情報を得る最も簡単な方法です。

ルール 27: 観測された望ましくない動作を数値化しようとする。

チームメンバーの中には、既存の損失関数では捕捉できないシステムの特性に不満を持つ人もいます。この時点で、グリップを実数に変えるために必要なことは何でも行います。たとえば、Google Play の検索に表示される「ギャグアプリ」が多すぎると思われる場合は、評価担当者にギャグアプリの特定を依頼できます。(このケースでは、トラフィックの大部分を占めるクエリの割合が比較的少ないため、ヒューマン ラベリングが行われたデータを使用することもできます)。問題が測定可能である場合は、問題を特徴、目標、または指標として使用し始めます。一般的なルールは、「最初に測定し、2 番目に最適化する」です。

ルール #28: 短期的に同じ行動であっても、長期的な行動も同じであるとは限らないことに注意してください。

たとえば、すべての doc_id と exact_query を調べて、クエリごとにすべてのドキュメントのクリック確率を計算する新しいシステムがあるとします。その動作は、サイド バイ サイド テストと A/B テストの両方で現在のシステムとほぼ同じであることがわかったため、シンプルなのでリリースします。しかし、新しいアプリは表示されていません。その理由は、システムは、このクエリを使用した自身の履歴に基づくドキュメントのみを表示するため、新しいドキュメントを表示する必要があることを確認する方法はありません。

このようなシステムが長期的にどのように機能するかを理解する唯一の方法は、モデルのライブ時に取得したデータのみでトレーニングすることです。これはとても 難しいことです

トレーニング サービング スキュー

トレーニング サービング スキューは、トレーニング中のパフォーマンスとサービング時のパフォーマンスの差です。このスキューは、以下のような原因で発生します。

  • トレーニング パイプラインとサービング パイプラインでのデータの処理方法の相違
  • トレーニング時とサービング時の間で起こるデータの変化。
  • モデルとアルゴリズム間のフィードバック ループ

Google の本番環境 ML システムには、パフォーマンスに悪影響を与えるトレーニング サービング スキューがあります。最善の解決策は、システムやデータの変更によって気づかれないスキューが発生しないように、明示的にモニタリングすることです。

ルール 29: サービスと同様のトレーニングを確実に実施するための最善の方法は、サービング時に使用した特徴のセットを保存して、それらの特徴をログに流出させ、トレーニング時に使用できるようにすることです。

すべてのサンプルに対してこれを行うことはできないとしても、サービス提供とトレーニングの整合性を検証できるように、対象はごく一部で実施します(ルール #37 を参照)。Google でこの測定を行ったチームは、結果に驚くことがありました。YouTube のホームページでは、サービス提供時にロギング機能に切り替えられ、品質が大幅に改善され、コードの複雑さが軽減されました。また、多くのチームがお話しするとおり、インフラストラクチャを切り替えています。

ルール 30: 重要度で重み付けしたサンプリング データ。勝手に削除しないでください。

データ量が多すぎる場合、ファイル 1 ~ 12 を取得して、ファイル 13 ~ 99 を無視する傾向があります。これは正しいやり方ではありません。ユーザーに表示されていないデータはドロップすることもできますが、それ以外は重要度の重み付けが最適です。重要度の重み付けは、サンプル X を 30% の確率でサンプリングする場合、10/3 の重みを設定することを意味します。重要度の重み付けを行った場合、ルール 14 で説明したすべての調整プロパティが保持されます。

ルール 31: トレーニング時とサービング時にテーブルのデータを結合すると、テーブルのデータが変わる可能性があるので注意してください。

ドキュメント ID を、そのドキュメントの機能(コメント数やクリック数など)を含むテーブルに結合するとします。トレーニングからサービングまでの間に、テーブル内の特徴が変わることがあります。同じドキュメントに対するモデルの予測は、トレーニングとサービングで異なる場合があります。このような問題を回避する最も簡単な方法は、サービング時に特徴をログに記録することです(ルール #32 を参照)。テーブルの変更があまりない場合は、1 時間ごとまたは 1 日ごとにテーブルのスナップショットを作成して、ほぼ同じデータを取得できます。それでも問題が完全に解決するわけではありません。

ルール 32: 可能な限り、トレーニング パイプラインとサービス パイプラインの間でコードを再利用する。

バッチ処理はオンライン処理とは異なります。オンライン処理では、到着するたびにリクエストを処理する必要があります(たとえば、クエリごとに個別のルックアップを行う必要があります)。これに対して、バッチ処理ではタスクを組み合わせる(結合など)できます。サービング時にはオンライン処理を行いますが トレーニングはバッチ処理タスクですただし、コードを再利用する方法がいくつかあります。たとえば、システムに固有のオブジェクトを作成して、クエリや結合の結果が非常に人間が読み取れる方法で保存され、エラーを簡単にテストできます。すべての情報を収集したら、サービス提供またはトレーニング中に、システムに固有の人が読める形式のオブジェクトと、ML システムが想定する形式を橋渡しする共通のメソッドを実行します。これにより、トレーニング サービング スキューの原因がなくなります。当然ながら、トレーニングとサービングで 2 つの異なるプログラミング言語を使用しないでください。そのため、コードの共有はほぼ不可能になります。

ルール 33: 1 月 5 日までのデータを基にモデルを生成した場合、1 月 6 日以降のデータでそのモデルをテストする。

一般的には、モデルのトレーニング後に収集されたデータでモデルのパフォーマンスを測定します。これにより、本番環境でのシステムの動作をより適切に反映できます。1 月 5 日までのデータに基づいてモデルを作成した場合は、1 月 6 日以降のデータでモデルをテストします。新しいデータでのパフォーマンスはそれほど良くないと予想されますが、大幅に低下するわけではありません。日々さまざまな影響が生じる可能性があるため、平均クリック率やコンバージョン率は予測できない可能性がありますが、曲線の下の領域は、正の例のスコアが負の例より高くなる可能性を表しています。

ルール 34: フィルタリング用のバイナリ分類(スパムの検出や重要なメールの特定など)では、非常にクリーンなデータのためにパフォーマンスを短期的に犠牲にする。

フィルタリング タスクでは、ネガティブとしてマークされた例はユーザーに表示されません。配信時にネガティブ サンプルの 75% をブロックするフィルタがあるとします。ユーザーに表示されるインスタンスから追加のトレーニング データを引き出そうとすることがあります。たとえば、ユーザーがメールを迷惑メールとしてマークし、そのメールがフィルタによって通過できる場合、そこから情報を得ることができます。

ただし、この方法ではサンプリング バイアスが発生します。サービング中にすべてのトラフィックの 1% に「保留」のラベルを付け、除外したすべての例をユーザーに送信することで、よりクリーンなデータを収集できます。これで、フィルタによって少なくとも 74% の陰性例がブロックされています。このように取り出したサンプルは、トレーニング データになります。

フィルタがネガティブなサンプルの 95% 以上をブロックしている場合、この手法は実用的ではありません。それでも、サービス提供のパフォーマンスを測定する場合は、さらに小さなサンプル(たとえば 0.1% や 0.001%)を作成できます。パフォーマンスを正確に推定するには、1 万サンプルで十分です。

ルール 35: ランキングの問題に内在する偏りに注意する。

ランキング アルゴリズムを根本的に切り替えて異なる結果が表示されるようにすることで、アルゴリズムが今後認識するデータを効果的に変更したことになります。このような偏りが見られるため、それを考慮してモデルを設計する必要があります。アプローチは複数あります。これらのアプローチはすべて、モデルがすでに認識しているデータを優先するための方法です。

  1. 1 つのクエリに対してのみ有効になっている特徴よりも、より多くのクエリをカバーする特徴の正則化が高い。このようにして、モデルはすべてのクエリに一般化される特徴よりも、1 つまたは少数のクエリに固有の特徴を優先します。このアプローチにより、非常に一般的な結果が無関係なクエリに流出するのを防ぐことができます。これは、より一意の値を持つ特徴列をより正規化するという従来のアドバイスとは逆です。
  2. 特徴量には正の重み付けのみを許可します。したがって、優れた特徴は「未知」の機能よりも優れています。
  3. ドキュメントのみの機能は用意されていません。これは #1 の極端なバージョンです。たとえば、クエリが何であれ、人気があるアプリであっても、すべての場所には表示しないようにします。ドキュメントのみの機能はなく、シンプルです。特定の人気アプリをどこにでも表示したくない理由としては、目的のアプリすべてにアクセスできるようにすることの重要性が関係しています。たとえば、ユーザーが「バード ウォッチング アプリ」を検索した場合、「angry birds」をダウンロードする可能性がありますが、それは明らかにユーザーの意図ではありません。そのようなアプリを表示することでダウンロード率は向上する可能性がありますが、ユーザーのニーズは最終的に不満足になります。

ルール 36: 位置的な特徴を持つフィードバック ループを避ける

コンテンツの位置は、ユーザーがそのコンテンツを操作する可能性に大きく影響します。アプリを最初の位置に配置すると、クリックされる頻度が高まり、クリックされる可能性が高いことがわかります。これに対処する 1 つの方法は、位置的な機能、つまりページ上のコンテンツの位置に関する機能の追加です。位置の特徴を使用してモデルをトレーニングすると、特徴「1stposition」などの重み付けが学習されます。そのため、1stposition=true である例について、他の要素に対する重みが小さくなります。 サービング時には、インスタンスの表示順序を決定する前に候補をスコアリングするため、インスタンスに位置特徴は与えません。また、すべて同じデフォルト特徴を割り当てます。

トレーニングとテストは非対称であるため、位置の特徴はモデルの他の部分からある程度分離することが重要です。モデルは、位置的な特徴の関数と残りの特徴の関数の合計であることが理想的です。たとえば、位置的な特徴をドキュメントの特徴と交差させないでください。

ルール 37: トレーニング/サービング スキューを測定する。

一般的な意味では、スキューの原因となる原因がいくつかあります。さらに、この資料は次のような複数の要素に分けることができます。

  • トレーニング データとホールドアウト データのパフォーマンスの差。一般的に、これは常に存在するものであり、常に悪いとは限りません。
  • ホールドアウト データと「nextday」データのパフォーマンスの差。繰り返しになりますが、これは常に存在します。翌日のパフォーマンスを最大化するように正則化を調整する必要があります。ただし、ホールドアウト データと翌日データのパフォーマンスが大幅に低下している場合は、一部の特徴に時間的制約があり、モデルのパフォーマンスが低下する可能性があります。
  • 「翌日」データとライブデータのパフォーマンスの差。トレーニング データ内のサンプルとサービング時の同じサンプルにモデルを適用した場合、結果はまったく同じになります(ルール 5 を参照)。したがって、不一致はエンジニアリング エラーを示している可能性があります。

ML フェーズ III: 成長の鈍化、最適化の改善、複雑なモデル

第 2 フェーズの終了に近づいていることを示す兆候があります。まず、毎月の収益は減少し始めます。テストによっては指標が上昇する場合と低下する場合とでトレードオフが生じます。そこが興味深いところです。ゲインを達成するのが難しいため、ML はより高度なものにする必要があります。なお、このセクションには、これまでのセクションよりも多くのブルースカイ ルールがあります。多くのチームがフェーズ 1 とフェーズ 2 の ML の楽しい時代を経験していますフェーズ III に達したら、チームは独自の道筋を見つける必要があります。

ルール 38: 目標が整合していないことが問題となった場合でも、新機能に時間を無駄にしない。

測定値が横ばいになると、チームは現在の機械学習システムの目的の範囲外の問題に注目し始めます。前述のように、商品目標が既存のアルゴリズム目標に含まれていない場合は、目標または商品目標のいずれかを変更する必要があります。たとえば、クリック数、プラスワン、ダウンロードを最適化することはできますが、人間の評価者によってリリースの判断を行うこともあります。

ルール #39: 発売の決定は、長期的な商品の目標の代わりになる。

アリスさんは、インストール数を予測する際のロジスティック損失を減らす方法について考えています。特徴を追加します。ロジスティック損失は減少します。ライブテストを実施したところインストール率が 上昇したことに気づきましたしかし、リリース レビューのミーティングで、1 日のアクティブ ユーザー数が 5% 減少したと言われました。チームはモデルをリリースしないことにしました。Alice はがっかりしましたが、リリースの決定が複数の基準に依存していて、ML を使用して直接最適化できるのはその一部だけであることに気づきました。

実は、現実世界はダンジョンやドラゴンではありません。プロダクトの状態を特定する「ヒット ポイント」はありません。チームは収集した統計情報を使用して、システムの将来の状態を効果的に予測する必要があります。重視する必要があるのは、エンゲージメント、1 日のアクティブ ユーザー数(DAU)、30 DAU、収益、広告主の費用対効果です。A/B テスト自体で測定可能なこれらの指標は、長期的な目標(ユーザーの満足度、ユーザーの増加、パートナーの満足度向上、利益)を示すもので、5 年後に有用で高品質な製品と繁栄した会社を手に入れるかどうかの目安となります。

リリースに関する簡単な決定は、すべての指標が改善されるか、少なくとも悪化しない場合にしか判断できません。チームが高度な ML アルゴリズムと単純なヒューリスティックのいずれかを選択する場合、単純なヒューリスティックがこれらのすべての指標で優れた成果を得られるのであれば、ヒューリスティックを選択するべきです。さらに、可能性のあるすべての指標値を明示的にランク付けすることはできません。具体的には、次の 2 つのシナリオについて考えてみましょう。

試験運用版 1 日のアクティブ ユーザー 1 日あたりの収益
A 100 万人 400 万ドル
B 200 万回 200 万ドル

現在のシステムが A であれば、チームが B に切り替える可能性は低くなります。現在のシステムが B であれば、チームが A に切り替える可能性は低くなります。これは合理的な動作と矛盾しているように見えますが、指標の変化の予測が成功する場合とうまくいかない場合があり、どちらの変更にも大きなリスクが伴います。各指標は、チームが懸念しているリスクを表しています。

さらに、チームの最終的な懸念「今から 5 年後に私の製品はどこにあるのか」をカバーする指標はありません。

一方、個人は直接最適化できる 1 つの目標を優先する傾向があります。ほとんどの機械学習ツールはこのような環境を優先します。エンジニアは、このような環境でも新しい機能を安定して提供できます。この問題に着手するのが ML の一種である多目的学習ですたとえば、各指標に下限を持つ制約充足問題を作成し、指標の線形組み合わせを最適化できます。しかし、その場合でも、すべての指標が機械学習の目的として簡単に構築できるわけではありません。ドキュメントがクリックされたりアプリがインストールされた理由は、コンテンツが表示されたからです。しかし、ユーザーがなぜサイトを訪問したのかを把握するのは非常に困難です。サイト全体の将来の成功を予測する方法は AI による完成度で、コンピュータ ビジョンや自然言語処理と同じくらい困難です。

ルール 40: アンサンブルをシンプルにする

未加工の特徴を取り込んでコンテンツを直接ランク付けする統合モデルは、最もデバッグと理解が容易なモデルです。ただし、複数のモデル(他のモデルのスコアを組み合わせた「モデル」)のほうが効果的です。説明をシンプルにするために、各モデルは、他のモデルの入力のみを受け入れるアンサンブルか、多くの特徴を受け入れるベースモデルのいずれかにし、両方はしないようにする必要があります。個別にトレーニングされた他のモデルの上に複数のモデルを重ねると、モデルを組み合わせると不正な動作が発生することがあります。

「ベース」モデルの出力のみを入力として受け取る単純なモデルをアンサンブルに使用します。また、これらのアンサンブル モデルにプロパティを適用するとします。たとえば、ベースモデルによって生成されるスコアが増えても、アンサンブルのスコアが低下することはありません。また、受信モデルが意味的に解釈可能(調整済みなど)で、基盤となるモデルの変更によってアンサンブル モデルが混乱しないようにすることもおすすめします。また、基になる分類器の予測確率が上昇しても、アンサンブルの予測確率は低下しないように強制します

ルール 41: パフォーマンスが頭打ちになっている場合は、既存のシグナルを絞り込むのではなく、追加する情報源を定性的に探します。

ユーザーの属性情報が追加されています。これで、ドキュメント内の単語に関する情報が追加できました。テンプレートの探索と正則化の調整が完了しました。ここ数四半期で主要な指標が 1% を超える改善を達成したことはありません。次にすること。

今こそ、ユーザーが過去 1 日、1 週間、1 年間にアクセスしたドキュメントの履歴や、別のプロパティからのデータなど、根本的に異なる機能のインフラストラクチャの構築を開始します。wikidata エンティティや社内のもの(Google のナレッジグラフなど)を使用します。ディープ ラーニングを使用します。まずは期待する投資収益率を調整し、それに応じて取り組みを拡大します。他のエンジニアリング プロジェクトと同様に、新機能を追加することのメリットと、複雑さが増すコストを比較検討する必要があります。

ルール 42: 多様性、パーソナライズ、関連性が、自分が思っているほど人気と相関していると考えないでください。

一連のコンテンツの多様性には多くの意味があり、最も一般的なものの一つはコンテンツのソースの多様性です。パーソナライズとは、各ユーザーがそれぞれ独自の結果を得ることを意味します。関連性は、特定のクエリの結果が、そのクエリに対して他よりも適していることを意味します。したがって、これら 3 つの特性は通常とは異なると定義されます。

問題は、普通のものは乗り越えることが難しい傾向にあることです。

なお、クリック数、視聴時間、視聴、+1、再共有などを測定しているシステムは、コンテンツの人気度を測定していることになります。チームによっては、多様性のある個人モデルを学習しようとすることもあります。パーソナライズでは、システムがパーソナライズ(ユーザーの興味を表すいくつかの特徴)または多様化(このドキュメントの作成者やコンテンツなど、返された他のドキュメントと共通の特徴があるかどうかを示す特徴)を追加して、その特徴の重みが想定よりも小さくなる(場合によっては異なる記号も)ことを可能にする特徴を追加します。

ただし、多様性、パーソナライズ、関連性に価値がないわけではありません。 前のルールで説明したように、後処理を行うことで多様性または関連性を高めることができます。長期的な目標が増加している場合は、人気度以外でも多様性/関連性が重要であると宣言できます。その後は、後処理を継続するか、多様性または関連性に基づいて目標を直接変更できます。

ルール 43: 商品間で友人が同じであることが多い。あなたの興味 / 関心はそれほど高くない傾向があります。

Google のチームは、あるプロダクトで接続の近さを予測するモデルを採用し、別のプロダクトで適切に動作できるようにすることで、多くの注目を集めています。友だちとは自分そのものです。その一方で 複数のチームが製品のカテゴリをまたいで パーソナライズ機能で苦労しているのも事実です確かに動くはずです現時点では、そうなっていないようです。あるプロパティの元データを使用して別のプロパティの挙動を予測することが、有効な場合があります。また、ユーザーが別のプロパティの履歴を保持していることを把握している場合でも、役立ちます。たとえば、2 つのプロダクトでのユーザー アクティビティが存在する場合、それ自体が指標となります。

ML に関する多くのドキュメントが Google 内外に存在します。

謝辞

協力: David Westbrook、Peter Brandt、Samuel Ieong、Chenu Zhao、Li Wei、Michalis Potamias、Evan Rosen、Barry Rosenberg、Christine Robson、James Pine、Tal Shaked、Tushar Chandra、Mustafa Ispir、Jeremiah Harstike 氏以前のバージョンの作成に協力してくれた Kristen Lefevre、Sudha Basu、Chris Berg にも感謝します。間違いや省略、または不評な意見については、私の意見です。

付録

このドキュメントでは、Google プロダクトにさまざまな言及をしています。より詳しく説明するために、最も一般的な例について以下に簡単に説明します。

YouTube の概要

YouTube はストリーミング動画サービスです。YouTube の次のチームと YouTube ホームページのチームは、どちらも ML モデルを使用しておすすめ動画をランク付けしています。Watch Next は、現在再生中の動画の後に視聴する動画をおすすめします。一方、ホームページは、ホームページをブラウジングするユーザーに動画をおすすめします。

Google Play の概要

Google Play には、さまざまな問題を解決する多くのモデルがあります。Play の検索、Play ホームページのパーソナライズされたおすすめ、「他にもインストール済み」のアプリはすべて ML を使用しています。

Google+ の概要

Google Plus は、ユーザーに表示されている投稿の「ストリーム」における投稿のランキング、「注目の投稿」(現在非常に人気がある投稿)のランキング、知り合いのランキングなど、さまざまな状況で機械学習を使用してきました。Google Plus は 2019 年にすべての個人アカウントを廃止し、2020 年 7 月 6 日にビジネス アカウント向けの Google Currents に置き換えられました。