≪  2020.05.22 「Einstein AI で Salesforce は進化する：（２） Einstein 予測ビルダーを通じて Einstein AI に触れてみましょう（前編）」

2020.06.05 「Einstein AI で Salesforce は進化する：（４） Einstein Discovery は御社の専任データサイエンティストです（前編）」 ≫

 

お世話になっております。
ウフル カスタマーサポート Salesforce 担当の 後藤 でございます。

 

皆様いかがお過ごしでしょうか。

先週の関西圏に続き、今週遂に北海道と首都圏でも緊急事態宣言が解除されました。

弊社でも来週より平常業務に戻りますが、完全に以前と同じではなく、一日のオフィス在勤人数を制限する措置を取る予定となっており、恐らく皆様の会社でも近い状況ではないかと存じます。

 

今、ビジネスの世界では「もはや以前と同じ働き方は出来ない、コロナの危機と常に共存することを念頭に置いて対処すべき」との文脈で、 「ポストコロナ」「アフターコロナ」というワードが飛び交っております。

例えば、訪問営業活動も以前のようには行えなくなるため、「訪問先を厳選し、必要度の高い順に活動を行っていく」という作業が必要となります。

その際に「企業に訪問必要度をスコアリング」する作業が発生することになり、役に立ってくるのが、先々週からカスタマーサポート通信で取り上げさせていただいている Salesforce Einstein になります。

先週は Einstein 予測ビルダーの使い方と機能についてご案内いたしましたが、分析結果を出したところでタイムオーバーとなっていました。

今週はその分析結果を見ていきますので、先週号をご覧いただいていない方は、まず先週の記事をご覧いただければ幸いでございます。

 

2020.05.22 「Einstein AI で Salesforce は進化する：（２） Einstein 予測ビルダーを通じて Einstein AI に触れてみましょう（前編）」
https://csminfo.uhuru.jp/hc/ja/articles/900001001363

 

 

 

＊ Einstein 予測ビルダーの結果を分析してみる

 

 

先週は、Trailhead で提供されている「クイックスタート」プロジェクトの手順に基づいて、組織の取得とビルダーの設定まで行いました。

そして、結果を見て「・・・あれ？全部に同じスコアが付いている」と呟いたところで「次週に続く」となりました。

 

＜分析結果： 対象レコード20件全部に「30点」が付いている＞

 

 

まず、このスコアは「何に基づいて」付与されているのか、こちらから確認していきましょう。

 Einstein 予測ビルダーのメイン画面で、対象の予測モデルの右側にある ▼ をクリックし、「スコアカードを表示」を開きます。

 

 

スコアカードを開いてみましょう。

  

 

概要を見ると、「予測品質」「予測情報」に加えて「上位プレディクター」という項目があります。

上位プレディクターとは、Einstein 予測ビルダーにおいて、予測モデルに対し最も影響を与えた項目を、最上位を「1.0」として上位５件表示するものです。

 

レコードの上位のプレディクターの表示
https://help.salesforce.com/articleView?id=custom_ai_prediction_builder_top_predictors_setup.htm&type=5

 

今回の場合は "Previous No Show" という項目が「1.0」で最上位、"Total Reservation" という項目が「0.58」で２番目に表示されています。

本来ならば上位５件が表示されるはずですが、今回の予測モデルでは、これら２項目以外に予測に影響を与えた項目がほぼ無いに等しかったため、項目は表示されているのですが（多分昇順かランダムで表示されているだけだと思います）、いずれも「0点」となっています。

"Previous No Show" は、当該顧客が過去にキャンセルした件数を表示しています。
"Total Reservations" は、当該顧客の過去の予約件数（今回も含む）です。

いずれも、取引先責任者オブジェクト上に積み上げ集計項目を作り、"Reservations" オブジェクトからクロスオブジェクト数式項目で参照したものです。

（ご安心ください。Trailhead プロジェクトで組織を取得した場合、これらの項目は既に作成済みです。）

 

"Reservations" のリストビューに項目を出してみましょう。

全件 "Previons No Show" は「ゼロ」でした。

