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

機械学習のルール:

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

Martin Zinkevich

このドキュメントは、機械学習に関する基本的な知識をお持ちの方を対象に、Google の機械学習のベストプラクティスを活用できるようにすることを目的としています。Google C++ スタイルガイドやその他の一般的な実践的なプログラミングガイドと同様に、機械学習のスタイルを示しています。機械学習のクラスを受講したことがある、または機械学習モデルを構築または操作したことがある場合は、このドキュメントを読むのに必要な背景知識があります。

Martin Zinkevich が、お気に入りの機械学習のルールを 10 個紹介します。43 個のルールをすべて確認する。

用語

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

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

概要

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

優秀なエンジニアとして機械学習を行い、優秀な ML エキスパートとして機械学習を行うのではなく、

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

パイプラインがエンドツーエンドで確実に機能していることを確認します。
最初は妥当な目標から始めます。
常識的な機能を簡単に追加できます。
パイプラインが安定していることを確認します。

このアプローチは長期的に効果的です。このアプローチから逸脱するのは、これ以上進むための簡単な方法がない場合に限ります。複雑さを増やすと、今後のリリースが遅くなります。

簡単な手法がすべて試し尽くされたら、最先端の機械学習が将来的に必要になるかもしれません。フェーズ III の ML プロジェクトのセクションをご覧ください。

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

最初のパートでは、ML システムを構築する時期が来ているかどうかを理解できます。
第 2 部では、最初のパイプラインのデプロイについて説明します。
第 3 部では、パイプラインに新機能を追加しながらリリースと反復処理を行う方法、モデルとトレーニングサービングスキューを評価する方法について説明します。
最後のパートでは、伸び悩みを感じたときの対処方法について説明します。
その後、関連作業のリストと、このドキュメントの例としてよく使用されるシステムの背景に関する付録があります。

機械学習以前

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

ML は優れた技術ですが、データが必要です。理論的には、別の問題からデータを取得して、新しいプロダクト用にモデルを微調整できますが、基本的なヒューリスティクスよりもパフォーマンスが低下する可能性があります。ML で 100% のパフォーマンス向上が期待できる場合、ヒューリスティクスでは 50% の向上が期待できます。

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

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

機械学習システムが行う処理を正式に定義する前に、現在のシステムで可能な限り多くのデータを追跡します。理由は次のとおりです。

早い段階でシステムのユーザーから権限を取得できます。
将来問題になる可能性があると思われる場合は、今のうちに過去のデータを確認することをおすすめします。
指標計測を念頭にシステムを設計すると、将来的に役立ちます。特に、指標を計測するためにログ内の文字列を grep するのは避けたいものです。
変更点と変更されない点を確認できます。たとえば、1 日あたりのアクティブユーザー数を直接最適化したいとします。ただし、システムの初期操作では、ユーザーエクスペリエンスの大幅な変更がこの指標に顕著な変化をもたらさない場合があります。

Google+ チームは、読み込みあたりの拡張、読み込みあたりの再共有、読み込みあたりの +1、読み込みあたりのコメント、ユーザーあたりのコメント、ユーザーあたりの再共有などを測定し、サービング時に投稿の優劣を計算するために使用しています。また、ユーザーをバケットにグループ化し、テストごとに統計情報を集計できるテストフレームワークが重要です。ルール 12 をご覧ください。

指標の収集をより自由に行うことにより、システムの全体像を把握できます。問題に気付いた場合は、指標を追加して追跡しましょう。前回のリリースで定量的な変更が加えられたことに関心をお持ちですか？指標を追加して追跡しましょう。

ルール 3: 複雑なヒューリスティクスよりも ML を選択する。

シンプルなヒューリスティクスで、製品を市場に出すことができます。複雑なヒューリスティクスはメンテナンスできません。データと、達成しようとしていることの基本的なアイデアが得られたら、機械学習に進みます。ほとんどのソフトウェアエンジニアリングタスクと同様に、ヒューリスティックモデルと ML モデルのどちらでも、アプローチを常に更新する必要があります。ML モデルは更新とメンテナンスが容易です（ルール #16 を参照）。

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

