By Reinier van Leuken, Product Manager Einstein Discovery.
SalesforceでEinstein Discoveryチームのプロダクトマネージャーをしています。私は常にデータサイエンスと人工知能に取り組んでおり、Einstein Discovery Stories と、組み込まれた拡張知能がより良いビジネス成果をもたらすことに非常に情熱を持っています。
Einstein Discovery モデルのための適切なデータがないと主張する顧客よりも悪いことは何でしょうか。正しいデータをすべて持っているにもかかわらず、モデルを完全に間違った方法でセットアップしている顧客です。
私は、多くのお客様のモデルの品質向上のお手伝いをしています。彼らはしばしば、以下の標準的な間違いのうち少なくとも1つ（たいていはそれ以上）を犯しています。最近、あるお客様と仕事をしたのですが、そのお客様はモデルのセットアップでほとんど全ての標準的な間違いを犯していましたので、ケーススタディとしてまとめることにしました。この修正作業をしながら、モデル品質の分析をしていくので、読んでみてください。
私がしたことは、誰にでもできる標準的な一連のステップを踏んだだけであり、何よりもEinstein Discoveryは、すでにこのステップを推奨していたのです。
予測モデルの作成は、繰り返し行われるプロセスです。ありがたいことに、モデルの品質を向上させるための一連のステップを繰り返し行うことができます。ここでは、私がある企業と協力して Einstein Discovery モデルをどのように改善したかについて、ケーススタディを紹介します。その目標は、エンジニアが顧客サイトで実行する技術的な作業指示の期間（分単位）を予測することでした。このようなモデルの価値は一目瞭然で、エンジニアのプランニングが非常に容易になり、その結果、エンジニアの効率も向上します。しかし、彼らは自分たちのユースケースに適した高品質のモデルを得るのに苦労しており、助言を求めてきました。
モデルの最初のバージョンは、“実際の期間”を結果変数として設定し、120,000件の作業指示書で学習させたGLMでした。これは32の予測変数を使用し、R2は0.42という結果となりました。しかし、どの予測変数も結果に対して1.0%以上の相関を持ちませんでした。これは疑わしいです。また、このモデルのMAE（平均絶対誤差）は62分でした。つまり、平均して予測は62分長いか短すぎるということです。あまりよくないですね。このモデルの全体的なパフォーマンスはこんな感じです（これらのモデル指標に馴染みがない方はこちらの記事をご覧ください）。
また、「予測 vs 実績」チャートでは、予測された期間が4種類しかないことに注意してください（！）。ワークオーダーの予測期間は、以下のいずれかです。
- 43 minutes
- 5,500 minutes
- 20,000 minutes or
- 37,000 minutes
つまり、このモデルはあまり良くなかったのです。
このような状況で私が最初に見るのは、「設定」と「アラート」です（以下のスクリーンショット）。アラートでは、クロスバリデーションが失敗していることがわかります（クロスバリデーションが何かわからない場合は、Tips & Tricks ビデオシリーズのこの説明ビデオをご覧ください）。この問題を解決するために、Einstein Discovery は外れ値を探すことを提案します。それは、結果変数にも発生する外れ値アラートによって確認されます。最後に、多重共線性のアラートもたくさん見つかりますが、それについては後で詳しく説明します。
外れ値除去
機械学習で最も重要な仕事は、結果変数が意味をなすことを保証することなので、まずこの異常値アラートを調査してみましょう。これは常に物事を修正する最初の場所です。この“Actual Duration”というフィールド、まさに私たちが予測しようとしているものを分析しようと思います。学習データ（120k行）では、“作業指示書”の”Actual Duration”は0から83,893分（つまり58日）の範囲です。おっと。これは大きな範囲です。このような広い範囲を扱うには、データポイントが範囲全体にうまく分布している必要があり、一部だけに集中していてはダメなのです。(言い換えれば、疎な分布ではなく、密な分布が必要なのです）。しかし、99%のワークオーダーが400分未満で、98%の“作業指示書”が216分未満であることがわかります。これは、1000分で上限を設定したときの結果変数のヒストグラムです（全範囲を含めるとヒストグラムは読めなくなります）。
Einstein Discoveryが外れ値について警告するのも無理はありません。合計すると、99.7%の数値範囲をカバーするデータ量は約2%です（その結果、98%のデータは0.3%の数値範囲に収まりますが・・・）。400分までの作業指示書、あるいは最大216分までの作業指示書だけをモデルに学習させることは理にかなっています。 この顧客は、時々発生する問題のある”作業指示書が30日または50日開いているかどうかを予測することには興味がなく、作業指示書の大部分について、技術者が1、2、4または8時間必要かを知りたいと考えています。
これらの外れ値の問題は、数が少ないにもかかわらず、モデルを完全に支配してしまうことです。これは、前に見たように、予測に歪みをもたらします。
この最初の繰り返しでは、外れ値をフィルタリングする以外に、単に目に留まったからという理由で、いくつかのクイックフィックスを適用しました。
1. 仕事の名前を含む“Name”という変数をモデルから削除しましたが、これは同じくあった“Service Type”という変数と100%同じです。このような重複は多重共線性を引き起こします。この問題に対する警告はかなり多く、それは後で扱いますが、これはあまりにも明白だったので、もう取り除くことにしました。なぜこのような重複が問題になるのか不思議に思うかもしれません。それについては、Tips & Tricksビデオシリーズで説明ビデオを作りました。
2. 同じく “Name “と呼ばれる、6,410個のユニークな値を含む別の変数を削除した。これは、”High Cardinality Data Alert “と表示されました。多くのユニークな値を持つ変数があっても、少数の値がデータの大部分をカバーし、小さくて頻度の低い値のロングテールが存在する限り、問題にはなりません。正確には、Einstein Discoveryは最も頻繁に出現する100個の値を取り、残りを「その他」というカテゴリにグループ化します。 しかし、この場合、最も頻度の高い変数の出現回数はわずか234回でした（120,000行あることを思い出してください…）。このデータセットでは、実際、全データの88.7%がこの “Other “というカテゴリにグループ化されることになり、この変数は予測変数としてはかなり役に立たないということになります。 この変数を高カーディナリティとしてマークして（これはモデル中の1つの変数に許されます）、最も出現する200個のフィールド値を取るとしても、ほとんどのデータが「その他」カテゴリにグループ化されるでしょう。詳しくは、Tips & Tricksビデオシリーズで、Einstein Discoveryのこのカーディナリティの概念を扱った説明ビデオを作成しました。 そこで、この高いカーディナリティの変数をモデルから削除しました。
3. そして、今のところ、モデルからすべての日付フィールドを削除しています。顧客は、将来の作業指示を予測したいのですが、それはいずれにせよ異なる日付範囲を持つことになります。もちろん、週や月レベルの季節性が実際の期間と相関があるかどうかを調べるために、WeekOfYear または MonthOfYear 変換を使用して、後でそれらを追加することができますが、今はそれを除外しています。
繰り返しになりますが、私が適用した最も重要な変更は、400分以上継続した1%のWork Orderを削除し、モデルを再トレーニングしたことです。これは、新しいモデルと元のモデル（下のスクリーンショットでは「Raw data」と呼んでいます）を比較したものです：
1,205行のデータを取り除いただけで、MAEは63.4分から17分へと改善されました。R2が0.42から0.26に低下したのは意外に見えるかもしれませんが、これは実際に悪化しています。しかし、外れ値はR2を人為的に高く維持する傾向があります。次の表は、実績値と予測値、それに対応するR2の値を比較したものです。2番目の表では、データセットに外れ値が1つだけ追加されており、モデルも確かに大きな値を予測しています。しかし、この予測に対してモデルがR2として受け取るスコアは非常に高いのです。ですから、外れ値を取り除いた後にR2が低下したことは、モデルの劣化を意味するものではありません。それは単に、いくつかの外れ値を方向的に正しく捉えることでモデルが得た非現実的なスコアが取り除かれ、より現実的なR2が明らかになったということです。
アルゴリズムの変更
さて、学習アルゴリズムについてですが、ここまではGLMとしてモデルを学習させました。Einstein Discoveryでは4種類の学習アルゴリズムを選択することができます。GLM、GBM、Random Forests、XGBoostの4種類です。これらについて詳しく知るために、Tips & Tricks ビデオシリーズで、これら4つのアルゴリズムの主な違いを説明するビデオを作成しました。もし、どれを選んだらいいかわからない場合でも、心配はいりません! モデルトーナメントを実行して、どれがあなたのデータとユースケースに最も適しているかを確認すれば、Einstein Discovery があなたに適したものを選択します。この場合、XGBoostは良い仕事をすると思います。ユースケースが回帰なので、非線形関係だということとレンジはかなり広いことを疑えば良いでしょう。とりあえずこれで試してみて、さらに変更を繰り返したら、やはりモデルトーナメントを実行して仮説を検証することができます。
実際、XGBoostを使用すると、R2は再び少し改善され、MAEは17分から16分へとさらに1分減少しました。どちらのモデルも同じデータ（400分以下の作業指示書）で学習させました。
まだまだ外れ値の除去
学習データを400分以下の受注に限定しても、実際の作業指示が長い受注は異常値として警告されます。結果変数の分布からすると、当然といえば当然なのですが。さらに制限をかけるべきでしょうか？データの98％を取って、216分に制限すべきでしょうか？あるいは、100分で上限を設定しても、95%のデータが残るのでしょうか？なぜなら、学習データを100分以下の作業指示に限定すると、それ以上の作業指示はうまく予測できない可能性があるからです。しかし、このような異常値はデータのごく一部であり、このモデルを使用する前に、異常値を特定する他の方法があるかもしれないので、顧客はそれを気にしないかもしれません。
さらに外れ値を除去することの利点は明らかです：
高カーディナリティの許可、NULLの除去
では、このXGBoostで学習させたモデルを、作業指示が100分未満のWork Orderに対して適用し、残りの予測変数について詳しく見てみましょう。
実際の“作業時間”との相関が最も強い予測変数は、“リソース名”と呼ばれるもので、実際に作業を行った技術者やエンジニアを指しています。100分以下の作業指示を見た場合、それは結果に対して15.5%の相関があります。しかし、この変数には171のユニークな値（171人の異なる技術者を意味する）があり、高いカーディナリティを持っています。ありがたいことに、カーディナリティに関するビデオで説明したように、Einstein Discoveryは、１つだけですが、変数が200のユニーク値までを許します。この変数はそれにぴったりだと思われます!
なお、すべての値が少なくとも25回出現することが要件となっています。そして、このケースでは、171人の技術者のうち、トレーニングデータで24件以下のWork Orderを持つ技術者は29人です。そのため、それらはやはり「その他」のカテゴリーに分類され、したがって、モデルには142人の異なる技術者が認識されることになります。
また、技術者が NULL 値の Work Order（42000）が多数存在します。とりあえずそれらも取り除いてしまうというのも一つの手ですが、かなり重大な決断です。 学習データを114000個のWork Ordersから72000個の Work Ordersに減らすだけでなく、この変数にモデルをより依存させる可能性があることを意味しているのです。つまり、最も正確な予測は、この142人のエンジニアのうちの1人が行ったワークオーダーになるということです。
しかし、私は、それが受け入れられるかどうか、そして、142人の技術者のセットが、彼らの将来のモデルの使用目的に対して十分に代表的であるかどうかを、顧客と議論するためにメモを取ります。
この最新のイテレーションの結果は以下の通りです。確かに、この特定のデータでは、リソース名（つまり技術者）の高カーディナリティを許可し、リソース名 = nullの作業指示を削除することは有益ですが、もう一度、既知の 142 件以外の作業指示の挙動を監視することが重要です。
Solve multicollinearity
さらに繰り返して、さまざまな変数とそのアラート、相関関係を改めて見てみましょう。なぜなら、縮小されたデータセットを見ている今、それらは変化しているからです。
まず、多重共線性の警告をいくつか解決するつもりです（説明ビデオはこちら）これは品質を根本的に改善することはありませんが、予測の品質を犠牲にすることなくモデルを単純化することができ、もちろんそれは常に良いことです。さらに、これはモデルの説明可能性を大きく向上させます。
“リソース名”は26.3%の相関を示し、実際にいくつかの多重共線性の警告を投げています。最も顕著なのは、“緯度”、“経度”、“地域”（実際にはまた「名前」と呼ばれます）、“都市”といった地理的な情報と重複していることです。 これらのうち、私は“都市”だけを残しています。これは適切な集計レベルであると思われます（“リソース”よりは高いですが、“作業時間”と1.8%の相関しかない“地域”ほど高くはありません）。
また、”Agreed Duration VD-WT” と “Agreed Duration in Minutes” は重複しているので、多重共線性のアラートを投げています。最も相関の強いもの、つまり相関8.6%の “Agreed Duration VD-WT “を残すことにしました。
数値変数のバケッティングを調整する
さて、この先、最も重要な連続変数に注目する必要があります。それは、”Agreed Duration WD-VT “と呼ばれるものです。合意された期間が最終的な実際の期間と強い相関があることは驚くことではありませんので、実際にそれをモデルで使用してみましょう。Einstein Discoveryは、これらの連続変数をバケットで扱います。このトピックについては、説明ビデオも作成しました。ここで、モデルに正しいバケットがあるかどうかを検討する必要があります。Einstein Discoveryのデフォルトのバケット化は、10進法です。しかし、この変数を見ると、本当の連続範囲（つまり、すべての可能な値を持つ）ではなく、これらは比較的少数の固定値（5分、10分、30分など）であることがわかります。したがって、これらをバケットとして反映するには、手動バケット化を設定するのが最善です。
しかし、R2とMAEはあまり改善されませんでした。もしかしたら、バケットを作りすぎてしまったのでしょうか？
この変数のDescriptive Insightを見てみると、以下のようになります。確かに多少は増加傾向にあるようですが、あまり強くはありません。
実は、Einstein Discoveryにはバケットに関する提案もあります。Einstein Discoveryでは、バケットを作成してユニークな値をすべて別のバケットにするのではなく、いくつかの値をそのようにグループ化することを提案しています。
Agreed Durationの相関性は、手動バケツでは11.04%でしたが、提案バケツでは8%に低下しています。バケット数が少ないと、結果との相関が弱くなるのは理解できます。しかし、このモデルの性能は、高いレベルで少しも変わっていません。
実際、Einstein Discoveryが連続変数で提案したバケットの提案のために、今、すべての推奨に従いましょう。ここでも、性能は多かれ少なかれ安定したままですが、よりシンプルなモデルになっています（一般的に、Einstein Discoveryは数値変数に対して10進法よりも少ないバケットを提案することに成功しています）。精度を犠牲にすることなく、よりシンプルであることは常に良いことです。
セグメンテーション
予測試験を見ていると、今のモデルはそれなりによく予測できていることがわかります。最も大きなミスは、より長いジョブに対して起こります。モデルは仕事が長くなりそうなときにピックアップしますが、常に正しい範囲にいるわけではありません。トレーニングデータセットの平均時間は現在15分です。ジョブがかなり長い場合、例えば80分程度かかる場合、モデルは40分程度に予測する傾向があります。短いジョブが多いため、このように予測が甘くなる傾向があり、本当に長くかかる少数のジョブを正しく特定するには、予測変数がまだ十分でないようです。
次のステップは、モデルがいつうまく予測し、いつ外れるかをさらに調査することです。そうする一つの方法は、手動でホールドアウトデータセットを作成し、データレシピpredictノードを使用してこのデータセットについて予測することです（その方法についての詳細な説明はこちらを参照してください。CRM Analytics の探索では、予測と実績を比較し、様々な次元でグループ化し、モデル品質がプラスまたはマイナスで際立っている箇所を見つけることができます。これにより、モデルをセグメント化して展開することを決定することができます（セグメント化されたモデルについての詳しい説明はこちらをご覧ください。
23年冬には、このプロセスをより簡単にする予定です。モデルインスペクター（Model Inspector）と名付けられた一連の機能は、上記のようにデータセグメントごとのモデル性能など、より多くのモデル品質に関する洞察をユーザーに提供するものです。
結論
かなり意味のないモデルからスタートして、以下のステップを踏んでそれなりに良いものに改善していきました。
- GLM（デフォルト）から始め
- アラートと設定を見直す
- 外れ値を除去
- 予測アルゴリズムの見直し
- 変数を詳細に見直す
- カーディナリティの分析
- nullの除去
- 多重共線性の解決
- バケットのチューニング
- セグメンテーションの検討
これは、誰でもできる一連の流れです。このリストが全てだとは言いませんし、もちろん順番を変えることも可能です。しかし、多くのお客様と一緒にモデルの品質向上に取り組んできた経験から、この方法でモデルの品質問題の大部分を解決できると断言できます。
翻訳：小見 一平、AI and Analytics Specialist, Salesforce Japan Co.,Ltd.