(67) Re: バージョン情報 by きよ at 2005/01/26 17:02:21 レス投稿

> バージョン情報ダイアログで出る日付のは普通にthunderbird.exeのビルド日時のようです。

へぇ〜　なるほど。
nightlyを追いかけていたときは気付きませんでした。

http://kiyo.chips.jp/blog/

(62) Re: (無題) by junnno' at 2005/01/26 04:02:04 レス投稿

> ヘッダについては残しておいた方が良かったのが有るのかも知れません。
> なぜかと言うと、本文のないメールもジャンク扱いさせていたんですが、junnno'版ではジャンクと決めつけることが出来なくなったから。（手動で設定しても次回は必ず非ジャンクとなる）これはトークン数が一定数を超えてからの現象かも知れませんが。

従来は、メールに固有のIDを登録していたために、一度学習したメールの成功率が引き上げられていたのだと思います。
再帰テストの成績は下がるかもしれませんが、予測フィルタの動作としては正しいのではないかと思います。

> ＃ 本文のないメールはジャンク判定以前の問題として削除しても構わないんですが（本文がないこと自体Thunderbirdのバグなのかも）

関係ないことを思い出しました。
本文が空で添付ファイルがWORD形式で一つ、
というとんでもないメールを送る偉い人がいました。
（さらにTo:には100人分ぐらいのメールアドレスが）


> mailnews.ui.junk.firstuse の設定のせいかも。どういう訳かjunnno'版では"false"がデフォルトになっています。この状態ではメッセージフィルタが先に走行します。
> ここのところの確認は「メーラーdeネットニュース」というソフトを使えば出来ると思いますし、時間が出来たら試します。

そんな設定があったのですね。
よろしくお願いします。

> Number of good messages: 1
> Number of bad messages: 518
> Number of good tokens: 77
> Number of bad tokens: 11299
> Number of good messages: 4102
> Number of bad messages: 213
> Number of good tokens: 87842
> Number of bad tokens: 1962
> Creating master table...
> Updating view...
> done.
> これは上半分が英語、下半分が日本語ですよね？

そうです。
学習数が多いですが、動作が遅くなりませんか？

> ＃ 結果の training.2.dat を提出しても良いかなと考えたんですが、中身を見ると私自身のプライベートや仕事関連の情報が多すぎて困ります。（例えばせっかく暗号化された情報やパスワードまで記録されている）

一方向関数でハッシュ化すればデータの共有ができるかも。
役に立つかどうかはともかく…。

(65) Re: (無題) by きよ at 2005/01/26 16:52:54 レス投稿

> 従来は、メールに固有のIDを登録していたために、一度学習したメールの成功率が引き上げられていたのだと思います。
> 再帰テストの成績は下がるかもしれませんが、予測フィルタの動作としては正しいのではないかと思います。
そうですね。ただThunderbirdにはアドレス設定によるジャンク特定の機能がないのでジャンクと決めつけることが出来ないのが残念です。


> そんな設定があったのですね。
> よろしくお願いします。
メーラーdeネットニュース は継続して使う気がなかったので期限切れになっていました　(^^;)

mailnews.ui.junk.firstuse は上に書いたようなメッセージフィルターにてアドレスでのジャンク特定に使えます。最初はこの機能を使っていました。


> 学習数が多いですが、動作が遅くなりませんか？
遅いですよ。Eudoraはもっと時間がかかります。

> > ＃ 結果の training.2.dat を提出しても良いかなと考えたんですが、中身を見ると私自身のプライベートや仕事関連の情報が多すぎて困ります。（例えばせっかく暗号化された情報やパスワードまで記録されている）
>
> 一方向関数でハッシュ化すればデータの共有ができるかも。
> 役に立つかどうかはともかく…。
人間は読めないってことですね。
ジャンクフィルタデータベースとして流通させるならばサニタイズするツールが有れば良いのかも。

http://kiyo.chips.jp/blog/

(43) Re: 言語別カウンタ by junnno' at 2005/01/22 06:48:22 レス投稿

> 言語別にカウンタを分けるんじゃなくて、
> 別のトークンと思えばいいんじゃないんでしょうか？
> 日本語メールなら、ja_JP:というプレフィックスをつけるとか。

現在のパッチでは、別のトークンとして認識させています。
具体的には、JA:というプレフィックスを付けています。

問題は、確率計算にこれまでに学習したメールの数を使うところにあります。
通常、トークンの数は学習メールの数に比例すると考えられます。
ですが、英語メールの学習は、日本語のトークンを増やさずに学習メール数だけを増やすことになります。
結果として、日本語トークンのジャンク確率の希釈が起こり、陰性になってしまいます。

で、結局次の式の分母を大きくしてしまうようです。

　(spamcount×ngood)
---------------------------------------
　(hamcount×nbad + spamcount×ngood)

ここで、
spamcountがジャンクとして学習したメールの数、
hamcountが非ジャンクとして学習したメールの数、
nbadがジャンク中に出現した回数、
ngoodが非ジャンク中に出現した回数。


あ。

ということは、別に辞書は分けなくても、言語毎にメールの数だけ数えていればいいのか……。

(45) Re: 言語別カウンタ by junnno' at 2005/01/22 06:55:27 レス投稿

間違えた。
正しくは、

　(spamcount×ngood)
---------------------------------------
　(hamcount×nbad + spamcount×ngood)

spamcountがジャンク中に出現した回数、
hamcountが非ジャンク中に出現した回数、
nbadがジャンクとして学習したメールの数、
ngoodが非ジャンクとして学習したメールの数。