最初のパイプラインでは、システムインフラストラクチャに重点を置きます。これから行う機械学習のアイデアを考えるのは楽しいことですが、パイプラインを最初から信頼しないと、何が起こっているのかを把握するのは難しいでしょう。

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

最初のモデルは商品のパフォーマンスを最も高めるため、複雑にする必要はありません。ただし、予想以上に多くのインフラストラクチャの問題が発生します。新しい機械学習システムを誰もが使用できるようにするには、次の点を決定する必要があります。

学習アルゴリズムにサンプルを取得する方法。
システムにとっての「良い」と「悪い」の最初の切り分け。
モデルをアプリケーションに統合する方法。モデルをライブで適用するか、オフラインでサンプルでモデルを事前計算して結果をテーブルに保存します。たとえば、ウェブページを事前に分類して結果をテーブルに保存する場合と、チャットメッセージをリアルタイムで分類する場合などがあります。

シンプルな特徴を選択すると、次のことを簡単に確認できます。

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

これらの 3 つの処理を信頼性を持って実行するシステムが構築できたら、ほとんどの作業は完了です。シンプルなモデルは、より複雑なモデルのテストに使用できるベースライン指標とベースライン動作を提供します。一部のチームは「中立」な最初のリリースを目指しています。これは、気を散らさないように、機械学習の成果を明示的に優先順位付けしない最初のリリースです。

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

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

アルゴリズムへのデータの取得をテストします。入力する必要がある特徴列にデータが入力されていることを確認します。プライバシーが許容される場合は、トレーニングアルゴリズムへの入力を手動で検査します。可能であれば、パイプラインの統計情報を、他の場所で処理された同じデータの統計情報と比較します。
トレーニングアルゴリズムからモデルを取得するテストを行います。トレーニング環境のモデルが、サービング環境のモデルと同じスコアを与えることを確認します（ルール 37 をご覧ください）。

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

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

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

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

通常、機械学習が解決しようとしている問題はまったく新しいものではありません。解決しようとしている問題のランキングや分類を行う既存のシステムがある。つまり、一連のルールとヒューリスティクスが存在します。これらのヒューリスティクスは、機械学習で微調整することで効果を高めることができます。ヒューリスティクスは、次の 2 つの理由から、利用可能なすべての情報から抽出する必要があります。まず、ML システムへの移行がスムーズになります。2 つ目は、通常、これらのルールには、破棄したくないシステムに関する多くの直感的な情報が含まれています。既存のヒューリスティックを使用する方法は 4 つあります。

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

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

モニタリング

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

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

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

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

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

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

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

これは、他の種類のシステムよりも ML システムで発生する問題です。結合されている特定のテーブルが更新されなくなったとします。機械学習システムは調整され、動作は引き続き適切に行われ、徐々に低下します。数か月前のテーブルが見つかることもあります。単純な更新で、その四半期の他のリリースよりもパフォーマンスが向上することもあります。特徴の範囲は、実装の変更によって変更される可能性があります。たとえば、特徴列が 90% のサンプルに入力され、突然 60% のサンプルに減少する可能性があります。Play では、6 か月間更新されていないテーブルがありましたが、テーブルを更新しただけでインストール率が 2% 向上しました。データの統計情報を追跡し、必要に応じてデータを手動で検査すると、このような障害を減らすことができます。

ルール 11: 特徴列にオーナーとドキュメントを割り当てる。

システムが大きく、特徴列が多い場合は、各特徴列を作成または維持しているユーザーを把握します。特徴列を理解している人が退職する場合は、誰かがその情報を把握していることを確認してください。多くの特徴列にはわかりやすい名前が付けられていますが、特徴の内容、出所、役割について詳細な説明を用意しておくとよいでしょう。

