目次


データのバランスを調整して、より現実に即した統計モデルを生成し、より正確な結果を出す

データ・マイニングの際に SPSS Modeler を使用してデータのバランスを調整するにはどのようにするのかとなぜ調整するのかを学ぶ

Comments

信頼性の高いデータ統計結果を得るためには、予測モデルをトレーニングする前に、特定のビジネス目標に基づいてあらかじめデータのバランスを調整する必要があります。初期の調整でデータのバランスを決定した後は、必ず定期的に、着信データのバランスをモニターしてください。それは、当初のバランスが徐々に変化する可能性があるためです。データのバランスを正確に維持するために、調整が必要になることもあります。

この記事では、達成しようとするビジネス目標によって、どのようにバランス調整方法とそのレベルを使い分けるのか、そしてバランスの調整レベルを評価する方法、IBM SPSS Modeler を使用してバランスが調整されるようにする方法を説明します。

バランス調整と重み付けの違いについて

データ・マイニングにおける「データのバランス調整」は、従来の統計における重み付けの概念と似ていますが、この 2 つの間には数々の重要な違いがあります。

データ・マイニングにおいてはデータのうちの代表的なサブセットだけでなく、すべてのデータを使用することができます。

従来の統計が開発された主な目的は、人口のサンプルから全人口に対する推定値を得ることでした。例えば、政治に関する世論調査員は、1,024 人の対象者から大統領選挙で投票しようと思っている候補についてのアンケートをとり、その回答に基づいて誰が大統領に当選されるかを推測できます。一方、データ・マイニングにおいては通常、対象とする全人口を網羅したデータを使用できるという利点を活用します。データ・マイニングのデータには、例えば特定の商品を購入した全顧客、特定のタスクを実行した全マシン、特定の学区にいる全学生などが含まれます。このように、データ・マイニングにおいてはデータのうちの代表的なサブセットだけでなく、すべてのデータを使用することができます。

データ・マイニングにおいてはほとんどの場合、人口の分布係数に応じた調整は必要ありません。

従来の統計においては、分析に使用するサンプルが予測対象の人口と同じ構成になるように、重み付けという手法を使用します。例えば、サンプルでの男性と女性の比率が 100 対 80 だとすると、実際の人口での男性 49、女性 51 の比率に戻すように意図された重みがサンプルに適用されることになります。使用するサンプル、そして実行する分析によっては、このようなシナリオでの重み付けスキームが極めて複雑になって、何十もの異なる次元が考慮されることになる可能性もあります。前述の政治に関する世論調査を例にとると、性別、年齢、収入、地理、支持する政党、持ち家かどうか、そして職業など、多数の要因に対して重みを調整する必要があります。このタスクは、極めて複雑な専門分野のタスクであり、実際の人口分布を把握していなければ対処できません。データ・マイニングにおいてこのような修正が必要になることはめったにありません。データ・マイニングにおいてはほとんどの場合、全人口を対象にできるからです。

サブセットを使用するデータ・マイニング・プロジェクトの場合、人口を調整するための係数は、従来の統計とは異なります。

データ・マイニング・プロジェクトにおいて使用するデータが、対象とする全人口から無作為に取り出されたものではないサンプルから取り込まれるとしたら、重み付けに関して説明したような調整を行うかどうかを検討する必要があるでしょう。データ・マイニングのコンテキストにおいては、より信頼性の高い統計モデルを構築する目的、そしてトレーニングによってより効果的に根本的なビジネス問題に対処するモデルにする目的でデータの相対的比率を変えるために、データのバランス調整が行われるのが通常です。手法に関して言うと、バランス調整は (まったく同じではないとしいても) 重み付けと同じように行われます。けれどもバランス調整を行う目的と理由も、バランスを調整するための係数を決定する方法も、重み付けとは全く異なります。

バランス調整を適用すべき場合について

バランス調整を適用する一般的な目的は、データ・サイエンティストがプロジェクトで対象としているビジネス問題により効果的に対処するモデルをトレーニングできるように、トレーニングで使用するデータ・セットを調整することです。この目的は、純粋に技術的観点からより正確なモデルを作成するという目的とは異なる場合があることに注意してください。そのような例は多数あり、その大半は、データ・セットに含まれるターゲット変数の分布が非対称である場合や、ターゲット変数の 1 つ以上のカテゴリーが他のカテゴリーと比べて過少評価されるような場合です。

例 1: 保険金詐欺

不正な保険金請求は損害保険会社にとって大きな問題であると考えられますが、不正が明らかになる請求の数は、個々の保険会社が処理する請求の合計数に比べるとわずかです。調査対象とする潜在的な不正請求を特定するためのデータ・マイニング・プロジェクトを任されると、この事実から困難な状況が生まれます。

