機械学習のルール:

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

Martin Zinkevich 氏

このドキュメントは、ML に関する基本的な知識をお持ちの方を対象としています。 Google のベスト プラクティスを ML で活用できます。これは、 Google C++ スタイルガイドに類似した、ML のスタイルを提示します その他一般的な実用的なプログラミング ガイドです。すでにクラスを受講した場合 ML モデルの構築や利用に携わった場合 このドキュメントを読むために必要な背景知識があることを前提としています。

Martin Zinkevich が紹介するお気に入りのルール 10 個 学びましたここでは、43 のルールをすべて見ていきましょう。

用語

次の用語は、効果的なセキュリティに関する論考で何度も登場します。 ML:

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

概要

優れた商品を作るには:

ML は、優れたエンジニアではなく、 ML 専門家ではないでしょう

直面する問題のほとんどは、実際にはエンジニアリングに関する問題です。均等 優れた ML 専門家のリソースを活用すれば 優れた ML アルゴリズムではなく 優れた特徴量から生まれます基本的な 次のようなアプローチがあります。

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

このアプローチは、 可能性があります。このアプローチから逸脱するのは、 ちょっとしたトリックでさらに上を目指しましょう。複雑さを増やすと、今後のリリースが遅くなります。

単純なコツをつかむと、最先端の ML が 考えてみましょう詳しくは、 フェーズ 3 いくつかあります。

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

  1. 第 1 部では、 ML システムを構築するのに最適な タイミングです
  2. 2 つ目のパートでは、 見てみましょう
  3. 3 つ目のパートは、Google Workspace の パイプラインに新機能を追加する際の反復処理、モデルの評価方法 トレーニングサービングスキューです
  4. 「 最後のパートです プラトーに達したらどうするかということです。
  5. その後に、関連作業のリストと、 付録 一般的に使用されているシステムの背景について説明します。

ML 前

ルール 1: プロダクトのリリースを ML なしで行うことを恐れない。

ML は素晴らしいものですが、データが必要です。理論上は 新しい製品向けにモデルを微調整しますが パフォーマンスがベーシックモデルより ヒューリスティック。もしそう思うなら、 ML では 100%向上し あります。

たとえば、アプリ マーケットプレイスでアプリをランク付けする場合は、 インストール率やインストール数を ヒューリスティックとして考慮しますスパムが検出された場合は 以前に迷惑メールを送信したパブリッシャーを除外できる。恐れずに人間による 編集できます。連絡先をランク付けする必要がある場合は、最近使用した連絡先をランク付けする アルファベット順に並べ替えることができます。ML が完璧ではなくても データを用意するまで使用しないでください。

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

ML システムの動作を形式化する前に、できる限り 現在のシステムで可能な操作ですその理由は次のとおりです。

  1. 比較的早い段階でシステムのユーザーから権限を取得する方が簡単です。
  2. 今後、懸念すべきことがあると思われる場合は、 過去のデータを取得することをおすすめします
  3. 指標計測を念頭に置いてシステムを設計すると、 パフォーマンスが 説明します。具体的には、失敗を 指標を測定できるようにしました。
  4. 何が変わって何が変わらないかに気づくでしょう。たとえば 1 日のアクティブ ユーザーを直接最適化するとします。ただし、 初期のシステム操作では、古いバージョンと ユーザーエクスペリエンスが劇的に変化しても 表示されます。

Google Plus チームの測定は読み取りごとに拡張されます。 読み取りあたりの再共有 閲覧、コメント/既読、ユーザーあたりのコメント、ユーザーあたりの再共有数など 投稿の有用性を計算する際の主な指標です。また、 ユーザーをバケットにグループ化して集計したり テストごとの統計が重要です。詳しくは、 ルール 12:

指標の収集に寛容になることで、全体像を把握できます。 自動的に最適化されます。問題がある場合は、追跡する指標を追加してください。Google Cloud の 量的な変化はあるか？追跡する指標を追加してください。

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

単純なヒューリスティックが、プロダクトの販売を後押しします。複雑なヒューリスティックは、 維持不可能ですデータと目標に関する基本的な考え方を揃えたら、 ML に進みます多くのソフトウェア エンジニアリングで アプローチを常に更新する必要があります。 ヒューリスティックまたは ML モデルを使用することです 更新と保守が容易になる（ ルール 16）。

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

最初のパイプラインのシステム インフラストラクチャに焦点を当てます。楽しみながら 想像力に富んだ ML を実際に活用し、 まず 信頼できるパートナーでなければ 何が起こっているか把握するのは困難です 説明します

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

最初のモデルは商品の価値を最大限に引き出すため、最初のモデルは 華やかに。しかし、インフラの問題は、自分のセキュリティだけでは解決できない あります。新しい ML システムを使用するには 次の点を確認します。

  • 学習アルゴリズムに例を取得する方法。
  • 「良い」のは何かに関する最初のカット「bad」システムにとって意味がありません。
  • モデルをアプリケーションに統合する方法。または モデルをライブで稼働させる オフラインでサンプルに基づいてモデルを事前に計算し、結果をテーブルに保存する たとえば、ウェブページを事前に分類して結果を保存し、 チャット メッセージはライブで分類できます。

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

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

これら 3 つのことを確実に行うシステムができたら、 大部分を占めています。このシンプルなモデルでは、ベースライン指標と より複雑なモデルのテストに使用できるベースライン動作です。チームによっては 「どちらでもない」初回起動: 明示的に優先順位を下げた初回起動 注意が散漫になるのを防ぎます

ルール 5: インフラストラクチャを ML とは別にテストする。

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

  1. アルゴリズムへのデータの取得をテストします。特徴量列が 表示されます。プライバシーが許す限り、手動で トレーニング アルゴリズムへの入力を検査します。可能であれば パイプライン内の統計情報を、同じデータの統計情報と比較 別の場所で処理されます。
  2. トレーニング アルゴリズムからモデルを取得することをテストします。必ず、 トレーニング環境でモデルは、そのモデルと同じスコアを 確認できます（ ルール 37）。