ちなみに "Total Reservations" の方も出してみましたが、こちらも全レコードで「１」でした（件数には「Upcoming」のものも含むため）

 

 

"Previons No Show" と "Total Reservations"  で差異が無く、その他の "Reservations" オブジェクト項目が予測因子とみなされていない以上、予測セットのレコード全件に「30点」が付くのもやむなしです。

 

ただ、これだけでは "Predicted No Show" のスコアは変わりません。

もう一度分析を実行する必要があります。

有効化済みの予測モデルは月一回自動で更新を行いますが、予測モデルの再編集を行うことで、手動で更新（AI の再トレーニング）を行うことができます。

 

予測のスコアカードの確認
https://help.salesforce.com/articleView?id=custom_ai_prediction_builder_scorecard.htm&type=5

 

=============================================================
予測が有効な限り、Einstein は毎月 1 回モデルをトレーニングしなおします。
=============================================================

 

※ 予測モデルの再編集を行うには、一旦無効化するか、有効化済みの予測モデルをコピーして別に作成する必要があります。

 

 

予測が完了した旨の通知が来たら、先ほどのリストビューを更新してみましょう。

 

 

「No Show」のレコードを追加したものは "Predicted No Show" のスコアが「41」にアップし、逆に「Completed」のレコードを追加したものはスコアが「23」にダウンしていました。

そして、今までは「30」だった他のレコードのスコアも全体的に「29」にダウンしていました。

「過去に一回キャンセルしたことがある顧客は今回もキャンセルする可能性が高い」ことを、Einstein AI が学習して導き出した、というわけです。

 

 

 

＊ Einstein 予測ビルダー応用編：「タイタニック号沈没事故の生存確率を出してみよう」

 

 

Einstein 予測ビルダーの設定方法と分析ロジックが理解できたところで、応用編に進みましょう。

データ解析や機械学習の世界では「ギターのFコードのように、初心者がまず最初に通る」サンプルと言われている（らしい）「タイタニック号乗船者の生存確率を算出する」チュートリアルがあり、そこで使用されているデータを拝借させていただきます。

 

Kaggle - Titanic: Machine Learning from Disaster
https://www.kaggle.com/c/titanic/

 

こちらの「Data」タブにある CSV ファイルをダウンロードしておきます。

• train.csv - 全体データを半分に分けた、結果（生存/死亡）を含むデータ
• test.csv - 全体を半分に分けた残りの、結果を削除したデータ
• gender_submission.csv - test.csv から切り取った結果のみのデータ（答え合わせで使用します）

 

インポート先のオブジェクトを作成する必要がありますが、「スプレッドシートからのカスタムオブジェクトの作成」を使用すると、オブジェクト作成が非常にスムーズに進みます。

  

Lightning Experience でスプレッドシートからカスタムオブジェクトを作成
https://help.salesforce.com/articleView?id=dev_objectcreate_task_lex_from_spreadsheet.htm&type=5

 

test.csv には "Survived" カラムが含まれていないので、上記の手順は必ず train.csv で行ってください。

test.csv については、オブジェクトが作成された後に通常のインポートウィザード経由でデータを投入します。（それにより "Survived" が適切に空欄となります）

 

先週の記事でご案内した「予測ビルダーでサポートされるデータ型の制限」について、ご記憶されていますでしょうか。

 

 

train.csv の "Survived" はチェックボックス型ではないので、チェックボックス型同様の「True / False」に置き換えるよう、数式項目を一つ追加します。

 

＜テキスト項目の値を基に「True / False」を返す数式項目を追加する＞

 

もう一つ、後で「答え合わせ」をするために必要な作業があります。

train.csv と test.csv には共に "PassengerId" という項目がありますが、予測分析後に test.csv のデータに対して gender_submission.csv の「結果データ」を追加する際に「外部 ID を使った上書き更新」が必要となり、この項目は上書きの際のキー項目になります。

「ユニーク」「外部 ID」属性の追加をこの段階で必ず行っておきます。

（予測モデル作成後だと項目がロックされ属性変更が行えなくなります）

 

