このページは Cloud Translation API によって翻訳されました。

機械学習のルール:

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

マーティンジンケビッチ

このドキュメントは、機械学習の基本知識があるユーザーが、Google の機械学習のベストプラクティスを活用できるようにすることを目的としています。Google C++ スタイルガイドや一般的なプログラミングの人気ガイドと同様に、機械学習のスタイルになっています。すでに機械学習のクラスを受講している場合や、機械学習モデルを構築または開発している場合は、このドキュメントを読むために必要な背景知識があります。

Martin Zinkevich は、機械学習に関するよく知られた 10 のルールを紹介します。43 のルールについて詳しく見ていきましょう。

用語

効果的な機械学習について説明する際に、次の用語が繰り返し出てきます。

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

概要

優れたプロダクトを作成するには:

直面する問題のほとんどはエンジニアリングの問題です。優れた機械学習エキスパートのすべてのリソースができたとしても、得られる利益のほとんどは優れた機械学習アルゴリズムからでなく、優れた機能から得られます。基本的なアプローチは次のとおりです。

パイプラインがエンドツーエンドで安定していることを確認します。
まずは妥当な目標を設定しましょう。
常識的な機能をシンプルな方法で追加します。
パイプラインが安定していることを確認します。

このアプローチは長期間にわたって効果を発揮します。この手法から逸脱するのは、さらに先に進めるための簡単なコツがなくなったときだけです。複雑さが増すと、今後のリリースが遅くなります。

簡単なコツを尽くしたら、最先端の機械学習はきっとあなたの未来につながるはずです。フェーズ III 機械学習プロジェクトのセクションをご覧ください。

このドキュメントは次のように構成されています。

前半では、機械学習システムを構築するのに適したタイミングであるかどうかを確認できます。
後半では、最初のパイプラインをデプロイします。
パート 3 では、パイプラインに新機能を追加すると同時に、モデルの評価とトレーニング / サービングスキューを行う方法を起動し、反復処理を行います。
最後の部分では、プラトーに達したときの作業について説明します。
その後、このドキュメントで一般的に使用されるシステムの背景情報を含む関連作業と付録の一覧を示します。

機械学習の前

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

機械学習には優れた機能がありますが、これにはデータが必要です。理論的には、別の問題からデータを取得し、新しい製品のモデルを微調整できますが、これは基本的なヒューリスティックより低い結果をもたらす可能性があります。機械学習で 100% のブーストが得られると思われる場合は、ヒューリスティックによりその半分を実現できます。

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

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

機械学習システムの機能を形式化する前に、現在のシステムで可能な限り追跡します。その理由は次のとおりです。

システムのユーザーから早く許可を得る方が簡単です。
今後、懸念される可能性がある場合は、今すぐ履歴データを取得することをおすすめします。
指標のインストルメンテーションを念頭に置いてシステムを設計すると、将来より良いものが得られます。具体的には、指標を計測するためのログ内の文字列を探し出さないようにする必要があります。
変更点と変更されない点を確認できます。たとえば、1 日のアクティブユーザーを直接最適化するとします。ただし、システムを早期に変更した際、ユーザーエクスペリエンスが大幅に変化しても、この指標はそれほど変わりません。

Google Plus チームは、配信あたりの読み取り、共有、共有、読み取り / コメント/読み取り、ユーザーごとのコメント、ユーザーごとの共有などを測定して、配信時に投稿の品質を評価しています。また、ユーザーをバケットにグループ化し、テストごとに統計情報を集計できるテストフレームワークが重要です。ルール #12 をご覧ください。

指標の収集をより自由に行うことで、システムの全体像を把握できます。問題が生じた場合指標を追加して追跡しましょう。前回のリリースでは、数量に変化がありましたか？指標を追加して追跡しましょう。

ルール 3: 複雑なヒューリスティックよりも機械学習を選択する。

シンプルなヒューリスティックにより、商品を目立たせることができます。複雑なヒューリスティックは維持できません。データの取得や達成しようとしている内容に関する基本的なアイデアを把握したら、機械学習に進みます。ほとんどのソフトウェアエンジニアリングタスクと同様に、ヒューリスティックモデルか機械学習モデルかにかかわらず、アプローチを常に更新する必要があります。これにより、機械学習モデルの更新と保守が簡単になります（ルール #16 を参照）。

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

最初のパイプラインのシステムインフラストラクチャに集中する。これから行うすべての想像上の機械学習について考えるのは楽しいですが、最初にパイプラインを信頼しないと、何が起こっているのかを理解するのが難しくなります。

ルール 4: 最初のモデルをシンプルにして、インフラストラクチャを正しく設定する。

最初のモデルは商品の大幅なブーストとなるため、派手なものにする必要はありません。しかし、インフラストラクチャの問題は想定よりも多く発生します。優れた新しい機械学習システムを使用する前に、次のことを決める必要があります。

学習アルゴリズムの例を取得する方法。
システムにとっての「良い」と「悪い」の意味の最初のカット。
モデルをアプリケーションに統合する方法モデルをライブで実行するか、オフラインの場合の例でモデルを事前計算し、結果をテーブルに格納できます。たとえば、ウェブページを事前に分類して結果をテーブルに保存し、チャットメッセージをライブで分類できます。

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

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