ML には予測不可能な要素が含まれているため、 トレーニングとサービングでサンプルを作成するためのコードのテスト サービング中に固定モデルを読み込んで使用できます。また データを理解するには、以下をご覧ください。 大規模で複雑なデータセットの分析に対する実践的なアドバイス。

ルール 6: パイプラインをコピーする際にデータの欠落に注意する。

多くの場合、既存のパイプライン（つまり、 カーゴカルト プログラミング ）、古いパイプラインでは新しいパイプラインに必要なデータがドロップされます。 たとえば、Google+ の「What's Hot」のパイプラインがこれに該当します。 古い投稿をドロップする（新しい投稿をランク付けしようとしているため）。このパイプラインは Google Plus Stream 用にコピー。以前の投稿も使用可能 パイプラインによって古い投稿が削除されていましたその他 ユーザーが見たデータのみをログに記録するというのが一般的なパターンです。したがって、このデータは 特定の投稿がユーザーに表示されない理由をモデル化したい場合は ネガティブサンプルがすべてドロップされているからです同様の事象が プレイする。Play アプリのホームで作業するなかで、新しいパイプラインが作られました。 Google Play Games のランディング ページに含まれている例を、 明確にする必要があります

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

通常、ML が解決しようとしている問題は、 完全に新しいものですランキング、分類、 あらゆる問題に対応できますこれは、さまざまな検出ルールが ルールとヒューリスティック。これらと同じヒューリスティックにより、 向上しますヒューリスティックは ルールがどのようなものであれ その理由は 2 つあります。まず マシンへの移行は スムーズになります第二に、通常これらのルールには、 システムに関する直感を捨てたくない4 つの 次のような方法で、既存のヒューリスティックを使用でき、

  • ヒューリスティックを使用して前処理します。驚くほど優れた機能があれば これはオプションですたとえば、迷惑メールフィルタで、 すでに「ブラックリスト」に登録されているため、「ブラックリスト登録済み」の内容を再確認しないでください。 意味します。メッセージをブロックします。このアプローチは、バイナリでは最も理にかなっています 学習します。
  • 特徴を作成します。ヒューリスティックから直接特徴を作成するのは素晴らしいことです。 たとえば、ヒューリスティックを使用して、あるクエリの関連性スコアを計算するとします。 スコアを特徴量の値として含めることができます。後で 機械学習技術を使用して価値をマッサージし （たとえば、値を離散的な有限の集合の 1 つに 他の特徴と組み合わせたりすることもできますが、まずは未加工の 値を使用します。
  • ヒューリスティックの未加工の入力をマイニングする。アプリにヒューリスティックが存在する場合 総インストール数と文字数の合計を 分割して考えてみましょう 入力を個別に学習にフィードします手法には、 アンサンブルに適用されます（詳細については、 ルール 40）。
  • ラベルを変更します。このオプションは、ヒューリスティックが は、現在はラベルに含まれない情報をキャプチャします。たとえば ダウンロード数を最大化したいが ラベルに値を掛け合わせることが 解決策となるでしょう アプリが獲得した星の数の平均。ここには十分な余裕があります。 「最初の目標」をご覧ください。

ML でヒューリスティックを使用するときは複雑さの増大に注意する ありません新しい ML アルゴリズムで古いヒューリスティックを使用すると、 スムーズに移行するために役立ちますが もっと簡単に同じ効果を実現できます。

モニタリング

通常は、アラートを実用的なものにするなど、適切なアラートを健全化します。 ダッシュボードページが必要です

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

1 日前のモデルを使用すると、パフォーマンスはどの程度低下しますか。1 週間 古い？4 分の 1 前？この情報は できます。重要なプロダクトを失った場合 モデルを更新しなかった場合に エンジニアに継続的に監視してもらうことは当然の流れです。ほとんどの広告 新しいアドバタイズメントが毎日配信システムに追加されるため、新しい広告を できます。たとえば、ML モデルがトレーニング Google Play の検索は更新されません。 1 か月未満で悪影響が及びます「注目の投稿」機能の一部モデル Google+ のモデルには投稿 ID がないため、 彼らは 低い頻度でエクスポートします。投稿 ID を持つその他のモデルは、 より頻繁に更新されます。また、鮮度は時間とともに変化する可能性があります。 特に特徴列がモデルに追加されたり モデルから削除されたりした場合に起こります

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

多くの ML システムには、モデルをエクスポートするステージがある あります。エクスポートしたモデルに問題がある場合は、 あります。

モデルをエクスポートする直前に、サニティ チェックを行います。具体的には モデルのパフォーマンスが、予測されたデータで妥当であることを保証します。または データに関する懸念が長引く場合は、モデルをエクスポートしないでください。多数のチーム モデルを継続的にデプロイする場合は、 ROC 曲線 （AUC） エクスポートする必要があります。エクスポートされていないモデルに関する問題を解決するには、 ユーザー向けモデルの問題にはページが必要になる場合があります。まあまあ ユーザーに影響が及ぶ前に確認してください。

ルール 10: サイレントの失敗を監視する。

これは、ML システムで他のシステムよりも多く発生する問題です。 サポートしています。結合しようとしている特定のテーブルが 更新されなくなりました機械学習システムが調整を行い、 ある程度良好な状態が保たれ、徐々に減衰していきます。ときには、 テーブルを最新の状態に保ち、単純な更新でパフォーマンスを その四半期のどのリリースよりも高い成果を達成しました。ニュース メディアの 実装の変更によって特徴量が変更される場合があります。たとえば、特徴量列 サンプルの 90% にデータが入力されていても、突然サンプルの 60% に 説明します。かつて Play には 6 か月間古いテーブルがあり、更新されていた この表だけでインストール率が 2% 上昇しました。たとえば 随時手動でデータを検査できるため、 防ぐことができます。

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

