Amazon Web Services ブログ

Amazon Aurora 機械学習を使用して顧客に関する洞察を得る

近年、AWS のお客様は、ますます多様化するデータセットとデータソースで機械学習 (ML) を実行しています。組織データの大部分は Amazon Aurora などのリレーショナルデータベースに保存されているため、このリレーショナルデータを ML モデルのトレーニングに利用できるようにし、ML モデルを使用してデータベースアプリケーションで予測を行えるようにするニーズが一般的にあります。この記事では、Aurora から本番データを簡単に抽出し、Amazon SageMaker で ML モデルをトレーニングし、モデルの推論を本番データベースとアプリケーションに統合する方法を示します。また、一般的な ML ユースケースを拡張して顧客離れを予測し、顧客離れを防止するという実際のビジネス目標を達成する方法も説明します。セッティングに大手電話会社を用います。

勤務する通信会社で、CEO から会議に呼び出されたとします。「当社のサービスを解約する、つまり「顧客離れ」をするお客様が毎年約 15% います! お客様を失うと、新しいお客様を獲得するには高い費用がかかります。これは当社の年次結果に大きな重しになります。  どのお客様が解約する可能性が高いかを予測して、そのお客様にサービスを使い続けてもらえるようなインセンティブを与えることができますか? 機械学習 (ML) を使ってこれに役立てられますか?」

いつまでも続くこの議論を簡潔にまとめます。

ML エンジニアは次のように言いました。「うーん、そうですね。すべての顧客データが Amazon Aurora リレーショナルデータベースに保存されていますね。DBA がこのデータを取得できれば、解約する顧客を予測する ML モデルを構築できます。Amazon SageMaker XGBoost Built In Model を使ってこれを行えます。これは、一般的に回帰、分類、ランク付けの問題に用いられるアルゴリズムです。そしてSageMaker 自動モデルチューニングで、かなり良いモデルが得られるはずです」

DBA は、「もちろん! 本番データベースの一部のダンプを提供できます。AWS は Amazon Aurora から S3 をダウンロードできるようにしているため、簡単に行えます」

CEO は唸りました。「誰が離れるのかを予測したいんじゃないんです! 顧客離れを防ぎたいんです!」

「顧客離れに最も関連している要因を教えてもらえれば、ターゲットを絞ったインセンティブプログラムを構築できます」とマーケティング部は述べました。

ML エンジニアは言いました。「うーん。モデルを入手したら、モデルで使用されている最も重要な要素、つまり機能を判別できます。これを「説明可能性」と呼びます」

カスタマーサービスは次のように述べました。「カスタマーサービスのチャットから、お客様一人一人の感情についての手がかりを探ることもできます。ただし、チャットの数が多すぎて手動で読むことはできません。ML ベースのシステムが、チャットの最初の文で、顧客が満足していない、または顧客離れする可能性があることを判別できれば、その場でインセンティブの 1 つを提供できます!」

「Amazon Comprehend を使用して、お客様の感情を読み取ることができます。それは朝飯前ですよ」と ML エンジニアは言いました。

DBA は次のように述べました。「Amazon Aurora Machine Learning を使用すると、チャットを開始したときに、顧客の感情と解約予測を基本的な顧客情報とともに返す SQL クエリを作成できます。そうすれば、すべてのお客様の詳細情報をすぐに利用できます。次に、マーケティング部が提案するプログラムを用いて、離れていく可能性が最も高いお客様にインセンティブを提供できます」

CEO は言いました。「すばらしい!是非そうしよう!」

このブログの以下の部分では、それを実現するために必要な手順を順を追って説明します。

ソリューションの概要

ほとんどの組織では、データベース管理者 (DBA) またはアプリケーション開発者がデータベースを扱い、ML エンジニアが ML モデルを扱います。けれども、ここで説明するソリューションを実装するための手順をすべて 1 人で実行できます。このソリューションは、Amazon SageMaker の組み込み XGBoost アルゴリズムを使用して実装されているため、この場合、より詳細なデータサイエンティストのスキルは必要ありません。