例えば、毎年 800,000 件の自動車保険の保険金請求を処理している架空の保険会社があるとします。不正の要素が含まれる可能性のある保険金請求の件数は全体の 20% にも及びます。けれども、実際に不正が証明される保険金請求のパーセンテージはわずかで、通常は合計件数の 2% (16,000 件) ほどです。不正が疑われる他の請求は、請求者が取り下げるか、元の請求額を下げた金額で解決されます。

このデータ・セットをそのまま使用して、不正請求を識別するための予測モデルをトレーニングするとしたら、結果的に 98% 正確なモデルになるでしょう。それは単に、トレーニング後のモデルを使用するとすべての請求が不正ではないと予測されるからです。技術的には非常に正確なモデルとは言え、このモデルは、潜在的な不正請求を識別するという根本的なビジネス問題に対処することにはなりません。このタイプのビジネス問題を処理するのにより有効な「ディシジョン・リスト」といったアルゴリズムもありますが、その効果には限度があります。

このような場合に解決策となり得るのが、データのバランス調整です。バランス調整を適用して、不正請求の比率をデータ・セットに含まれる既知の不正請求の 2 倍にします。ここまでのレベルにすれば、ディシジョン・リスト・アルゴリズムによって妥当な数の請求件数が不正であると予測されるモデルを作成できます。

バランス調整は、データの特定のサブセットに重みを加えるためにも適用できます。例えば、パターンが徐々に変化することが予想されるため、直近の観測結果を重視しなければならない場合があります。この場合、直近の観測結果だけを使用するという方法の代わりとなるのが、バランス調整です。

IBM SPSS Modeler 内でバランス調整を導入する

IBM SPSS Modeler 内でバランス調整を導入するには、実際の使用事例に応じて、複数の方法があります。そのうち、この記事では最もよく使われている方法だけを取り上げて説明しますが、これらの方法はすべて、必要に応じて拡張したり組み合わせたりすることができます。

データ・セットのバランスを調整するのに最も単純な方法は、組み込みバランス・ノードを使用することです。大半の使用事例では、この方法によって必要を満たすことができます。

バランス・ノードは、そのノードに指定されたバランス調整ディレクティブに従って、データ・セットに含まれるレコードを複製または破棄するという仕組みによって機能します。係数を 1 より大きくするとデータ・セットに含まれるレコードが複製され、1 より小さくするとレコードが破棄されます。整数以外の係数を指定した場合は、複製および破棄するレコードが無作為に選ばれることになります。ただし、バランス・ノードには、ランダム・シードを設定して実行ごとにわずかに異なる結果を出すための手段は用意されていません。

バランス・ノードには「Only balance training data (トレーニング・データのみをバランス調整)」という選択項目があり、デフォルトではこの項目が選択されています。やむ負えない理由からテスト・データや検証データのバランスを調節しなればならない場合を除き、このデフォルトの設定は変えないでください。

例えばデータ・セットに、個人の性別とその個人が閲覧した重複しない Web ページだけを対象とした 6 つの観測結果があるとします。データ・セットに含まれる男性は 4 人、女性は 2 人です。この後、性別が一様に分布するデータ・セットを作成する際に、バランス・ノードの効果を確認します。

バランス・ノードを使用したブースティング

バランス調整において使用する係数によって出現頻度の低いカテゴリーが複製されることを「ブースティング」と呼びます。例 2 でブースティングについて説明します。

例 2: ブースティング

このリンクをクリックして、この例で使用するストリームをダウンロードしてください。

図 1. ブースティングによるバランス調整のサンプル・ストリーム
「Gender & Pages (性別とページ数)」ノードから、「Boost Females (女性のブースティング)」ノード、「Table (テーブル)」ノードへと続くストリームを示す図
「Gender & Pages (性別とページ数)」ノードから、「Boost Females (女性のブースティング)」ノード、「Table (テーブル)」ノードへと続くストリームを示す図

元のデータ・セットには男性4 人のレコード、女性2 人のレコードが含まれています。

IDGENDERNUM_PAGES
A 男性 181
B 男性 191
C 男性 142
D 男性 164
E 女性 175
F 女性 188

現時点では、男性 2 人のレコードにつき、女性のレコードは 1 つしかありませんが、これから男性と女性のレコードが均等に分布するように調整します。それには、バランス・ノードを構成して、性別が女性の場合に係数 2.0 を使用するという条件を設定します。

図 2. 女性のレコード数を増やす条件が設定されたバランス・ノード
「Settings (設定)」タブで係数 2.0、条件「GENDER = "Female"」を設定する画面のスクリーン・キャプチャー
「Settings (設定)」タブで係数 2.0、条件「GENDER =

設定した条件に当てはまらないレコードは常にそのままの状態で受け渡されます。

バランス調整後のデータ・セット内では、ID が E と F のレコードのそれぞれが 2 回出現します。