この 3 つの処理を確実に行うシステムを用意したら、ほとんどの作業は完了です。シンプルなモデルでは、ベースライン指標とベースライン動作が提供され、より複雑なモデルをテストできます。一部のチームは「ニュートラル」の初回リリースを目指しています。これは、気が散らないように、機械学習のゲインを明示的に優先度を下げる最初のリリースです。

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

インフラストラクチャがテスト可能で、システムの学習部分がカプセル化されており、周囲すべてをテストできることを確認します。詳細は以下のとおりです。

アルゴリズムへのデータの取得をテストします。入力対象の特徴列にデータが入力されていることを確認します。プライバシーが許す場合、トレーニングアルゴリズムへの入力を手動で調べます。可能であれば、他の場所で処理された同じデータの統計と比較して、パイプラインの統計情報を確認します。
トレーニングアルゴリズムからのモデルの取得をテストします。トレーニング環境のモデルが、サービス環境のモデルと同じスコアを提供することを確認します（ルール #37 を参照）。

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

ルール 6: パイプラインのコピー時にデータが削除されないように注意する。

多くの場合、既存のパイプライン（Cargo cult プログラミング）をコピーしてパイプラインを作成し、古いパイプラインは新しいパイプラインに必要なデータを削除します。たとえば、Google Plus の「ホット」というパイプラインでは、古い投稿が破棄されます（新しい投稿がランク付けされるため）。このパイプラインは、Google Plus ストリームで使用するためにコピーされました。古い投稿は引き続き有効ですが、パイプラインは古い投稿を破棄していました。もう一つの一般的なパターンは、ユーザーが認識したデータのみをログに記録することです。したがって、ネガティブサンプルがすべて破棄されているため、特定の投稿がユーザーに表示されない理由をモデル化する場合、このデータは役に立ちません。Play でも同様の問題がありました。Play アプリホームの開発中に新しいパイプラインが作成されました。このパイプラインには、各サンプルの提供元を明確化する機能のない、Play ゲームのランディングページからのサンプルも含まれています。

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

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

ヒューリスティックを使用した前処理。この機能が非常に優れている場合は、このオプションを使用できます。たとえば、迷惑メールフィルタで送信者がすでに拒否リストに登録されている場合、「拒否リスト」が何を意味するのか、もう一度学習しようとしないでください。メールをブロックする。この方法により、バイナリ分類タスクで最適な結果が得られます。
対象物を作成します。ヒューリスティックから特徴を直接作成するのはすばらしいことです。たとえば、ヒューリスティックを使用してクエリ結果の関連性スコアを計算する場合は、そのスコアを特徴の値として含めることができます。その後、機械学習手法を使用して値をマッサージします（たとえば、値を有限の離散値のセットに変換する、または他の特徴と結合するなど）。ただし、最初にヒューリスティックによって生成された未加工の値を使用します。
ヒューリスティックの未加工の入力をマイニングする。アプリのインストール数、テキスト内の文字数、曜日を組み合わせたヒューリスティックがある場合は、これらの要素を分離して、学習への入力を別個に行うことを検討してください。アンサンブルに適用される手法は、ここで適用されます（ルール #40 を参照）。
ラベルを変更します。これは、ヒューリスティックが現在ラベルに含まれていない情報をキャプチャしていると感じた場合に選択します。たとえば、ダウンロード回数を最大にするために高品質のコンテンツが必要な場合、解決策としては、ラベルにアプリの平均星の数を掛ける方法があります。余裕はたくさんあります。「最初の目標」をご覧ください。

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

モニタリング

一般に、アラートを実用的にする、ダッシュボードページを用意するなど、適切なアラートの環境を整えます。

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

1 日前のモデルを使用した場合、パフォーマンスはどのくらい低下しますか。1 週間前？今四半期ですか？この情報は、モニタリングの優先度を把握するのに役立ちます。モデルが 1 日間更新されない場合、プロダクトの品質が著しく低下する場合は、エンジニアに継続的に確認してもらうのが理にかなっています。ほとんどの広告配信システムでは、新しい広告を毎日処理しており、毎日更新する必要があります。たとえば、Google Play 検索の ML モデルが更新されていない場合、1 か月以内に悪影響が生じる可能性があります。Google Plus の「ホット」のモデルには、投稿 ID がないため、これらのモデルを低頻度でエクスポートできます。投稿 ID を使用しているその他のモデルは、はるかに頻繁に更新されます。また、鮮度は時間の経過とともに変化する可能性があります。特に特徴列がモデルに対して追加または削除された場合に注意してください。

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

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

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

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

これは、他の種類のシステムよりも機械学習システムで多く発生する問題です。結合されている特定のテーブルが更新されなくなったとします。機械学習システムを調整し、その動作はある程度良くなり、徐々に減衰します。場合によっては、テーブルが数か月前に更新され、この四半期の他のリリースよりもパフォーマンスが改善されます。特徴のカバレッジは、実装の変更によって変化する可能性があります。たとえば、特徴列にサンプルが 90% 入力され、突然サンプルの 60% に落ちることがあります。Play ではテーブルが 6 か月間停滞し、テーブルだけを更新するとインストール率が 2% 向上しました。データの統計情報を追跡し、必要に応じてデータを手動で検査すれば、この種の障害を減らすことができます。

ルール 11: 特徴量列の所有者とドキュメントを提供する。

システムが大きく、多くの特徴列がある場合は、各特徴列を作成または維持しているのがどこかを把握します。特徴量列を理解している人が離れることになった場合は、誰かに情報があることを確かめてください。多くの特徴列には説明的な名前がありますが、特徴の概要、発生元、期待される動作の詳しい説明を用意することをおすすめします。