＜"PassangerId" に外部 ID 属性を付与する＞

 

これで準備完了です。

予測ビルダーを起動します。

具体的な手順は先週ご案内したものと同じですが、注意点としては、予測基準項目で分析に関係のなさそうなものを適切に除外するという点です。

CSV ファイルに含まれていた項目は以下の通りです。

このうち、PassengerId, Name, cabin は明らかに分析時のノイズになりそうなので、除外しておきます。

「train.csv での生存者の名前が "N" で始まるものが多いから、test.csv のデータでも "N" で名前が始まる人の生存確率を上げておきました」というのは少々ナンセンスですよね！

この「ノイズとなる項目を除外する」ことこそが、今まで何度か述べた「バイアスの排除」に他なりません。

その他、Salesforce システム項目の「作成者」「所有者」「最終更新者」も省きます。

 

＜予測基準項目からバイアスとなりそうな項目を取り除く＞

 

あとは、サンプルセットは「"Survived" の値に何かしら入っているもの」、予測セットは「"Survived" の値が空欄のもの」、予測する内容は "Survived" ではなくて、後で追加した "Survived_T/F" の方・・・と、先週のおさらいになります。

 

＜サンプルセットの抽出条件： "Survived" の値に「0」か「1」が入っているもの＞

 

予測の準備が完了したので、スコアカードを見てみましょう。

 

 

気になる「上位プレディクター」を見てみましょう。

最上位が「Sex: Male」つまり「男性であること」、次位が同じく「Sex: Female」つまり「女性であること」となっています。その差はかなり大きく（1:0.58）、つまり「男性であること」が予測モデルに対して最も支配的なファクターだということになります。

その次が「Pclass」つまり「チケット等級」になっています。

（「女性であること」の影響度が控えめに計上されたことが、後々若干のバイアスをもたらしています。後ほど「答え合わせ」の項でご説明いたします。）

 

予測の準備が完了したら、予測モデルを有効化してしばらく待ちます。
コーヒーを淹れて一息ついたら、予測セットの一覧を表示するリストビューを作成しましょう。

リストビューの表示条件は "Survived" が空欄のもの、つまり test.csv をソースとするデータです。

表示項目には、Age （年齢）、Sex （性別）、Pclass （チケット等級）に加えて、予測モデル作成の際に設定した「結果を保存するカスタム項目」も表示します。（今回の例では "SurvivalPredictionScore" という名前を付けました）

 

＜スコアが振られた予測セットの一覧を表示するリストビュー＞

 

結果を見ると、スコアは 15 ～ 77 の間でいい感じに分散して付与されています。

前回の「レストランのキャンセル予測」に比べて、予測ファクターが「性別」「年齢」「チケット等級」「同乗者の有無」「既婚か未婚か」「どの港から乗船したか」など多岐にわたっており、そのことがスコアの振られ方にも影響してくるものと考えられます。

 

さて、答え合わせのお時間です。

本章の冒頭で「結果だけのデータがある」とお伝えしました。

このデータ（gender_submission.csv）をインポートし、予測セットのデータに「実際の結果」を追加したうえで、予測ビルダーが導き出した生存確率とマッチングをしてみたいと思います。

 

=============================================================
【※注】
"PassangerId__c" の外部 ID 属性追加はお済みでしょうか。

もし未実施で予測モデルを作成してしまった場合、外部 ID を使用した上書きではなく、「Excel 上で VLOOKUP 関数を使って値の紐づけをした上で、Salesforce ID を使って上書きアップデート」の手順が必要になります。
=============================================================

 

gender_submission.csv に含まれるカラムは "PassengerId" と "Survived" だけになります。

（"PassengerId" の値は、test.csv のものと一致しています）

データローダ、およびインポートウィザードで "PassengerId" をキーにしてレコードの更新を行うことで、test.csv のデータに "Survived" の値を反映させることができます。

この場合、train.csv からの値が既に入っている "Survived__c" とは別に、チェックボックス型項目（名前は例えば "Survived_Result__c" とします）を作成して値の挿入対象とした方がわかりやすいと思われます。