システムの規模が大きく、特徴列が多数ある場合は、 各特徴量列を維持管理していますスペースにつながっている人物が 特徴量列が離れていることを確認したら 情報です。多くの特徴列にわかりやすい名前が付いていますが、 その機能がどこにあるのかを より詳しく 期待される効果について説明します。

最初の目標

重視するシステムに関する指標や測定値はたくさんありますが、 しかし多くの場合、ML アルゴリズムには 1 つの目標、 試行します。最適化しますここで区別する 目標と指標の間の数値のグラフです 重要な場合もあれば、そうでない場合もあります。関連項目 ルール 2:

ルール 12: 直接最適化する目標は、あまり考えすぎないでください。

収益を上げ、ユーザーを満足させ、世界をより良いものにしたいと考えています。 できます。重視すべき指標はたくさんあります。 （ルール 2 を参照）。ただし、 ML プロセスの早い段階で すべての値が上昇することに気づきます 直接最適化していないものが 多くありますたとえば サイトでのクリック数と滞在時間です通常のショッピングキャンペーンを 費やす時間が増える可能性があります。

そのため、シンプルに保ち、さまざまな指標のバランスについてあまり考えすぎないようにしましょう。 すべての指標を簡単に増やすことができますこのルールも遵守しない ですが ご自身の目標を 組織の最終的な健全性と混同しないでください （参照: ルール 39）。 また、直接広告リンクを増やす 指標を最適化したものの、導入しないことを決定した場合は、客観的な見直しを行い、 必要です。

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

本当の目的は何か、わからないことはよくあります。そう思ったら 古いシステムと新しい ML について、データと並べて分析に着目します。 目標を微調整する必要があることに気づきます。さらに 別のチームは 本当の目標に同意できないことが多々ありますML の目標は、 測定しやすく、「真実」の代用となるもの説明します 実際、多くの場合、「真実」は存在しない（参照: ルール#39）。 まず シンプルな ML の目標に基づいてトレーニングし、「ポリシーレイヤ」の組み込みを検討します。上 これを使用して、追加のロジック（できれば非常にシンプルなロジック）を 決定します。

最も簡単なのは、直接観察され、その要因によって生じるユーザーの行動です。 アクション:

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

最初は間接効果をモデル化しない:

  • ユーザーは次の日に訪問しましたか？
  • ユーザーがサイトにアクセスした時間
  • 1 日のアクティブ ユーザー数。

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

最後に、

  • お客様は製品の使用に満足していますか？
  • ユーザーはエクスペリエンスに満足していますか？
  • その製品は全体的なユーザーのウェルビーイングを向上させていますか？
  • これは会社全体の健全性にどのような影響を与えるか？

これらはすべて重要ですが、測定が非常に困難です。代わりに、 プロキシ: ユーザーが満足すると、サイトに長く滞在する。ユーザーが 明日も訪問する見込みですウェルビーイングと 懸念事項に対処するには 人間の判断が欠かせません 販売しているプロダクトの性質に合わせて ML モデルを学習し ビジネスプランを作成できます

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

線形回帰、ロジスティック回帰、ポアソン回帰は、 決定できます。予測された各予測は、 確率または期待値ですモデルよりもデバッグが容易になるから 目標（ゼロワン損失、さまざまなヒンジ損失など）を使用して、 を使用して分類精度やランキング パフォーマンスを直接最適化できます。対象 トレーニングの確率が、トレーニング中に予測された確率から 並べて見たり、生産システムを検査したりして、この偏差が 問題を明らかにします。

たとえば、線形回帰、ロジスティック回帰、ポアソン回帰では、 平均予測期待値が平均ラベル（1 - タイミングが調整されたか、調整されたばかりかなど）が表示されます。これは、API アカウントを持っていない アルゴリズムが収束したことを確認でき、 あります。各例で 1 または 0 の特徴がある場合 次に、特徴が 1 である 3 つのサンプルのセットが調整されます。また すべての例に 1 の特徴がある場合、すべての例の集合は あります。

シンプルなモデルでは、フィードバック ループ（ ルール 36）。 多くの場合、意思決定にはこれらの確率的予測を使用します。順位 投稿の期待値（クリック、ダウンロードなど）の低下。 ただし、使用するモデルを選択するときは、 モデルに与えられたデータの可能性よりも重要性が ルール 27）。

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

品質ランキングは芸術的なものですが、迷惑メール フィルタは戦争に関係します。これらのシグナルは 投稿の質を判断するための基準は、 その投稿にこれらのプロパティが含まれるように調整します。したがって、次のようになります。 品質ランキングでは、優れた品質のサイトに投稿されたコンテンツをランキングすることに重点を置く必要があります。 信仰スパムをランク付けする際に、品質ランキングの学習者を減らすことはできません 向上します同様に「際どい」品質管理とは別個に処理する必要があります。 ランキング。迷惑メールフィルタは別の話です。ただし、 生成する必要のある特徴は絶えず変化します多くの場合、 明確なルールとしてシステムに配置します（投稿に 取得しないでください）。学習したモデルはすべて、 毎日更新されますコンテンツの作成者の評判は、 非常に重要な役割を果たします。

ある程度のレベルで、これら 2 つのシステムの出力を統合する必要があります。維持 検索結果のスパムフィルタは 迷惑メールフィルタよりも効率的ですまた、これは一般的な方法で、 トレーニング データから得たものです。

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

ML システムのライフサイクルの第 1 フェーズでは、 トレーニング データを学習システムに取り込み、 サービング インフラストラクチャを構築する。変更後 単体テストとシステムテストがインストルメント化された エンドツーエンドのシステムであること フェーズ 2 が開始します。

2 番目のフェーズでは、容易に解決できる問題が数多くあります。さまざまな システムに取り込める明白な特徴量ですしたがって、2 つ目の 可能な限り多くの特徴を取り込み 直感的に組み合わせることができますこのフェーズでは、すべての指標が 増え続けています今後多数のリリースが予定されており、 大勢のエンジニアを雇い、必要なすべてのデータを結合して、 真に素晴らしい学習システムを作ることができます

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

