ベイジアンネットワークのエッジの向きが逆だと(;´Д`)?な理由

Risk Assessment and Decision Analysis with Bayesian Networks(以下、リスクベイズ本)の172ページに書かれているように、ベイジアンネットワークの構造を考えている場合、ついつい「原因->結果」ではなく、「結果(観察された事象)->原因」という方向にエッジを引きたくなる。

 
リスクベイズ本には「原因から結果に引くのが原則だが、数学的にはどちらの方向に引いても等価であり、別にBNとしてInvalidということはない」と書いてある。

仮に、開き直って「結果から原因」に向かって引いたら何が起こるのか?と考え、Wekaで実行してみた。

超シンプルなナイーブベイズでのスパムメール検出を例に考えてみる。

ここでは『AAAA』『BBBB』『CCCC』という3つの単語だけが登場するものとする。
 
AAAAは「とてもお行儀の良い」単語であるとする。AAAAがスパムメールに含まれる確率は1%であると仮定する。正常なメール(ハムメール)に含まれる確率は、5倍の5%であるものとする。AAAAのCPTは以下のようになる。(ここではtrueは「AAAAがメールに含まれる」という意味)

BBBBは「とにかくよく見かける」単語であるとする。BBBBがスパムメールに含まれる確率は2%であると仮定する。ハムメールに含まれる確率も、同じく2%であると仮定する。BBBBのCPTは以下のようになる。

CCCCは「行儀が悪い」単語であるとする。「バイアグラ」のようなイメージである。CCCCがスパムメールに含まれる確率は5%であると仮定する。また、ハムメールに含まれる確率は0.5%であるとする。CCCCのCPTは以下のようになる。


 
メール全体に対するスパムメールとハムメールの割合は、それぞれ同じであると仮定する。
すると、Wekaのベイズネットワークエディタで作成したモデルは以下のようになる。

この段階では、これから分類しようとするメールにそれぞれの単語が見つかったかどうか(エビデンス)をまだ反映していないので、緑で記述されている数値には殆ど意味がない。
 
上図において、エッジの方向は、Class(スパムかどうかの分類)のノードから「それぞれの単語が含まれるかどうか」のノードへ向かっている。ここで、原因はClassノードが意味する「スパムメールであること(あるいはその逆)」であり、結果として「CCCCが含まれる」というような事象が発生する、と考えるのが王道である。つまり、このエッジの向きは正しい。

しかし、「スパムメールの検出を行いたい!」と強く思っていると、「CCCC」のノードから「Class」のノードに向かってエッジを引きたくなってしまう、というのが、このエントリの発端となっている現象だ。
つまり、「スパムメールの5%にCCCCという単語が含まれている」という思考ではなく、「CCCCという単語が含まれていれば○X%の割合でスパムメールだ」という思考をしたくなってしまうのである。

さて、メールが到着したとする。このメールには単語「CCCC」が含まれていることがわかったとする(他の2つについてもわかるはずだが、何かしらの理由でまだわかっていないものとする)。上記ベイジアンネットワークにこのエビデンスを反映する。つまり、「CCCC」の値を「true」にセットする。すると次のようになる。

Classノードの値に注目する。するとスパムメールである確率が9090(おそらく90.9%という意味。この表記わかりにくいよWeka…)と、跳ね上がることがわかる。

このように、モデルは正しく機能する。モデルを作成する際にはそれぞれの単語について「スパムメールに含まれる確率」「正常なメールに含まれる確率」をCPTとして記述していけばよく、作業は単純で難しい部分はない。もちろん、数が多い場合には面倒ではあるが、それによって特に難易度が変わることはない。

では、エッジの向きが逆だったらどうなるだろうか。この場合、モデルは次のようになる(ここでは緑で記述された値には特に意味はない)

ClassノードのCPTを編集しようとすると、以下のようになる。

(;´Д`)!!!!!

意味がわかっただろうか?
つまり、このCPTを埋めるためには『各単語がメールに登場した場合にそれがスパムかどうかについて、すべての組み合わせについての確率を明確にしなくてはいけない』のだが、それこそがこのベイジアンネットワークを使って求めたい情報なのである。そのため、この向きでベイジアンネットワークを作る意味は無いのであった…

おしまい(´Д`)