Share via

コンテキストとアクション

  • [アーティクル]

重要

2023 年 9 月 20 日以降は、新しい Personalizer リソースを作成できなくなります。 Personalizer サービスは、2026 年 10 月 1 日に廃止されます。

Personalizer は、特定のコンテキストでアプリケーションがユーザーに表示する内容を学習することで機能します。 コンテキストとアクションは、Personalizer に渡す最も重要な 2 つの情報です。 コンテキストは、現在のユーザーまたはシステムの状態に関する情報を表し、アクションは選択肢となるオプションです。

Context

コンテキストの情報は各アプリケーションとユース ケースに左右されますが、通常、次のような情報が含まれます。

  • ユーザーの人口統計情報とプロフィール情報。
  • ユーザー エージェントなど、HTTP ヘッダーから抽出された情報、または IP アドレスに基づく地理的逆参照など、HTTP 情報から誘導された情報。
  • 曜日、週末または平日、午前または午後、休暇期または労働期など、現在の時間に関する情報。
  • 場所、移動、バッテリ レベルなど、モバイル アプリケーションから抽出された情報。
  • このユーザーが最も多く視聴している映画のジャンルなど、ユーザーの過去の行動の集計。
  • システムの状態に関する情報。

アプリケーションは、関連するデータベース、センサー、システムからコンテキストに関する情報を読み込む役目を担います。 コンテキスト情報が変わらない場合、Rank API に送信する前に、この情報をキャッシュするロジックをアプリケーションに追加できます。

アクション

アクションはオプションの一覧を表します。

アクションに順位を付ける場合は、50 を超えるアクションを送信しないでください。 毎回同じ 50 のアクションになることもあれば、変わることもあります。 たとえば、eコマース アプリケーションに品物が 10,000 個の製品カタログを用意している場合、レコメンデーションまたはフィルター エンジンを使用し、顧客が気に入りそうな上位 40 品目を決定することができます。さらに、Personalizer を使用し、現在のコンテキストに対して生成されるリワードが最も大きい品目を見つけることもできます。

アクションの例

Rank API に送信するアクションは、パーソナライズしようとしている内容に依存します。

次に例をいくつか示します。

目的 アクション
ニュース Web サイトで強調表示する記事をパーソナライズします。 各アクションは潜在的にニュース記事です。
Web サイトでの広告配置を最適化します。 各アクションはレイアウトか広告のレイアウトを作成するルールになります (たとえば、上、右、小さい画像、大きい画像)。
買い物 Web サイトにお勧めの品目を個人的にランク付けして表示します。 各アクションは特定の製品になります。
特定の写真に適用するフィルターなど、ユーザー インターフェイス要素を提案します。 各アクションは異なるフィルターになることがあります。
チャット ボットの応答を選択し、ユーザーの意図を明確にするか、アクションを提案します。 各アクションは、応答を解釈する方法の選択肢です。
検索結果一覧の一番上に表示するものを選択します 各アクションは上位検索結果の 1 つです。

クライアント アプリケーションからアクションを読み込む

アクションのフィーチャーは通常、コンテンツ管理システム、カタログ、推奨システムを情報源とします。 アプリケーションは、関連するデータベースやシステムからアクションに関する情報を読み込む役目を担います。 アクションが変わらない場合、あるいは毎回読み込むことがパフォーマンスに不要な影響を与える場合、この情報をキャッシュするロジックをアプリケーションに追加できます。

ランク付けの対象からアクションを外す

ユーザーに見せたくないアクションが存在する場合があります。 アクションに順位を付けないようにするための最善の方法は、そのアクションを除外アクション リストに追加するか、順位要求に渡さないようにすることです。

場合によっては、既定でイベントをトレーニングしないようにすることをお勧めします。 つまり、特定の条件が満たされた場合にのみイベントをトレーニングするようにします。 たとえば、Web ページのパーソナル化された部分が折りたたみの下にあるとします (ユーザーは、パーソナル化されたコンテンツを操作する前にスクロールする必要があります)。 この場合に、ページ全体をレンダリングしても、ユーザーがスクロールしてパーソナル化されたコンテンツを操作できる状態にならないとイベントがトレーニングされないようにする必要があります。 このような場合は、エンド ユーザーが操作する機会がなかった既定の報酬 (およびトレーニング) イベントを割り当てないように、イベントのアクティブ化を延期する必要があります。

機能