最初の目標

重要なシステムには多くの指標や測定値がありますが、機械学習アルゴリズムでは多くの場合、単一の目標（アルゴリズムが「最適化しようとしている」数値）が必要です。ここでは、目標と指標を区別しています。指標とは、システムが報告する数値のことです。重要なものもあれば、そうでないものもあります。ルール 2 もご覧ください。

ルール 12: 直接最適化する目標を過度に深く考えすぎない

収益を上げ、ユーザーを満足させ、世界をより良い場所にしたいと考えています。注目すべき指標はたくさんあり、すべて測定する必要があります（ルール 2 を参照）。ただし、機械学習プロセスの初期段階では、直接最適化していないものも含め、すべての指標が上昇します。たとえば、クリック数とサイト滞在時間を重視しているとします。クリック数を重視して最適化すると、総再生時間が長くなる傾向があります。

すべての指標を簡単に増やすことができるのであれば、シンプルに保ち、さまざまな指標のバランスをとることにあまり神経質にならないようにしましょう。ただし、このルールを過度に適用しないでください。目標とシステムの最終的な健全性を混同しないでください（ルール 39 を参照）。また、直接最適化された指標が増加しているにもかかわらず、キャンペーンを開始しない場合は、目標の見直しが必要になることがあります。

ルール 13: 最初の目標に、シンプルで測定可能かつアトリビューション可能な指標を選択します。

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

最も簡単にモデル化できるのは、直接観察され、システムのアクションに起因するユーザー行動です。

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

最初は間接効果をモデリングしないでください。

お客様は翌日訪問しましたか？
ユーザーがサイトにアクセスした時間
1 日のアクティブユーザー数はどれくらいでしたか？

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

最後に、機械学習で次のことを判断しようとしないでください。

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

これらはすべて重要ですが、測定が非常に困難です。代わりにプロキシを使用してください。ユーザーが満足すれば、サイトに長く滞在するようになります。お客様が満足された場合は、明日また来店されるでしょう。ウェルビーイングと企業の健全性に関しては、機械学習による目標を販売する商品の性質やビジネス計画に結び付けるために、人間の判断が必要です。

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

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

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

シンプルなモデルでは、フィードバックループを扱いやすくなります（ルール 36 を参照）。多くの場合、Google はこれらの確率的予測を使用して意思決定を行います。たとえば、期待値（クリック / ダウンロードなどの確率）が低い順に投稿をランク付けします。ただし、使用するモデルを選択する際には、モデルに与えられたデータの確率よりも、その決定が重要であることを覚えておいてください（ルール 27 を参照）。

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

品質のランク付けは芸術ですが、スパムフィルタリングは戦争です。高品質な投稿を判断するために使用するシグナルは、システムを使用するユーザーにとって明らかになり、ユーザーはこれらのプロパティを備えるように投稿を調整します。したがって、品質ランキングでは、善意で投稿されたコンテンツを重視する必要があります。スパムを高く評価したからといって、品質ランキング学習ツールを軽視しないでください。同様に、「刺激の強い」コンテンツは、品質ランキングとは別に処理する必要があります。迷惑メールフィルタは別の話です。生成する必要がある特徴は絶えず変化することを想定する必要があります。多くの場合、システムに明確なルールを設定します（投稿に 3 件を超えるスパム票が付いた場合は取得しないなど）。学習したモデルは、速くとも毎日更新する必要があります。コンテンツの作成者の評判が大きな役割を果たします。

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

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

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

2 つ目のフェーズでは、簡単に着手できる取り組みが数多くあります。システムに組み込むことができる明らかな機能はたくさんあります。したがって、機械学習の第 2 フェーズでは、できるだけ多くの特徴量を取り込み、直感的な方法で組み合わせます。この段階では、すべての指標が引き続き増加しているはずです。多くのリリースが予定されているため、本当に優れた学習システムを構築するために必要なすべてのデータを統合できるエンジニアを多数採用する絶好の機会です。