次の図は、ソリューションの実装に使用する AWS のサービスを示しています。

次の手順を実行して、本番データベースから ML 推論にアクセスできます。

  1. 対象のデータは元々Aurora MySQL に保存されています (Aurora の PostgreSQL 互換エディションでも同様のプロセスを使用できます)。 DBA は SQL SELECT INTO OUTFILE S3 ステートメントを使用して、Aurora から S3 バケットにデータをアンロードします。
  2. ML エンジニアは、Amazon SageMaker ノートブックインスタンスでホストされている Jupyter ノートブックを使用して、Amazon S3 からデータを読み取り、探索します。AWS Secrets Manager を使用すると、Aurora のアクセス認証情報を安全に保持できます。
  3. ML エンジニアは Jupyter ノートブックからデータを個別のデータセットに分割して、ML モデルのトレーニングとテストに使用します。ML エンジニアはトレーニングデータを Amazon S3 に書き戻し、モデルトレーニング中に使用します。(Aurora からの初期データのアンロード中にパーティションを実行することもできます)。
  4. 同じノートブックから、ML エンジニアは、Amazon SageMaker の組み込み XGBoost アルゴリズムを使用してトレーニングジョブを開始します。
  5. Amazon SageMaker は、Amazon S3 からトレーニングデータを読み取ります。
  6. Amazon SageMaker はモデルをトレーニングします。
  7. ML エンジニアはモデルの特性をチェックします。モデルの特性に満足したら、ML エンジニアは Amazon SageMaker エンドポイントを作成してトレーニング済みモデルからの予測を提供し、データベースとエンドポイント間の接続をセットアップします。
  8. アプリケーション開発者 (または DBA) は、Aurora で SQL クエリを実行します。
  9. Aurora は解約予測のリクエストを Amazon SageMaker エンドポイントに渡します。
  10. Aurora は、テキストで感情予測を行うリクエストを Amazon Comprehend に渡します。
  11. Aurora は結果をアセンブルし、SQL クエリの結果として、独自のテーブルからのデータとともにそれらを返します。

この記事では、AWS Samples Customer Churn のサンプルノートブックのデータセットを使用しています。このノートブックは公開されており、Daniel T. Larose 著の『Discovering Knowledge in Data』で言及されています。これは、著者がカリフォルニア大学アーバイン校の機械学習データセットリポジトリに帰属しているためです。

助かるのは、Aurora に Aurora 機械学習と呼ばれる機能があり、re:Invent 2019 でローンチされたことです。これは、Amazon SageMaker と Amazon Comprehend の事前構築された統合機能で、SQL クエリ内でこのサービスを呼び出します。これにより、データの効率的な転送を行います。Aurora ML 機能の設定手順については、「Aurora 機械学習の有効化」をご覧ください。この記事では、AWS CloudFormation テンプレートを使用してこのようなコンポーネントを作成および設定します。AWS サンプルの顧客インサイトを得るで、すべてのコードのコピーを見つけることもできます。

ソリューションインフラストラクチャのセットアップ

