モデルスクリーニングプラットフォームでハイパーパラメータを変更する方法JMPの専門家の皆さん、こんにちは。
モデル スクリーニング プラットフォームは非常に便利です。チューニング デザイン テーブルを通じてハイパーパラメータを把握したので、JSL などのモデル スクリーニング プラットフォームでハイパーパラメータを変更する方法があるかどうか疑問に思っています。
プラットフォームがハイパーパラメータを変更できない場合、記事のデフォルトパラメータを使用できますか。
お返事を楽しみにしています
高度な統計モデリングRe: モデルスクリーニングプラットフォームでハイパーパラメータを変更する方法Victor_G さん、こんにちは。
非常に刺激的なご返信をありがとうございます。私も、まずモデル スクリーニング プラットフォームで、次に適切なアルゴリズムでこのアプローチを試すことができます。
過剰適合を避けるために、少量のデータの場合は K 分割交差検証が適しています。ただし、一部のアルゴリズムプラットフォーム（モデルスクリーニング以外）では、ブートストラップフォレスト、ブーステッドツリー、ベイブベイズなど、K分割交差検証をサポートしていません。もちろん、層別式（K分割）検証列は適合しません。したがって、モデル スクリーニング プラットフォームとハイパーパラメータの最適化で最も有望なアルゴリズムを選択した後、少量データの場合にモデルをより適切にトレーニングする方法についての経験を共有していただけますか?
最後に、「選択したものを実行」ボタンをクリックした後、K分割交差検証を備えたモデルスクリーニングプラットフォームのすべてのアルゴリズムが自動的に生成する検証フォールド。それでは、過剰適合を避けるために、この検証フォールドを最適なハイパーパラメータと同じアルゴリズムで使用できますか?
あなたからの返信を楽しみにしています。
Re: モデルスクリーニングプラットフォームでハイパーパラメータを変更する方法こんにちは@Wang123 、
私の回答が役に立ったと聞いて嬉しいです。
機械学習をうまく利用するには、分析を始める前に機械学習プロジェクトの戦略とフレームワークを設定する必要があります。多くの場合、機械学習プロジェクトは、開始点 (データ収集の考慮事項) または終了フェーズ (テスト条件と監視) が十分に考慮され定義されていないために失敗します。
- 出発点: データの収集方法について考えます。データセットは、実行したいタスクをどの程度代表していますか? データはどのようなコンテキストで収集されましたか: 観察研究、または DoE などの制御された実験? データのサンプリングと機能/変数の分布は、モデルの環境で発生するものと似ていますか (たとえば、変数の範囲/レベル、クラスまたは値間の不均衡または均衡、応答分布、同様の測定機器のパフォーマンス、測定の不確実性など)?
これらの質問は、機械学習にデータを使用する際に考慮して定義する必要がある内容のほんの一例であり、期待を管理するのに役立ちます。
- 終了フェーズ: 最終モデルをどのようにテストするかを知っておく必要があります。データセットを分割してテスト用に一部を保持しておくことはできますか? それとも、モデルのパフォーマンスをテストおよび監視するために新しいデータを取得する予定ですか?
ご質問に関連するその他の推奨事項とガイダンス、および追加のコメントを以下に示します。
- 誤解を避けるために、各セットの用途とニーズが何であるかを知ることが重要です。
- トレーニングセット:モデルの実際のトレーニングに使用されます。
- 検証セット: モデルの最適化（ハイパーパラメータの微調整、特徴/閾値の選択など）とモデルの選択に使用されます。
- テスト セット: 新しいデータや未知のデータに対する選択したモデルの一般化と予測パフォーマンス評価に使用されます。この段階では、複数のモデルが競合することはありません。
- データセットが小さい場合、モデルの検証（モデルの比較と選択）を実現するためのオプションがいくつかあります。
- 小さなデータセットを扱う場合は、シンプルなアルゴリズムを選択してください。一般的に、モデル内の (ハイパー) パラメータの数が多いほど、モデル内の各 (ハイパー) パラメータを正確に推定するためにより多くのデータが必要になるため、トレーニング データセットを大きくする必要があります。小さなデータセットを扱う場合は、ランダム フォレスト、サポート ベクター マシン、一般化回帰/分類などの堅牢なアルゴリズムを選択することをお勧めします。
詳しい説明については、私が作成した LinkedIn の記事をご覧ください。- ランダムフォレスト
- SVM
これらのアルゴリズムは両方とも、調整するハイパーパラメータがほとんどないか、ハイパーパラメータの調整に対してパフォーマンスが堅牢であるか（前述のhttps://arxiv.org/abs/1802.09596を参照）、または、過剰適合を回避して予測の分散を減らすのに役立つトレーニングの特異性を持っています（たとえば、ランダムフォレストのブートストラップサンプル部分）。
ブースト ツリーやブースト アルゴリズムは、以前のエラーを順次修正することでバイアス (系統的エラー) を可能な限り減らすことに重点を置いているため、使用しません。これにより、これらは非常に効果的な予測アルゴリズムになりますが、非常に敏感で、トレーニング セットの影響を受けやすく、一般化のパフォーマンスが低下し、分散が大きくなる可能性があります。
より一般的には、 ML アルゴリズムを扱う方法は 2 つあります。
- データセットのサイズ、制約、その他の多くの選択基準によってモデルと可能性の数が減り、最も有望なモデルを選択するためにいくつかのモデルを試すことになります。今年行った、空間充填混合 DoE と機械学習の使用に関するプレゼンテーションの録画がこちらにあります。実験計画法と機械学習の相乗効果によるドメイン実験の強化 - JMP ユーザー コミュニティモデルの選択を見ると、自分のプロジェクトの選択基準についてのアイデアが浮かぶかもしれません。
- どのモデルのパフォーマンスが優れているかがわからず、アルゴリズム間で最初の探索的モデリング テスト/競争を実施したいと考えています。この場合、データのサブセット (60 ～ 80%) を使用してモデルをトレーニングし、比較するか、データセットが非常に小さい場合は、この最初の探索部分を実行するために、データ全体をクロス検証と共に使用します。有望なアルゴリズムを特定したら、明確な検証戦略 (たとえば、再現性を確保するために固定シードを使用した層別 K 分割クロス検証) を備えた個別のモデル プラットフォームを使用してみてください。
クロス検証と結果の表示方法に関する最後のコメントとして、いくつかの警告がある可能性があります。
- 結果は各フォールドごとに表示されます。特定のフォールドでトレーニングおよび検証されたモデルを実行しないでください。これは、モデルのパフォーマンスを向上させるために最適なデータ分割を選択しているため、「不正行為」と見なされ、新しいデータ/テスト セットで期待される全体的なパフォーマンスに偏りが生じます。
- K 分割クロスバリデーションは、正確には検証方法ではなく、異なるデータ パーティションでモデルがどのように動作するかを確認する「堅牢性テスト」であるため、誤解を招く名前が付けられています。参照: MFML 065 - K 分割クロスバリデーションの理解 (youtube.com)
したがって、このステップで重要な情報は、各フォールドでのモデルの個々のパフォーマンスではなく、パフォーマンスがどの程度規則的で類似しているか (すべてのフォールドでの平均パフォーマンスと標準偏差パフォーマンス) です。結果に矛盾や大きな差異が見られる場合、モデルがタスクに適していないか、データに個別のポイント (チェック対象) があり、モデルが混乱して一般化やパターンの検出が妨げられている可能性があります。
- 最後に、クロスバリデーションが完了したら、その結果をどうするかについてコンセンサスはありません。データセット全体で選択したモデルを再トレーニングする人もいれば、各フォールドでトレーニングした個々のモデルをアンサンブルする人もいます。または、予測を積み重ねる人もいます...この展開フェーズに関するリンクは、評価から最終モデルに到達する方法です (substack.com)
あなたにとってより意味のあるオプションを選択してください。
この投稿には補足的な議論や回答も掲載されています: クロス検証 - 検証列メソッド
長くて申し訳ありませんが、この長い回答があなたにとって何か役に立つことを願っています。:)
Re: モデルスクリーニングプラットフォームでハイパーパラメータを変更する方法Victor_G さん、こんにちは。
ご協力ありがとうございます。ハイパーパラメータ調整機能を備えたモデル スクリーニング プラットフォーム、またはK フォールド機能を備えたすべての個別モデル プラットフォームのいずれかを使用すると、問題を簡単に解決できます。2 つのプラットフォームにいくつかの機能が欠けているのは残念です。
少し考えた後、次の手順が適切かどうかも尋ねたいと思います。
（１）80％のトレーニングセットと20％のテストセットによる層別サンプリング。
（２）トレーニングセット（80％）では、K分割交差検証法を用いて複数の機械学習アルゴリズムをトレーニングした。モデルスクリーニングプラットフォームで。もちろん、このステップではデフォルトのハイパーパラメータを使用します。比較した結果、Bootstrap Forest などのアルゴリズムの一部が最適であることがわかりました。
（３）次に、チューニング設計表を通じてブートストラップフォレストの最適なハイパーパラメータを明らかにした。
（4）トレーニングセット（80％）では、最適なハイパーパラメータを使用してブートストラップフォレストアルゴリズムを再適合しました。もちろん、他のアルゴリズムを適合させることもできます。
（５）テストセット（20％）では、ブートストラップフォレストと他のアルゴリズムのモデルパフォーマンスをさらに評価しました。
上記の手順は JMP では適切でしょうか?
ステップ2では、デフォルトのハイパーパラメータを使用したモデル比較の結果（K分割交差検証の結果）を記事に報告するだけでよいのでしょうか？もちろん、多くの記事はステップ3から始まり、次にステップ2に進むので、最適なハイパーパラメータを使用したモデル比較の結果を報告します。
ステップ 4 では、クロス検証メソッドを設定していませんが、これは正しいですか? または、別の方法がありますか?
あなたからの返信を楽しみにしています。
Re: モデルスクリーニングプラットフォームでハイパーパラメータを変更する方法Victor_G さん、こんにちは。
あなたの返信はとても有意義です。K 分割検証列の作成方法はわかっています。私が知る限り、一部のアルゴリズム プラットフォームは、ブートストラップ フォレスト、ブーステッド ツリー、ベイブ ベイズなどの K 分割クロス検証をサポートしていません。これは、JMP ヘルプ ( https://www.jmp.com/support/help/en/18.0/index.shtml#page/jmp/kfold-and-holdback-validation.shtml ) で利用できます。この場合、小さなデータをトレーニング セット、検証セット、テスト セットに分割する必要があります。これらのアルゴリズム プラットフォーム (ブートストラップ フォレスト、ブーステッド ツリー、ベイブ ベイズ) で K 分割クロス検証を使用する方法はありますか?
あなたが言ったように、「結果は各フォールドに表示されます。特定のフォールドでトレーニングおよび検証されたモデルを実行しないでください。それは不正行為と見なされます...」、そして別の人は「最後に、クロス検証が完了したら、結果をどうするかについてのコンセンサスはありません。データセット全体で選択したモデルを再トレーニングする人もいれば、各フォールドでトレーニングされた個々のモデルをアンサンブルする人もいます」と言いました。特定のフォールドでトレーニングするか、トレーニング セット全体でトレーニングするか、どちらの方法が適切かわかりません。
あなたからの返信を楽しみにしています。
Re: モデルスクリーニングプラットフォームでハイパーパラメータを変更する方法こんにちは@Wang123 、
申し訳ありませんが、一部のモデリング プラットフォームでは K 分割交差検証列の使用が制限されているというのはその通りです。
回避策として、共通の検証列式 (80% のトレーニングと 20% の検証による層別サンプリング) を作成し、それをモデル プラットフォームで使用して、「シミュレート」機能を使用して多数のクロス検証サンプルと結果を生成し、堅牢性を評価することが考えられます。この方法については別の投稿で説明しました: 解決済み: Re: 多数の繰り返し検証を自動化して 1 つの出力タブにまとめる方法 - JMP ユーザー コミュニティ
2 番目の質問に関して、私の個人的な意見としては、個々のモデルからの予測を積み重ねて、各個々のモデルが最終予測に同じ貢献をするようにすることです。これは最も中立的なアプローチのようで、バイアスと (主に) 分散の削減 (「群衆の知恵」アプローチ) と、過剰適合の防止が可能になります。また、個々のモデルの貢献により、不確実性の予測間隔を推定する良い機会にもなります。
個々のモデルの組み合わせには、最終的なアンサンブル モデルが過剰適合せず、一般化できることを確認するための追加の検証が必要になるため、小規模なデータセットではアンサンブルは複雑すぎます。
ML アルゴリズムに関する詳しい知識に応じて、データセット全体を使用して最終モデルをトレーニングするオプションも使用できます。また、クロス検証済みモデルの結果と「非検証済み」モデルの結果を比較して、過剰適合の兆候を見つけることもできます。
繰り返しになりますが、単純なモデルと正規化/制限手法を使用すると、過剰適合を防ぐのに大いに役立ちます。
この回答がお役に立てば幸いです。
Re: モデルスクリーニングプラットフォームでハイパーパラメータを変更する方法こんにちは@Wang123 、
ステップ 1) と 2) が適切だと思います。
ステップ 3) と 4) を組み合わせることで、複数のモデルの最適なハイパーパラメータを見つけ、それらを評価、比較し、最終モデルを選択できます。検証なしでハイパーパラメータを最適化するとオーバーフィッティングにつながるため、このステップでは検証戦略も必要です。(K 分割?) 検証セットでのこのハイパーパラメータ最適化の結果に応じて、最も適切と思われるアルゴリズムを選択します。
検証戦略に応じて、アルゴリズムをそのままトレーニングしたままにするか (検証セットを使用してモデルを比較および選択した場合)、K 分割クロス検証を使用した場合はモデルのスタッキングを行うことができます (個々のモデルから平均予測を取得するため)。
ステップ 5 では、新しいデータや未知のデータで最終モデルのパフォーマンスを評価します。この段階では、アルゴリズム/モデルは 1 つだけである必要があります。検証は、モデルを比較して選択するために使用され、テスト フェーズではありません。
ご質問に関して：
「ステップ 2 では、デフォルトのハイパーパラメータを使用したモデル比較の結果 (K 分割クロス検証の結果) を記事で報告するだけでよいですか?」: 何を表示/実証したいかによって異なります。特定のモデルを選択した理由を説明したい場合は、ステップ 2 の結果を使用できます。ハイパーパラメータの調整の重要性と利点を強調したい場合は、選択したアルゴリズムのステップ 2 と 3 の結果を比較する方が理にかなっています (ランダム フォレストなどの一部の堅牢なモデルでは、必ずしも重要ではありません)。
「ステップ 4 では、クロス検証メソッドを設定していませんが、これは正しいですか? それとも別の方法がありますか?」 堅牢なアルゴリズムを使用し、過剰適合していないことを確認するためのメトリックがない限り、トレーニング セット全体を再適合することはお勧めしません。ランダム フォレストは、通常、堅牢なアルゴリズムの良い例であり、Out-Of-Bag サンプルによる内部検証 (継続的な応答用) を備えています: https://www.jmp.com/support/help/en/17.2/#page/jmp/overview-of-the-bootstrap-forest-platform.shtml#
In-Bag サンプルと Out-Of-Bag サンプルのメトリックを比較すると、ランダム フォレストに過剰適合があるかどうかを評価するのに役立ちます。
別のアルゴリズムを使用している場合や、その堅牢性が不明な場合は、前の手順で最適化された（検証済みの）モデル（または K 分割クロス検証を使用していた場合はスタックされたモデル）を保持してください。
この最後の回答がお役に立てば幸いです。
PS: 回答が役に立った場合は、必ず「解決策として承認」してください。これは、他の JMP ユーザーがすべてを読まなくてもすぐに解決策にたどり着くことができる良い方法です。
Re: モデルスクリーニングプラットフォームでハイパーパラメータを変更する方法こんにちは、Victor_Gさん。
貴重なご意見をありがとうございます。とても助かります。
