相互検証 (Analysis Services - データ マイニング)
相互検証は標準の分析ツールであり、データ マイニング モデルの開発と微調整に役立つ重要な機能です。 マイニング構造および関連マイニング モデルを作成した後に、相互検証を使用してモデルの有効性を確認します。 相互検証には次の用途があります。
特定のマイニング モデルの堅牢性を検証します。
1 つのステートメントから複数のモデルを評価します。
複数のモデルを作成し、統計情報に基づいて最適なモデルを特定します。
ここでは、SQL Server 2008 の相互検証機能の使用方法と、特定のモデルやデータセットに関する相互検証結果の解釈方法について説明します。 相互検証は、一連のストアド プロシージャとして実行できます。 また、Business Intelligence Development Studio のデータ マイニング デザイナーから相互検証を使用することもできます。
相互検証プロセスの概要
相互検証は、トレーニングと結果生成の 2 つのフェーズから構成されます。 これらのフェーズには、次の手順が含まれます。
対象のマイニング構造を選択します。
テストするモデルを指定します。
構造データをパーティション分割する際のフォールド数を指定します。
Analysis Services により、フォールドと同数のモデルが作成されてトレーニングされます。
結果を生成するには、トレーニング済みのモデルをテストするためのパラメーターを指定する必要があります。
テスト データのソースを指定します (この機能は、ストアド プロシージャを使用する場合にのみ利用できます)。
予測可能な属性、予測値、および精度のしきい値を指定します。
Analysis Services から、各モデルの各フォールドに対する一連の精度基準が返されます。 データセット全体の精度基準を返すこともできます。
データ マイニング デザイナーでの相互検証の使用
Business Intelligence Development Studio で [マイニング精度チャート] ビューの [相互検証] タブを使用して相互検証を実行する場合、トレーニングと精度の結果のパラメーターを 1 つのフォームで構成できます。 これにより、設定と結果の表示が簡単になります。 1 つのマイニング構造に関連するすべてのマイニング モデルの精度を測定し、その結果を HTML レポートですぐに表示することができます。
相互検証によって提供されるレポートの形式および精度基準の詳細については、「クロス検証レポート (Analysis Services - データ マイニング)」を参照してください。
Business Intelligence Development Studio で相互検証パラメーターを構成する方法については、「[相互検証] タブ ([マイニング精度チャート] ビュー)」を参照してください。
相互検証ストアド プロシージャの使用
上級ユーザーの場合、相互検証を 4 つのシステム ストアド プロシージャとして使用することもできます。 SQL Server Management Studio または任意のマネージ コード アプリケーションから Analysis Services 2008 のインスタンスに接続することによって、これらのストアド プロシージャを実行できます。
ストアド プロシージャは、マイニング モデルの種類別にグループ化されています。 最初のプロシージャ ペアは、クラスタリング モデルでのみ動作します。 2 番目のプロシージャ ペアは、他のマイニング モデルで動作します。
.gif "注意") 注意 |
|---|
KEY TIME 列または KEY SEQUENCE 列が含まれているモデルでは、相互検証を使用できません。 |
マイニング モデルの種類ごとに、2 つのストアド プロシージャがあります。 最初のプロシージャは、指定した数のパーティションをデータセット内に作成し、各パーティションに対して精度の結果を返します。 それぞれの基準について、パーティションの平均と標準偏差が Analysis Services によって計算されます。
2 番目のプロシージャは、データセットのパーティション分割を行わずに、指定したデータセット全体の精度の結果を生成します。 マイニング構造とそのモデルが既にパーティション分割および処理されている場合にも、2 番目のストアド プロシージャを使用できます。
データのパーティション分割とパーティションの基準の生成
SystemGetCrossValidationResults (Analysis Services - データ マイニング)
SystemGetClusterCrossValidationResults (Analysis Services - データ マイニング)
データセット全体の基準の生成
SystemGetAccuracyResults (Analysis Services - データ マイニング)
SystemGetClusterAccuracyResults (Analysis Services - データ マイニング)
相互検証の構成
相互検証の動作をカスタマイズして、セクション数、テストするモデル、および予測の精度バーを制御できます。 相互検証ストアド プロシージャを使用する場合、モデルの検証に使用するデータセットを指定することもできます。 このように選択肢が豊富なため、結果を比較して分析する必要がある多数のさまざまな結果セットを簡単に生成できます。
ここでは、相互検証を適切に構成するために役立つ情報を示します。
パーティション数の設定
パーティション数を指定すると、作成される一時的なモデルの数が決まります。 パーティションごとに、複数のセクションにわたるデータにテスト セットとして使用するためのフラグが設定され、パーティションに含まれない残りのデータをトレーニングすることによって新しいモデルが作成されます。 指定した数のモデルが Analysis Services で作成およびテストされるまで、このプロセスが繰り返されます。 相互検証で使用できるよう指定したデータは、すべてのパーティション間で均等に分散されます。
図の例は、3 つのフォールドを指定した場合のデータの使用方法を示しています。
.gif "クロス検証によるデータの分割方法")
図のシナリオでは、テスト用に使用される提示されたデータセットがマイニング構造に含まれていますが、相互検証にはこのテスト データセットが含まれていません。 その結果、トレーニング データセット内のすべてのデータ、つまりマイニング構造内のデータの 70% が、相互検証に使用されます。 相互検証レポートには、各パーティションで使用されたケースの合計数が示されます。
使用するケースの合計数を指定することによって、相互検証時に使用するデータ量を指定することもできます。 ケースは、すべてのフォールド間で均等に分散されます。
マイニング構造が SQL Server Analysis Services のインスタンスに格納されている場合、フォールド数として設定できる最大値は、256 またはケース数のいずれか小さい方です。 セッションのマイニング構造を使用する場合、フォールドの最大数は 10 です。
| 注意 |
|---|
フォールド数を増やすと、それに応じて相互検証の所要時間も長くなります。フォールドごとにモデルを生成およびテストする必要があるためです。 フォールド数が多すぎると、パフォーマンス上の問題が発生することがあります。 |
テスト データの定義
精度を計算するストアド プロシージャ (SystemGetAccuracyResults (Analysis Services - データ マイニング) または SystemGetClusterAccuracyResults (Analysis Services - データ マイニング)) を実行する際、次のオプションを組み合わせることによって、相互検証時のテストに使用するデータのソースを指定できます。
トレーニング データのみを使用する。
既存のテスト データセットを含める。
テスト データセットのみを使用する。
既存のフィルターをそれぞれのモデルに適用する。
トレーニング セット、テスト セット、およびモデル フィルターを任意に組み合わせる。
テスト データセットの構成を制御するには、DataSet パラメーターに値を設定します。
データ マイニング デザイナーの [相互検証] レポートを使用して相互検証を実行する場合は、使用するデータセットを変更できません。 既定で、各モデルのトレーニング ケースが使用されます。 フィルターがモデルに関連付けられている場合、そのフィルターが適用されます。
フィルター処理されるマイニング モデルの相互検証
複数のマイニング モデルをテストする場合、モデルにフィルターがあると、各モデルが個別にフィルター処理されます。 相互検証中は、モデルにフィルターを追加したり、モデルのフィルターを変更したりすることができません。
既定の相互検証では、構造に関連付けられているすべてのマイニング モデルがテストされるため、フィルターを持つモデルと持たないモデルがあると、返される結果に一貫性がなくなることがあります。 同一のフィルターを持つモデルだけが比較されるようにするには、ストアド プロシージャを使用してマイニング モデルの一覧を指定します。 また、すべてのモデルに対して同一のデータセットが使用されるようにするには、フィルターがないマイニング構造テスト セットだけを使用します。
精度のしきい値の設定
状態のしきい値を使用すると、予測の精度バーを設定できます。 モデルではケースごとに、予測された状態が正確である確率 (予測確率) が計算されます。 予測確率が精度バーを超える場合は予測が正しいと見なされ、超えない場合は誤りと見なされます。 この値は、[状態のしきい値] を 0.0 ～ 1.0 の数値に設定することによって制御します。この数値が 1 に近いほど予測の信頼性レベルが高く、0 に近いほど予測が正しい可能性が低くなります。 状態のしきい値の既定値は NULL です。これは、最も高い確率を持つ予測された状態が、対象の値と見なされることを意味します。
| 注意 |
|---|
値 0.0 を設定することは可能ですが、確率が 0 の予測も正しいと見なされるようになり、意味がありません。 [状態のしきい値] を誤って 0.0 に設定しないよう注意してください。 |
たとえば、[Bike Buyer] 列を予測するモデルが 3 つあり、予測する値が 1 ("はい、購入します" の意味) だとします。 3 つのモデルから、それぞれ 0.05、0.15、0.8 の予測確率を持つ予測が返されます。 状態のしきい値を 0.10 に設定すると、2 つの予測が正しいと見なされます。 状態のしきい値を 0.5 に設定すると、1 つのモデルだけが正しい予測を返したものと見なされます。 既定値の NULL を使用すると、最も確率の高い予測が正しいと見なされます。 この場合、3 つの予測すべてが正しいと見なされます。
相互検証で使用される基準
マイニング モデルの種類、予測可能な属性のデータ型、および予測可能な属性値 (存在する場合) によって、生成される精度基準が異なります。 ここでは、参考情報として、主な基準を定義します。 各モデルのレポートで返される精度基準の種類別一覧については、「クロス検証レポート (Analysis Services - データ マイニング)」を参照してください。
メジャー |
適用対象 |
実装 |
|---|---|---|
分類: 真陽性、偽陽性、真陰性、偽陰性 |
不連続属性、値を指定 |
状態のしきい値より予測確率が大きく、予測された状態が対象の状態と一致するパーティション内の行または値の数。 不足値のあるケースは除外されます。 |
分類 : pass/fail |
不連続属性、対象の指定なし |
予測された状態が対象の状態と一致し、予測確率の値が 0 を超えるパーティションの行または値の数。 不足値のあるケースは除外されます。 |
リフト |
不連続属性。 対象の値を指定できますが、必須ではありません。 |
対象となる属性に値があるすべての値の平均ログ確率値。各ケースのログ確率値が Log(ActualProbability/MarginalProbability) として計算されます。 平均値を計算するには、合計ログ確率値を入力データセットの行数で割ります (対象となる属性に不足値がある行を除く)。Lift は負の値か正の値です。 正の値は、ランダムな推測よりも高いパフォーマンスの効果的なモデルであることを表します。 |
ログ スコア |
不連続属性。 対象の値を指定できますが、必須ではありません。 |
各ケースの実際の確率値のログを合計してから、入力データベースの行数で割ります (対象となる属性に不足値がある行を除く)。 確率値は小数部として表されるので、ログ スコアは常に負の数です。 値が 0 に近いほどよいスコアを表します。 |
Case likelihood |
クラスター |
すべてのケースの合計クラスター確率値スコアを、パーティション内のケース数で割ります (対象となる属性に不足値がある行を除く)。 |
Mean absolute error |
連続属性 |
パーティション内のすべてのケースの合計絶対誤差を、パーティション内のケース数で割ります (対象となる属性に不足値がある行を除く)。 |
Root mean square error |
連続属性 |
パーティションの平均 2 乗誤差の平方根。 |
Root mean squared error |
不連続属性。 対象の値を指定できますが、必須ではありません。 |
確率値スコアの補数を 2 乗した平均の平方根を、パーティション内のケース数で割ります (対象となる属性に不足値がある行を除く)。 |
Root mean squared error |
不連続属性、対象の指定なし |
確率値スコアの補数を 2 乗した平均の平方根を、パーティション内のケース数で割ります (対象となる属性に不足値があるケースを除く)。 |