以前書いた “ベイジアンアルゴリズムは効くのか?” では、Thunderbird のスパムフィルタ機能が思ったように機能しなかったことと、オレが確率論そのものを胡散臭く思っていることから、ベイジアンアルゴリズムによるスパムのフィルタリングに対する疑問を書いたが、その後調べていくうちにいろいろわかってきたので紹介したいと思う。
まず、コメントで教えてもらったPOPFileというソフト。 自分でも使ってみたが、思った以上に機能して驚いた。確かに、スリ抜けるものもあるが、その数はThunderbird の比ではない。
管理画面で、メール中のどの単語がピックアップされ、どの確率で使われているか表示されるとよくわかる。 これが本当のベイジアンアルゴリム(オリジナルのアルゴリズムを改良したモノのようだ)の威力なのかと再認識させられた。 みんながスゴいというのは伊達じゃなかった。
では、なぜ Thunderbird のスパムフィルタが機能しなかったのか。
training.dat はジャンクメールコントロールの学習結果を格納しているファイルであり、プロファイルディレクトリにあります。
このサイトにはジャンクメールコントロールに使われる、training.dat というデータファイルを参照することができる perl スクリプトが置いてある。 これを使って、オレの情報を見てみたのが下のデータ。
pmin=0.000000 pmax=1.000000 bmin=0 nGood 33 nBad 309 total non-spam tokens 11204 total spam tokens 28344 0 572 0.990 span 0 238 0.990 neomail . . .
nGood (Spamじゃなかったメール数) が極端に少ない。 nBad (Spam だったメール数) にしてもこんなもんじゃない。 もうちょっと調べるために training.dat を新しく作り変えて、手持のSpamメールを送り直してみて確かめたところ Thunderbird (version 0.5)は、スパムマーク(ゴミ箱アイコン)をクリックして、マークを付けたり、外したときだけ、そのメールの情報を training.dat に記録しているようだ。
つまり、スパムフィルタが通した通常のメールや、一度憶えて、スパムだと認識したメールは training.dat に記録されない。 一方、POPFile は何らかの方法で、ほとんどのメールが次回以降のスパムチェックのために記録されていく。 このヘンの処理方法の違いが、 Thunderbird のスパムフィルタが正常に機能しない理由じゃないだろうか。
ベイジアンフィルタの論文には、
ベイジアンフィルタがうまく動く鍵は、大きく綺麗なコーパスにある。 そういうコーパスはベイジアンフィルタの入力としても使えるだけでなく、 その他のフィルタにもテスト用として利用できる。
とあるように、判断情報は多ければ多いほどよいらしいので、Thunderbird のような方法ではなかなか賢くなっていかず、いつまでも誤認識してしまう。 自分が今持っているメール全てに一旦スパムマークを付けて、スパムじゃないメールはマークを外すという作業をすれば、ある程度は改善されると思うがあまりスマートじゃない。 Thunderbird/Mozilla チームはこのへんの問題を認識をしているのだろうか?
相変らず、なんでうまくいくんだろうという部分に疑問は残るが、ベイジアンアルゴリズムは、結構機能するという風に意見を改めたいと思う。
Thunderbird/Mozilla のスパムフィルタに関しては今後も動向を追っていきたい。
—
他にもウラを取れたわけじゃないが Thunderbird にはおかしな動きがある。
-
何度もスパムマークを付け変えると出現回数だけがどんどん増える(しかも、一部は Good のカウントのまま残る)。
-
日本語の扱いがヘン? ソースを見るとI18N対応で共通のトークナイズルーチンを通しているようだが、こいつはひらがな、カタカナはそれぞれ別の種類の文字が来るまでを1トークンとして扱っているようだが、漢字だけは1文字ごとに分割するようだ これは日本語のSpamメールを本格的に対応していこうと思ったときに問題になりそうな気がするのだがどうなのだろうか? 確率的には問題ない?
2004年4月11日 at 6:59 PM
> これは日本語のSpamメールを本格的に対応していこうと思ったときに問題になりそうな気がするのだがどうなのだろうか? 確率的には問題ない?
あるある。
「未承諾広告」を spam 判定をした場合に、「広い」と入ったメイルも spam 判定されたら困るだろうし、逆に「広い」が OK なら「未承諾広告」も OK になっちゃう。
イナミの読みどおり POPFile では日本語の処理時に Kakasi を用いて分かち書きをしてます。なので単語単語でちゃんと処理できるわけです。
2004年4月12日 at 10:43 AM
あー、そうか。
単純に 「未承諾広告」 1語として出た場合と、「未」「承」「諾」「広」「告」の 5単語に分割されて出現した場合を比べてどっちがいいかな? と思って書いたんだけど、「広い」のように、関係ない単語内に出現した場合の情報も加わってきちゃうからダメなんだ。
でも、こういったことを全言語に対して行わなければいけないのは大変だな。I18N も見ためだけじゃなくて、そういった情報もきちんと扱わなればいけない時代になってきたってことか。
2004年4月13日 at 5:12 AM
全世界共通で使えるソフトウェアとか出てき始めているということは、要求が出てきているってことかしらね。
でもマルチバイト系言語（何か変な表現）では、要するに kakasi と同様な分かち書きができるツールがあればいい気がする。辞書ベースで活用形を… あ、活用形か。これは言語毎に随分違うか。難しいね。
はて、POPFile の各言語対応ってどうなってるんだろう。
2005年1月27日 at 7:11 PM
ちなみに私の所には、なぜか、韓国語のspamが多く来るけど、POPFileは、これも、きちんと分けてくれます
大変助かってます