インフラストラクチャコンポーネントをセットアップして接続を設定するには、事前定義された CloudFormation スタックを起動します。スタックは次のリソースをセットアップします。

  • コンポーネントを実行する Amazon VPC、および 2 つのプライベートサブネットと 1 つのパブリックサブネットと NAT ゲートウェイ。
  • 単一のデータベースインスタンスを含む Amazon Aurora クラスター、および Amazon SageMaker ノートブックインスタンスへのアクセスを許可するように設定されたセキュリティグループ。クラスターはプライベートサブネットにあります。このデータベースインスタンスは、本番設定としてセットアップされていません。詳細については、「カテゴリ: Amazon Aurora」と「Aurora 用の AWS クイックスタート」を参照してください。スタックは、適切なパラメータ設定、具体的には以下のパラメータを持つ DB クラスターパラメータグループも作成します。
    • aws_default_comprehend_role は、Amazon Comprehend DetectSentiment と BatchDetectSentiment API を呼び出す権限を Aurora に付与する IAM ロールに設定します
    • aws_default_sagemaker_role は、この記事のモデルに使用する Amazon SageMaker エンドポイントを呼び出すための Aurora 権限を付与する IAM ロールに設定されます。
    • aws_default_s3_role は、データに使用する S3 バケットへのアクセスを許可する IAM ロールに設定されます。
  • 関連する以下のコンポーネントを備えた Amazon SageMaker ノートブックインスタンス。
    • ノートブックインスタンスで使用する IAM ロール。IAM ロールには、マネージドロール AmazonSageMakerFullAccess があり、それには名前に SageMaker を含む S3 バケットへのアクセスが含まれています。このロールには、本番環境で使用するよりも多くの権限がある場合があります。
    • ノートブックインスタンスに使用するセキュリティグループ。
    • サンプルコードとともに事前定義された 3 つの Jupyter ノートブックをコピーする Amazon SageMaker ライフサイクル設定。また、cloudformation_values.py というファイルも作成します。これには、S3 バケット名や、Aurora ホスト名とパスワードを含むシークレット名など、スタックが作成した主要なリソースの値が含まれます。このファイルは、これらの値を Jupyter ノートブックに渡すために使用します。
  • Amazon SageMaker エンドポイント。このエンドポイントは、DB クラスターパラメータグループのパラメータ aws_default_sagemaker_role で指定された IAM ロールに一覧表示されています。
  • Amazon SageMaker のデフォルトの IAM ロールで使用できるように、名前に SageMaker が含まれる S3 バケット。
  • データベースのユーザー名、パスワード、ホスト名を含む Secrets Manager シークレット。シークレットを使用すると、ユーザー名とパスワードはノートブックに保存されません。

このソリューションが米国東部 (バージニア北部) リージョンで動作していることを確認するには、次のリンクからスタックを起動します。ソリューション全体の費用は、1 回限りの料金として約 1.00 USD、それに加えて実行に 1 時間あたり 1.15 USD かかります。ソリューションを終了したら、追加料金を避けるために忘れずに AWS CloudFormation スタックを削除してください。

スタックを実行するには、次の手順を実行します。

  1. [スタックの起動] を選択し、[次へ] をクリックします。
  2. ご使用の環境に合わせて以下のパラメータを更新するか、デフォルトのままにします。
    1. DatabaseAdministratorUsername
    2. SageMakerInstanceType
    3. RDSInstanceType
  3. [次へ] をクリックします。
  4. [AWS CloudFormation がカスタム名で IAM リソースを作成する可能性があることを認めます] を選択します。
  5. [作成] を選択します。
  6. CloudFormation スタックが CREATE_COMPLETE のステータスになるまで待ちます (最大 15〜20 分)。
  7. 作成されたリソースの [出力] タブを確認します。次のスクリーンショットを参照してください。
  8. Amazon SageMaker コンソールで、[ノートブックインスタンス] を選択します。
  9. ノートブックインスタンスのリストで、PreventChurnSMNotebook- で始まるノートブックを見つけます。
  10. [JupyterLab を開く] を選択します。

次のスクリーンショットのように、ノートブックにコピーされたファイルのリストが表示されます。

次のセクションでは、各ノートブックについて説明します。

データのセットアップとアンロード

Amazon Aurora データベースをセットアップし、ML で使用するためにデータを Amazon S3 に保存することは、DBA が通常 SQL クライアントを使用して通常実行するステップです。一貫性を保つために、この記事では、mysql.connector Python モジュールを使用した Jupyter ノートブックの手順を示します。

最初のノートブック、part_1_preventing_customer_churn_Amazon_Aurora_setup.ipynb は 2 つのセクションに分かれています。実行前の HTML バージョンについては、「顧客離れの防止、パート 1」を参照してください。Amazon Aurora MySQL データベースに接続し、データの読み込みと抽出を行います。