最初の目標

関心のあるシステムに関する指標や測定値は多数ありますが、機械学習アルゴリズムでは多くの場合、単一の目標（アルゴリズムが最適化の試行中の数値）が必要になります。ここでは、目標と指標を区別します。指標は、システムによって報告される任意の数値です。これらは重要とは限りません。ルール #2 もご覧ください。

ルール 12: 直接最適化する目標を過度に決めないようにする。

お金を稼ぎ、ユーザーを満足させ、世界をより良い場所にすること。関心のある指標がたくさんあり、すべて測定する必要があります（ルール #2 を参照）。しかし、機械学習プロセスの早い段階で、直接最適化していないものも含め、すべてが上がっていることに気づきます。たとえば、サイトのクリック数と滞在時間が重要な場合、クリック数を最適化すると、費やす時間が増加する可能性が高くなります。

したがって、すべての指標を簡単に増やせる場合は、さまざまな指標のバランスをあまり気にする必要はありません。ただし、このルールはあまり厳格にはしないでください。目的をシステムの最終的な健全性と混同しないでください（ルール #39 を参照）。ただし、直接最適化した指標を増やすことを開始しても、リリースしない場合は、客観的なリビジョンが必要になることがあります。

ルール 13: 最初の目標として、シンプルでオブザーバブルな、アトリビューション可能な指標を選択する。

多くの場合、実際の目標が何であるかはわかりません。しかし、そうしていると、古いシステムと新しい ML システムのデータと並べて分析に目を向けたときに、目標を微調整したいことに気付きます。さらに、さまざまなチームメンバーが真の目標に同意できない場合も少なくありません。ML の目標は、測定が容易なもので、「真」の目的を表すものでなければなりません。 実際、「true」の目標はあまり存在しません（Rule#39 を参照）。したがって、単純な ML の目標でトレーニングを行い、上部に「ポリシーレイヤ」を配置して、追加のロジック（できれば非常にシンプルなロジック）を追加して最終的なランキングを行えるようにすることを検討してください。

モデル化の最も簡単な方法は、システムの動作に起因する直接観察するユーザー行動です。

このランク付けされたリンクはクリックされましたか？
ランク付けされたオブジェクトはダウンロード済みですか？
このランク付けされたオブジェクトは、転送されたか、返信されたか、またはメールで送信されましたか？
ランク付けされたオブジェクトは評価済みですか？
見せかけのオブジェクトは、スパム/ポルノ/侮辱的なものとしてマークされていましたか？

最初に間接的な影響をモデル化することは避けてください。

次の日にユーザーは訪問しましたか？
ユーザーがサイトにどれだけの期間アクセスしたか
1 日のアクティブユーザーは何人でしたか？

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

最後に、機械学習で状況把握を試みないようにします。

お客様はプロダクトを満足していますか？
お客様は満足されていますか？
この製品はユーザーの全般的な健康状態を改善していますか？
会社全体の健康にはどのような影響がありますか。

これらはすべて重要ですが、測定は非常に困難です。代わりにプロキシを使用してください。ユーザーの満足度が高い場合は、サイトに長く留まります。ユーザーが満足した場合は、明日再度アクセスします。健康と企業の健全性が関係する限り、機械学習の目標を販売している製品の性質とビジネスプランに関連付けるには、人間による判断が必要です。

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

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

たとえば、線形回帰、ロジスティック回帰、ポアソン回帰では、データのサブセットが、平均予測期待値を平均ラベル（1 モーメント補正済みまたは単に調整値）に等しい値になります。これは、正則化がなく、アルゴリズムが収束し、一般にほぼ真実であると仮定します。例ごとに 1 または 0 である特徴がある場合、その特徴が 1 である 3 つのサンプルのセットが調整されます。また、サンプルごとに 1 である特徴がある場合、すべてのサンプルのセットが調整されます。

単純なモデルでは、フィードバックループの処理が簡単になります（ルール #36 を参照）。多くの場合、こうした確率的な予測を使用して決定を下します。たとえば、投稿を予想値（クリック / ダウンロードなど）を減らすようにランク付けします。使用するモデルを選択するときは、そのモデルが与えられたデータの可能性よりも、この決定が重要になります（ルール #27 を参照）。

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

品質ランキングは優れた技術ですが、スパムのフィルタリングは重要です。高品質の投稿を判断するためのシグナルは、システムを利用するユーザーには明白になります。こうした特性を生むように投稿を調整します。したがって、品質ランキングでは、誠意を持って投稿されたコンテンツをランク付けすることに焦点を絞る必要があります。迷惑メールのランク付けが高い場合は、品質ランキングの学習者に割引を適用しないでください。同様に、「racy」のコンテンツは品質ランキングとは別に処理する必要があります。迷惑メールのフィルタリングはこれとは異なります。生成する必要がある特徴量は、絶えず変化することを想定する必要があります。多くの場合、システムには明らかなルールがあります（投稿に 3 つ以上のスパム投票がある場合、それを取得しないでください）。学習したモデルは毎日更新する必要がありますが、そうでない場合は更新する必要があります。コンテンツ作成者の評判は大きな役割を果たします。

