データのバランスこんにちは、
回答率がわずか27%なので、データ分析前にデータのバランスを取りたいと思っています。まず、ターゲット列に基づいて層別化された検証列を作成し、トレーニングセット、検証セット、テストセットを作成しました。質問は、トレーニングセットと検証セットの両方でデータのバランスを取り、テストセットではバランスを取らないのか、それともトレーニングセットのみでバランスを取るべきなのかということです。SMOTE手法を使用し、最後にモデルスクリーニングプラットフォームのクロス検証手法を使用して、連結されたデータベース（トレーニングセット、検証セット、テストセット）で検証列を使用してテストセットのパフォーマンス分析を行いたいと思っています。この方法は、クロス検証前にデータのバランスを取るための方法でしょうか？その他の提案も歓迎します。
よろしくお願いいたします
月曜日
基本的なデータ分析とモデリング予測モデリングと機械学習Re: データのバランス調整こんにちは@ルー 、
私は SMOTE やその他の分類のバランス調整技術については複雑な気持ちです。
- SMOTEは分類器のキャリブレーションを完全に「破壊」します（学習フェーズで2つのクラスの比率を完全に変更するため）。つまり、分類器によって計算された確率は、データセット内の実際の測定確率と一致しなくなります。これは、特定のアプリケーション（医療、金融／銀行など）では特に注意が必要です。最終的な多数派クラスではなく、計算された確率が必要になる場合があるためです。
- さらに、 元の論文とその後の研究で確認されたように、SMOTEは分類器が決定木やナイーブベイズのような弱学習モデルである場合にのみわずかな効果をもたらします。最先端の「強力な」モデル（ランダムフォレスト、XGBoostなど）と併用した場合、SMOTEは効果をもたらさず、学習に悪影響を与える可能性さえあります。別の研究はこちら： 機械学習ベースの予測モデルにおけるクラス不均衡補正の害：シミュレーション研究 - Carriero - 2025 - Statistics in Medicine - Wiley Online Library
ほとんどの研究では、これらの手法に関する結論は同じです。「強力な分類器を使用することで適切かつ最良の予測が達成され、データのバランスをとることは必要ではなく、有益でもない」または「クラスの不均衡を修正することは必ずしも必要ではなく、個別に信頼性の高いリスク推定値を生成することを目的とする臨床予測モデルに有害となる可能性さえある」。
- SMOTEは、弱学習器の使用や判定閾値を調整できない場合など、特定の状況では有益となる可能性がありますが、その相対的な利点は、選択したパフォーマンス指標によっても変化する可能性があります。そのため、SMOTEの使用はお勧めしません。
少数派クラスで27%というのは大きな不均衡ではありません。 決定閾値の調整や利益行列の指定といった従来の手法を用いれば、状況に合わせて分類器のパフォーマンスを調整できるはずです。新しい特徴量や変数の追加、モデルを支援するためのデータの前処理（特徴量エンジニアリング）、新しいデータの追加、最も代表的で異なる観測値の選択、そして比較とベンチマークのために複数のモデルを試すことも、パフォーマンスの向上に役立ちます。
データの不均衡が問題となるのは、トレーニングセット内の少数クラスが十分に代表的ではない、または特徴量がラベルの指標として十分ではない場合のみであることを理解することが重要です。理想的なシナリオは、これら2つの問題を解決することで、不均衡があってもモデルが完璧に良好なパフォーマンスを発揮できるようにすることです。
ただし、ワークフローにSMOTE（または任意の前処理）操作を追加する場合（必要な場合）、データ漏洩や過度な楽観的なパフォーマンス期待を回避するため、慎重に行う必要があります。SMOTEやその他のバランス調整手法は、トレーニングセットと検証セット（トレーニング、比較、そして最適なパフォーマンスのモデルを選択するため）に適用する必要がありますが、モデルは「現実の」環境（深刻な不均衡を含む）で動作し、評価される必要があるため、テストセットには適用しないでください。
この回答がお役に立てれば幸いです。
Re: データのバランス調整ビクターさん、明確なアドバイスをありがとう。
とりあえず、「不均衡分類」アドインを使ってモデルのパフォーマンスをチェックし、ニューラルネットワーク、ブートストラップフォレスト、ブーステッドツリーの各モデルについて、SMOTE、TOMECバランス、重み付けなしで適合率、再現率、ROC AUCを計算しましたが、AUCは全く改善されませんでした。つまり、データのバランスを取ってもパフォーマンスは改善されない可能性が高いということです。
ご支援ありがとうございます。
よろしく
月曜日
Re: データのバランス調整やあ、ラス
トレーニング行、検証行、テスト行を区別する「検証」列があります。ネストされたクロスバリデーションを適用する場合、モデルスクリーニングプラットフォームでこの列を指定する必要がありますか？この列の有無によって、パフォーマンス統計の概要が異なることに気づきました。
この場合に推奨されるアプローチは何であるか確認できますか?
ML モデルのパフォーマンスを比較して報告したいと思います。
F1、MCC、Sens、Spec、FP、FN など、現在作成されている概要レポートよりも詳細な情報を素早く取得する方法はありますか?
よろしくお願いいたします
月曜日
Re: データのバランス調整こんにちは@ルー 、
モデル スクリーニング プラットフォームを起動するときにクロス検証オプションを選択した場合は、検証列を追加しても何も変わりません。選択したクロス検証オプションが検証列を引き継ぐためです。 モデル スクリーニング プラットフォーム (検証部分) を起動します。
異なる結果になる可能性があるのは、ランダムシードを固定していない場合、ランダムシードが原因となるからです。クロスバリデーションオプションを選択した場合、検証列を追加するかどうかは、ランダムシードを固定した場合と同じ結果になります。
モデルの評価、比較、選択という（広範な）トピックに関しては、関連する検証戦略を見つけるのに役立つトピックがいくつかあります。
ML モデル (ニューラル ネットワークやランダム フォレストなど) で k 分割クロス検証を実行し、固定テスト データでモデルのパフォーマンスを確認するにはどうすればよいでしょうか? モデルスクリーニング
1つ以上の検証列
k-fold適合品質を用いたクロスバリデーション
1 つを除外する手法と k 分割交差検証手法のどちらですか?
クロスバリデーション - バリデーション列法
この回答がお役に立てれば幸いです。