ルール 16: リリースと反復を計画する。

現在取り組んでいるモデルが最後のモデルになる、またはモデルのリリースを停止することはないと考えてください。したがって、このリリースで追加する複雑さが今後のリリースを遅らせるかどうかを検討してください。多くのチームは、長年にわたって四半期ごとに 1 つ以上のモデルをリリースしてきました。新しいモデルをリリースする主な理由は次の 3 つです。

新しい機能を開発している。
正則化を調整し、古い特徴を新しい方法で組み合わせている。
目標をチューニングしている。

いずれにしても、モデルを少し手入れすることは良いことです。例に入力するデータを調べることで、新しいシグナルや古くて壊れたシグナルを見つけることができます。そのため、モデルを構築する際には、特徴の追加、削除、再結合がどれくらい簡単かを検討してください。パイプラインの新しいコピーを作成して、その正確性を確認するのがいかに簡単かを考えてみましょう。2 つまたは 3 つのコピーを並行して実行できるかどうかを検討します。最後に、35 個のうち 16 個の特徴がこのバージョンのパイプラインに含まれるかどうかは気にしないでください。来四半期にお届けします。

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

これは議論の余地がある点ですが、多くの落とし穴を回避できます。まず、学習済み特徴量について説明します。学習済み特徴量は、外部システム（教師なしクラスタリングシステムなど）または学習者自体（ファクタモデルやディープラーニングなど）によって生成される特徴量です。どちらも有用ですが、多くの問題が発生する可能性があるため、最初のモデルには含めないでください。

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

分解モデルとディープラーニングモデルの主な問題は、非凸であることです。したがって、最適解を近似または検出できる保証はなく、反復処理ごとに検出される局所最小値が異なる場合があります。このばらつきにより、システムへの変更の影響が有意なものかランダムなものかを判断することが難しくなります。ディープリンクを使用しないモデルを作成することで、優れたベースラインパフォーマンスを得ることができます。このベースラインを達成したら、より難解なアプローチを試すことができます。

ルール 18: コンテキスト全体に一般化できるコンテンツの特徴を使用して探索する

多くの場合、ML システムは、はるかに大きな全体の一部にすぎません。たとえば、[急上昇] に表示される可能性がある投稿を想像してみてください。多くのユーザーが、[急上昇] に表示される前に、その投稿にプラスワン、再共有、コメントをしています。これらの統計情報を学習者に提供すると、最適化のコンテキストでデータがない新しい投稿を宣伝できます。YouTube の「次のおすすめ」には、YouTube 検索の視聴回数や視聴の同時数（ある動画の視聴後に別の動画が視聴された回数）が使用される場合があります。明示的なユーザー評価を使用することもできます。最後に、ラベルとして使用しているユーザー操作がある場合、別のコンテキストでドキュメント上のその操作を確認できると便利です。これらの機能を使用すると、新しいコンテンツをコンテキストに組み込むことができます。これはパーソナライズとは異なります。まず、このコンテキストでコンテンツが好まれているかどうかを判断し、好まれているかどうかを判断します。

ルール 19: 可能な場合は非常に具体的な機能を使用する

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

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

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

離散化は、連続的な特徴量を取り、そこから多くの離散的な特徴量を作成することです。年齢などの連続型特徴量について考えてみましょう。年齢が 18 歳未満の場合は 1、年齢が 18 ～ 35 歳の場合は 1 となる特徴を作成できます。これらのヒストグラムの境界を深く考えすぎないでください。基本的な分位でほとんどの影響を確認できます。

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

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