このセクションでは、サンプルの顧客データをフェッチします。この顧客が解約したかどうかに応じて、各レコードにラベルが付けられます。このデータを Amazon S3 に書き出します。データベースにテーブルを作成してデータを保持し、次に LOAD DATA FROM S3 ステートメントを使用して、データを Aurora データベーステーブルに一括読み込みします。また、過去の顧客メッセージの一部を 2 番目のテーブルに格納します。

これで、ユースケースを順を追って説明する準備ができました。

セクション 2 では、次から始めます。DBA が次のリクエストを受け付けました。「データサイエンティストがデータから顧客離れの理由を調査できるように、顧客データを S3 にエクスポートしてください。よろしくお願いします」

さいわい、Amazon Aurora にはこれを簡単に行う機能があります。Amazon Aurora MySQL DB クラスターからのデータを Amazon S3 バケットのテキストファイルに保存する機能です。単一の SQL ステートメントが得られ、DBA は担当する仕事を果たしました! これで、電話プラン、使用状況、顧客からの電話の概要などの顧客データはすべて S3 にあります。2 つ目のノートブックに進む準備ができました。

ML アルゴリズムを実行してモデルの結果を確認する

2 番目のノートブックでは、Amazon SageMaker XGBoost モデルを顧客データでトレーニングし、ハイパーパラメータ最適化 (HPO) を使用して最適なモデルを見つける方法を説明します。また、最もパフォーマンスの高いモデルで使用されている機能を調べて、最も影響力のある機能を知ることができます。これは、インセンティブプログラムを作成するためにマーケティングが必要とする情報です。

データ探索とトレーニングコードについては、ノートブック part_2_preventing_customer_churn_XGBoost.ipynb を参照してください。(このノートブックの起動時にメッセージ「カーネルを選択してください」が表示された場合は、[conda_python3] を選択します)。 実行前の HTML バージョンについては、「顧客離れの防止、パート 2」を参照してください。ML モデルの構築。

このノートブックでは、2 つの XGBoost モデルを作成します。最初のモデルは、顧客データで利用可能なすべての機能を使用します。相関の高い列をいくつか削除し、カテゴリ変数 (state など) を one-hot ベクトルに変換すると、約 70 列がトレーニングデータに含まれます。

この記事はサンプル実行を示しています。この実行では、最初のモデルのトレーニング AUC は 0.949、検証 AUC は 0.884 でした。すべての場合において、XGBoost に固有のランダム化により、詳かい点は実行ごとにわずかに異なります。これは、いくつかの機能の予測値が類似しており、類似した結果で相互に置き換えることができる場合に最も可能性が高く、これによりモデルのパフォーマンスが類似したものになります。

次に、XGBoost トレーニング済みモデルをノートブックにロードして、これらの結果を達成するために使用した機能を分析します。まず、XGBoost の組み込み機能別重要度プロットを使用します。次のグラフは、ゲイン、つまりブランチへの機能により精度が向上したことを示しています。

次のグラフは、特徴に関係する観測の相対量を測定するカバーを示しています。

cust_service_calls、day_mins、int_plan_no (バイナリ機能で、顧客には国際プランがない) などのいくつかの機能は、顧客離れのキードライバーです。機能の重要度は、この機能が影響力があることを示しますが、方向を示していません (離れる顧客が増加または減少こそはしますか)。以下に示すように、方向は多くの場合、ビジネスセンスを通じて、またはモデルが生成したツリーを評価することによって推測できます。

この問題に応えるために、この記事では生成したツリーのいくつかをご紹介します。すべてのツリーを探索することは一般的に現実的ではありませんが、モデルが使用するデータとモデル自体の両方が妥当であることを確認するのには役立ちます。これは、データ抽出エラー、偽のパターン、または機能エンジニアリングの必要性を識別するのに非常に有用です。

次の図は、XGBoost が生成した最初のツリーを示しています。

興味深いですね! 最初の分割は 3.5 の customer_service_calls です。この画像では、さまざまな種類の解約者を提案または理解するためにこれらのツリーを使用できる可能性を示しています。追加のツリーを簡単にプロットしたり、さまざまなツリーの上位の分割といった主要な分割のリストを取得したりできます。この情報により、マーケティング部は顧客セグメント間のさまざまな解約プロファイルに対して考察できるようになるかもしれません。これにより、さまざまなターゲットインセンティブプログラムの開発につながる可能性があります。