現在作業中のモデルが、モデルの予測を行う最後のモデルであるとは モデルのリリースをやめることになるでしょうしたがって 今回のリリースで複雑性が増すかどうかを検討し、 説明します。多くのチームが四半期あたり以上 提供できます。新しいモデルをリリースする基本的な理由は 3 つあります。

  • 新しい機能が思い浮かびます。
  • 正則化を調整し、古い特徴を新しい方法で組み合わせています。
  • 目標を調整しています。

いずれにせよ、モデルにある程度の愛を持たせるのは良いことです。データを見てみると、 サンプルにフィードすることで、新しいシグナルだけでなく、 あります。そのため、モデルを構築する際は、モデルの追加や削除がどれほど簡単か、 組み合わせることもできます新しいコピーをどれほど簡単に その正しさを検証します顧客の獲得と拡大が可能かどうかを 2 つまたは 3 つのコピーが並行して実行されます。最後に、 このバージョンのパイプラインに 組み込めるかどうかがわかります内容 来四半期にお届けします

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

議論の余地があるポイントかもしれませんが、多くの問題を回避できます。最初の 学習済みの特徴とは何かを説明しましょう学習した特徴とは 外部システム（教師なしクラスタリングなど）によって生成された または学習者自身が（因数分解モデルやディープ ラーニングなどを介して）学習させることもできます。 どちらも便利ですが、問題が多いため、使用する必要があります。 モデル化されます

外部システムを使用して特徴を作成する場合は、 独自の目標があります外部システムの目標は、 現在の目標と相関関係を確認できます外部 IP アドレスのスナップショットを 最新でなくなる可能性がありますアプリから 外部システムを使用している場合、意味が変わる可能性があります。外部システムを使用して、 機能を提供する場合、この方法には細心の注意が必要になります。

因数分解モデルとディープモデルの主な問題は 非凸ですしたがって、最適なソリューションが 各反復処理で見つかった局所的な最小値を 異なりますこのバリエーションでは、特定のキャンペーンの影響が 無意味なものもあれば、ランダムなものもあります。モデルを作成することで、モデルに 優れたベースライン パフォーマンスを得ることができます。この後 より難解なアプローチを試すことができます。

ルール 18: コンテキストを超えて一般化するコンテンツの特徴を探る。

多くの場合、ML システムは大きな全体像のごく一部にすぎません。対象 たとえば「人気の投稿」に掲載される投稿を想像すると、多くのユーザーが [あなたの投稿] に表示される前に、投稿を +1、再共有、コメントします 高温です。それらの統計情報を受講者に提供すれば、新しい投稿をプロモーションできます。 データがないということです。 YouTube 「次のおすすめ」では、複数の視聴や同時視聴を 再生数（動画が視聴された後に別の動画が視聴された回数） 視聴した動画など）が表示されます。YouTube明示的な ユーザーの評価。最後に、ラベルとして使用するユーザー アクションがある場合、 異なるコンテキストでドキュメントに対するアクションを確認できるので、 説明します。これらすべての機能により、新しいコンテンツをコンテキストに取り入れることができます。 これはパーソナライズではなく 次に、そのコンテンツを好む人とそうでない人を見極めるという流れになります。

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

膨大な量のデータを持つため、多くの単純な特徴量を 必要があります。取得するドキュメントの識別子 正規化クエリはあまり一般化されませんが、 ベストプラクティスを紹介しますつまり、 データの一部にしか当てはまらない 全体のカバレッジが 90%を超えています正則化を使用して 例が少なすぎる場合に効果的です。

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

対象物を組み合わせたり変更したりするには、さまざまな方法があります。ML トレーニング データを使用してデータを前処理し、 変換。 最も一般的な 2 つのアプローチは「離散化」です。「クロス」です。

離散化は、連続する特徴を受け取り、多くの 離散させます年齢などの連続的な特徴について考えてみましょう。Google Chat では この場合、年齢が 18 歳未満のときに 1、 （例: 年齢が 18 ～ 35 歳の場合）。インフラストラクチャの境界を ヒストグラムでは、基本的な分位数でほとんどの効果が得られます。

クロスは 2 つ以上の特徴列を組み合わせます。TensorFlow の特徴量列では、 用語は、同種の特徴の集合です（例: {male, female}、{US、 カナダ、メキシコ} など）。クロスは新しい特徴量列で 例: {男性、女性} × {米国、カナダ、メキシコ}。この新しい特徴量列は 特徴が含まれます（男性、カナダ）。TensorFlow を使用していて、 TensorFlow にこのクロスを作成するよう指示すると、この（男性、カナダ）の特徴量は カナダ人の男性を代表する例に含まれている。なお、 3、4、またはそれ以上の底の交差を持つモデルをトレーニングするためのデータ量 特徴列です

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

テキストを処理する方法は 2 つあります。最も厳しいのは ドット積。最も単純な形式のドット積は、単に対象の数を 単語の共通する単語を減らすことができます。この機能はその後 します。もう 1 つのアプローチは交差です。したがって、 これは、「pony」という単語がドキュメントと 「the」という単語が出現する場合に限って含まれる ドキュメントとクエリの両方です

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

この分野に関する統計的学習理論の結果は、 程度の複雑さが加わりますが、このルールは基本的に 知っておく必要があります私も以前から意見が交わされますが、 あらゆるものを 1, 000 の例から学習できます 100 万以上のサンプルが必要です。これは、特定のメソッドで行き詰まっているためです。 学びました。重要なのは、学習をデータのサイズに合わせてスケールすることです。

  1. 検索ランキング システムを担当していて、 含まれている場合、1,000 個の単語が 使用する場合は、ドキュメント間のドット積を使用して、 クエリの特徴（TF-IDF） その他 6 種類ほどの高度で人間工学による 説明します。1, 000 の例、10 の特徴があります。
  2. サンプルが 100 万個ある場合は、ドキュメントとクエリを交差させる 特徴列（正則化と、場合によっては特徴選択を使用） 数百万の特徴量が得られますが 少なくなります1, 000 万の例、10 万個の特徴があります。
  3. 数十億から数千億の例がある場合 特徴選択を使用した、ドキュメント トークンとクエリ トークンを含む特徴列 正則化です。10 億のサンプルと 1, 000 万のサンプルが 説明します。統計学習理論で厳密な境界が与えられることはめったにないが、 出発点として最適です