IDGENDERNUM_PAGES
A 男性 181
B 男性 191
C 男性 142
D 男性 164
E 女性 175
E 女性 175
F 女性 188
F 女性 188

これで、データ・セットには男性4 人と女性4 人のレコードが含まれるようになり、性別の分布が均等になりました。

バランス・ノードを使用した集約

集約は、ブースティングの代わりとなる手段です。集約という用語は、バランス調整において使用される係数によって、出現頻度の高いカテゴリーから観測結果が破棄される場合に使われます。

例 3: 集約

この例で使用するダウンロード可能なストリームは、例 2 で使用したストリームと同じです。

図 3. 集約による単純なバランス調整のサンプル・ストリーム
「Gender & Pages (性別とページ数)」ノードから、「Reduce Males (男性の集約)」ノード、「Table (テーブル)」ノードへと続くストリームを示す図
「Gender & Pages (性別とページ数)」ノードから、「Reduce Males (男性の集約)」ノード、「Table (テーブル)」ノードへと続くストリームを示す図

前と同じく、元のデータ・セットには男性 4 人のレコードと、女性2 人のレコードが含まれています。

IDGENDERページ数
A 男性 181
B 男性 191
C 男性 142
D 男性 164
E 女性 175
F 女性 188

データ・セットには、女性 1 人のレコードに対して男性 2 人のレコードが含まれています。前と同じく、男性と女性のレコードが均等に分布されるようにしますが、今回は性別が男性の場合に、バランス・ノードで係数 0.5 を適用するようにします。

図 4. 男性のレコード数を減らす条件が設定されたバランス・ノード
「Settings (設定)」タブで係数 0.5、条件「GENDER = "Male"」を設定する画面のスクリーン・キャプチャー
「Settings (設定)」タブで係数 0.5、条件「GENDER =

バランス調整後のデータ・セットからは、ID が B と D のレコードが破棄されています。

IDGENDERページ数
A 男性 181
C 男性 142
E 女性 175
F 女性 188

これで、データ・セットの性別の分布は均等になり、男性2 人と女性2 人のレコードが含まれるようになりました。

設定された係数は整数ではないため、破棄されるレコードは実行ごとに変わります。

ブースティングと集約を組み合わせる

この 2 つの方法を組み合わせて、男性3 人と女性3 人のレコードが含まれるようにデータ・セットのバランスを調整することもできます。その場合、男性に対して係数 1 を設定し、4 人の男性のうち 1 人のレコードを破棄します。また、女性に対しては係数 2 を設定して、2 人の女性のうち 1 人のレコードを複製します。

グラフからバランス・ノードを生成する

カテゴリー・フィールドの分布図、または連続フィールドのヒストグラムから、2 つ以上のカテゴリーを均等に分布させる単純なバランス・ノードを生成することができます。それには、データ・セットから対象とするフィールドの実際の分布を示すグラフを生成した後、ツールバー上の「Generate (生成)」をクリックします。

図 5. グラフからバランス・ノードを生成する
「Generate (生成)」ドロップダウン・メニューの「Balance node (バランス・ノード)」項目を強調表示した画面のスクリーン・キャプチャー
「Generate (生成)」ドロップダウン・メニューの「Balance node (バランス・ノード)」項目を強調表示した画面のスクリーン・キャプチャー

ダウンロード可能な例 2 のストリームには、この方法によってバランス・ノードを生成するために使用できる分布図とヒストグラムも含まれています。

IBM SPSS Modeler 内でグラフからノードを生成するには、このリンク先のページで説明されているように、いくつかの方法があります。

グラフからノードを生成するための選択項目は、分布ノードとヒストグラム・ノードを使用して作成したグラフ内でしか有効になりません。グラフボード・ノードを使用して作成されたグラフからは、ノードを生成することはできないことに注意してください。

再現可能な割り当てに対処する

整数以外の係数を設定すると、複製または破棄されるレコードが無作為に選ばれます。また、この係数はデータがノードを通過するたびに適用されます。つまり、バランス調整後のデータ・セットは、ノードが実行されるごとに異なることを意味します。

IBM SPSS Modeler 内では、無作為に割り当てられる要素を含むノードの一部 (サンプル・ノードパーティション・ノードなど) に、パーティション割り当ての再現を強制する手段が用意されています。けれども、バランス・ノードにはそのような手段が用意されていません。毎回まったく同じようにバランス調整を行う必要がある場合は、キャッシュまたはエクスポートを使用してください。

キャッシュを使用する場合

バランス調整を再現するのに最も簡単な方法は、バランス・ノード上でキャッシュを有効にすることです。キャッシュが有効にされていれば、バランス調整の設定がデータ・セットの残りと一緒に一時ファイルまたはデータベース・テーブルに保管されるようになります。セッション内でいったんキャッシュに入れられたバランス調整の設定は、そのセッションが終わるまで使用されます。キャッシュが有効にされるとノードの右上隅に小さなアイコンが追加されます。このアイコンは、キャッシュにデータが入れられると緑色に変わります。