データ探索を少し行うと、4 回以上のコールにより解約者の割合が変化するという考え方が裏付けられます (次のスクリーンショットを参照)。顧客が 4 回目の電話をかける前に介入するのが良いでしょう。

XGBoost アルゴリズムを使用する場合 (主にデータに情報がほとんどない場合、またはモデルがうまく収束していない場合) には、ツリーの多くまたは一部には 1 枚のリーフしか含まれていない可能性があるため、決定を下す際にモデルに過度に依拠しないようにしましょう。他にも、データに固有の複雑さがあるために、使用しているハイパーパラメータの境界を拡張する必要があることが分かりました。この特定のモデルに影響があるかどうかを確認するために、次の棒グラフのように、各ツリーの深度を計算します。

このテスト実行では、いくつかのツリーにはリーフが 1 枚のみ含まれているため、さらに最適化が可能であるように見えます。

また、ツリー全体で機能がどのように使用されているかを確認することで、モデルに影響を与える機能を把握したいと考えています。次のグラフは、モデルの特徴と、トレーニング中にツリーを分割するために使用したそれぞれの機能数を示しています。

上のグラフでは、機能の大部分はツリー分割に使用されていません。次の表は、実行中に少なくとも 1 回使用される機能と、機能の使用回数を示しています。

 

機能 使用回数
day_mins 8
cust_service_calls 7
eve_mins 7
int_plan_no 6
int_charge 6
vmail_msg 6
night_mins 5
int_calls 4
day_calls 1

ここにチャンスがあります! トレーニングデータには約 70 の特徴がありましたが、このモデルでは 9 つの特徴のみを使用しています。XGBoost のランダム化された性質により、機能の正確な使用回数とめったに使用されない機能 (分割数が少ない) は実行ごとに異なります。後のセクションでは、モデルを単純化し、それによって本番データベースからの呼び出しを単純化して、モデルに渡すデータを大幅に減らすことを試みます。

モデルの評価

次に、テストデータに対してモデルを評価します。保留されたテストデータに対してモデルをテストするために、CloudFormation スタックの起動中に作成された Amazon SageMaker エンドポイントにモデルをデプロイします。このエンドポイントは、Amazon SageMaker の推論機能を表しています。簡単にするために、この記事では事前定義された endpoint_name を使用します。CloudFormation テンプレートのセットアップでは、この endpoint_name を IAM ロールで指定し、Aurora DB クラスターグループパラメータ aws_default_sagemaker_role をこの IAM ロールに設定しました。この設定の組み合わせにより、ここで作成する Amazon SageMaker エンドポイントを呼び出す権限が Aurora に与えられます。次に、正しい予測の数やモデルの精度などの統計を確認できます。

次に、同じアプローチを使用して更新されたモデルを構築しますが、最初のモデルで使用した機能のみを使います。次の表に示すように、正確さ、再現率、精度などの標準的な ML 尺度を使用して、モデル全体に対して評価します。

次のグラフのように、両方のモデルの ROC 曲線を評価することもできます。

更新後のモデルは、元のモデルに近い結果を提供します。一部の実行ではわずかにパフォーマンスが向上し、他の実行ではわずかにパフォーマンスが低下します。

2 つのモデルの差は誤差範囲を下回っており、更新後のモデルは呼び出しで渡されるデータがはるかに少ないため (70 ではなく、9 の機能)、更新されたモデルを使用します。

ビジネスへの影響の評価

また、予測スコアを確認して、誰かが解約者であるかどうかを判断するために使用するしきい値を調整することにより、モデルのパフォーマンスを評価することもできます。これをバイナリ分類として扱うことが一般的ですが、現実の世界はそれほどバイナリではありません。人は実際に解約する前にしばらく解約する可能性が高い状態にあると考えられています。ブランドロイヤルティの喪失は、競合他社に乗り換える前に発生することもあります。