最終的に ルール 28 使用する機能を決めます。

ルール 22: 使わなくなった機能はクリーンアップする

使用されていない特徴は技術的負債を生む。使用していない場合は、 他の機能と組み合わせてもうまくいかない場合は、 インフラから切り離すことができますインフラストラクチャをクリーンな状態に保ち、 最も有望な機能ができるだけ早く試せるというものでした。条件 機能の追加はいつでも可能です。

どの機能を追加または維持するかを検討する際は、カバレッジを念頭に置いてください。いくつ どうすればよいでしょうか。たとえば パーソナライズ機能を利用しているユーザーは 8% にとどまっています 効果は期待できません。

同時に、一部の特徴量は重みを超える可能性があります。たとえば 特徴量の 1% しかカバーしていないが、サンプルの 90% が 良い特徴があれば もう追加すべきです

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

ML の 3 番目のフェーズに進む前に、 ML のクラスでは教えられないことに 焦点を当てる必要があります モデルを改善する必要がありますこれは単なる芸術ではなく 回避できるアンチパターンもいくつかあります。

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

これが、チームが行き詰まりを感じる最も簡単な方法でしょう。一方で、 チーム内でプロトタイプを使用する fishfooding には多くのメリットがありますが ドッグフーディング（社内でプロトタイプを使用）では、従業員は パフォーマンスが妥当かどうかです明らかに悪い変更ですが 使用しないでください。本番環境と合理的に近いものは、 一般ユーザーにお金を払って質問に答えてもらうか 実際のユーザーを対象としたライブテストで行うことができます。

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

ユーザーからのフィードバックが本当に欲しい場合は、ユーザー エクスペリエンスを使用してください。 方法論があります。ユーザー ペルソナを作成する（説明の 1 つは Bill Buxton の ユーザー エクスペリエンスのスケッチを参照） ユーザビリティ テスト（1 つの 説明は Steve Krug の「 Don’t Make Me Think） 後で説明しますユーザー ペルソナ 仮想的なユーザーを作成しますたとえば、チーム全員が男性で、 35 歳の女性ユーザー ペルソナ（ユーザー 生成された結果を見てください。10 件ではなく、 25 ～ 40 歳の男性。実在の人物を招き、それに対する反応を ユーザビリティ テストで（ローカルまたはリモートで） 見ていきます

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

これまでになく簡単に、場合によっては最も有用な測定手法の一つです。 新しいモデルを見たことがあるとしたら 新しい結果が本番環境から得られたものですたとえば ランキングに問題がある場合 システム全体のサンプルのクエリに対して両方のモデルを実行し、 結果の対称的な差の大きさ（ランキングによって重み付け） あります。差が非常に小さい場合は、コードを実行しなくても ほとんど変更されないテストです差が大きい場合 変化が良好な状態であることを確認する必要があります。見下ろす 対称性の差が大きいクエリは、 定性的に把握できたからですただし システムが最新であることを 示します。モデルをそれ自体と比較したときの値が低い（理想的には）低いことを 対称差を生じます。

ルール 25: モデルを選択するときは、予測能力よりも実用主義のパフォーマンスを優先する。

モデルによってクリック率の予測が試みられることがあります。ただし結局のところ、 その予測をどうするかという問題ですランキングに使用している場合 場合、最終的なランキングの品質がシステムよりも 説明します。ドキュメントがスパムである確率と、 次に ブロックする対象をカットオフして 理解が深まりますほとんどの場合、この 2 つを 同意します。同意しなかった場合、わずかな利益しか見込めません。したがって、 ログ損失は改善されますが、ログのロギング パフォーマンスは 別の機能を探してくださいこれが頻繁に起こると モデルの目的をもう一度確認しましょう

ルール 26: 測定された誤差からパターンを探し、新しい特徴を作成する。

モデルが「正しくない」トレーニング サンプルを見たとします。新しい 偽陽性または偽陰性の可能性があります。 ランキング タスクでのエラーは、ポジティブの方がランクが低いペアである可能性があります。 決定できます最も重要な点は、これがインフラストラクチャの 機械学習システムは問題を認識しており、 学びます。エラーを修正できる特徴をモデルに与えると、 モデルはそれを使用しようとします

一方、サンプルから特徴を作成しようとすると、 誤りとして認識されない場合、その機能は無視されます。たとえば ユーザーが Play のアプリ検索で「無料ゲーム」と検索したとします。仮説 上位の検索結果の 1 つが関連性の低い gag アプリです。そこで、予測を行う特徴量を 「ギャグアプリ」ただし、インストール数とユーザー数を最大化するのであれば、 ユーザーが無料ゲーム「ギャグアプリ」を検索したときにインストール機能 期待した効果を得られません。

モデルが間違っている例が見つかったら、モデルに問題がある傾向を探ります。 現在の機能セットから逸脱していますたとえば、システムの動作状態から 長い投稿の順位を下げる 投稿の長さを増やすあまり具体的に おすすめします。投稿の長さを追加する場合は、 多くの特徴量を追加すれば 何をすべきかモデルに判断させるだけです （ ルール 21 をご覧ください）。これが最も簡単な方法です。

ルール 27: 確認された望ましくない行動を数値化する。

