2007年7月 4日

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

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

一個,有効か無効か判断に迷うネタを.

From: SATOH Kiyoshi <satoh0@xxxxx>
Subject: [SpamAssassin-JP 570] Re: 分かち書き手法で精度が変らないというレポート

Date: Wed, 04 Jul 2007 10:59:46 +0900
>
> さとうです。
>
> On Wed, 4 Jul 2007 00:03:03 +0900
> TAKIZAWA Takashi <taki@xxxxx> wrote:
> Subject: [SpamAssassin-JP 565] Re: 分かち書き手法で精度が変らないというレポート
>
> > >  そういった問題ないのだとすると、N-gramでの分かち書きであれば、言語依存
> > > しないから、パッチを取り込んでもらう際にだいぶ有利になると思うので。
> > 日本語対応パッチを作っているときに、N-gramも検討したのですが、データ量が
> > 大きくなりすぎることが気になって採用しませんでした。
> > ベイズの学習データの制限値を大きくしたり、N-gram用のベイズの学習データを
> > 従来の学習データとは別に管理したりすれば問題ないのかも知れませんが。
> > でも、中国語のベイズ学習にも対応しようとするとN-gramを採用するしかないん
> > ですよね。

辞書肥大化を防ぐためには,単一でなくて言語体系毎の辞書の方がそれなりに
効果があります.
ただ,Unicode を使われてしまうと,言語の判定ができなくなっちゃうので,
現状では区別して処理速度面での効果が見込めても,遠い将来にはマルチバイ
トコードは Unicode に一本化しないといけないかもしれません.

なお,spam は Content-Type: の charset は嘘だらけですので,bsfilter で
は中身のコード判定で言語を決めています.

確か仕様が定まった段階では...

日本語 -> 日本語DB
その他 -> 英語DB (後に US-ASCII 以外のものもこちらに含まれる形に...)

だったと思います.
なべけんさん的には,辞書を増やすことについて色々と迷っておられた模様.
# 中国語か韓国語対応版は覗いてみたことがないなぁ...

その昔の仕様として,内部コードを EUC-JP にしてしまわれたのですが,
マルチリンガルに対応する意味では UTF-8 とかの方が良かったのでは?
と思った事があります.
コード変換を伴うと,逆変換が成立しないものもあるので,正規化が重要だと
思うのですが,Unicode はちょっとねー... という矛盾した思いも.


-- Eisaku YAMAGUCHI @ bsfiler の source code もそうとうご無沙汰...
--
SpamAssassin メーリングリスト
http://mm.apache.jp/mailman/listinfo/spamassassin-jp

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




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