コンテキストと選択できるアクションの両方について、フィーチャーを使用して説明します。 フィーチャーは、報酬を最大化するための意思決定プロセスにおいて、重要と考えられるすべての情報を表します。 各タイムスタンプで最適なアクションを選択する任務を負っていることを想像し、次のように自問することから始めることをお勧めします。「情報に基づいた意思決定を行うためにどのような情報が必要か。 コンテキストと考えられる各アクションを記述するために使用できる情報は何か」。特徴は汎用的なものでも、アイテムに固有のものでもかまいません。

Personalizer では、アクションとコンテキストに対して送信できるフィーチャーを規定したり、制限したり、修正したりすることはありません。

  • 時間の経過と共に、コンテキストやアクションに関するフィーチャーを追加したり、削除したりすることができます。 Personalizer では、利用可能な情報から学習が継続されます。
  • カテゴリの特徴の場合、使用可能な値を事前に定義する必要はありません。
  • 数値の特徴の場合、範囲を事前に定義する必要はありません。
  • アンダースコア _ で始まるフィーチャー名は無視されます。
  • フィーチャーのリストが大きくなる (数百) 可能性がありますが、簡潔なフィーチャー セットから始めて、必要に応じて拡張することをお勧めします。
  • アクション フィーチャーは、コンテキスト フィーチャーと相関関係がある場合もあれば、ない場合もあります。
  • 使用可能ではない特徴は要求から除外する必要があります。 特定のフィーチャーの値が特定の要求で使用できない場合は、この要求で対象のフィーチャーを省略してください。
  • null 値を持つフィーチャーは送信しないようにしてください。 null 値は、"null" という値を持つ文字列として処理されますが、これは望ましくありません。

時間の経過とともにフィーチャーが変化するのは、自然なことであり問題ありません。 ただし、Personalizer の機械学習モデルは、認識したフィーチャーに基づいて適応するこを留意してください。 すべての新しい特徴を含む要求を送信した場合、Personalizer のモデルは、過去のイベントを利用して現在のイベントに最適なアクションを選択できなくなります。 "安定した" フィーチャー セット (繰り返しフィーチャーを含む) を使用すると、Personalizer の機械学習アルゴリズムのパフォーマンスの向上に役立ちます。

コンテキストの特徴

  • 一部のコンテキスト フィーチャーは、一部の時間にしか使用できない場合があります。 たとえば、ユーザーがオンライン食料品店の Web サイトにログインしている場合、コンテキストには購入履歴を記述するフィーチャーが含まれます。 これらの特徴は、ゲスト ユーザーでは使用できません。
  • 少なくとも 1 つのコンテキスト フィーチャーが必要です。 Personalizer では、空のコンテキストはサポートされていません。
  • コンテキスト フィーチャーがすべての要求で同じである場合、Personalizer はグローバルに最適なアクションを選択します。

アクションの特徴

  • すべてのアクションに同じフィーチャーを含める必要はありません。 たとえば、オンライン食料品店のシナリオでは、電子レンジ対応のポップコーンには "調理時間" の特徴がありますが、きゅうりにはありません。
  • 特定のアクション ID のフィーチャーは 1 日だけ利用できて、その後は利用不可能になることがあります。

例 :

以下は、アクション フィーチャーの好例です。 これらは各アプリケーションに大きく依存します。

  • アクションの特性を持つフィーチャー。 たとえば、それは映画ですか? それともテレビ シリーズですか?
  • 過去にユーザーがこのアクションとどのようにやりとりした可能性があるかに関するフィーチャー。 たとえば、この映画は人口統計 A または B の住民が一番多く見ています。再生回数は概して 1 回のみです。
  • ユーザーがアクションを見る方法という特性に関するフィーチャー。 たとえば、サムネイルに表示されている映画のポスターには、顔、車、または景色が含まれていますか?

サポートされているフィーチャーの種類

Personalizer では、フィーチャーとして文字列、数値、ブールをサポートしています。 多くの場合、いくつかの例外を除いて、アプリケーションでは主に文字列の特徴が使用されます。