テキストを扱う方法は 2 つあります。最も厳格なのはドット積です。最も単純な形式のドット積は、クエリとドキュメントに共通する単語の数をカウントするだけです。この特徴量は離散化できます。別のアプローチとして、交差点があります。これにより、ドキュメントとクエリの両方に「ポニー」という単語が含まれている場合にのみ存在する特徴と、ドキュメントとクエリの両方に「the」という単語が含まれている場合にのみ存在する特徴が作成されます。

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

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

検索ランキングシステムを構築していて、ドキュメントとクエリに数百万もの異なる単語があり、ラベル付きの例が 1,000 個ある場合は、ドキュメントとクエリの特徴量、TF-IDF、および 6 個の高度な人間工学に基づく特徴量の間のドット積を使用する必要があります。1, 000 個のサンプル、12 個の特徴。
100 万個のサンプルがある場合は、正則化と場合によっては特徴選択を使用して、ドキュメントとクエリの特徴列を交差させます。これにより数百万もの特徴が得られますが、正則化によりその数は減ります。1, 000 万のサンプル、10 万の特徴量。
数十億または数百億のサンプルがある場合は、特徴選択と正則化を使用して、特徴列をドキュメントトークンとクエリトークンとクロスできます。10 億のサンプルと 1, 000 万の特徴量が得られます。統計学習理論では厳密な上限が得られることはあまりありませんが、出発点に関する優れたガイダンスが得られます。

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

ルール 22: 使用しなくなった機能をクリーンアップする

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

追加または維持する機能について検討する際は、カバレッジに注意してください。この機能が適用される例はいくつありますか？たとえば、パーソナライズ機能がいくつかあるものの、パーソナライズ機能を利用しているユーザーが 8% しかいない場合は、あまり効果的ではありません。

一方で、一部の機能は期待以上のパフォーマンスを発揮することもあります。たとえば、データの 1% しかカバーしていない特徴量でも、その特徴量を含む例の 90% がポジティブであれば、追加する価値のある特徴量です。

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

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

ルール 23: あなたは一般的なエンドユーザーではありません。

これは、チームが行き詰まる最も簡単な方法かもしれません。フィッシュフーディング（チーム内でプロトタイプを使用する）とドッグフーディング（社内でプロトタイプを使用する）には多くのメリットがありますが、パフォーマンスが正しいかどうかを確認する必要があります。明らかに不適切な変更は使用すべきではありませんが、本番環境に近いと思われる変更は、クラウドソースプラットフォームで質問に回答する一般の人々に報酬を支払うか、実際のユーザーを対象としたライブテストを行うなど、さらにテストする必要があります。

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

ユーザーのフィードバックが本当に必要な場合は、ユーザーエクスペリエンスの方法論を使用します。プロセスの早い段階でユーザーペルソナを作成し（Bill Buxton の Sketching User Experiences に説明があります）、後でユーザビリティテストを行います（Steve Krug の Don’t Make Me Think に説明があります）。ユーザーペルソナでは、架空のユーザーを作成します。たとえば、チームに男性しかいない場合は、35 歳の女性ユーザーペルソナ（ユーザー特性を含む）を設計し、25 ～ 40 歳の男性の 10 件の結果ではなく、そのペルソナから生成された結果を確認するとよいでしょう。ユーザビリティテストで実際のユーザーを招き、サイトに対する反応を（ローカルまたはリモートで）観察することで、新しい視点を得ることもできます。

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

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

ルール 25: モデルを選択する際は、予測力よりも実用的なパフォーマンスを重視します。

モデルはクリック率を予測しようとします。ただし、最終的には、その予測をどうするかが重要な問題となります。ドキュメントのランク付けに使用する場合、予測自体よりも最終的なランキングの品質が重要になります。ドキュメントがスパムである可能性を予測し、ブロックする内容にカットオフを設ける場合は、許可される内容の精度が重要になります。ほとんどの場合、この 2 つは一致しているはずです。一致していない場合は、わずかな利益になる可能性があります。したがって、ログロスを改善する変更がシステムのパフォーマンスを低下させる場合は、別の特徴量を探します。このようなことが頻繁に発生する場合は、モデルの目的を見直す必要があります。

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

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

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