チームの一部のメンバーは、インフラストラクチャのプロパティに不満を覚えるようになるでしょう。 既存の損失関数では捕捉できないちなみに この段階では、不満を強固に変えるために何でもする必要があります。 あります。たとえば「ギャグアプリ」が多すぎると表示されています Play 検索で、人間の評価者がギャグアプリを特定できるようにもなります。（ ヒューマン ラベリングが有効です。このケースでは、 トラフィックの大部分を占めている検索語句の割合）お使いの 問題を測定できれば ありません一般的なルールは、「最初に測定し、2 番目に最適化する」です。

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

すべての doc_id と exact_query を調べる新しいシステムがあり、 クエリごとに各ドキュメントのクリック確率を計算します。 どちらの場合でも、その動作は現在のシステムとほぼ同じであることが判明しました。 比較と A/B テストを行うので、そのシンプルさを考慮して、アプリをリリースしました。 しかし、新しいアプリは表示されていないことに気付きました。その理由は、なぜなら、 そのクエリに関する履歴に基づいてドキュメントのみが表示されます。 新しいドキュメントを表示すべきかどうかがわかります。

このようなシステムが長期的にどのように機能するかを理解するには、 モデルがライブ状態だったときに取得したデータのみを使用してトレーニングを行います。これは非常に 困難です。

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

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

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

Google の本番環境 ML システムのトレーニング パフォーマンスに悪影響を及ぼす サービングスキューが生じるからです最適な解決策は、 システムやデータの変更によってスキューが発生しないよう、モニタリングを明示的にモニタリングする 見過ごされてしまいます。

ルール 29: サービング時と同じようにトレーニングするには、サービング時に使用される特徴のセットを保存しておき、それらの特徴をログにパイプしてトレーニング時に使用することをおすすめします。

すべての事例で実施できないとしても、 サービングとトレーニングの間の整合性を検証できます（ ルール 37）。これを作ったチーム 結果に驚かされることもありました。 YouTube ホームページ サービング時に優れた品質のログ機能に切り替え 改善、コードの複雑さの軽減、多くのチームが乗り換えています。 説明するように

ルール 30: 重要性を重み付けしたサンプリング データを勝手に落とさない

データが多すぎると、ファイル 1 ～ 12 を使用しようとしますが、 13 ～ 99 番目までのファイルは無視します。これは正しいやり方ではありません。古いデータは 破棄される可能性がある場合は、重要度の重み付けが最適です。 あります。重要度の重み付けでは サンプル X を 30% の確率で与え、重みを 10/3 にします。変更後 重要度の重み付け、前述の調整特性のすべてを ルール 14 保持します

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

ドキュメント ID を、そのドキュメントの機能（ （コメントやクリック数など）です。トレーニング時刻とサービング時刻の間で、 テーブルが変更されることがあります。同じドキュメントに対するモデルの予測では、 トレーニングとサービングで違いがありますこの並べ替えを避ける最も簡単な方法は サービング時に特徴を記録することが ルール 32 をご覧ください）。テーブルが テーブルのスナップショットを 1 時間ごとまたは 1 日ごとに設定して かなり近いデータです。この方法では、 あります。

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

バッチ処理はオンライン処理とは異なります。オンライン処理では 受け取ったリクエストを個別に処理する必要があります（たとえば、リクエストごとに個別のルックアップを実行する、 ）ですが、バッチ処理では、複数のタスク（たとえば、 結合など）が含まれます。サービング時にはオンライン処理を行いますが バッチ処理タスクですただし、 できることがあります。たとえば、Pod の状態に基づいて システムに固有のもので、クエリや結合の結果を 保存され、エラーのテストも簡単です。その後、 すべての情報を収集したら、サービング中やトレーニング中に 共通のメソッドを実行して、人間が読み取れるオブジェクト間の 形式や形式を問わず、ML システムが 説明します。これにより、トレーニング サービング スキューの原因を排除できます。たとえば、 トレーニングとトレーニングの間に 2 つの異なるプログラミング言語を 提供しますこの決定を行うと、共有することはほぼ不可能になります。 できます。

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

一般に、モデルのパフォーマンスは、データの収集後に収集されたデータで測定します。 モデルをトレーニングできます。これは、 できます。1 月 5 日までのデータに基づいてモデルを作成する場合、 モデルを再トレーニングしましたパフォーマンスが 新しいデータではそれほど悪化しませんが、根本的に悪化することはないはずです。 日常的な影響がある可能性があるため、平均クリック数を予測できない可能性がある グラフの下の領域は 肯定的な例に否定的な例よりも高いスコアを与える可能性 ある程度近いはずです

ルール 34: フィルタリングのためのバイナリ分類（スパムの検出や関心のあるメールの判別など）では、非常にクリーンなデータに対して、パフォーマンスを短期間でわずかに犠牲にします。

フィルタリング タスクでは、ネガティブとマークされた例は、 できます。ネガティブ サンプルの 75% をブロックするフィルタがあるとします。 役立ちます生成されたデータから追加のトレーニング データを引き出したくなるかもしれませんが、 表示されます。たとえば、ユーザーがメールを迷惑メールに分類すると、 そこから学ぶことができます。

しかしこの方法ではサンプリング バイアスが発生します。よりクリーンなデータを収集できる 代わりに、すべてのトラフィックの 1% に「保留」というラベルを付け、 ユーザーに例を挙げてもらいました。フィルタで除外されたページの少なくとも 74% ネガティブ サンプルを排除します。提示された例をトレーニング データとして使用できます。

フィルタが否定的なサンプルの 95% 以上をブロックしている場合、 実用性が低くなります。それでもなお 広告配信の成果を 測定したい場合は より小さなサンプル（0.1% や 0.001% など）を作成できます。10 個 パフォーマンスを正確に推定するには 数千の例で十分です

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