この 2 つのシステムの出力は、ある程度統合する必要があります。検索結果での迷惑メールのフィルタリングは、メールメッセージでのスパムのフィルタリングよりも積極的なものである必要があります。これは、正則化がなく、アルゴリズムが収束していることを前提としています。これは一般にほぼ当てはまります。また、品質分類器のトレーニングデータからスパムを削除するのが一般的な方法です。

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

機械学習システムのライフサイクルの最初のフェーズでは、トレーニングデータを学習システムに取り込んで、関心のある指標を取得し、サービス提供インフラストラクチャを作成する必要があります。単体テストとシステムテストをインストルメント化してエンドツーエンドのシステムを使用する準備が整うと、フェーズ II が開始されます。

2 番目のフェーズには簡単に達成できる目標がたくさんあります。システムに取り込まれる可能性のある明らかな機能にはさまざまなものがあります。そのため、機械学習の 2 番目のフェーズでは、できるだけ多くの特徴を取り込んで、直感的に組み合わせます。このフェーズでは、すべての指標がまだ増加している必要があります。たくさんのリリースがあるので、本当に優れた学習システムを作り出すために必要なデータを結合できるエンジニアをたくさん集める絶好の機会です。

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

ここで取り組むモデルが、リリースする最後のモデルになることも、モデルのリリースをやめる可能性もあります。したがって、このリリースで追加する複雑さによって、今後の起動が遅くなるかどうかを検討してください。多くのチームが数年ごとに四半期ごとにモデルをリリースしています。新しいモデルをリリースする 3 つの基本的な理由:

新しい機能を思いつくところです。
正則化を調整して、古い機能を新しい方法で組み合わせています。
目標を調整する

いずれにしても、モデルに愛を持たせるのは良いことです。この例に与えられたデータフィードを調べると、新しいシグナルだけでなく、古い壊れたシグナルを見つけることもできます。モデルを構築する際に、特徴量の追加または削除が簡単であることを考慮してください。パイプラインの新しいコピーを簡単に作成し、その正確性を検証してください。2 つまたは 3 つのコピーを並行して実行できるかどうかを考えてみましょう。最後に、機能 16 / 35 で、このバージョンのパイプラインに組み込まれるかどうか心配する必要はありません。次の四半期に贈呈します。

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

物議を醸すかもしれませんが、多くの落とし穴を避けることができます。まず、学習済み特徴とは何かを説明します。学習済み特徴は、外部システム（教師なしクラスタリングシステムなど）または学習者自体（因数分解モデルやディープラーニングなど）によって生成された特徴です。どちらも有用ですが、多くの問題があるため、最初のモデルにしないでください。

外部システムを使用して特徴を作成する場合は、外部システムに固有の目的があることに注意してください。外部システムの目標は、現在の目標とわずかに相関している可能性があります。外部システムのスナップショットを取得すると、古くなることがあります。外部システムから機能を更新すると、意味が変わる可能性があります。外部システムを使用して機能を提供する場合は、このアプローチに多くの注意が必要です。

因数分解モデルとディープモデルの主な問題は、非凸型です。したがって、最適なソリューションを近似したり特定したりできる保証はありません。また、各イテレーションで求められる極小値が異なる場合があります。この変動により、システムに対する変更の影響が意味のあるものか、ランダムなものかを判断するのが難しくなります。深い特徴のないモデルを作成することで、優れたベースラインパフォーマンスを実現できます。このベースラインが達成されたら、より難解な手法を試すことができます。

ルール 18: コンテキストを一般化するコンテンツの特徴を使う。

多くの場合、機械学習システムは全体像のごく一部に過ぎません。たとえば、「注目の話題」に使用される投稿を想像すると、多くのユーザーはその投稿が「おすすめ」に表示される前に、プラスワン、再共有、コメントを追加することになります。こうした統計情報を学習者に提供すると、最適化するコンテキストでデータがない新しい投稿をプロモートできます。 YouTube Watch Next では、YouTube 検索からの視聴数または共視聴（ある動画が視聴された後に再生された回数）を使用できます。明示的なユーザー評価を使用することもできます。最後に、ラベルとして使用しているユーザーアクションがある場合、そのアクションを異なるコンテキストでドキュメントで確認できます。これらすべての機能により、新しいコンテンツをコンテキストに取り入れることができます。ここで注意すべきは、パーソナライズとは関係ありません。まずこのコンテキストでコンテンツが気に入ったかどうかを確認し、その後、誰がそれを高く評価したか、または低くしたかを把握します。

ルール 19: できるだけ具体的な機能を使用する。

データが大量にある場合は、少数の複雑な特徴よりも、何百万もの単純な特徴を学ぶ方が簡単です。取得および正規化されたクエリの識別子から識別子が一般化される可能性はあまりありませんが、ヘッドクエリではラベルにランク付けが行われます。したがって、各特徴量がデータのごく一部にのみ適用される場合、全体的なカバレッジが 90% を超えることを恐れないでください。正則化を使用して、あまり例がない特徴を排除できます。

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

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

離散化は、連続的な特徴を取り、それから離散的な特徴量を多数作成することを意味します。年齢のような継続的な特徴を考えてみましょう。年齢が 18 歳未満であれば 1 で、18 歳から 35 歳の間の場合は 1 という特徴量を作成できます。これらのヒストグラムの境界を誤って考えないでください。基本的な分位点がほとんどの影響を及ぼします。