次のグラフは、モデルからの継続的な値の予測が 0 または 1 に偏る傾向があることを示していますが、0.1 と 0.9 の間には十分な質量があり、カットオフを調整すると実際に多くの顧客の予測が変化します。ここでは、インセンティブが 1 つであることを想定してしきい値を最適化する簡単なアプローチを採用して、将来の分析の出発点とします。

この時点では、マーケティングはまだ使用したいインセンティブを教えていないので、モデルが特定した顧客の維持インセンティブは 50 ドルで、偽陰性ごとに 500 ドルのコストを想定します。これらの数値をコスト最適化モデルで使用して、最適なしきい値を特定できます。

次のグラフは、顧客離れのしきい値の設定が低すぎる (0.1 未満) と、すべての顧客に維持インセンティブが与えられ、コストが急上昇する様子を示しています。さらに、しきい値の設定が高すぎる (0.7 以上) と、顧客が離れ、最終的にはコストがほぼ同等に高くなります。その間に大きなギャップがあり、おそらくさらに微妙なインセンティブを与えることでより良い結果が生み出されるかもしれません。

これらのインセンティブの数値を使用して、カットオフを 0.12 に設定することにより、5950 ドルで全体のコストを最小限に抑えることができます。これは、何も行動を起こさないことでビジネスが失うと予想される 20,000 ドル以上の損失よりもはるかに優れています。マーケティング部は、これらの数値をインセンティブプランニングの開始点としてが使用できます。

インセンティブの開発

ML エンジニアは、分析結果を携えてマーケティング部に伝達します。

機能別重要度グラフは、カスタマーサービスコールの数、国際プランの使用、日中のコールの分数といった少数の機能が解約予測の大部分を構成していることを示しました。

機能別重要度グラフは、XGBoost モデルのどの機能がモデルのパフォーマンスに最も貢献しているかを示しますが、これらの変数がどの方向またはどのような値で結果に変化をもたらすかは示されていません。ツリーを調べると、洞察が得られます。前に示したツリーとそれに関連する解約確率の場合、カスタマーサービスに 4 回目の電話をかけると、誰かが解約者になる確率が大幅に変化したように見えます。別のセグメンテーションは、1 日あたり約 3 時間の通話のようです。

これらの洞察に基づいて、マーケティング部は顧客に提供する一連のインセンティブを開発できます。マーケティング部は、郵送または他のアウトリーチ方法により特定の顧客をターゲットにするなど、インセンティブを展開する方法をいくつか選択できます。ここでは、顧客が次回カスタマーサービスに電話をかけるときに介入することに焦点を当てます。これらのインセンティブを使用するためのキーは、カスタマーサービスがそれぞれの顧客のコールを評価し、適切な場合は関連するオファーを特定して提供する能力です。次のセクションでは、この機能を実装する方法を示します。

このユースケースでは、通話中の顧客の感情と国際プランの使用に基づいた簡単なヒューリスティックから始めます。

本番環境での ML 機能の使用

ML モデルをトレーニングおよびデプロイし、使用するインセンティブプログラムに関してマーケティング部からアドバイスをもらったことで、これらを組み合わせる準備が整いました。

3 番目のノートブック part_3_preventing_customer_churn_inferences_from_Amazon_Aurora.ipynb は、Aurora への SQL クエリの一部として、ML 機能 (Amazon SageMaker および Amazon Comprehend) に接続して結果を取得する方法を示しています。これらの両方の情報を手に入れれば、顧客にどのようなインセンティブプログラムを提供するかを即座に決定できます。実行前の HTML バージョンについては、「顧客離れの防止、パート 3」を参照してください。Amazon Aurora からの推論。

このすべての作業を Aurora で実行できます。これらのクエリを内部アプリケーションのバックエンドに組み込むことで、カスタマーサービスが顧客からのメッセージとその顧客の詳細に基づいて顧客が離れていくリスクをリアルタイムで理解できます。

