Show Menu
トピック×

Experience Decisioning domain model

In this section, the components of Decisioning Service are explained and the ways in which those components interact are detailed. 概念とその関係は、判定問題の​ ドメイン ​を形成します。These fundamental components come into play regardless of how you use Decisioning Service.

判定オプション

エクスペリエンス​ 判定オプション ​は、特定の顧客に提示できる潜在的なエクスペリエンスです。オプションは、選択肢または代替とも呼ばれます。When deciding on the next best option for a customer, Decisioning Service considers options d 1 to d N from amongst a finite set of options D .
判定は、利用可能な一連のオプションの中で最適なオプションを特定することでおこなわれます。1 つのアプローチは、いずれか 1 つだけが残るまでセット​ d から​ 判定オプション​ ​d i ** を連続的に削除し、残りのセットから「勝者」をランダムに選択することです。もう 1 つの意思決定方法は、残りの(適格な)判定オプションを、期待される結果に従ってランク付けすることです。

判定オプションの有限セット

エクスペリエンス判定ドメインでは、1 つ以上の選択元となるオプションが事前に存在し、判定を計算しても、その場で新しいオプションは作成されません。選択肢の領域は判定時には有限だと言います。これは制限のように見えますが、有限のオプションセットは機械学習アルゴリズムや類似の手法を使用して、どのオプションが「最も良い」かを判断する可能性を生み出します。多くの学習アルゴリズムは、互いに比較できず、サンプルデータが存在しない無限の代替オプションの中で最適なオプションを生み出せません。

判定結果

判定の出力 d と結果 o 、つまり決定によって規定された結果を区別することが重要です。判定は、直接結果を生み出すことはできない場合が多いです。判定は、最適な結果を得るためのオプションを選択(または提案)するだけです。提案と成果の間で、多くのイベントややりとりが起こり、多くの場合、数日または数週遅れます。より正式な言い方では、結果は判定の機能 o = f(d) です。
最適な判定を見つけるために、各結果に​ ユーティリティ値 U(o) = U(f(d)) が割り当てられます。 オファー判定の使用例では、その機能はオファーを満たすためのコストと、オファーが顧客に受け入れられたときにビジネスが得る価値を計算します。結果は、すべてのオプション(オファー)に対してユーティリティ値を最大限にすることで、最適な判定(オファー)を見つけるために使用されます。
一般に、特定の判定の結果がどうなるかを確実に予測することは不可能で、確率的アプローチが必要です。 ユーティリティ値 U(o) は、 判定オプションの期待されるユーティリティ値 EU(d) になります。

判定提案

判定提案 ​とは、実際の判定リクエストに応じて作成された、選択された判定オプションのことです。上述の通り、判定の結果ははるかに後に起こり、一歩では成し遂げられません。したがって、様々な​ エクスペリエンスイベント ​を通じて提案をトラックし、判定オプションに関連付けることが重要です。このフィードバックループは、 EU(d) の予測精度を向上させるために使用されます。
提案はエンティティとして持続され、識別子を持ちます。エンティティは、選択したオプションへの参照を保持し、決定に使用されたコンテキストデータを記録できます。識別子を持つことで、他のエンティティも参照できます。その一つが​ 判定イベント ​です。判定(提案)がなされた時点のタイムスタンプが保持されます。判定イベントは、判定を実行するというアクションの発生を記録したものでです。提案イベントを参照するその他のエンティティは、エクスペリエンスイベントです。すべてのエクスペリエンスイベントを拡張して、判定の提案を参照できます。そうする解釈は、エクスペリエンスのイベントを、完全に、または部分的に、判定の提案に関連付けることができるという点です。

判定戦略 — アルゴリズム