ただし、キャッシュに入れられたレコードの割り当てはセッション間で維持されません。したがって、ストリームを閉じた後、再度開く際にレコードの再割り当てが行われます。あるいは何らかの理由でキャッシュの中身が消去された場合も、同じくレコードの再割り当てが行われます。キャッシュを有効にすると、基本的に完全なデータ・セットがコピーされることになるため、データ・セットに多数のフィールドがあると、不必要にサイズの大きな一時ファイルが生成される可能性があります。詳細については、このリンク先の記事「ノードのキャッシュ・オプション」を参照してください。

エクスポートを使用する場合

割り当てを再現するもう 1 つの方法は、バランス調整したデータ・セットを作成した後、そのデータ・セットを、各レコードを一意に識別する 1 つ以上のフィールドと一緒にファイルまたはデータベース・テーブルにエクスポートすることです。エクスポートされたバランス調整の設定は元のソース・データにマージできるため、セッション間でバランス調整を維持できるようになります。

ただしバランス調整にわずかでも変更があると、その小さな変更が推定モデル内で大きな違いとなって表われます。その差異は、推定モデルが不安定であることを示す兆候として解釈されることになります。この問題は、バランスを調整していないデータ・セットを使用するよりも、遥かに大きい問題になり得ます。

動的なバランス調整

データ・サイエンティストはバランス・ノードを使用して、バランスを調整する条件とその係数を入力できますが、バランス調整係数は通常、分析対象のデータ・セットに含まれるデータのバランスによって決まります。したがって、データ・セットの変化に合わせて定期的にモデルを再トレーニングする環境では、バランス調整に使用する係数も同じく変わっていきます。モデルを手作業で再トレーニングする場合、あるいは基礎となるデータのバランスが大幅に変化しないのであれば、データ・サイエンティストがデータを調べた後、モデルを再トレーニングする前に係数を変更するという追加の作業はそれほど多くはないはずです。その一方、モデルの構築と再トレーニングが自動化された形で行われる場合、つまり、同じストリームを使用して異なる顧客区分またはオファーのモデルを作成する場合には、各データ・セットに含まれるデータの比率に応じて動的にバランスが調整されるようにしなければなりません。

ストリーム・スクリプトを使用してバランス・ノードを操作することで、ノードの係数、さらに条件までリセットすることがきます。

例 4: スクリプトを使用した動的なバランス調整

このリンク先から、この例で使用するストリームとストリーム・スクリプトをダウンロードしてください。

例 4 では、データ・セットのバランスを調整するために必要な係数と条件を動的に作成する方法を説明します。ここで使用するデータ・セットは前の例で使用したものと同じなので、データ・セットに含まれる男性のレコードの数は減らされていて、男性と女性の分布が均等になっています。

図 6. ストリーム・スクリプトによる動的なバランス調整に使用するストリーム
「Counts by Gender (性別ごとの数)」ノードから、「Merge (マージ)」ノード、「Factor (係数)」ノード、「Condition (条件)」ノード、「Filter (フィルター)」ノード、「Directives (ディレクティブ)」ノードへと続くストリームを示す図
「Counts by Gender (性別ごとの数)」ノードから、「Merge (マージ)」ノード、「Factor (係数)」ノード、「Condition (条件)」ノード、「Filter (フィルター)」ノード、「Directives (ディレクティブ)」ノードへと続くストリームを示す図

このストリームの最も長い分岐では、係数と条件が計算されます。count_by_gender 集約ノードは単に、男性と女性のレコードが以下の数となるようなデータ・セットを作成するに過ぎません。

性別count_by_gender
男性4
女性2

「Target Count (ターゲット数)」という名前の集約ノードが、性別ごとの数の最小値を取ってバランスの調整方法を決定します (この例の場合は集約)。その調整方法により、各カテゴリーでターゲットとする事例の数が決まりますが、この設定は「Min (最小)」(集約) から「Max (最大)」(ブースティング) または「Mean (平均)」(集約とブースティングの組み合わせ) に簡単に変更できます。目的のターゲット数をさまざまな方法によって作成するために、このノードを 1 つ以上のノードで置き換えることもできます。

Merge (マージ)」ノードは、2 つの集約結果を 1 つのデータ・セットにマージします。これにより、データ・セットに含まれるレコードは、性別ごとに 1 つとなります。

性別count_by_genderTarget_Count
男性42
女性22

「Factor (係数)」ノードは派生ノードとして、バランス調整において性別ごとに適用する係数を算出します。そのために使用する式は、target_count/count_by_gender です。この式は、各カテゴリーでターゲットとする事例の数と、それぞれのカテゴリーの実際の事例の数との比率を計算します。