Personalizer でフィーチャーの種類が機械学習に与える影響

  • 文字列: 文字列型の場合、すべてのキーと値 (フィーチャー名、フィーチャー値) の組み合わせがワンホット フィーチャーとして扱われます (たとえば、category:"Produce" と category:"Meat" は、内部的には機械学習モデルの異なるフィーチャーとして表されます)。
  • 数値: 数値がパーソナル化の結果に比例して影響する規模である場合にのみ、数値を使用してください。 これはシナリオに大きく依存します。 数値単位に基づき、意味が線形ではないフィーチャー (年齢、気温、身長など) は、カテゴリ文字列としてエンコードすることをお勧めします。 たとえば、年齢は "Age":"0-5"、"Age":"6-10" などのようにエンコードできます。高さは、"Height": "<5'0"、"Height": "5'0-5'4"、"Height": "5'5-5'11"、"Height":"6'0-6-4"、"Height":">6'4" のようにバケット化できます。
  • Boolean
  • 配列 数値配列のみがサポートされます。

機能エンジニアリング

  • 規模ではないフィーチャーには、カテゴリと文字列の型を使用します。
  • パーソナル化を進めるために十分なフィーチャーがあることを確認してください。 コンテンツの対象を絞り込む必要性が上がるにつれて、必要とされるフィーチャーの数も増えます。
  • 多様な "密度" のフィーチャーがあります。 たくさんの項目が 2、3 のバケットにグループ化される場合、フィーチャーは密度が高くなります。 たとえば、大量の動画を "長編" (5 分以上) と "短編" (5 分未満) に分類できます。 これは非常に密度の高いフィーチャーです。 一方で、同じくらい大量の項目に "タイトル" という属性を与えることができます。その属性に項目間で同じ値が与えられることはほとんどありません。 これは密度が非常に低い、まばらなフィーチャーです。

高密度のフィーチャーを使用すると、Personalizer は項目間で学習を外挿することができます。 ただし、フィーチャーが数個しかなく、それらの密度が高すぎる場合、Personalizer は、少ないバケットからしか選択できないコンテンツを正確にターゲットにしようとします。

フィーチャー設計と書式設定に関する一般的な問題

  • カーディナリティの高いフィーチャーを送信します。 多くのイベントで繰り返される可能性が低い、一意の値を持つフィーチャー。 たとえば、ある個人を特定できる情報 (名前、電話番号、クレジット カード番号、IP アドレスなど) は、Personalizer で使用しないでください。
  • ユーザー ID の送信 ユーザー数が多い場合、この情報が Personalizer 学習に関連して平均報酬スコアを最大化する可能性は低くなります。 ユーザー ID (個人を特定できる情報ではなくても) を送信することは、モデルにノイズが増える可能性が高いため、推奨されません。
  • 数回以上発生することがめったにない一意の値を送信します。 より詳細にフィーチャーをバケット化することをお勧めします。 たとえば、"Context.TimeStamp.Day":"Monday" や "Context.TimeStamp.Hour":13 などのフィーチャーを持つことは、有用である場合があります。これは、それぞれ 7 個と 24 個しか一意の値が存在しないためです。 しかし、"Context.TimeStamp":"1985-04-12T23:20:50.52Z" は非常に厳密であり、非常に多くの一意の値を持っているため、Personalizer がそこから学習するのは非常に困難です。

フィーチャー セットを改善する

フィーチャー評価ジョブを実行して、ユーザーの行動を分析します。 これにより、過去のデータを見て、ポジティブなリワードに大きく貢献しているフィーチャーと貢献度が低いフィーチャーを比較できます。 どのフィーチャーが役立っているのか判断できます。Personalizer に送信するより良いフィーチャーを見つけ、結果をさらに改善するのは利用者とそのアプリケーション次第となります。

人工知能や Azure AI サービスでフィーチャー セットを拡大する

AI や、すぐに実行できる Azure AI サービスは Personalizer にとって非常に強力な追加機能となります。

人工知能サービスを利用して項目を事前に処理することで、パーソナライズに関連する可能性がある情報を自動的に抽出できます。

以下に例を示します。

  • Video Indexer で映画ファイルを実行し、シーンの要素、テキスト、センチメント、その他さまざまな属性を抽出できます。 そのような属性は密度を高くし、元の項目メタデータにはなかった特性を反映できます。
  • たとえば、画像は物体検出で、顔はセンチメントで実行できます。
  • テキストに含まれる情報は、エンティティやセンチメントを抽出し、Bing ナレッジ グラフでエンティティを拡大することで強化できます。

他にも次のような Azure AI サービスを利用できます。

埋め込みをフィーチャーとして使用する

さまざまな機械学習モデルからの埋め込みは、Personalizer に効果的なフィーチャーであることが実証されています。

  • 大規模言語モデルからの埋め込み
  • Azure AI Vision モデルからの埋め込み

名前空間

