2007年7月25日

[SpamAssassin-JP 606] Re:分かち書き手法で精度が変らないというレポート

** SpamAssassin メーリングリスト **
** 注意:このメールへの返信は SpamAssassin-jp へ行きます **
沖です。

> メイルで考え方を伝えるのは難しいですね.
> ということで,必要以上に長く,くどくなっているかもしれません.
>
 MLでは、気をつけないと、なかなか意図が伝わりにくくて

ときにはナーバスになっちゃいますよね:-)。

>
> >  私はプログラマなので、芸術的な考え方よりも、現実的な考え方を
> > してしまうのかもしれません。ベイズでSpamらしさの確率を得るのに、
> > いちいち全部の単語を"文字通り"処理する必要は無いでかな?と
> > 思っています。
>
> 決して芸術的考え方ではないのです.
> 現実で,unique にならないのが Unicode なのですけれど.
> その認識をされていないのであれば,多分,話の接点は見いだせないと思います.
>
> そんなの,"SpamAssassin という閉じた中では,converter の仕様が変わらな
> い限り関係ない" という考えもまた解かなと考えてはいます.
>
 そうですね、これが POPFile みたいに クラス分けを行うという姿勢で
あれば、Unicode への変換部分で支障をきたす可能性は十分にあると思います。
Spam 判定というだけならば、そこまで神経質にならなくても良いかな?
といったところです。

> コンバータの種類によって,「ある文字コード」の「とある文字」が,
> Unicode になる時に,一意に決定されず,Unicode のある文字になったり別の
> ある文字になったりすることがあります.
>
> ex. 記号では wave dash 等
>
 〜 のコードを含むワードの Unicode 変換で検索がうまく行かない
といった弊害は聞きますが、ベイジアンでは、-> Unicode した結果が
(多対一でも)一意であれば、ワードとしての確率を押し上げたり、押し
下げたりできるので、もし、特定の値域に相当するワードに焦点を当てて
変数域のワードを見たときに、極端にスパムの確率として高いものと、
極端にハムの確率として高いものが、多く混在するようでは、失敗する
可能性が高いと言えるかもしれません。

 ちょっと、スパムチックな観点から言えば

 え○こう
 え■こう

といった表現を取られた場合に、これら記号パートが同一で扱われれば
ワードとしての扱いが同一になるので、検出精度が上がる方向に働くの
では?なんて事を漠然と思ったわけですが、その前に、どうトークンに
切り出すか?も重要な要素なわけで、物事そう単純では無さそうです。

> N-gram 云々以前の tokenizer 上の切り分け場所の差にもなりますので,
> Unicode 化の際は,Unicode は万能ではなくてマッピングに関する注意とか
> survery をしっかりやり直しておかないと安易には難しいよね!!!
> という次第です.
>
 という事で深く考えていけば、そういう事ですね。

>
sinp...

> 自信の経験からは,思いつきから出てくる,heuristic な処理は実は非常に
> 有効な可能性を多分に含んでいる事があるものだと思います.
>
> しかし,その正当性を訴えかけるためには,試行したデータを見せたり,
> 反例を潰していくことが必要です.
>

そこなんですが、会社勤めをしてると、なかなか時間が取れないのが
悩みですorz。ここはひとつ…(爆)

 こうやって、アイデアを出してみてMLで考えてみると、
いろんな角度から検討できていいですね。

> 提案に対して一つお願いするとしたら,例示した mail magazine 等の banner
> が誤判定されてしまう可能性は? となる訳です.
> 少なくとも,Web 等で公開されている mail magazine では,あぁ...
> banner に記号が多用されているなぁと思いました.人目を引きたいのは,
> spam も mail magazine の広告も一緒.
>
 ここは、現状でも十分にグレイゾーンで、私の受けているその手のメールの
ベイジアンのスコアは、BAYES_50 が大半のようです。

 個人的意見では、メルマガはたいしてスパムメールと中身が変わらないので
ベイジアン判定の対象から外していいと思っています。

> 小生は,容易に類推可能な反例を示してみました.
> それ,「大丈夫でした」問題ありませんという判断事例があると,「おおそう
> なのですか!」じゃ,そういう方式についてもっと検討してみましょう.成功
> したら広めましょうということになると思います.:-)
>
> 因に,SpamAssassin をベースにしたものとか,その他の複数エンジンを抱え
> るサポート付き商品であっても,現状でも mail magazine のみならず,
> security vendor からの report(security alart) や,全うな業務連絡を
> spam 扱いしてラベル付けしてくれるなど,世の中には false positive が
> ゴロゴロしているという認識です.
> (その誤判定要因は,非常に安易なスコアの付け方によるものだったりします)
> 敢えて,false positive に傾くネタは増やすのは,信頼性を下げるだけでは?
> というのがその心でもあります.
>
> 既に色々な文字コードの実装がある以上,完璧は無理だと思っています.
> 実用性と美しさとの両立は不可能だという認識です.
>
> spammer は,自身が記号混じりの特異な語彙を使うことが,spam と判定され
> る確率が高くなることを考えないのか,敢えて特異な表現を使います.
> 敢えてその特徴を捨ててしまうかもしれない実装をする必要はないのではない
> かと.
> その特徴も含めて判定するのが Bayesian Filter の本質だという認識です.
>
 あと、ユーザ会としての指針として、日本語対応のベイジアンを本家に
取り入れてもらうよう努力するというのがありまして、平たく言ってしまうと
utf8 で処理するのが一般的な解法って事に辿り着いてしまうんです。

> -- Eisaku YAMAGUCHI @ ML への reply は時間がかかるかも...

 山口さん、いろいろと、面白い意見をありがとうございます。
もっと、若い人?がバンバン活躍してくれると、心強いかも…。

--
SpamAssassin メーリングリスト
http://mm.apache.jp/mailman/listinfo/spamassassin-jp

投稿者 xml-rpc : 2007年7月25日 11:09
役に立ちました?:
過去のフィードバック 平均:(0) 総合:(0) 投票回数:(0)
本記事へのTrackback: http://hoop.euqset.org/blog/mt-tb2006.cgi/62168
トラックバック
コメント
コメントする




画像の中に見える文字を入力してください。