十字は 2 つ以上の特徴列を結合します。TensorFlow の用語では、特徴量列は同種の特徴のセット（例: {male, female}、{US, Canada, Mexico} など）です。クロスは、{男性, 女性} × {米国,カナダ, メキシコ} などの特徴を含む新しい特徴列です。この新しい特徴列には、特徴（男性、カナダ）が含まれます。TensorFlow を使用していて、このクロスを作成するように TensorFlow に指示した場合、このカナダの（男性）特徴は、カナダの男性を表すサンプルに含まれます。なお、3 つ、4 つ、または複数の基本特徴量列にまたがるモデルを学ぶには、膨大な量のデータが必要になります。

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

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

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

モデルの適切な複雑さに関する興味深い統計的理論の結果はありますが、このルールは基本的に知っておくべきものです。これまでは、1,000 の例から何かを学ぶことができるか、あるいは 100 万を超える例が必要で、ある特定の学習方法に固執するため、人々にその疑念を抱かせるような会話をしてきました。重要なのは、データのサイズに合わせて学習をスケーリングすることです。

検索ランキングシステムで作業しており、ドキュメントとクエリには何百万もの異なる単語があり、ラベル付きサンプルが 1,000 個ある場合は、ドキュメント特徴とクエリ特徴の間のドットドット TF-IDF と、その他の高度な人間工学的特徴量を使用する必要があります。1, 000 サンプル、十数個の特徴があります。
100 万サンプルがある場合は、正則化と特徴選択を使用して、ドキュメントとクエリの特徴列を交差させます。何百万もの特徴が得られますが、正則化を使用すると、少なくなります。サンプル数は 1, 000 万、特徴の数は数十万です。
数十億または数千億の例がある場合、特徴の選択と正則化を使用して、特徴列をドキュメントトークンやクエリトークンとクロスすることができます。10 億個のサンプルがあり、1, 000 万個の特徴があります。統計的学習の理論には厳密な境界はほとんどありませんが、出発点については大まかなガイダンスとなります。

最後に、ルール #28 を使用して、使用する機能を決定します。

ルール 22: 使用していない機能をクリーンアップする。

未使用の機能には、技術的負債が生じます。使用していない機能が他の機能と組み合わせると機能しない場合は、インフラストラクチャから削除してください。最も有望な機能を可能な限り早く試行できるように、インフラストラクチャをクリーンに維持する必要があります。必要に応じて、いつでも対象物を再度追加できます。

どの機能を追加または保存するかを検討する際は、カバレッジに留意してください。この機能でカバーされるサンプルの数はいくつですか。たとえば、なんらかのパーソナライズ機能があるものの、パーソナライズ機能を持っているユーザーが 8% しかない場合、その効果はそれほど発揮されません。

同時に、一部の機能は重量を上回る可能性があります。たとえば、1% のデータのみを含む特徴量があり、その特徴量を持つサンプルの 90% が陽性である場合は、追加するのが非常に有用です。

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

機械学習の第 3 段階に進む前に、機械学習のクラスで教えていないこと、つまり、既存のモデルを確認して改善する方法に焦点を合わせることが重要です。これは科学というより芸術という意味ですが、避けるべきアンチパターンはいくつかあります。

ルール #23: 通常のエンドユーザーではない。

おそらくこれは、チームが滞りなく取り組むための最も簡単な方法でしょう。fishfood（チーム内のプロトタイプを使用）と dogfood（社内でプロトタイプを使用）には多くのメリットがありますが、従業員はパフォーマンスが正しいか確認する必要があります。明らかに悪い変更を使用することはおすすめできませんが、本番環境の近くで合理的に見える変更に対しては、クラウドソーシングのプラットフォームで質問に回答するか、実際のユーザーによるライブテストを行うことによって、さらにテストを行う必要があります。

これには 2 つの理由があります。1 つ目は、コードが近すぎることです。投稿の特定の側面を探している場合や、単に感情的に関与しすぎている（確認バイアスなど）可能性があります。2 つ目は貴重な時間です1 時間の会議に 9 人のエンジニアが参加した場合の費用を考えてみましょう。また、クラウドソーシングのプラットフォームで購入する契約スタッフの人数を考えてみてください。

本当にユーザーフィードバックを得るには、ユーザーエクスペリエンスの手法を使用してください。プロセスの早い段階でユーザーペルソナ（Bill Buxton の Sketching User Experiences を参照）を作成し、ユーザビリティテストを実施します（説明は Steve Krug の Don’t Make Me Think にあります）。ユーザーペルソナには、架空のユーザーを作成します。たとえば、チームがすべて男性である場合、35 歳の女性ユーザーペルソナ（ユーザー機能も備えた）を設計し、25 ～ 40 歳の男性の結果を 10 件ではなく 10 個ではなく結果を出すと効果的です。ユーザビリティテストで実際の人を自分のサイト（ローカルまたはリモート）に引き込むことで、新鮮な視点を得られます。

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

ユーザーが新しいモデルを確認する前に行う測定は、簡単で、場合によっては非常に便利なものでもあります。測定の結果は、新しいモデルが本番環境とどの程度異なるかを判断するのに役立ちます。たとえば、ランキングの問題がある場合は、システム全体でクエリのサンプルに対して両方のモデルを実行し、結果の対称サイズのサイズ（ランキング位置によって重み付け）を確認します。差異が非常に小さい場合は、テストを実行しなくても、ほとんど変化がないことがわかります。差が非常に大きい場合は、変更が正常であることを確認する必要があります。対称差が大きいクエリを調べると、変更がどのような変化なのかを定性的に理解するのに役立ちます。ただし、システムが安定していることを確認してください。モデルとの比較において、対称差が小さい（できればゼロ）ようにする。