「Condition (条件)」ノードは、"GENDER = \"" >< GENDER >< "\"" という式を使用して、バランス調整において性別ごとに使用する条件を算出します。

「Directives (ディレクティブ)」という名前のテーブル・ノードは、テーブルに係数と条件を表示し、そのテーブル内の値をスクリプト内で使用できるようにします。

係数条件
0.500GENDER = "Male"
1.000GENDER = "Female"

係数が 1 と等しいレコードにはバランス・ノード内で何も適用されないため、「Directives (ディレクティブ)」ノードの前に選択ノードを追加して、それらのレコードを破棄するという方法もあります。

以下のコードは、「Directives (ディレクティブ)」テーブル・ノードを実行して、算出されたディレクティブをテーブルに表示するストリーム・スクリプトです。

 # Execute the "Directives" table node to compute the directives 
 directivesResults = [] 
 diagram.findByType('tablenode', "Directives:).run(directivesResults) 
 directivesRowSet = directivesResults[0].getRowSet() 
 directivesRowCount = directivesRowSet.getRowCount()

このコードは、ディレクティブの合計数もテーブル内の行数としてキャプチャーします。

以下のコードでは、ディレクティブがテーブル出力からキャプチャーされるごとに、そのディレクティブをリストに格納するための directivesAll = [ ] 変数を宣言しています。

スクリプトがテーブル出力の各行を繰り返し処理する際は、以下のコードで係数と条件をディレクティブにアセンブルし、2 つの要素を持つリストとして保管します。

 # Iterate through the table output to read each directive 
 for ii in range(directivesRowCount): 
   directiveCurrent = [] 
   # Get the factor 
   directiveFactor = directivesRowSet.getValueAt(ii, 0) 
   directiveCurrent.append(directiveFactor) 
   # Get the condition 
   directiveCondition = directivesRowSet.getValueAt(ii, 1) 
   directiveCurrent.append(directiveCondition) 
   # Append the directive into a list of lists 
   directivesAll.append(directiveCurrent)

以下のコードによってアセンブルされたディレクティブが、バランス・ノード内でディレクティブとして使用されます。

 # Set the directives in the Balance node 
 balanceNode = diagram.findByType('balancenode', "Balance") 
 balanceNode.setPropertyValue('directives', directivesAll)

スクリプトの実行前にバランス・ノードの設定がどのようになっていたかに関わらず、スクリプトを実行した後にテーブル・ノードが出力するディレクティブの内容が、バランス・ノードの設定に反映されます (図 7 を参照)。

図 7. スクリプト化されたバランス・ノードのディレクティブ
「Settings (設定)」タブで男性の係数が 0.5、女性の係数が 1.0 に設定された画面のスクリーン・キャプチャー
「Settings (設定)」タブで男性の係数が 0.5、女性の係数が 1.0 に設定された画面のスクリーン・キャプチャー

現時点で、データ・セットに含まれる男性と女性のレコードの分布は均等になっています。この均等な分布は、ソース・データ内での基礎となる分布が変わったとしても常に維持されます。

IDGENDER NUM_PAGES
A 男性 181
D 男性 164
E 女性 175
F 女性 188

出現頻度の低いカテゴリーを増やすとしても、出現頻度の高いカテゴリーを集約するとしても、バランス調整という方法は常に効果を発揮します。それは、この方法は Target_Count フィールドの計算に依存しているためです。

スクリプトに頼らなくても、キャンバス上のノードだけを使用して、動的に係数が割り振られるバランス・ノードの出力を複製することもできます。ストリーム・スクリプトがすでに十分複雑な場合や、複数の属性に基づいて込み入ったバランス調整を行わなければならない場合は、スクリプトに頼らないこの方法を選ぶことになるでしょう。

動的なバランス調整は、出現頻度の高いカテゴリーのレコード数を少なくする場合に最もよく使用されます。なぜなら、スクリプトを実行することを必要とせずに、例 4 で説明したものと同じ基本ノードの多くを使用して同じ結果を得ることができるためです。

例 5: 複雑なサンプリングを使用した動的なバランス調整

このリンクをクリックして、この例で使用するストリームをダウンロードしてください。

例 5 の目的は例 4 と同じく、男性の数と女性の数が一様に分布するデータ・セットを作成することです。

図 8. サンプリングによる動的なバランス調整に使用するストリーム
「Counts by Gender (性別ごとの数)」ノードから、「Merge (マージ)」ノード、「Filter (フィルター)」ノード、「Type (タイプ)」ノードに達した時点で、「Directives (ディレクティブ)」ノードに分岐して終わるか、あるいは「Merge (マージ)」ノードに分岐して「Complex (複合)」ノード、「Filter (フィルター)」ノードと続いて「Table (テーブル)」ノードで終わるストリームを示す図
「Counts by Gender (性別ごとの数)」ノードから、「Merge (マージ)」ノード、「Filter (フィルター)」ノード、「Type (タイプ)」ノードに達した時点で、「Directives (ディレクティブ)」ノードに分岐して終わるか、あるいは「Merge (マージ)」ノードに分岐して「Complex (複合)」ノード、「Filter (フィルター)」ノードと続いて「Table (テーブル)」ノードで終わるストリームを示す図

ストリームの上側の分岐は、分岐ノードの名前が「Factor (係数)」となっている点、「Condition (条件)」ノードが不要になって省略されている点を除けば、例 4 で使用した分岐と同じです。

この例で追加されているもう 1 つのマージ・ノードは、上の分岐内で算出されたディレクティブをソース・データにマージします。マージされるディレクティブには、各カテゴリーのターゲット数と、出現頻度の高いカテゴリーのサンプリングに使用されることになる係数が含まれます。

GENDERIDNUM_PAGESTarget_count
女性 F 188 4
女性 E 175 4
男性 D 164 4
男性 C 142 4
男性 B 191 4
男性 A 181 4

「Complex (複合)」という名前のサンプル・ノードは、バランス・ノードに代わってバランス調整を行うノードです。

以下に示すように、サンプリング方法を「Complex (複合)」に設定します。サンプリングの層化フィールドとしては、「GENDER」フィールドを選択します。

図 9. サンプル・ノードの設定
「Settings (設定)」タブ上で「Complex (複合)」ボタンが選択され、「Stratify by (層化フィールド)」として「GENDER」が指定されている画面のスクリーン・キャプチャー
「Settings (設定)」タブ上で「Complex (複合)」ボタンが選択され、「Stratify by (層化フィールド)」として「GENDER」が指定されている画面のスクリーン・キャプチャー

比率に基づく無作為のサンプリングの変数としては、計算後の「Factor」フィールドを選択します。

IDGENDERNUM_PAGES
A 男性 181
D 男性 164
E 女性 175
F 女性 188

この場合も、男性と女性のレコードが一様に分布するデータ・セットが生成されます。

サンプリングを使用して動的なバランス調整を適用するという方法のメリットの 1 つは、サンプル・ノードには、ランダム・シードを定数に設定できるオプションがあるという点です。定数に設定すると、ノードを実行するたびに、無作為なサンプリングによって常に同じ数のレコードが返されます。「再現可能な割り当てに対処する」で説明したように、この機能は通常のバランス・ノードにはありません。

最良のバランス調整係数を選択する

バランスを調整すべきかどうか、バランス調整がモデリングにとって有益であるかどうかは、通常、プロジェクトで達成しようとしているビジネス目標によって決まります。まずはモデルの混合行列を調べて、モデルがビジネス目標を満たすかどうかを判断するところから始めてください。例 1 で概説した状況では、混合行列を調べると、バランスが取れていないデータ・セットに基づくモデルを使用すると、正当な保険金請求のほぼすべてを識別することはできても、不正な請求は 1 つも (あるいはわずかな数しか) 識別できないことが明らかになるでしょう。別の言葉に置き換えると、このモデルは次のように表現できます。

  • 多数の検出漏れがある
  • タイプ II のエラー率が高い
  • 特異度が 1.0 に近い

ビジネス目標が、有効な保険金請求を調査しなくても済むようにすることであるとしたら、このモデルは妥当であると見なせます。けれども、不正を検出して抑止することが目標だとすると (こちらの目標のほうが一般的です)、このモデルを使用してその目標を達成することはできません。その場合、モデルを改善するために、データのバランス調整という方法をとることになるでしょう。

ブースティング、集約、またはこの 2 つの組み合わせのどの方法を使用するかは、データ・セットの相対的比率およびビジネス目標に依存します。適切なバランス調整レベルを見つけるのに最も効果的な方法は、調整方法と係数を変えて複数のモデルを作成し、それらのモデルを評価して互いに比較することによって、どのモデルがビジネス目標を達成するのに最適であるかを判断することです。

その場合の経験則および指針は次のとおりです。

  • データ・セットのバランスを調整する際は、最終的に均等な分布にしなければならないわけではありません。
  • 出現頻度の高いカテゴリーを過剰にサンプリングしないでください。その場合、出現頻度の低いカテゴリーのデータを破棄しすぎることになり、全体的なデータ・セットから引き出されるはずの重要な相関関係やパターンを見つけられなくなる可能性があります。
  • 個々のレコードを複製しすぎないでください。ランダムで、まれなレコードの出現頻度が高くなって、モデリング・アルゴリズムがそれを有意のパターンとして認識する恐れがあります。

保険金詐欺の例では、不正な請求を複製して分布を均等にするのは賢明なことではありません。分布を均等にすると、モデリング・アルゴリズムによって、元の不正な請求のそれぞれに備わっているプロパティーの組み合わせが、不正を示唆するパターンとして認識されることになるからです。また、正当な請求を集約して分布を均等にするのも賢明なことではありません。その場合、正当な請求の特性を持つデータの大半が破棄されて、正当な請求を表すパターンを識別するのが難しくなります。解決策は、この両極端の方法の中間にあります。つまり、不正な請求を複製し、正当な請求を集約することで、ビジネス目標を達成するモデルを作成するのに妥当なバランスに調整することです。

データ・セットを過度にバランス調整しないようにするために最も重要となる対策は、バランスが調整されていないデータ・セットをトレーニング用のデータとテスト用 (そしておそらく検証用) にパーティション化して、トレーニング・パーティションとテスト・パーティションでは元の比率を維持することです。その上で、テスト・パーティションまたは検証パーティションに基づいてモデルのパフォーマンスを評価し、そのモデルの真の有効性を判断します。

例 6: クレジット・カードのオファー

このリンク先から、この例で使用するストリームとサンプル・データ・セットをダウンロードしてください。

例 6 のシナリオでは、あるクレジット・カード会社が、その会社に問い合わせてきた既存のカード保有者に対して、さまざまなオファーとマーケティング・キャンペーンを提示します。これらのオファーのうち 1 つは、カード保有者が同じアカウントを使用して配偶者や他の家族のために家族カードを登録できるというものです。

コール・センターにかかってくる 5,904 件の電話のうち、2,000 人未満のカード保有者にこのオファーを提示したところ、オファーを受け入れたカード保有者は13.8% でした。

まず、バランス調整が適用されていない実際の不均等な分布のデータ・セットを使用してモデルをトレーニングします。

図 10. クレジット・カード・オファー・モデルのトレーニングに使用する基本的なストリーム
以下で説明する「Credit Cards (クレジット・カード)」ノードから「Confusion Matrix (混合行列)」ノードへと続くフローを示す図
以下で説明する「Credit Cards (クレジット・カード)」ノードから「Confusion Matrix (混合行列)」ノードへと続くフローを示す図

上記の図では、「Credit Cards (クレジット・カード)」ノード > 「Reclassify (再分類)」ノード > 「Offer Made (オファー提示)」ノード > 「Partition (パーティション)」ノード > 「Balance (バランス)」ノード > 「Type (タイプ)」ノードに至ると、そこから分岐して「Training, (トレーニング)」ノード > 「Offer Response (オファー応答)」ノードへと至るか、または「Offer Response (オファー応答)」ノードへと向かって追加のテストと分析が行われた後、終点の「Confusion Matrix (混合行列)」ノードに辿り着きます。

予測モデルは応答者の 87.5% を正しく分類しますが、混合行列では応答者の 94.9% がオファーを拒否すると予測しています。また、このモデルはオファーを受け入れたカード保有者の 23.9% だけを識別します。この検出漏れの率は 76.1% にも上ります。

表 1. 不均等な分布のデータ・セットを使用してトレーニングされたモデルの混合行列
実際の応答
受け入れ 拒否 合計
予測される応答受け入れ 23.9% 1.9% 5.1%
拒否 76.1% 98.1% 94.9%
合計 100.0% 100.0% 100.0%

次は、ブースティングを使用して、オファーを受け入れた応答者と拒否した応答者の分布が均等になるようにモデルをトレーニングします。それには、オファーを受け入れた場合のレコードに対して係数 6.2409 を適用するバランス・ノードを追加します。データ・セットには、オファーを受け入れた応答者が 274 人、拒否した応答者が 1,710 人含まれています。この 2 つのグループを均等に分布させるための係数は、大きいほうのグループの応答者数 (1,710) を小さいほうのグループの応答者数 (274) で除算することによって算出できます。したがって、係数は 1,710/274=6.2409 となります。

トレーニング後のモデルは、トレーニング・パーティションに含まれる応答の 95.1% を正しく分類しますが、テスト・パーティション内で正しく分類されるのは応答の 81.4% だけです。この結果は、モデルが過度にトレーニングされていることを意味します。つまり、ブースティングしすぎているため、レベルを調整する必要があるということです。

表 2. バランス調整された均等な分布のデータ・セットを使用してトレーニングされたモデルの混合行列
実際の応答
受け入れ 拒否 合計
予測される応答受け入れ 56.3% 14.4% 20.4%
拒否 43.7% 85.6% 79.6%
合計 100.0% 100.0% 100.0%

一方、検出漏れの率を 43.7% にまで下げることには成功しました。元のモデルと比べると、この結果は、大幅な改善です。

バランス調整レベルを変えて複数のモデルを作成すると、わずかに違った結果になります。同じモデルを同じデータ・セットによって、ただしバランス調整レベルを変えた上でトレーニングした結果を以下の表に記載します。検出漏れの率と誤検出の率は、テスト・パーティションに基づいています。

表 3. データ・セットを使用してバランス調整レベルを変えてトレーニングしたモデルの全体的な精度
方法 ディレクティブ 検出漏れ率 誤検出率 精度のトレーニング 精度のテスト 精度の差異
なし 適用外 76.1% 32.0% 87.5% 87.5% 0.0% ポイント
ブースティング (25/75) 2.1070: 受け入れ 71.8% 44.4% 85.9% 86.4% -0.5% ポイント
ブースティング (33/67) 3.1200: 受け入れ 43.7% 53.5% 91.6% 84.4% 7.2% ポイント
ブースティング (40/60) 4.2000: 受け入れ 39.4% 57.4% 91.7% 82.6% 9.1% ポイント
ブースティング (50/50) 6.2409: 受け入れ 45.1% 60.2% 95.3% 81.6% 13.7% ポイント
組み合わせ (50/50) 3.6204: 受け入れ 0.5801: 拒否 33.8% 60.5% 90.3% 80.6% 9.7% ポイント

表 3 の結果を図 11 に示すグラフにすると、バランス調整のレベルの違いによる検出漏れ率と誤検出率との間のトレードオフがわかりやすくなります。点線で示しているのは、残りのバランス調整レベルの結果を同じスペースにプロットした場合に表れると予想される極めて主観的な境界線です。

図 11. 異なるバランス調整レベルのデータ・セットに基づくモデルの検出漏れ率と誤検出率との間の関係を示す図
検出漏れの増加に伴って誤検出が減少するという相互関係を示す図
検出漏れの増加に伴って誤検出が減少するという相互関係を示す図

これらのモデルを評価する方法はさまざまにありますが、バランスを調整する目的を考えると、結局のところはビジネス・ケースが適切なバランスを決定します。高収益の製品を低コストのチャネルを通じてオファーするのであれば、低収益の製品を高コストのチャネルを通じて販売する場合よりも高い誤検出率を受け入れることを厭わないでしょう。

例 6 で取り上げたオファーは、既存のアカウントに追加する家族用のクレジット・カードです。カードをアカウントに追加するということは、そのクレジット・カードのアカウントを使用する個人がもう 1 人増えるということなので、カードが使われるたびに、クレジット・カード・プロバイダーに収益がもたらされます。各アカウントに期待される収益は多種多様な要因に基づくため、年間の期待収益と期待されるアカウント存続期間を評価するためのモデルを作成することになるはずです。この例の場合、家族用のクレジット・カードの追加によって期待される収益は 10 US ドルになると想定します。

このオファーを提示するためのコストも考慮に入れる必要があります。そのコストには、コール・センターのエージェントが費やす時間や、このオファーを受け入れたであろうアカウント保有者ではなく他のアカウント保有者に提示したことによる収益の損失など、さまざまな要素が含まれますが、単純にするために、コストは 2 US ドルという設定にします。これらの前提に基づくと、クレジット・カード会社は 80% の誤検出率を受け入れたとしてもまだ、収支が合うことになります。

どの使用事例でも、適用するのに適切なバランス調整ディレクティブを決定するのは難しいことであり、その決定は明らかに、ビジネス目標に応じた最適なバランスを見つけるための試行錯誤から導かれます。鍵となるのは、ビジネス目標を十分に把握し、予測モデルがどのように実装されて使用されるかを明確に理解することです。

まとめ

この記事では、さまざまなバランス調整方法とそのレベルを評価する方法と、BM SPSS Modeler にバランス調整を導入する方法を説明しました。記事で提供しているテスト・データ・セットを使用し、必要に応じてバランス・ノードを使用してブースティングまたは集約を適用することで、目的の結果を得ることができます。さらに、動的にバランスが調整されるようにすれば、分析対象のデータの変化に応じてバランス・ノードを変更できます。例えば、予測モデルを使用して家族用のクレジット・カードをオファーする顧客を選択する場合、顧客のオファー受け入れ率が上がると、データのバランスが変わってきます。多くの場合、データはこのように動的であるため、バランス調整係数も定期的に手作業で調整しなければなりませんが、IBM SPSS Modeler を使用すれば、ユーザー固有のビジネス目標に基づいて、データに適用すべきバランス調整係数を判断することができます。

参考資料


ダウンロード可能なリソース


コメント

コメントを登録するにはサインインあるいは登録してください。

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=ビジネス・アナリティクス
ArticleID=1043768
ArticleTitle=データのバランスを調整して、より現実に即した統計モデルを生成し、より正確な結果を出す
publish-date=03102017