クロス検証 - 検証カラム法相互検証に検証列メソッドを使用する場合、データ セットをトレーニング セット、検証セット、およびテスト セットに分割します。 この分割比率はユーザーが指定します。 分割比率(60:20:20 / 70:15:15 / 50:25:25 / 80:10:10など)を決めるためのガイドライン/参考となるものはありますか。 観測値の総数 -N にも基づいて選択されますか?
データのブレンディングとクリーンアップ予測モデリングと機械学習Re: クロスバリデーション - バリデーションカラムメソッド最初の質問に対して、いいえ、どの程度のデータを除外するかについての特別なルールはありません。 JMP Education 分析コースでは、満足できる限り多くのデータを保持することをお勧めします (少なくとも 20% は保持)。 トレーニング セットが小さすぎて多くの行を保持できないと思われる場合は、k 分割相互検証を検討してください。 検証のために何行犠牲にしても構わないと思いますか? k = n / その数の行を使用します。 その式を使用して k < 5 の場合は、leave-one-out 相互検証を検討してください。
Re: クロスバリデーション - バリデーションカラムメソッドどういたしまして@sreekumarp 。
これらの回答の 1 つまたは複数を解決策と考える場合は、JMP コミュニティの訪問者が探している回答をより簡単に見つけられるように、ためらうことなくそれらを解決策としてマークしてください。
さらに質問がある場合、またはアドバイスが必要な具体的なケースがある場合は、ためらわずにこのトピックについて回答するか、新しいトピックを作成してください。
Re: クロスバリデーション - バリデーションカラムメソッド相互検証列にご入力いただきありがとうございます。
スリークマール・パナピリー
Re: クロスバリデーション - バリデーションカラムメソッド機械学習におけるデータセットの分割について詳しくご説明いただきありがとうございます。 これは私の研究に役立つと確信しています。
スリークマール・パナピリー
Re: クロスバリデーション - バリデーションカラムメソッドやあ@Victor_G 、
そうですね、何か誤解があるかもしれませんね。 おそらく、テスト データ セットではなくホールドアウト データ セットがあると言うべきかもしれません。 ホールドアウト データ セットは、特定のアルゴリズム (テスト セット) からのモデルのトレーニング、検証、または選択に使用されなかったデータです。 このホールドアウト セットを使用して、さまざまなアルゴリズムを相互に比較し、どのアルゴリズムが最も優れたパフォーマンスを発揮するかを確認します。 JMP のモデル比較プラットフォームは、ホールドアウト セットを使用してさまざまなアルゴリズムを相互に比較する場合に非常に役立ちます。 これにより、さまざまなアルゴリズムを公平かつ漏れなく比較できます。 したがって、ホールドアウト データ セットを使用して、この「純粋な」データ セットに対してさまざまなアルゴリズムのどれが最も優れたパフォーマンスを発揮するかを確認するという意味で、これは一種の「テスト」データ セットになります。
これは、JMP で異なるアルゴリズムを相互に比較するために私が知っている唯一の方法です。 私が言いたいのは、これが、たとえば JMP がニューラル ネット アルゴリズムと XGBoost アルゴリズムを比較できる唯一の方法であるということです。 私は、プラットフォーム内で異なるモデルを比較するためにホールドアウト データ セットを使用することは決して使用しませんし、推奨しません。 ブートストラップ フォレスト プラットフォーム内の 20 の異なる調整されたモデルを、ホールドアウト セットを使用して相互に比較するつもりはありません。それがテスト データ セットの目的です。
したがって、誤解/混乱があった場合は申し訳ありません。 テスト セットとの混同を避けるため、今後はこれをホールドアウト セットと呼ぶことにします。
議論してくれてありがとう！、
DS
Re: クロスバリデーション - バリデーションカラムメソッド層化サンプリングの良い点@SDF1 ！
申し訳ありませんが、同じ名前を使用していないか、誤解があります。
テスト セットに複数のモデルを入れて比較する (そして 1 つを選択する) 場合、使用するプラットフォームやモデルに関係なく、それは問題であり、このセットの目的ではありません。 モデルの比較は検証セットで行う必要があります(情報漏洩や偏りのない明確で「純粋な」テストセットを維持するため)。そのため、このトピックに関するいくつかのリソースを含む私の以前の回答です。
セット間の違いについても強調している JMP ヘルプを参照してください:「テスト セットはモデルの予測能力をチェックします」後モデルが選ばれました。」 : https://www.jmp.com/support/help/en/17.1/index.shtml#page/jmp/overview-of-the-make-validation-column-platform.shtml#ww269465
これは、同じ検証セット (または同じメソッド) で異なるモデルを適切に評価するために、さまざまなセットを適切に定義し、セットまたはメソッドを修正することが重要である理由でもあります。
Re: クロスバリデーション - バリデーションカラムメソッドやあ@Victor_G 、
明確でなかったら申し訳ありませんが、実際には同じことを指しています。 前にモデルについて言及したとき、同じテスト/検証セットアップを使用してモデルを生成することについて話していますが、JMP の異なるプラットフォーム間でもモデルを生成することについて話しています。 私は、特定のプラットフォームを念頭に置いてモデルを構築することはありませんが、さまざまなプラットフォーム (NN、BT、ブートストラップ フォレスト、SVM、KNN、XGBoost など) を使用してモデルを生成および調整し、トレーニング セットと検証セットを使用して相互検証を行います。 次に、さまざまなモデルを生成した後、ホールドアウト (テスト) データ セット、つまりトレーニングと検証のステップ中にどのモデルも見たことがないデータ セットでの予測能力を比較します。 NN が最適に機能する場合もありますが、XGBoost やその他のプラットフォームが最適な場合もあります。
最後に@sreekumarp前回の投稿で言い忘れたことの 1 つは、出力列 (予測しようとしている列) を使用して相互検証列を層別化するのに非常に役立つということです。 これにより、トレーニング、検証、テストのデータセットに対して同様の分散構造が維持されます。 特に非常に不均衡なデータセットの場合、これを実行できない場合がありますが、可能であれば、これを強くお勧めします。 そうしないと、データが各タイプのデータ セットにランダムに配置されるため、検証列が適切に分割されず、不適切なモデルが作成される可能性があります。
DS
Re: クロスバリデーション - バリデーションカラムメソッドやあ@SDF1 、
あなたが提供した素晴らしい追加に対する小さな修正が 1 つあります。検証セットは、テスト セットではなく、モデルの比較と選択に使用されるセットです (ただし、テスト名と検証名が交互に使用されたり、混同されたりする場合があります)。
これら 2 つのセットにはまったく異なる目的があります。
- テストセットはデータのホールドアウト部分であり、使用されません前モデルの一般化と予測パフォーマンスの不偏な推定を提供するために、モデルを選択しました。
- 検証セットは、最適な候補モデルを選択するために、モデルの微調整とモデルの比較に使用されるデータの一部です。
説明は次のとおりです。機械学習 - テスト データセットを使用してモデルを選択できますか? - データ サイエンス スタック交換
この使用上の違いについては 2 つの説明があります。
- 実践的な方法 : データ サイエンスのコンテストでは、テスト データセットにアクセスできないため、最高のパフォーマンスのアルゴリズムを作成して選択するには、データをトレーニング セットと検証セットに分割し、良好なパフォーマンスが得られることを「期待」する必要があります (および一般化）、目に見えないテストセットについて。
- 理論的 1: モデルを比較するためにテスト セットを使用している場合、テスト セット上で最もパフォーマンスの高いアルゴリズムを選択することで (その後、おそらく、テスト データのパフォーマンスに基づいて微調整を続けるか、他のモデルを試してください...)。 したがって、アルゴリズムの選択 (および選択後に実行されるその他のアクション) がこれに基づいて行われるため、テスト セットは不偏ではなくなります。
テスト セットは、多くの場合、モデルの作成/開発と、本番環境または公開での展開の間の最後のステップであるため、最終評価は可能な限り公平かつ公平である必要があります。
セット上のいくつかのリソース:トレーニング、テスト、および検証セット (mlu-explain.github.io)
MFML 071 - テストと検証の違いは何ですか? - YouTube
これにより、セットの名前付けと使用における混乱が回避されることを願っています。
Re: クロスバリデーション - バリデーションカラムメソッドやあ@sreekumarp 、
それに加えて@Victor_Gまた、テスト データ セットを分割し、それを使用して新しいデータ テーブルを作成することを強くお勧めします。 そうすることで、モデルをトレーニングおよび検証するときに、テスト ホールドアウト データ テーブルでモデルを比較して、どのモデルが最も優れたパフォーマンスを発揮するかを確認できます。 これにより、テスト データ セットがトレーニング セットまたは検証セットで誤って使用される可能性が軽減されます。
シミュレートされたデータを使用してモデルをトレーニングし、実際のデータでモデルをテストする他の方法もあります。 元のデータセットが小さく、入力の相関構造を維持する必要がある場合に、このアプローチを使用することがあります。
幸運を！、
DS
Re: クロスバリデーション - バリデーションカラムメソッドやあ@sreekumarp 、
興味深い質問です。残念ながら、ご質問に関して最終的な回答はありません。データセット、考慮するモデルの種類、分析者 (または分析を行う人) の実践/習慣によって異なります。
まず、各セット間の用途とニーズを知ることが重要です。
- トレーニングセット: 用途モデルの実際のトレーニング、
- 検証セット : モデルの最適化 (ハイパーパラメーターの微調整、特徴/しきい値の選択など) とモデルの選択に使用されます。
- テスト セット : 新しい/未確認のデータに対する選択したモデルの一般化と予測パフォーマンス評価に使用されます。
目的とデータセットのサイズに応じて、データを分割するにはいくつかの選択肢/方法があります。
- トレーニング/検証/テストセット: モデルのパフォーマンスをトレーニング、最適化、評価するための固定セット。 大規模なデータセットに推奨されます。
- K 分割交差検証: データセットを K 個のフォールドに分割します。 モデルは K 回トレーニングされ、各フォールドはトレーニングに K-1 回、検証に 1 回使用されます。 すべてのフォールドでパフォーマンスが同等である必要があるため、モデルの堅牢性を評価できます。
- Leave-One-Out 相互検証: K 分割相互検証の極端なケース。K = N (観測値の数)。 これは、データセットが小さく、モデルが堅牢かどうかを評価したい場合に使用されます。
- 自動検証/自己検証アンサンブル モデル : いくつかの観測値を異なるセットに分ける代わりに、各観測値をトレーニングと検証の重みに関連付けます (トレーニングの重みが大きいほど検証の重みは低くなります。つまり、この観測は主にトレーニングに使用されます)検証の場合はそれ以下)、重みを変更してこの手順を繰り返します。 これは、非常に小さなデータセットや、一部の観測を異なるセット間で独立して分割できないデータセットに使用されます。たとえば、実験計画法では、実行する一連の実験をモデルに基づいて行うことができ、その場合は、モデルにマイナスのバイアスがかかるため、トレーニングと検証の間で一部の実行を独立して分割することはできません。パラメーターの推定に必要な実行が利用できなくなるため、モデルのパフォーマンスが大幅に低下します。
これらのアプローチはすべて JMP でサポートされています。 Make Validation Column Platform (jmp.com) を起動します。
経験則として、70/20/10 の比率がよく使用されます。論文を読むことができます」データ分割の最適な比率詳細については、こちらをご覧ください。一般に、モデル内のパラメーターの数が増えるほど、モデル内の各パラメーターを正確に推定するためにより多くのデータが必要になるため、トレーニング データセットが大きくなります。そのため、モデルの複雑さ/タイプも考慮する必要があります。トレーニング/検証/テスト セットを作成するとき。
より正確な使用例がある場合は、一般的ではないものの、ガイダンスを提供するために、これがより役立つ可能性があります。
モデルのトレーニング、検証、テストについて詳しく学ぶために、Cassie Kozyrkov のプレイリスト「Making Friends with Machine Learning」も強くお勧めします。機械学習で友達を作る - YouTube
この最初の回答がお役に立てば幸いです。
件名：クロスバリデーション - 検証列法ありがとう。
JMP Proのルーチン回帰を用いたK分割交差検証（CV）とリーブワンアウト（LOO）検証に関して、明確にしておくべき点が2つあります。
どちらの方法もPLSR（部分最小二乗回帰）部分で直接利用できますが、単純な回帰にCVやLOOを適用した場合、何をすべきか、またどのように指標を可視化すべきかについて、やや不明瞭な点があります。例えば、私はスペクトルを分析していますが、このケモメトリクス処理ではPCRとPLSRが日常的に用いられています。
少し奇妙な現象が発生しました。4分割検証列（上記、72個の観測値に対して4分割）を作成し、PCR（数値応答と主成分を予測変数として使用）を実行すると、以下のエラー応答が表示されます。
つまり、実際の履歴書作成は行われていないということですよね？
2つ目のポイント：PCR用のLOO検証（列？）をどのように構築するか？
総じて、一般的な回帰分析において、適切な交差検証とリーブワンアウト検証を行い、適切な適合度指標を取得するために、どのような手順を踏む必要があるのか教えてください。これは非常に重要な点ですが、私にとってはまだ明確ではありません。
同僚の皆さん、本当にありがとうございました！
件名：クロスバリデーション - バリデーション列法こんにちは、 @Nazarkovsky さん。
この古い投稿に返信するのではなく、新しい投稿を始めた方がおそらく簡単だったでしょう。そうすればより多くの人の目に触れ、他のJMPユーザーもあなたの質問に関する議論に参加できたはずです。
はい、JMPモデリングプラットフォームでは、固定K分割交差検証列を使用する場合にエラーが発生することがあります。これは、JMPが検証列から2レベル（トレーニングと検証またはテスト）または3レベル（トレーニング、検証、テスト）を認識するためです。表示されているエラーメッセージでは、交差検証は実行されず、すべてのデータに対して線形モデルが適合されます。
非常にシンプルな線形モデルを使用しているため、 モデルスクリーニングプラットフォーム（異なるモデルの結果を比較したい場合はPLSも含まれています）を使用して、X、応答Y、4分割検証列（またはプラットフォームから直接交差検証を実行）、および適合させたいモデルの種類（線形回帰モデルオプション＋モデリングオプション）を指定してみてください。
または、プラットフォームのK分割交差検証オプションを直接使用すると、以下の結果が得られます。
Leave-One-Out交差検証を実行する場合は、K=n（nはテーブルの実行回数）と指定するだけです。個々のフォールドの結果にアクセスしたい場合は、ここで提供したソリューションをモデリングプラットフォームに合わせて調整できます。K -Fold CVのフォールド外メトリクスへのアクセス
最後に、モデリングワークフローにおいてデータ漏洩につながる可能性のある重大な問題が少なくとも1つあります。それは、主成分分析にも交差検証または分割/検証戦略を適用する必要があるということです。そうしないと、PCAはデータセット全体を参照し、データセット全体の因子間の相関関係を学習します。そして、その後に適合させる（交差検証によって評価する）線形モデルは、4分割のうち3分割の情報ではなく、データセット全体の情報から恩恵を受けることになります。JMPはPCAに検証ロールを実装していないため（まだ！）、データ漏洩や、あなたのようなモデリングワークフローにおけるエラーを防ぐために、この要望リストを追加しました。 主成分分析プラットフォームに検証ロールオプションを追加する。まとめると、次のようになります。
- 検証戦略（CV、LOO、標準的な訓練／検証分割、または訓練／検証／テスト分割）を定義し、適用する。
- トレーニングセットのみでデータを前処理する（または、使用するフォールドに応じてデータを複数回前処理する）
- トレーニングセット（または対応するトレーニングフォールド）からの前処理済みデータを使用して、同じ検証戦略でモデルを適合させます。
この回答がお役に立てば幸いです。
件名：クロスバリデーション - バリデーション列法いずれにせよ、JMPのk分割交差検証のセクションは依然として不十分です。この検証方法は、特にデータ数が少ない場合、あらゆるモデルの予備評価のための主要なツールであるにもかかわらず、なぜ開発者がこの点に関心を示さないのか不思議に思います。さらに、K分割交差検証列を作成するための適切なオプションでは、3分割交差検証を作成することは不可能で、最小値は4となっています。
JMPの交差検証（CV）の指標レポートも気に入らない。なぜなら、すべての実行後に平均結果として「予測値」列を作成し、一般化回帰やPLSRによって得られた予測値と比較するための最終的なオプションやボタンがないからだ。
PCAの検証に関しては、このオプションは化学計量学（スペクトルなどの化学データの多変量解析）用の従来型ソフトウェアであるUnscramblerで利用できます。はい、検証は、事前に設定されたコンポーネント数と説明された分散に対して行われます。このリークのテストにはUnscramblerを使用します。
このコミュニティには、スペクトル解析に特化したJMPに関する一連の投稿がありますが、CVとPCRに関する包括的な議論はまだ不足しています。
しかし、ケモメトリクスにおいては、SVR（サポートベクター回帰）、PLSR、PCRが常に適用され、それらの指標が比較される。
LOO（トイレ）に関しては、本当にちゃんと機能します。
件名：クロスバリデーション - 検証列法いずれにせよ、JMPのk分割交差検証機能は依然として不十分です。この検証方法は、特にデータ数が少ない場合、あらゆるモデルの予備評価における主要なツールであるにもかかわらず、開発者がこの点に関心を示さないのは不思議です。さらに、K分割交差検証列を作成するための適切なオプションでは、3分割交差検証を作成することは不可能で、最小値は4となっています。
JMPの交差検証（CV）の指標レポートも気に入らない。なぜなら、すべての実行後に平均結果として「予測値」列を作成し、一般化回帰やPLSRによって得られた予測値と比較するための最終的なオプションやボタンがないからだ。
PCAの検証に関しては、このオプションは化学計量学（スペクトルなどの化学データの多変量解析）用の従来型ソフトウェアであるUnscramblerで見つけることができます。はい、検証は設定されたコンポーネント数と説明された分散に対してスキャンされます。このリークのテストにはUnscramblerを使用します。
このコミュニティには、スペクトル解析に特化したJMPに関する一連の投稿がありますが、CVとPCRに関する包括的な議論はまだ不足しています。
しかし、ケモメトリクスにおいては、SVR（サポートベクター回帰）、PLSR、PCRが常に適用され、それらの指標が比較される。
LOO（トイレ）に関しては、本当にちゃんと機能します。