ルール 25: モデルの選択時には、予測能力よりも実用的パフォーマンスが優れている

このモデルでは、クリック率の予測を試みることがあります。結局のところ重要なのは、その予測をどうするかです。これを使用してドキュメントをランク付けする場合は、予測自体よりも最終的なランキングの品質が重要です。ドキュメントがスパムである確率を予測し、ブロックする対象を切り取る場合は、許可される対象の精度がより重要になります。ほとんどの場合、この 2 つの点について合意する必要があります。同意しない場合、通常は利益はわずかです。したがって、ログ損失を改善するが、システムのパフォーマンスを低下させる変更がある場合は、別の機能を探します。これが頻繁に発生するようになったら、モデルの目的を見直します。

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

モデルが「間違っている」というトレーニングサンプルがあるとします。分類タスクでは、このエラーが偽陽性または偽陰性になることがあります。ランキングタスクでは、陽性が負よりも低くランク付けされたペアになる場合があります。最も重要な点は、これは問題が発生したことを示している機械学習システムで、機会があれば修正したいと考えている点です。モデルにエラーを修正できる特徴を指定すると、モデルはその特徴を使用しようとします。

一方、システムが誤りとみなさない例に基づいて特徴を作成しようとしても、その特徴は無視されます。たとえば、ユーザーが Play アプリ検索で「無料ゲーム」を検索するとします。上位の結果の 1 つが関連性の低い GAG アプリであると仮定します。そこで、「gag アプリ」用の特徴を作成します。ただし、インストール数を最大化し、無料のゲームを検索したときに gag アプリをインストールした場合、「gag apps」機能の効果が期待できません。

モデルに誤りがあった例を把握したら、現在の特徴セット外の傾向を探します。たとえば、システムが、より長い投稿の順位を下げていると思われる場合は、投稿の長さを追加します。追加する機能について詳細にしすぎないようにしてください。投稿の長さを長くする場合は、時間をかけて評価するつもりでも、機能を 10 数個追加すれば、モデルにどう対応するかを判断できます（ルール #21 を参照）。これが最も簡単な方法です。

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

チームのメンバーの中には、既存の損失関数では把握できない、好みにないシステムの特性に不満を抱く人もいます。この段階では、障害をしっかりと数値に変える必要があります。たとえば、Play 検索で表示される「gag アプリ」が多すぎると思われる場合、評価担当者は gag アプリを特定できます。（この場合、トラフィックの大部分を占めるクエリが比較的少ないため、ヒューマンラベリングされたデータを使用できる可能性があります）。問題が測定可能な場合、特徴、目標、指標として利用できます。一般的なルールは「まず測定し、次に最適化」です。

ルール 28: 短期的な同一の行動が長期的な長期的な行動を意味するものではありません。

すべてのシステムで、すべての doc_id と exact_query を確認し、クエリごとにすべてのドキュメントがクリックされる確率を計算するとします。並べてテストと A/B テストの両方で現在のシステムの動作とほぼ同じであることがわかったので、シンプルであることを前提にリリースしました。しかし、新しいアプリが表示されていないことに気づきました。なぜでしょうか。システムは、そのクエリの履歴に基づいてのみドキュメントを表示するため、新しいドキュメントが表示されることを知る方法がありません。

システムが長期間どのように機能するかを理解する唯一の方法は、モデルが稼働しているときに取得したデータのみを使用してトレーニングすることです。これは非常に難しいことです。

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

トレーニングサービングスキューは、トレーニング中のパフォーマンスとサービング中のパフォーマンスの差です。この偏りは、以下が原因で発生する可能性があります。

トレーニングパイプラインとサービス提供パイプラインでのデータの処理方法が異なる。
トレーニング時とサービング時の間のデータの変化。
モデルとアルゴリズム間のフィードバックループ。

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

ルール 29: サービング時と同様にトレーニングするには、特徴量をサービング時に使用するセットを保存してから、それらの特徴をログにパイプしてトレーニング時に使用するのが最善の方法です。

すべての例でこの操作ができないとしても、小さな割合でこれを行うようにしてください。これにより、サービングとトレーニングの一貫性を確認できます（ルール #37 を参照）。Google でこうした測定を行ったチームは、結果に驚くことがありました。YouTube のホームページは、サービング時にロギング機能に切り替え、品質が大幅に改善され、コードの複雑さが軽減されました。多くのチームでは、お話しているようにインフラストラクチャを切り替えています。

ルール 30: 重要性に基づき重み付けしたサンプリングデータを任意にドロップしない

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

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

ドキュメント ID を、それらのドキュメントの機能（コメントやクリック数など）を含むテーブルと結合するとします。トレーニング時とサービング時とで、テーブル内の特徴が変わる可能性があります。その場合、同じドキュメントに対するモデルの予測はトレーニングと提供の間で異なる可能性があります。この種の問題を回避する最も簡単な方法は、サービング時に特徴をロギングすることです（ルール #32 を参照）。テーブルの変更が遅いだけの場合は、テーブルを 1 時間ごとまたは 1 日ごとにスナップショットして、適度に近いデータを取得することもできます。それでも完全には問題が解決されないことに注意してください。

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

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

ルール #33: 1 月 5 日までのデータに基づいてモデルを作成する場合は、1 月 6 日以降のデータに基づいてモデルをテストする。