手順については以下のヘルプおよびリリースノートをご参照ください。

 

（データインポートウィザードの場合）
データインポートウィザードの外部 ID による一致に関する機能強化
https://releasenotes.docs.salesforce.com/ja-jp/summer16/release-notes/rn_forcecom_data_diw_match_by_external_id.htm

 

（データローダの場合）
外部 ID を使用して関連レコードをインポートする
https://help.salesforce.com/articleView?id=000320964&language=ja&type=1&mode=1

 

インポートが完了したら、先ほどのリストビューに今回追加した "Survived_Result__c" をカラムに加えて再表示しましょう。

予測ビルダーが導き出した生存率の高い順に上から見ていくと、上位の方は順当に実際の答えも「生存」となっていて、

 

 

生存率 51% ～ 50% の間に境目がありますが・・・

 

 

実際生存している何名かに、43% ～ 38% の低い予測を出しています。

 

 

予測が外れたレコードの一覧をリストビューに出してみました。

（「予測生存率が 50% 以下で実際は生存」、または「予測生存率が 51% 以上で実際は死亡」を表示条件とする）

いずれも明確な共通点があります。

• 女性である
• チケット等級が「３等」である

 

 

これは、以下の理由によるものと考えられます。

• サンプルセットにおいて「全体的にチケット等級が低いほど生存率が低い」傾向がみられた
• サンプルセットと予測セットの両方で「女性の生存率は極めて高く、男性の生存率は極めて低い」共通点があるが、予測セットでは「女性の生存率はチケット等級に関連はほぼ見られない」という差異があった

つまり、Einstein がサンプルセットから最初に「男性は生存率が低い」ことを優先的に学習し、次に「女性は生存率が高い」ことを学習したが、その優先度が「58%」だったために（スコアカードにその旨記載があります）、次位のファクターである「チケット等級」に引っ張られたことで誤差が生じた、と言えるのではないでしょうか。

 

とはいえ、予測を外したレコードは 418 件中の 7 件ですから、かなりの精度です。
この誤差も、分析対象となるサンプルセットの数を増やせば、次第に少なくなっていきます。

皆様も是非ご自身でお試しいただき、Einstein 予測ビルダーの有用性を体感していただければ幸いです。

（実際の業務データをもとに分析を行ってみたらどんな結果が出るか、想像するだけでワクワクしませんか？）

 

ちなみに、予測ビルダーでは「女性は生存率が高い」「チケット等級が高いほど生存率が高い」といった、所謂「ストーリー」は、自身で読み取る必要があります。

一方、もう一つの Einstein 分析予測アプリケーションである Einstein Discovery では、そのストーリーも込みで結果を出してくれるとのことです。

 

Einstein Discovery については次回以降取り上げていく予定です。

 

本章は以下の Qiita ブログ記事を参考にさせていただきました。ありがとうございます。

Salesforce予測ビルダーでタイタニックのデータを分析してみた
https://qiita.com/az-ak/items/5dd711535093b5e849ef

 

 

=================================================

Einstein 予測ビルダーについての記事、如何でしたでしょうか。

冒頭で述べた「ポストコロナ/アフターコロナにおいて Einstein がいかに重要か」という論拠ですが、今後訪問営業なども対象を厳選しなければいけない状況で、対象営業先を厳選する際に、この予測ビルダー、もしくは次週以降取り上げる予定の Sales Cloud Einstein や Einstein Discovery が大きく役に立ってくるはずで、そういった意味では今この段階で Einstein の知見を習得しておくことに大いに意義がある、そのような意図で述べさせていただきました。

 

不明点や疑問点は遠慮なくお知らせください。
まだまだ私もわからないことが少なからずあります、皆様からのご質問は知見を得るうえでの大きな糧になります。

 

今後ともウフル カスタマーサポートを引き続きご愛顧いただきますよう、何卒よろしくお願い申し上げます。

Salesforce･Googleの運用･サポートでお困りなら

 カスタマーサポートへお問合せください。