Show Menu
トピック×

Experience Decisioningドメインモデル

この節では、Decisioningサービスのコンポーネントについて説明し、それらのコンポーネントの相互作用の仕方について詳しく説明します。 概念とその関係は、判定の問題の ドメイン を形成します。 これらの基本コンポーネントは、Decisioningサービスの使用方法に関係なく機能します。

決定オプション

エクスペリエンス 決定オプション は、特定の顧客に提示できる潜在的なエクスペリエンスです。 オプションは、選択または代替とも呼ばれます。 顧客にとって次に最適なオプションを決定する際、Decisioningサービスは、有限のオプションセットの中から d 1 dN のオプションを考慮 D ​します。
最適なオプションを利用可能なオプションの中から特定することで判断します。 1つ目のアプローチは、1つの みが残る まで、セット *** D***から​***​決定オプション​***diを連続的に削除し、残りのセットからランダムに「勝者」を選択します。 もう1つの意思決定方法は、残りの(適格な)決定オプションを、期待される結果に従ってランク付けすることです。

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

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

決定の結果

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

意思決定の提案

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

決定戦略 — アルゴリズム

有限選択肢の中から選択するのは、基本的にアルゴリズムである か、関数である N options{d1122, d, d, d, d. d, d. d. dn, d. d ** n, dの入力リストを生成する。これにより、リストの最初の決定は、期待されるユーティリティに最適と見なされ、結果のリストの2番目の選択肢は、2番目の最良の選択肢と見なされます。 通常、デシジョンアルゴリズムによって資格のないリストが排除され、十分なオプションが見つかった場合に停止して、上位のオプションのみを返すようにアルゴリズムが設定される場合があるので、セットのカーディナリティは、結果のランク付けオプションよりも高くなります。 K 次の図に一般的な決定フレームワークを示します。

決定アクティビティ

決定アクティビティ :特定の決定戦略のアルゴリズムとパラメーターの提供を設定します。 戦略パラメーターには、オプションに適用される制約とランキング関数が含まれます。 すべての決定は、アクティビティのコンテキストで行われます。 判定サービスは多くのアクティビティをホストし、アクティビティはチャネル間で再利用できます。 常に、最適なオプションは、最新の拘束、規則、モデルのセットに基づいて評価されます。
判断アクティビティは、考慮する決定オプションの集まりを定義します。 このアクティビティに関心のあるすべてのオプションのサブセットをフィルターします。 これにより、判定サービスは、すべてのオプションのカタログ内の局所カテゴリを管理できます。
デシジョンアクティビティは、組み合わせられた制約によって他のすべての オプションが無効になる場合の フォールバックオプションを指定します。 つまり、常に質問に対する答えがあるということです。 現在「最良」の選択肢は何か。
決定アクティビティは、エクスペリエンスの配信先を指定できます。 これにより、検討できる決定アクティビティの数がさらに減り、決定オプションによって課せられる別の制約が生じます。 これは 配置拘束と呼ばれます 。 この配置の制約に適合する内容を持つ決定オプションのみが考慮されます。 これは、決定戦略の初期段階で評価されます。 定義が変更された場合、各決定アクティビティの配置制約が再評価され、決定アクティビティが1つ以上の決定オプションを考慮に入れないか、考慮に入れなくなる可能性があります。

決定コンテキスト

今のところ、決定に影響するビジネス ロジック のみが説明されています。 しかし、出力に対するより大きな影響は、決定の入力 データ です。 このデータは 決定コンテキストと呼ばれ、ユーザーごとに異なり 、アクティビティごとに決定がなされるたびに異なります。制約、ルールおよびモデルは、同じユーザーごとに異なります。 また、ルール、拘束、モデルの変更頻度も低くなります。 リアルタイム判定の場合、決定コンテキストもリアルタイムで決定する必要があります。
決定コンテキストデータは、ユーザープロファイル関連のデータ、ビジネスデータ、および内部収集データに分割できます。
  • プロファイルエンティティは 、エンドユーザーデータを表すために使用されますが、すべてのプロファイルエンティティが個人を表すわけではありません。 家庭、社会グループ、その他のテーマにすることができます。 エクスペリエンスイベントは、プロファイルに付属する時系列のデータレコードです。 エクスペリエンスがある場合、このデータはこのエクスペリエンスの 対象 となります。
  • 一方、 事業主体が存在する 。 これらは相互作用の 対象と考えられます 。 これらのエンティティは、多くの場合、プロファイルエンティティのエクスペリエンスイベントで参照されます。 事業体の例としては、Webサイトやページ、店舗、製品詳細、デジタルコンテンツ、製品在庫データなどが挙げられる。
  • デシジョンコンテキストの最後のカテゴリは、Decisioningサービスの操作中に作成されたデータです。 すべての意思決定イベントは、顧客からの回答と共に、提案カテゴリ履歴と呼ばれる内部データセットを形成し ます
データは、3つのパスを経て、決定コンテキストの一部となることができます。 レコードと時系列のデータは、データセットファイルを介してアップロードできます。 このパスは、主に外部システムとのバルク同期のためのものです。 レコードと時系列のデータは、データのインデックスが作成され、フォームエンティティと結合されるプラットフォームにストリーミングすることもできます。 3つ目のパスを介して、コンテキストデータをパラメーターとしてデシジョンリクエストに渡すことができます。 このデータ形式は、本質的にははかないもので、要求された決定にのみ関連します。 エンティティとして保持されず、他のリクエストでは使用できません。