選択肢の選択肢が有限であるため、各​ 判定戦略 ​は基本的にアルゴリズムまたは関数であり、 N ​判定オプション {d 1、d 2、…d N} を入力として受け取り、判定オプションのランク付けされたリスト​ (d r1、d r2、…d rk) ​を生成します。これにより、リストの最初の判定オプションは期待されるユーティリティに従って最適と見なされ、結果リストの 2 番目のオプションは 2 番目に最適なオプションと見なされます。通常、セットの基数は、結果のランクリストよりも高くなります。判定アルゴリズムによって、適格でないオプションが削除され、上位の K オプションのみが返されるようにアルゴリズムが設定され、十分なオプションが見つかった場合は停止します。 次の図に、一般的な判定フレームワークを示します。

判定アクティビティ

判定アクティビティ :特定の判定戦略のアルゴリズムを設定し、パラメーターを指定します。戦略パラメーターには、オプションに適用される制約とランキング関数が含まれます。すべての判定は、アクティビティのコンテキストでおこなわれます。Decisioning Service ホストには多数のアクティビティが含まれ、アクティビティはチャネル間で再利用できます。 常に、最適なオプションは、最新の拘束、ルール、モデルのセットに基づいて評価されます。
判定アクティビティは、考慮する判定オプションのコレクションを定義します。このアクティビティに関連するすべてのオプションのサブセットをフィルターします。This allows the Decisioning service to manage topical categories within the catalog of all options.
判定アクティビティは、組み合わされた制約によって他のすべてのオプションが無効になった場合の​ フォールバックオプション ​を指定します。つまり、現在「最良」の選択肢は何かという質問に対する答えは常にあるということです。
判定アクティビティは、エクスペリエンスの配信先を指定できます。これにより、考慮可能な判定オプションの数がさらに減り、判定アクティビティによって課せられるもう 1 つの制約になります。これは​ 配置制約 ​と呼ばれます。この配置制約を満たすコンテンツを持つ判定オプションのみが考慮されます。これは、判定戦略の初期段階で評価されます。定義が変更されると、各判定アクティビティの配置制約が再評価され、判定オプションが 1 つ以上の判定アクティビティの考慮に入るか、または考慮から外れる場合があります。

判定コンテキスト

今のところ、判定に影響を与えるビジネス​ ロジック ​のみが説明されています。しかし、出力に対するより大きな影響は、決定の入力​ データ ​です。このデータは​ 判定コンテキスト ​と呼ばれ、判定するアクティビティとユーザーごとに異なります。これは、同じアクティビティでの異なるユーザーに対して同じ制約、ルール、モデルとは異なります。また、ルール、制約、モデルの変更頻度も低くなりました。リアルタイム判定の場合、判定コンテキストもリアルタイムで決定する必要があります。
判定コンテキストデータは、ユーザープロファイル関連データ、ビジネスデータ、内部収集データに分割できます。
  • プロファイルエンティティ ​は、エンドユーザーデータを表すために使用されますが、すべてのプロファイルエンティティが個人を表すわけではありません。家庭、ソーシャルグループ、その他のテーマの場合があります。エクスペリエンスイベントは、プロファイルに添付される時系列データレコードです。エクスペリエンスがある場合、このデータはこのエクスペリエンスの​ 主体 ​となります。
  • 逆に​ 事業主体 ​もあります。これらは相互作用の​ 対象 ​と考えることができます。これらのエンティティは、多くの場合、エンティティのエクスペリエンスイベントで参照されます。ビジネスエンティティの例としては、Web サイトやページ、ストア、製品の詳細、デジタルコンテンツ、製品の在庫データなどがあります。
  • The last category of data in the decision context is data that was created during operation of the Decisioning Service. すべての判定イベントはそのカテゴリに分類され、顧客からの応答とともに、提案データは​ 提案応答履歴 ​と呼ばれる内部データセットを形成します。
データが判定コンテキストの一部となるためにとることのできるパスは 3 つあります。レコードと時系列のデータは、データセットファイルを介してアップロードできます。このパスは主に外部システムとの一括同期用です。Record and time series data can also be streamed into Platform where the data is indexed and joined to form entities. 3 つ目のパスを介して、コンテキストデータをパラメーターとして判定リクエストに渡すことができます。この形式のデータは、本質的には短命であり、リクエストされた判定にのみ関連します。エンティティとして保持されず、他のリクエストでは使用できません。