必要に応じて、(コンテキストとアクションの両方のフィーチャーに関連する) 名前空間を使用して、フィーチャーを整理することもできます。 名前空間を使用すると、トピック別、ソース別、またはアプリケーションで意味のあるその他のグループ別にフィーチャーをグループ化できます。 名前空間を使用するかどうか、およびどのような名前空間にするかを決定してください。 名前空間は、フィーチャーを個別のセットに整理したり、類似した名前のフィーチャーを明確にしたりします。 名前空間は、フィーチャー名に追加される "接頭辞" と考えることができます。 名前空間は入れ子にしないでください。

アプリケーションで使用されるフィーチャーの名前空間の例:

  • User_Profile_from_CRM
  • 時刻
  • Mobile_Device_Info
  • http_user_agent
  • VideoResolution
  • DeviceInfo
  • Weather
  • Product_Recommendation_Ratings
  • current_time
  • NewsArticle_TextAnalytics

名前空間の名前付け規則とガイドライン

  • 名前空間は入れ子にしないでください。
  • 名前空間の先頭は一意の ASCII 文字にする必要があります (UTF-8 ベースの名前を使用することをお勧めします)。 現在、同じ文字で始まる複数の名前空間が存在すると競合が発生する可能性があるため、名前空間が相互に異なる文字で始まるようにすることを強くお勧めします。
  • 名前空間では、大文字と小文字が区別されます。 たとえば user と User は異なる名前空間と見なされます。
  • フィーチャー名は複数の名前空間をまたいで繰り返し使用でき、別個のフィーチャーとして扱われます。
  • コード < 32 (印刷不可)、32 (スペース)、58 (コロン)、124 (パイプ)、126 から 140 の各文字は使用できません。
  • アンダースコア _ で始まるフィーチャー名はすべて無視されます。

JSON の使用例

アクション

Rank を呼び出すとき、次から複数のアクションを選択して送信します。

JSON オブジェクトには、入れ子にした JSON オブジェクトと単純なプロパティ/値を含めることができます。 配列は、配列の項目が数値の場合にのみ含めることができます。

{
    "actions": [
    {
      "id": "pasta",
      "features": [
        {
          "taste": "salty",
          "spiceLevel": "medium",
          "grams": [400,800]
        },
        {
          "nutritionLevel": 5,
          "cuisine": "italian"
        }
      ]
    },
    {
      "id": "ice cream",
      "features": [
        {
          "taste": "sweet",
          "spiceLevel": "none",
          "grams": [150, 300, 450]
        },
        {
          "nutritionalLevel": 2
        }
      ]
    },
    {
      "id": "juice",
      "features": [
        {
          "taste": "sweet",
          "spiceLevel": "none",
          "grams": [300, 600, 900]
        },
        {
          "nutritionLevel": 5
        },
        {
          "drink": true
        }
      ]
    },
    {
      "id": "salad",
      "features": [
        {
          "taste": "salty",
          "spiceLevel": "low",
          "grams": [300, 600]
        },
        {
          "nutritionLevel": 8
        }
      ]
    }
  ]
}

Context

コンテキストは、Rank API に送信される JSON オブジェクトとして表現されます。

JSON オブジェクトには、入れ子にした JSON オブジェクトと単純なプロパティ/値を含めることができます。 配列は、配列の項目が数値の場合にのみ含めることができます。

{
    "contextFeatures": [
        {
            "state": {
                "timeOfDay": "noon",
                "weather": "sunny"
            }
        },
        {
            "device": {
                "mobile":true,
                "Windows":true,
                "screensize": [1680,1050]
            }
        }
    ]
}

名前空間

次の JSON では、user、environment、device、および activity が名前空間です。

注意

フィーチャー名前空間には、異なる文字で始まる UTF-8 ベースの名前を使用することを強くお勧めします。 たとえば、user、environment、device、および activity はそれぞれ、u、e、d、および a で始まります。 現時点では、同じ文字で始まる複数の名前空間が存在する場合、競合が発生する可能性があります。

{
    "contextFeatures": [
        { 
            "user": {
                "profileType":"AnonymousUser",
                "Location": "New York, USA"
            }
        },
        {
            "environment": {
                "monthOfYear": "8",
                "timeOfDay": "Afternoon",
                "weather": "Sunny"
            }
        },
        {
            "device": {
                "mobile":true,
                "Windows":true
            }
        },
        {
            "activity" : {
                "itemsInCart": "3-5",
                "cartValue": "250-300",
                "appliedCoupon": true
            }
        }
    ]
}

次のステップ

強化学習