自信を持って Analytics へようこそ。このシリーズでは、最新のデータ分析の成功の鍵である検証について探求します。 最初と2 回目の投稿では、一般化可能性について説明し、一般化されない問題のあるモデルを構築する方法について説明しました。この投稿では、反応レシピのケーススタディを続け、信頼できるモデルを構築するためのシンプルなツールとしてホールドバック検証を紹介します。
このケーススタディでは、高価値の化学製品を製造するためのレシピを検討していることを思い出してください [1]。成分の選択には 4,608 通りのバリエーションがあります (求電子剤 4 個 x 求核剤 3 個 x 配位子 12 個 x 塩基 8 個 x 溶媒 4 個)。私たちは、考えられるレシピのうち 150 件のデータを使用して、レシピの収量を予測し、材料の最適な組み合わせを見つけるためのモデルを構築したいと考えています。
前回構築したパーティション モデルは、RSquare が 0.985 で、実際と予測のプロットがデータに非常によく適合していることがわかり、一見すると素晴らしく見えました。しかしその後、トレーニング データに含まれていない 4,458 レシピすべてについて、モデルの予測が実際の収量とどのように比較されるかを調べました。このモデルは、実際には収量が 0 に近いいくつかのレシピについて、100% に近い収量を予測しました。
Actual versus Predicted plots for the data that was used to train the model (left) and the data for all the other recipes that were not used to train the model (right). This is an example of an "overfit" model that does not generalize.Actual versus Predicted plots for the data that was used to train the model (left) and the data for all the other recipes that were not used to train the model (right). This is an example of an "overfit" model that does not generalize.Actual versus Predicted plots for the data that was used to train the model (left) and the data for all the other recipes that were not used to train the model (right). This is an example of an "overfit" model that does not generalize.モデルのトレーニングに使用されたデータ (左) と、モデルのトレーニングに使用されなかった他のすべてのレシピのデータ (右) の実際のプロットと予測のプロット。これは、一般化されない「オーバーフィット」モデルの例です。
トレーニング データでは適切に見える種類のモデルを構築しても、目に見えないデータでテストしたときに一般化できないことが判明することを回避するにはどうすればよいでしょうか?また、モデルが不必要に複雑にならないようにするにはどうすればよいでしょうか?
あなたが思いついたかもしれないアイデアの 1 つは、構築プロセスの各ステップで目に見えないデータに対してモデルを検証することです。デシジョン ツリーの各分割後に停止して、モデルのトレーニングに使用されなかった 4,458 のレシピの実際と予測 (および RSquare) をチェックすることもできました。目に見えないデータへの適合が最も優れているモデルとして最適なモデルを選択できます。そして、それがどの程度のパフォーマンスを期待できるかについての知識が得られるでしょう。
もちろん、これは人為的な状況です。考えられるすべてのレシピのデータがあれば、モデルを検証するためにデータの大部分を差し控えることはありません。同じアイデアで、150 レシピのデータだけを活用することはできますか?
導入…検証列の作成
はい、これを行うためのツールがあります。 JMP Pro の検証列の作成は、モデル構築プロセスの各ステップで保留され、検証として使用されるデータ テーブル内の行の一部をマークします。さまざまな便利なオプションがありますので、後の投稿で説明しますが、この例ではシンプルにしてデフォルトのままにします。
The Make Validation Column tool in JMP Pro (Analyze > Predictive Modeling). In this example, we stick with the defaults to make a Random Validation Column and click OK.The Make Validation Column tool in JMP Pro (Analyze > Predictive Modeling). In this example, we stick with the defaults to make a Random Validation Column and click OK.The Make Validation Column tool in JMP Pro (Analyze > Predictive Modeling). In this example, we stick with the defaults to make a Random Validation Column and click OK.JMP Pro の検証列の作成ツール ([分析] > [予測モデリング])。この例では、デフォルトのままにしてランダム検証列を作成し、「OK」をクリックします。
提案された 0.75/0.25 を使用します。トレーニング/検証の分割。つまり、150 行のデータのうち 37 行が検証のために保留されます。
The default 0.75/0.25 training/validation split in Make Validation Column. Enter “1234” as the Random Seed if you want to follow along in JMP Pro and get the same results.The default 0.75/0.25 training/validation split in Make Validation Column. Enter “1234” as the Random Seed if you want to follow along in JMP Pro and get the same results.The default 0.75/0.25 training/validation split in Make Validation Column. Enter “1234” as the Random Seed if you want to follow along in JMP Pro and get the same results.[検証列の作成] のデフォルトの 0.75/0.25 トレーニング/検証分割。 JMP Pro で操作して同じ結果を得たい場合は、ランダム シードとして「1234」と入力します。
これで、データ テーブルに Validation 列が追加され、行のうち 37 行を検証用にマークし、残りの行をトレーニング用にマークしました。
Validation column in our data table that marks 37 of the rows for validation and the others for trainingValidation column in our data table that marks 37 of the rows for validation and the others for trainingValidation column in our data table that marks 37 of the rows for validation and the others for trainingデータテーブルの検証列。37 行を検証用にマークし、残りをトレーニング用にマークします。
ここで、投稿 #2 で作成したパーティション モデルを検証しながら繰り返してみましょう。ここで重要な手順は、パーティションを起動するときに検証ロールに検証列を追加することです。
Partition model with validationPartition model with validationPartition model with validation検証付きパーティションモデル
最初の分割は、検証を行わないモデルの場合と同じです。しかし、トレーニング データと検証データの両方の RSquare を確認できるようになりました。検証データへの適合はトレーニング データほど良好ではありません (RSquare = 0.133 vs 0.224)。
Go ボタンを押すと、アルゴリズムが多数の分割を探索し、最大の検証 RSquare を持ったツリー、つまり保留されているデータを最もよく予測するモデルに枝刈りを戻します。この場合、検証 RSquare (赤色) は 5 つの分割でピークに達しました。その時点を超えると、モデルはより複雑になり、トレーニング データへの適合性が向上しましたが、目に見えないデータに一般化するパターンを見つけるのではなく、ノイズに対して過剰適合していました。検証 RSquare は同じであり、モデルがより単純であるため、4 つの分割に戻すこともできます。
他のモデルはどうですか？
他にも使用できるさまざまな統計および機械学習モデルのタイプがあります。ホールドバック検証のもう 1 つの利点は、検証済みのモデルを迅速に構築して比較し、どれが最もパフォーマンスが高いかを見つけることができることです。 JMP Pro のモデル スクリーニング プラットフォームを使用すると、これが非常に簡単になります。この場合、Boosted Tree モデルが最も高い検証 RSquare を持つことがわかります。
Model Screening report showing the Boosted Tree has a slightly better Validation RSquare than the Decision Tree and the other statistical and machine learning methods.Model Screening report showing the Boosted Tree has a slightly better Validation RSquare than the Decision Tree and the other statistical and machine learning methods.Model Screening report showing the Boosted Tree has a slightly better Validation RSquare than the Decision Tree and the other statistical and machine learning methods.モデル スクリーニング レポートは、ブースト ツリーがデシジョン ツリーや他の統計および機械学習手法よりもわずかに優れた検証 RSquare を持っていることを示しています。
ここで、この Booted Tree モデルのパフォーマンスを確認すると、モデルのトレーニングや検証に使用されなかった 4,458 レシピの予測と実際の収量がかなりよく一致していることがわかります。
もっと詳しく知る：
[1] Perera D、Tucker JW、Brahmbhatt S、Helal CJ、Chong A、Farrell W、Richardson P、Sach NW からのデータ。ナノモルスケールの反応スクリーニングとフロー内でのマイクロモルスケールの合成を自動化するためのプラットフォーム。科学。 2018 1 26;359(6374):429-434。土井: 10.1126/science.aap9112。 PMID: 29371464。サンプリングされたデータセットと完全なデータセットは、JMP データ テーブルとして添付されます。
素晴らしい説明ですね、フィル！ 私は Arla Foods の最初の人物として、8 月から PRO バージョンへのアクセスを許可されました 
私が構築したモデルの検証を開始するのを本当に楽しみにしています。
あなたの投稿に関連して、フォローアップの質問が 2 つあります。アプリを使用してカスタム DoE 設計を作成したとします。 20〜30回実行します。
モデルのトレーニング、検証、テストは引き続き機能しますか、それとも実際に何かを得るには 100 回以上の実行が必要ですか?
その後、同じ設計を新しいレベルで拡張 (同じ要素のテスト) し始めたらどうでしょうか? JMP はこれらの実行をトレーニングと検証の両方として再度配布しますか?
ありがとう。
よろしくお願いします
クリスチャン・ベルテルセン
こんにちは、 @Steffen_Bugge 。
当初の計画では、モデル検証に関する他のトピックを探求するために、さらに投稿を書く予定でした。しかし、今はこれに取り組む時間がないと思います。将来、他の誰かが引き継ぐかもしれません。