検索結果が変わるようにランキング アルゴリズムを根本的に入れ替えると、 アルゴリズムが出力するデータが 事実上変更されていることが示されます 説明します。このような歪みが生じます その周囲にモデルを作成します。アプローチは複数あります。これらのアプローチは モデルに与えられたデータに 優先順位を付けることができます

  1. より多くのクエリをカバーする特徴量の正則化が、 1 つのクエリに対してのみオンになっている機能ですこれにより、モデルはトレーニングの 特定の特徴に対する特定のクエリに特有の すべてのクエリに一般化できます。このアプローチにより、特定のリソースへの 関連性のないクエリに漏れるのを防ぐことができます。これは、ファイアウォール ルールの 特徴量列の正則化に関する従来のアドバイス 作成します
  2. 正の重みを持つ特徴のみを許可する。そのため 良い特徴は 「未知」の特徴よりも優れていると考えます。
  3. ドキュメントのみの機能は利用できません。これは 1 番の極端なバージョンです。対象 人気があるダウンロードのアプリであっても、そのアプリが 場所によっては表示したくない場合ですドキュメントのみの機能はない 機能によって簡単に操作できます。特定のキャンペーンを表示したくない理由 あらゆる場所で人気が高いアプリです 目的のアプリをすべて到達可能にしますたとえば、ユーザーが Google Chat で 「怒っている鳥」をダウンロードするかもしれませんが 考えていませんでしたそのようなアプリを表示すると、ダウンロード率は向上する可能性がありますが、 最終的にユーザーのニーズが満たされなくなります

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

コンテンツの位置はユーザーが操作する可能性に大きく影響する できます。アプリを掲載順位 1 位に配置すると、クリック数が増えます。 クリックされる可能性も高まりますこれに対処する一つの方法は これは位置特徴、つまり対象物の位置に関する おすすめします位置特徴量でモデルをトレーニングすると 重みを学習する（たとえば、特徴「1stposition」大幅に低下しましたモデル そのため、"1stposition=true" の例については、他の要因の重みが小さくなります。 次に、サービング時に、どのインスタンスにも位置的特徴を渡さず、 すべて同じデフォルトの特徴にできます。これは、最初に候補を採点するためです どの順番で表示するかは決まっています。

なお、位置的な対象物は、ターゲット対象物と トレーニングとテストの間に非対称性があるためです。 モデルが位置特徴の関数の和と 残りの特徴量は理想的ですたとえば、単語のシーケンスを 位置の特徴をドキュメント特徴と併用できます

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

最も一般的な意味で歪みが生じる原因はいくつかあります。 さらに、テストはいくつかの部分に分けることができます。

  • トレーニング データのパフォーマンスとホールドアウトのパフォーマンスの差 できます。一般的に、これは常に存在するものであり、必ずしも悪いわけではありません。
  • ホールドアウト データと「翌日」のパフォーマンスの差 できます。繰り返しになりますが、これは常に存在します。正則化を調整して、 翌日のパフォーマンスを最大化できますしかし パフォーマンスの大幅な低下は 予測から、いくつかの特徴が 時間的制約があり、モデルのパフォーマンスが低下するおそれもあります。
  • 「翌日」のパフォーマンスの差ライブデータとは できます。トレーニング データのサンプルにモデルを適用し、 まったく同じ結果が得られるはずです（ ルール 5 をご覧ください）。 したがって、この不一致はエンジニアリング エラーを示している可能性があります。

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

第 2 フェーズの終了に近づいている兆候が見えてきます。 まず、月あたりの収益が減少し始めます。新しい P-MAX キャンペーンを トレードオフがあります。上がることもあれば下がることもあります。 学びました。興味深いのはここです。デメリットは、デメリットの方が ML はより高度化する必要があります。注意点: 以前のセクションよりも多くの BlueSky ルールが含まれています。多くのチームが 段階 1 とフェーズ 2 の ML の幸せな時期を振り返りましょう。一旦 III に到達。チームは独自の道筋を見つける必要があります。

ルール 38: 整合性のない目標が原因で、新機能に時間を浪費しないようにする。

測定値が横ばいになると、チームは 現在の ML システムの目標の範囲外ですとして 目標が既存のアルゴリズムでカバーされない場合は、 目標または商品目標を変更する必要があります対象 たとえば、クリック数、+1、ダウンロード数を最適化しながら、 人間による評価にもとづく判断を下します

ルール 39: リリースの決定は長期的なプロダクト目標を表す。

アリスさんは、インストール数の予測におけるロジスティック ロスを減らすことを考えています。彼女 特徴を追加します。ロジスティックの損失が下がります。彼女は実際の実験を行うと、 インストール率も上昇しましたしかし、リリース レビューに参加して 1 日のアクティブ ユーザー数が 5% 減少したことが指摘されています。 チームはこのモデルをリリースしないと決定する。Alice はがっかりしていますが、 導入の決定は複数の基準に左右される ML を使用して直接最適化できます

現実の世界はダンジョンでもドラゴンでもなく、真実は「ヒット」 点」商品の状態を把握できますチームは システムの健全性を効果的に予測するために収集した統計情報を使用 使用できます。エンゲージメントを重視する必要がある（1 日のアクティブ ユーザー（DAU））、30 DAU、収益、広告主様の費用対効果これらの指標は A/B テストで測定可能であること自体は、長期的な指標にすぎない ユーザーの満足度、ユーザー数の増加、パートナーの満足度、利益 その場合でも、高品質で有用かつ高品質なコンテンツを 5 年後には会社として成功するでしょう

すべての指標が改善された場合（または少なくとも 悪化しないことなど）チームが高度なマシンから 単純なヒューリスティックが、単純なヒューリスティックを ヒューリスティックを選択すべきですさらに、 取り得るすべての指標値を明示的にランク付けするものではありません。具体的には 次の 2 つのシナリオがあります

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

現在のシステムが A であれば、チームが B に切り替える可能性は低くなります。条件 現在のシステムが B である場合、チームが A に切り替える可能性は低くなります。この 合理的な行動と矛盾していると思われる場合。予測された変化は パフォーマンス指標がうまくいかない場合もあるため、 変更してください。各指標は、チームが関係するリスクをカバーしています。

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