モデルが誤って予測した例が見つかったら、現在の特徴量セットの範囲外の傾向を探します。たとえば、長い投稿が優先されないように見える場合は、投稿の長さを追加します。追加する機能について具体的に記述しないでください。投稿の長さを追加する場合は、長い投稿とは何かを推測しようとせず、数十個の特徴量を追加して、モデルにそれらをどう処理するかを判断させます（ルール 21 を参照）。これが、目的のものを取得する最も簡単な方法です。

ルール 27: 観察された望ましくない動作を定量化してみてください。

チームの一部のメンバーは、既存の損失関数でキャプチャされない、システムの望ましくない特性に不満を感じ始めます。この時点では、不満を具体的な数値に変えるために何でもすべきです。たとえば、Google Play 検索に表示される「いたずらアプリ」が多すぎると思われる場合は、人間のレーティング担当者にいたずらアプリを特定してもらえます。（この場合、トラフィックの大部分を占めるのは比較的少数のクエリであるため、人間がラベル付けしたデータを使用できます）。問題が測定可能な場合は、問題を特徴、目標、指標として使用できます。一般的なルールは「まず測定し、次に最適化する」です。

ルール 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: 可能な限り、トレーニングパイプラインとサービングパイプラインの間でコードを再利用します。

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

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

一般に、モデルのトレーニングに使用したデータの後に収集されたデータでモデルのパフォーマンスを測定します。これは、本番環境でシステムが行うことをより適切に反映するためです。1 月 5 日までのデータに基づいてモデルを生成する場合、1 月 6 日以降のデータでモデルをテストします。新しいデータではパフォーマンスが低下することが予想されますが、大幅に低下することはありません。日ごとの効果がある可能性があるため、平均クリック率やコンバージョン率を予測できない場合がありますが、曲線の下の面積（正例に負例よりも高いスコアを与える可能性を表します）は、かなり近い値になるはずです。

ルール 34: フィルタリングのためのバイナリ分類（スパムの検出や興味深いメールの特定など）では、非常にクリーンなデータのために、短期的にパフォーマンスを少し犠牲にします。

フィルタリングタスクでは、否定的な例はユーザーに表示されません。サービング時にネガティブサンプルの 75% をブロックするフィルタがあるとします。ユーザーに表示されるインスタンスから追加のトレーニングデータを取得したくなるかもしれません。たとえば、フィルタによって許可されたメールをユーザーが迷惑メールとしてマークした場合は、そのメールから学習できます。

ただし、この方法ではサンプリングバイアスが発生します。代わりに、サービング中にすべてのトラフィックの 1% を「ホールドアウト」としてラベル付けし、ホールドアウトされたすべての例をユーザーに送信すると、よりクリーンなデータを収集できます。これで、フィルタはネガティブな例の少なくとも 74% をブロックします。これらの保持されたサンプルはトレーニングデータになります。

フィルタで負の例の 95% 以上がブロックされている場合、このアプローチは有効ではありません。それでも、サービングパフォーマンスを測定したい場合は、さらに小さいサンプル（0.1% や 0.001% など）を作成できます。1 万個のサンプルがあれば、パフォーマンスをかなり正確に予測できます。

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

ランキングアルゴリズムを大幅に変更して結果が異なる場合は、アルゴリズムが今後参照するデータが実質的に変更されたことになります。この種の偏りは発生するため、そのことを考慮してモデルを設計する必要があります。アプローチは複数あります。これらのアプローチはすべて、モデルがすでに見たデータに優先する方法です。

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

ルール 36: 位置情報の特徴量でフィードバックループを回避する