一般的に、モデルがトレーニングされたデータの後に収集されたデータのパフォーマンスを測定します。これは、システムが本番環境で行う処理をより適切に反映するためです。1 月 5 日までのデータに基づいてモデルを生成する場合は、1 月 6 日のデータに対してテストします。新しいデータではパフォーマンスはそれほど良くないと思われるが、根本的に悪くなることはありません。1 日の平均効果やコンバージョン率は予測できないため、曲線の下の領域は、陽性サンプルに陰性サンプルよりも高いスコアを与える可能性を表しています。

ルール #34: フィルタリング（迷惑メールの検出、興味深いメールの確認など）のバイナリ分類で、クリーンなデータを得るためにパフォーマンスを短期的に犠牲にする。

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

ただし、この手法ではサンプリングバイアスが発生します。サービス提供時にすべてのトラフィックの 1% に「保持」というラベルを付けた場合は、よりクリーンなデータを収集し、保留したすべてのサンプルをユーザーに送信できます。これで、除外サンプルの 74% 以上がフィルタでブロックされます。先ほど説明した例がトレーニングデータになります。

フィルタによってネガティブサンプルの 95% 以上をブロックしている場合、このアプローチは実行可能性が低くなります。それでも、サービングパフォーマンスを測定する場合は、さらに小さなサンプル（0.1% や 0.001% など）を作成できます。パフォーマンスを非常に正確に推定するには、10,000 のサンプルで十分です。

ルール 35: ランキングの問題に固有の歪みに注意する。

ランキングアルゴリズムを根本的に変えて、さまざまな結果を表示すると、アルゴリズムが将来受け取るデータを効果的に変更できます。このような歪みが生じるため、モデルを中心に設計する必要があります。さまざまなアプローチがあります。これらの方法は、モデルがすでに認識しているデータを優先する方法です。

1 つのクエリでのみオンになっている特徴よりも、多くのクエリに対応する特徴の正則化が高い。これにより、すべてのクエリに一般化する特徴よりも、1 つまたは少数のクエリに固有の特徴が優先されます。このアプローチにより、非常に人気のある結果が無関係なクエリに漏洩するのを防ぐことができます。これは、一意の値を持つ特徴列でより正則化されるという、一般的なアドバイスとは逆です。
特徴に正の重み付けのみを許可する。したがって、「不明な」特徴よりも良い特徴のほうが適しています。
ドキュメント専用の機能がない。これは #1 の極端なバージョンです。たとえば、あるアプリが人気のダウンロードであっても、そのクエリの内容にかかわらず表示したくない場合があります。ドキュメント専用機能がないため、シンプルです。特定の人気アプリをあらゆる場所で表示したくない場合は、目的のアプリがすべてアクセス可能であるようにする重要性があります。たとえば、ユーザーが「バードウォッチングアプリ」を検索した場合、「アングリーバード」をダウンロードしたものの、それが意図は意図と異なることもあります。そのようなアプリを表示することで、ダウンロード率が向上する可能性がありますが、最終的にはユーザーのニーズを満たさなくなります。

ルール 36: 位置特徴を含むフィードバックループを避ける。

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

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

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

最も広範囲にゆがむ原因はいくつかあります。さらに、次のようにいくつかの部分に分けることができます。

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

ML フェーズ III: 低速な成長、最適化の絞り込み、複雑なモデル

2 つ目のフェーズがもう少しで完了していることを示している可能性があります。まず、毎月の収益が減少し始めます。指標間にはトレードオフが生じます。指標が上がった場合と下がった場合があることがわかります。ここからが面白いところです。利益を実現するのが難しいため、機械学習はより洗練する必要があります。注意: このセクションには、以前のセクションよりも青空のルールがあります。多くのチームがフェーズ 1 とフェーズ 2 の機械学習の幸せな時代を経験しています。フェーズ 3 に到達すると、チームは独自のパスを見つける必要があります。

ルール 38: 目標に適合しない目標があっても、新機能に時間を浪費しない。

測定値の向上に伴い、チームが現在の機械学習システムの目標の範囲外の問題を検討するようになります。前述のように、商品の目標が既存のアルゴリズム目標でカバーされていない場合は、目標や商品目標を変更する必要があります。たとえば、クリック数、プラスワン、ダウンロードのいずれかを最適化しても、評価者による判断に基づいてリリースを決定できます。

ルール 39: 長期的な意思決定は、リリースの判断材料となる。

アリスさんは、インストールを予測する際のロジスティック損失を減らす方法を考えています。特徴を追加します。物流の損失が減少する。公開テストを実施すると、インストール率が上昇します。しかし、リリースレビューの会議にアクセスすると、1 日あたりのアクティブユーザー数が 5% 減少すると指摘されています。チームはモデルをリリースしないことに決めました。アリスはがっかりしましたが、リリースの決定が複数の基準に依存することに気が付きましたが、ML を使用して直接最適化できるものは一部しかありません。

実世界はダンジョンやドラゴンではありません。商品の健全性を識別する「ヒットポイント」はありません。チームは、収集した統計情報を使用して、将来のシステムの性能を効率的に予測する必要があります。エンゲージメント、1 日のアクティブユーザー（DAU）、30 DAU、収益、広告主の費用対効果を重視する必要があります。A/B テスト自体で測定できるこれらの指標は、ユーザー満足度、ユーザー数の増加、パートナー満足度、利益の向上などの長期的な目標を表すものです。これらが有用で高品質なプロダクトであり、5 年先の繁栄企業でもあるという観点で、プロキシを検討することもできます。