一方、個人は、自分が達成できる目標を 1 つに絞る傾向があります 直接最適化できます。ほとんどの ML ツールは、このような環境に適しています。「 エンジニアが新機能をリリースすると、 できます。ML の種類には多目的学習があります この問題への対処が始められます。たとえば、あるトピックについて 各指標の下限を持つ制約満足度問題 指標の線形結合を最適化しますしかしその場合でも、 ML の目標として簡単に捉えることができます。つまり、ドキュメントが ユーザーがクリックしたりアプリがインストールされたりすると、そのコンテンツが表示されたためです。しかし、 ユーザーがサイトにアクセスする理由を特定するのがはるかに難しくなります。予測値の予測方法、 将来的にサイト全体で成功を収めるためには AI による完全完成: コンピュータと同じくらい難しい 画像処理や自然言語処理などです。

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

未加工の特徴を取り込んでコンテンツを直接ランク付けする統合モデルは、 デバッグと理解が容易なモデルです。ただし、複数のモデル（ 「モデル」（他のモデルのスコアを組み合わせたもの）の方が性能が高くなります。 各モデルは、入力のみを受け取るアンサンブルか、 両方ではなく多数の特徴を使用するベースモデルなどが挙げられます。既存の 個別にトレーニングされた他のモデルを基盤として構築され、それらのモデルを組み合わせる 不正な動作につながることがあります

「ベース」の出力のみを使用するシンプルなモデルをアンサンブルに使用する 入力として使用します。また、これらのアンサンブル モデルにプロパティを適用したいと考えています。 たとえば、ベースモデルによって生成されたスコアの増加は、 アンサンブルのスコアを下げます。また、導入するモデルが新しいモデルに 意味的に解釈可能（調整されたものなど）として扱うことで、 アンサンブル モデルを混同しないことです。また、関連するすべての 基になる分類器の予測確率の増加は アンサンブルの予測確率を下げます。

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

先ほど、ユーザーの属性情報をいくつか追加しました。すでに追加されています ドキュメント内の単語に関する情報です。テンプレートが完了しました 正則化を調整しました今までに一度もリリースしたことがない わずか数四半期で主要な指標が 1% 改善したとはいえません。次のステップ

今こそ、根本的に異なる組織のためにインフラストラクチャの構築を始めるときです。 このユーザーが Google Chat でアクセスしたドキュメントの履歴など、 前日、前週、前年のデータ、または別のプロパティのデータ。使用 Wiki データ 企業内部のもの（Google の ID など） ナレッジグラフをご覧ください）。深い階層を使用する 学びます。期待値の調整を開始する それに応じて取り組みを拡大できますその他 新しい特徴量を追加することのメリットと 複雑さが増す代わりにパフォーマンスが 低下する可能性があります

ルール 42: 多様性、パーソナライゼーション、関連性と人気度の相関は、想定しているほどではない。

一連のコンテンツにおける多様性は、さまざまな意味を持つ可能性があり、 最も多いものの一つですパーソナライズとは 結果が表示されます関連性は、特定のエンティティに対する そのクエリに適していると判断できます。したがって これらのプロパティは通常とは異なるものとして定義されています。

問題は、普通は勝ちにくい傾向にあることです。

クリック数、滞在時間、視聴、+1、 コンテンツの人気を測定することになります。チーム 多様性のある個人モデルを 学習しようとすることもありますパーソナライズするために システムがパーソナライズできる機能（一部の特徴量は 多様化（このドキュメントに 返される他のドキュメントと共通する機能（投稿者やコンテンツなど） その特徴量の重みが小さくなる（または符号が異なる）ことが 期待以上です。

これは、多様性、パーソナライズ、関連性に価値がないという意味ではありません。 前のルールで説明したように、後処理を実行して、 多様性または関連性です長期的な目標が増加した場合は 人気以外に、多様性/関連性に価値があると宣言する。Google Chat では 後処理を引き続き使用するか、 多様性または関連性に基づいて 目標を設定することです

ルール 43: 友だちはどのサービスでも同じ傾向がある。あなたの興味の対象は、必ずしもそうではありません。

Google のチームは、予測を行うモデルを採用することで、 あるプロダクトでの接続の近さと 別のプロダクトでの正常な動作です 友だちは本物です。その一方で 複数のチームが サービスの分断にわたるパーソナライゼーション機能に苦労しています。はい、そうです 考えてみましょう今のところ、そうではないようです。何が起こったか あるプロパティの元データを使用して別のプロパティの行動を予測するというものですまた、 ユーザーが別のプロパティの履歴を持っていることがわかっていても、 できます。たとえば、2 つのサービスでユーザー アクションが存在する場合、 インジケーターとなります。

ML については、Google 内外で多数のドキュメントがあります。

謝辞

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、Sishhir Birmiwal、Gal Elidan、Su Lin Wu、Jaihui Liu、Fernando Pereira、Hrishikesh Aradhye が多くの修正を行いました。 ヒント、役立つ例が記載されています。また Kristen のおかげで Lefevre、Sudda Basu、Chris Berg は、以前のバージョンで協力してくれました。制限なし 間違い、欠落、（感嘆して！）という意見は私自身のものです。

付録

このドキュメントには、Google プロダクトへのさまざまな言及が含まれています。宛先 最も一般的な例について簡単に説明します。 ご覧ください

YouTube の概要

YouTube はストリーミング動画サービスです。YouTube の「次のおすすめ」と YouTube ホームの両方 ページチームは ML モデルを使用して動画のレコメンデーションをランク付けします。次のおすすめ 再生中の動画の後に再生される動画が表示され、トップページにはおすすめ動画が表示されます。 ホームページを閲覧するユーザーに 動画を表示します

Google Play の概要

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

Google+ の概要

Google Plus はさまざまな状況で ML を活用: 「ストリーム」ユーザーが閲覧した投稿のうち、「注目の投稿」をランク付け件の投稿（posts 知名度の高いランキングなどですGoogle+ 2019 年にすべての個人アカウントが閉鎖され、Google Currents に置き換わりました ビジネスアカウントについて 2020 年 7 月 6 日に公開されました