まず、Aurora から Amazon Comprehend を呼び出します。このようにして、カスタマーサービスへのメッセージで顧客の感情を評価することもできます。CloudFormation テンプレートは、DB クラスターパラメータグループのパラメータ aws_default_comprehend_role に IAM ロールを追加することにより、Amazon Comprehend を呼び出す権限をすでに Aurora に提供しています。これで、Amazon Comprehend の呼び出しは、以下に示すように、SQL クエリを発行するのと同じくらい簡単です。

sql = """SELECT message,
       aws_comprehend_detect_sentiment(message, 'en') AS      sentiment,
       aws_comprehend_detect_sentiment_confidence(message, 'en') AS confidence
  FROM {} LIMIT 1;""".format(customer_msgs_table)

[('Thank you very much for resolving the issues with my bill!',   bytearray(b'POSITIVE'), 0.9981661438941956)]

クエリの応答には、元のメッセージと Amazon Comprehend からの 2 つの出力 (感情 (POSITIVE) と信頼レベル (前のコードでは非常に高い) が一覧表示されます。

これで、Amazon SageMaker モデルを接続する準備ができました。そのために、Amazon SageMaker エンドポイントを呼び出す関数を作成します。手順については、「Aurora Machine Learning の有効化」を参照してください。Aurora では、モデルに必要な変数を使用する SQL 関数 will_churn を作成します。前のセクションで one-hot エンコーディングによって作成した列を含めます。

次に、Aurora データベースを設定して、Amazon SageMaker エンドポイントを呼び出し、予測を返すために必要なデータを渡す必要があります。そのためには、データを収集し、必要な変換 (データの結合やデータ型の変更など) を実行し、モデルエンドポイントを呼び出す SQL 関数を作成します。

元のデータには、数値変数といくつかのカテゴリ変数 (area_code や int_plan など) が含まれていました。ML モデルの作成中に、カテゴリ変数は one-hot ベクトルに変換されました。この変換により、モデルが使用する列数が急増する可能性があります。このユースケースでは、元の 15 の機能列は、one-hot への変換後に 70 列になりました。使用したのは列が少ないリストだったため、それらの列のみを使用してモデルを構築できます。これにより、SQL が呼び出しに含める必要のあるフィールドの数が減るため、ML モデルへのデータベース呼び出しが簡素化されます。

最終的なモデルでは、1 つのカテゴリ値 (int_plan_no) のみを使用しました。ただし、データベースの列は int_plan で、one-hot 表現に変換する必要があります。この問題に対処するには 2 つの方法があります。ML エンドポイントに変換コードを追加するか、one-hot エンコードされた変数を表す関数を SQL データベース中に作成する方法です。

簡単にするために、この記事では 2 番目のオプションを示します。このフィールドの one-hot エンコードされた値を返す SQL 関数 (IntPlanNo (int_plan)) を作成します。より複雑な変換の場合、最初のオプションがより良いオプションである可能性があります。

では、始めましょう!

これで、ようやくすべてのピースを組み合わせることができます。

マーケティング部が定義したインセンティブプログラムを採用し、デモンストレーションのために、Python 関数 assess_and_recommend_incentive を作成しました。この関数は、顧客の電話番号と、顧客がカスタマーサービスに (たとえば、チャットを介して) 送信したメッセージを受け取ります。カスタマーサービスが必要とする顧客の詳細についてデータベースをクエリし、顧客離れする可能性と推奨されるインセンティブを返します。この機能には、特定の特性を持つ顧客向けの固定インセンティブがいくつか含まれています。ランダム化されたインセンティブで代替案をテストすることもできます。出力には、推奨されるインセンティブと、インセンティブが選択された理由を説明する短いメッセージが含まれます。本番設定では、ビジネスアプリケーションから上記と同じ呼び出しを行います。

次のコードは、関数の 2 つの呼び出しの結果を示しています。1 つ目は、否定的な顧客メッセージと解約確率が高い顧客の場合で、クレジットを付与することが推奨されます。2 つ目は、中立的な顧客メッセージと解約確率が低い顧客の場合で、インセンティブは何も提供しません。

print(assess_and_recommend_incentive( 415, '358-1921', "You morons! You charged me extra again!"))
Sentiment NEGATIVE and will_churn>0.8: $25 credit

print(assess_and_recommend_incentive(408, '375-9999', "How do I dial Morocco?"))
NOT (cust_service_calls > 4 and not int_plan_no): No incentive.

これで、カスタマーサービスに必要なツールを提供できます。顧客の電話番号と顧客が懸念を表明したテキストを使用して、データベース内の履歴と現在のやり取りに基づいて、提供するインセンティブを即座に特定できます。

また、インセンティブプログラムのさまざまな値の効果を、モデルから返される真陽性と真偽性、偽陽性と偽陰性に対してテストすることもできます。これにより、計画されているインセンティブの経済的な影響を見積もることができます。

クリーンアップ

追加料金の発生を回避するには、ソリューションを一通り試した後に CloudFormation スタックを削除する必要があります。

モデルのトレーニング中に作成された S3 バケットと Amazon SageMaker エンドポイントも削除する必要があります。パート 2 ノートブックの最後のセルには、これらを削除するコードが含まれています。

まとめ

これで、顧客との対話中に、これがリスクのある顧客であるかどうかを検出し、サービスを利用し続けるためのインセンティブを提供することで介入できます。この相互作用の感情と、顧客の現在の特性、対話の履歴、および推定リスクとを組み合わせたものというように、応答のベースとなる要因を選択できます。提案された一連のインセンティブと、インセンティブプログラムのコストの見積もりを持って、CEO に伝達することができます。または、それぞれ個別の最適化曲線を表示する一連の代替案を示せます。顧客の行動について貴重な洞察を得ており、より多くのデータを収集してより多くの洞察を得る計画があります。

効果的なインセンティブと顧客の行動に関するデータをさらに収集するために、回答をランダム化することもできます。主要な要素を理解し始め、実験プラットフォームから始めることができます。そのデータを将来の ML モデルで使用して、提供されるインセンティブをさらに絞り込むことができます。

次のようなインセンティブプログラムに実験とニュアンスを追加することができます。

  • インセンティブを提供するときの顧客の感情と、現時点での解約予測、キードライバーの現在の価値、および提供するインセンティブを記録します。
  • 提供するインセンティブをランダム化して、同様の特性を持つ顧客に異なるインセンティブの A/B テストを実行します。
  • 新しい電話戦略や計画のアップグレードなど、単純なキャッシュバックを超えたさまざまな種類のインセンティブを試します。
  • 提供されたインセンティブを保存し、後でその使用と達成された結果を分析します。顧客離れを抑止するために、どのような顧客にどの程度のインセンティブを提供する必要があるでしょうか? インセンティブのコストと比較して、その顧客を維持することにどれほどの価値があるでしょうか? インセンティブを聞いて、顧客の感情はどうなりますか?
  • 経済分析を追加します。この顧客を維持する価値はどのくらいありますか? 利益を最大化するための最適なしきい値は何ですか?

これらの代替案を検討するにつれ、予測から具体的で実用的なビジネス価値を提供していく過程に移ります。マーケティング部、あとはよろしくお願いします!

著者について

Veronika Megler 博士は、AWS プロフェッショナルサービスのデータサイエンス、ビッグデータおよびアナリティクス担当の主任コンサルタントです。彼女は、科学的データ検索をテーマとして、コンピュータサイエンスの博士号を取得しています。技術採択を専門とし、企業が新しい技術を使って新しい問題を解決し、古い問題をより効率的かつ効果的に解決できるように支援しています。

 

 

 

Vitalina Komashko は、AWS プロフェッショナルサービスのデータサイエンティストです。彼女は薬理学と毒物学の博士号を持っていますが、畑違いというわけではありません。彼女は再現可能な研究、クリーンなコードを専門とし、バイオテクノロジーと製薬会社がスケーラブルなソリューションで問題を策定して解決するのを支援しています。