コンテンツの位置は、ユーザーがコンテンツを操作する可能性に大きく影響します。アプリを 1 位に配置すると、クリックされる回数が増え、クリックされる可能性が高いと判断できます。この問題に対処する 1 つの方法は、位置特徴（ページ内のコンテンツの位置に関する特徴）を追加することです。位置情報の特徴量を使用してモデルをトレーニングすると、たとえば「1st_position」などの特徴量に重み付けを学習します。したがって、モデルは「1st_position=true」の例では他の要素に重きを置きません。サービングでは、表示順序を決定する前に候補をスコアリングするため、インスタンスに位置情報特徴を指定しないか、すべてに同じデフォルト特徴を指定します。

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

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

一般的な意味での偏差の原因はいくつかあります。また、複数のパートに分割することもできます。

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

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

第 2 フェーズが終了に近づいていることを示す特定の兆候があります。まず、毎月の収益が減少し始めます。指標間のトレードオフが始まります。一部のテストでは指標が上がったり下がったりすることがあります。ここからが面白いところです。成果を達成するのが難しくなるため、機械学習はより高度なものにする必要があります。注意: このセクションには、前のセクションよりも多くのブルースカイルールがあります。多くのチームが、フェーズ 1 とフェーズ 2 の ML の幸せな時代を経験してきました。フェーズ III に到達したら、チームは独自の道を見つける必要があります。

ルール 38: 目標の不一致が問題になっている場合は、新機能に時間を浪費しないでください。

測定値が横ばいになると、現在の ML システムの目標の範囲外の問題にチームが注目するようになります。前述のように、プロダクトの目標が既存のアルゴリズム目標でカバーされていない場合は、目標またはプロダクトの目標のいずれかを変更する必要があります。たとえば、クリック数、高評価数、ダウンロード数を最適化しながら、人間のレーティングに基づいてリリースの決定を行うことができます。

ルール 39: リリースに関する意思決定は、プロダクトの長期的な目標の代用となる。

アリスは、インストール数を予測する際のロジスティック損失を減らすアイデアを持っています。彼女は機能を追加します。ロジスティック損失が低下します。ライブテストを実施すると、インストール率が上昇していることがわかります。しかし、リリース審査ミーティングで、1 日のアクティブユーザー数が 5% 減少していることを指摘されました。チームはモデルをリリースしないことにしました。アリスはがっかりしましたが、リリースの決定は複数の条件に依存しており、そのうちの一部のみを ML を使用して直接最適化できることに気づきました。

現実はダンジョンズ＆ドラゴンズではありません。プロダクトの健全性を示す「ヒットポイント」はありません。チームは、収集した統計情報を使用して、将来のシステムの性能を効果的に予測する必要があります。エンゲージメント、1 日あたりのアクティブユーザー数（DAU）、30 日間のアクティブユーザー数、収益、広告主様の費用対効果を重視する必要があります。A/B テストで測定できるこれらの指標は、ユーザーの満足度、ユーザー数の増加、パートナーの満足度、利益など、より長期的な目標の代用指標にすぎません。それでも、5 年後には有用で高品質なプロダクトと繁栄する企業を構築するための代用指標と見なすことができます。

すべての指標が改善された場合（または少なくとも悪化していない場合）にのみ、簡単にリリースを決定できます。高度な ML アルゴリズムと単純なヒューリスティクスのどちらを選択するかを検討している場合、単純なヒューリスティクスがすべての指標で優れている場合は、ヒューリスティクスを選択する必要があります。また、考えられるすべての指標値の明示的なランキングはありません。具体的には、次の 2 つのシナリオについて検討します。

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

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

さらに、チームの最終的な懸念事項である「5 年後の製品の状況」をカバーする指標はありません。

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

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

未加工の特徴を取得してコンテンツを直接ランク付けする統合モデルは、デバッグと理解が最も簡単なモデルです。ただし、モデルのアンサンブル（他のモデルのスコアを組み合わせた「モデル」）の方が効果的です。シンプルにするため、各モデルは、他のモデルの入力のみを受け取るアンサンブルか、多くの特徴を受け取るベースモデルのいずれかである必要があります。両方ではありません。別々にトレーニングされた他のモデルの上にモデルがある場合、それらを組み合わせると動作が不安定になる可能性があります。

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