リリースの判断は、すべての指標が改善された（または悪化しなかった）場合にのみ行います。チームが高度な機械学習アルゴリズムと単純なヒューリスティックを選択できる場合、単純なヒューリスティックがすべての指標でうまく機能する場合は、ヒューリスティックを選択すべきです。また、可能性のあるすべての指標値の明示的なランキングはありません。具体的には、次の 2 つのシナリオについて考えてみます。

テスト	1 日のアクティブユーザー	1 日あたりの収益
A	100 万人	400 万ドル
B	200 万回	200 万ドル

現在のシステムが A であれば、B への切り替えはまず不可能です。現在のシステムが B の場合、A への切り替えはほぼ不可能です。これは、合理化された動作と矛盾しているように見えますが、指標の変化の予測が遅れる場合とそうでない場合があり、いずれかの変更に大きなリスクが伴います。各指標には、チームが懸念するリスクが含まれています。

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

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

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

未加工の特徴を受け取って直接コンテンツをランク付けする統合モデルは、デバッグと理解が最も容易なモデルです。ただし、モデルのアンサンブル（「他のモデルのスコアを組み合わせた」モデル）の方が適しています。物事を単純にするために、各モデルは、他のモデルの入力のみを受け取るアンサンブルであるか、多数の特徴量を受け取るが、両方ではない基本モデルである必要があります。個別にトレーニングされた他のモデルの上にモデルがある場合、それらを組み合わせると不適切な動作が発生する可能性があります。

「ベース」モデルの出力のみを入力として使用する、アンサンブルにシンプルなモデルを使用します。また、これらのアンサンブルモデルにはプロパティを適用する必要があります。たとえば、ベースモデルによって生成されたスコアが増えても、アンサンブルのスコアは低下しません。また、受信側のモデルが意味的に解釈可能な場合（キャリブレーションなど）は、基盤となるモデルを変更してもアンサンブルモデルを混同しないようにすることをおすすめします。また、基になる分類器の予測確率が高くても、アンサンブルの予測確率は低下しないようにします。

ルール 41: パフォーマンスが停滞している場合、既存のシグナルを絞り込むのではなく、質的に追加する情報を探す。

ユーザーの属性情報を追加しました。ドキュメント内の単語に関する情報を追加しました。テンプレートの確認を行い、正則化を調整しました。主要指標が数四半期にわたって 1% 以上改善されたリリースは見られていません。次のステップ

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

ルール 42: ダイバーシティ、パーソナライズ、関連性が人気度と相関があるとは思いません。

コンテンツセットの多様性とは、コンテンツのソースの多様性が最も一般的なものであることを表します。パーソナライズは、各ユーザーが独自の結果を取得することを意味します。関連性は、特定のクエリの結果が他のクエリよりも適切であることを意味します。これら 3 つのプロパティは、すべて通常とは異なるものとして定義されます。

問題は、普通の人には打ち勝つことが難しい傾向があるということです。

クリック数、視聴時間、総再生時間、+1、再共有数などが測定されている場合、コンテンツの人気度が測定されています。多様性のある個人的モデルを学習しようとするチームもあります。パーソナライズするには、システムがパーソナライズできる機能（ユーザーの興味 / 関心を表す一部の機能）や多様化する機能（このドキュメントで返される他のドキュメントと共通する機能（著者やコンテンツなど）を示す機能）を追加し、それらの機能に期待するよりも少ない（場合によっては異なる）特徴があることを確認します。

これは、ダイバーシティ、パーソナライズ、関連性に価値がないという意味ではありません。前のルールで指摘したように、後処理を実行して多様性や関連性を高めることができます。長期的な目標が増加している場合は、人気度以外にダイバーシティや関連性に価値があることを宣言できます。その後、引き続き後処理を使用するか、多様性または関連性に基づいて目標を直接変更できます。

ルール 43: 異なるサービス間で友だちが同じになる傾向がある。関心がない傾向があります。

Google のチームは、ある商品の接続が近いことを予測するモデルを採用し、それを別のプロダクトとうまく連携させることから、多くのことを得てきました。友だちは、あなた自身と一方で、複数のチームがサービス間の分類をまたいでパーソナライズを行うのに苦労しています。はい、動作しているはずです。現時点ではできないようです。うまくいかないと、あるプロパティの元データを使用して別のプロパティの行動を予測することがあります。また、ユーザーが別のプロパティの履歴を持っていることもわかっていれば、それも役立つことに留意してください。たとえば、2 つのサービスにおけるユーザーアクションの存在は、それ自体を示している可能性があります。

謝辞

{0/}0:02:09.280,0:02:11.240 クリステン・レフェールさんスッダ・バスさんクリス・ベルグさんありがとうございました意見、不作為、または不評な意見は私自身のものです。

付録

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

YouTube の概要

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

Google Play の概要

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

Google Plus の概要

Google Plus は、さまざまな状況で機械学習を使用しました。たとえば、ユーザーが閲覧している投稿の「ストリーム」内でのランキング、「注目の投稿」のランキング、非常に人気のある投稿のランキングなどです。Google Plus は 2019 年にすべての個人用アカウントを終了し、2020 年 7 月 6 日にビジネスアカウント向けの Google Currents に置き換えられました。