ルール 41: パフォーマンスが停滞している場合は、既存のシグナルを改良するのではなく、質の高い新しい情報源を探して追加します。

ユーザーに関する属性情報を追加しました。ドキュメント内の単語に関する情報が追加されました。テンプレートの探索を行い、正則化を調整しました。過去数四半期に、主要指標が 1% 以上改善されたリリースはありません。どうすればよいでしょうか。

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

ルール 42: 多様性、パーソナライズ、関連性が、あなたが考えているほど人気と相関があるとは限りません。

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

問題は、普通なものは打ち負かすのが難しい傾向があることです。

クリック数、総再生時間、視聴回数、+1 数、再共有数などを測定している場合は、コンテンツの人気度を測定しています。チームは、多様性のある個人モデルを学習しようとすることがあります。パーソナライズするために、システムがパーソナライズ（ユーザーの関心を表す一部の特徴）または多様化（このドキュメントが返された他のドキュメント（作成者やコンテンツなど）と共通の特徴があるかどうかを示す特徴）できるように特徴を追加し、これらの特徴が想定よりも重みが低い（または異なる符号が付いている）ことが判明します。

これは、多様性、パーソナライズ、関連性が価値がないという意味ではありません。前述のルールで説明したように、ポスト処理を行うと、多様性や関連性を高めることができます。長期的な目標の増加が確認できた場合は、人気度だけでなく、多様性や関連性が重要であると宣言できます。その後、ポスト処理を引き続き使用するか、多様性や関連性に応じて目標を直接変更できます。

ルール 43: ユーザーの友人は、さまざまなサービスで同じ傾向があります。興味 / 関心はそうではありません。

Google のチームは、あるプロダクトで接続の近さを予測するモデルを取得し、別のプロダクトでうまく機能させることで、多くの成果を上げています。友だちは友だちです。一方で、複数のチームがプロダクト間のパーソナライズ機能に苦労しているのを見ました。はい、問題なく動作するはずです。現時点では、そうはなさそうです。あるプロパティの元データを使用することで、別のプロパティの動作を予測できることもあります。また、ユーザーが別のプロパティで履歴を持っていることを把握しているだけでも、役に立つことがあります。たとえば、2 つのプロダクトでユーザーアクティビティが検出された場合は、それ自体が指標になる可能性があります。

謝辞

このドキュメントの多くの修正、提案、有用な例を提供してくれた David Westbrook、Peter Brandt、Samuel Ieong、Chenyu Zhao、Li Wei、Michalis Potamias、Evan Rosen、Barry Rosenberg、Christine Robson、James Pine、Tal Shaked、Tushar Chandra、Mustafa Ispir、Jeremiah Harmsen、Konstantinos Katsiapis、Glen Anderson、Dan Duckworth、Shishir Birmiwal、Gal Elidan、Su Lin Wu、Jaihui Liu、Fernando Pereira、Hrishikesh Aradhye に感謝します。また、以前のバージョンの作成に協力してくれた Kristen Lefevre、Suddha Basu、Chris Berg にも感謝します。誤り、脱落、（驚くべきことに）不評の意見はすべて私個人のものです。

付録

このドキュメントでは、さまざまな Google サービスについて説明しています。コンテキストをより明確にするために、以下に最も一般的な例を簡単に説明します。

YouTube の概要

YouTube はストリーミング動画サービスです。YouTube の [次のおすすめ] チームと YouTube のトップページチームの両方が、ML モデルを使用しておすすめの動画をランク付けしています。[次のおすすめ] は、現在再生中の動画の後に視聴する動画をおすすめします。一方、[ホーム] は、ホームページを閲覧しているユーザーに動画をおすすめします。

Google Play の概要

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

Google+ の概要

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