Loading...

より良いベイズフィルタリング

Original

2003年1月

(この記事は、2003年のスパム会議で講演として発表されたものです。 スパムのための計画で説明されているアルゴリズムのパフォーマンスを向上させるために私が行った作業と、将来行う予定の作業について説明しています。)

ここで最初に紹介したい発見は、研究論文の遅延評価のためのアルゴリズムです。 好きなことを書いて、以前の研究を引用しないでください。 腹を立てた読者が、引用すべきだったすべての論文への参照を送ってくれます。 このアルゴリズムは、``A Plan for Spam'' [1]がSlashdotに掲載された後に発見しました。

スパムフィルタリングはテキスト分類のサブセットであり、 これは確立された分野ですが、 ベイズスパムフィルタリングそのものに関する最初の論文は、 1998年の同じ会議で発表された2つの論文のようです。 1つはPantelとLinによる[2]、 もう1つはMicrosoft Researchのグループによる[3]です。

この研究について聞いたとき、私は少し驚きました。 人々が4年前からベイズフィルタリングに取り組んでいたなら、 なぜ誰もそれを利用していなかったのでしょうか？ 論文を読んだとき、その理由がわかりました。 PantelとLinのフィルターは、 2つのうちより効果的でしたが、 スパムの92%しか捕捉できず、偽陽性は1.16%でした。

ベイズスパムフィルターを作成しようとすると、 スパムの99.5%を捕捉し、偽陽性は0.03%未満でした[4]。 2人が同じ実験を試みて、大きく異なる結果が出ると、 いつも不安になります。 特にここでは、2つの数値セットが 反対の結論を生み出す可能性があるため、不安です。 ユーザーによって要求は異なりますが、 多くの人にとって、92%のフィルタリング率と1.16%の偽陽性は、 フィルタリングが受け入れられない解決策であることを意味する一方、 99.5%と0.03%未満の偽陽性は、 フィルタリングが受け入れられる解決策であることを意味します。

では、なぜこのような異なる数値が得られたのでしょうか？ PantelとLinの結果を再現しようと試みたことはありませんが、 論文を読んだところ、違いの原因となる可能性のある5つの点が見られます。

1つは、フィルターのトレーニングに使用したデータが非常に少ないことです。 スパム160件と非スパムメール466件です。 フィルターのパフォーマンスは、 このような小さなデータセットでもまだ上昇するはずです。 そのため、彼らの数値は、 アルゴリズムのパフォーマンスの正確な尺度ではなく、 一般的にベイズスパムフィルタリングのパフォーマンスの尺度ですらありません。

しかし、最も重要な違いは、 おそらくメッセージヘッダーを無視したことです。 スパムフィルターに取り組んだことがある人なら誰でも、 これは奇妙な決定のように思えるでしょう。 しかし、私が最初に作成したフィルターでは、 ヘッダーも無視していました。 なぜでしょうか？ なぜなら、問題をきれいに保ちたかったからです。 当時はメールヘッダーについてあまりよくわかっておらず、 ランダムなものがたくさんあるように思えました。 フィルター作成者にとって、 ここでは教訓があります。 データを無視しないでください。 この教訓はあまりにも明白で言及するまでもないと思うかもしれませんが、 私は何度もそれを学ぶ必要がありました。

3つ目は、PantelとLinはトークンをステミングしました。 つまり、たとえばmailing''とmailed''の両方を ルート``mail''に減らしました。 彼らは、コーパスのサイズが小さいため、 これを行うことを余儀なくされたと感じたのかもしれませんが、 もしそうなら、これは一種の早すぎる最適化です。

4つ目は、確率の計算方法が異なります。 彼らはすべてのトークンを使用しましたが、 私は最も重要な15個のトークンのみを使用します。 すべてのトークンを使用すると、 長いスパムを見逃しがちになります。 これは、誰かがマルチレベルマーケティングスキームで お金持ちになった経緯まで、 自分のライフストーリーを語ってくれるようなスパムです。 そして、そのようなアルゴリズムは、 スパマーが簡単に偽造できます。 スパム用語を打ち消すために、 大量のランダムなテキストを追加するだけです。

最後に、彼らは偽陽性をバイアスしていませんでした。 私は、 スパムフィルタリングアルゴリズムは、 フィルタリング率を犠牲にして、 偽陽性率を下げることができる便利なノブを持っているべきだと思います。 私は、 非スパムコーパス内のトークンの出現回数を2倍にすることで、 これを実現しています。

スパムフィルタリングを 単純なテキスト分類問題として扱うのは、 良い考えだとは思いません。 テキスト分類の手法を使用できますが、 ソリューションは、 テキストがメールであり、 特にスパムであるという事実を反映する必要があり、 反映することができます。 メールは単なるテキストではありません。 構造を持っています。 スパムフィルタリングは単なる分類ではありません。 偽陽性は偽陰性よりもはるかに悪いため、 異なる種類のエラーとして扱う必要があります。 そして、エラーの原因は、 ランダムな変動だけでなく、 フィルターを無効にするために積極的に活動している 生きた人間のスパマーです。

トークン

Slashdotの記事の後、 私が耳にした別のプロジェクトは、 Bill Yerazunisの CRM114 [5]です。 これは、私が ちょうど述べた設計原則に対する反例です。 これは単純なテキスト分類器ですが、 驚くほど効果的なので、 それが何をしているのかを知ることなく、 スパムをほぼ完璧にフィルタリングできます。

CRM114の仕組みを理解すると、 最終的には、 単一の単語に基づくフィルタリングから、 このようなアプローチに移行する必要があることは明らかでした。 しかし、最初に、 私は単一の単語でどこまでできるか見てみようと思いました。 そして、答えは、 驚くほど遠くまでです。

私は主に、 よりスマートなトークン化に取り組んできました。 現在のスパムでは、 CRM114に匹敵するフィルタリング率を達成することができました。 これらのテクニックは、 Billのテクニックとはほとんど無関係です。 最適なソリューションには、 両方が組み込まれる可能性があります。

``A Plan for Spam''では、 非常に単純なトークンの定義を使用しています。 文字、数字、ダッシュ、アポストロフィ、 およびドル記号は構成文字であり、 それ以外のすべてはトークンセパレーターです。 また、大文字と小文字も無視しました。

現在、 私はより複雑なトークンの定義を持っています。

大文字と小文字は保持されます。

感嘆符は構成文字です。

ピリオドとカンマは、 2つの数字の間にある場合は構成文字です。 これにより、 IPアドレスと価格をそのまま取得できます。

$20-25のような価格範囲は、 $20と$25の2つのトークンになります。

To、From、Subject、Return-Path行内、 またはURL内にあるトークンは、 それに応じてマークされます。 たとえば、Subject行のfoo''は、 Subject*foo''になります。 （アスタリスクは、 構成文字として許可されていない任意の文字にすることができます。）

このような対策により、 フィルターの語彙が増加し、 より識別力が高まります。 たとえば、現在のフィルターでは、 Subject行の``free''は、 スパム確率が98%であるのに対し、 本文の同じトークンは、 スパム確率が65%しかありません。

現在の確率のいくつかを以下に示します[6]。

SubjectFREE 0.9999 free!! 0.9999 Tofree 0.9998 Subjectfree 0.9782 free! 0.9199 Free 0.9198 Urlfree 0.9091 FREE 0.8747 From*free 0.7636 free 0.6546

Plan for Spamフィルターでは、 これらのトークンはすべて、 同じ確率、0.7602を持っていました。 そのフィルターは、 約23,000個のトークンを認識していました。 現在のフィルターは、 約187,000個のトークンを認識しています。

トークンの宇宙が大きいことの欠点は、 ミスが発生する可能性が高くなることです。 コーパスをより多くのトークンに分散させると、 コーパスを小さくすることと同じ効果があります。 たとえば、 感嘆符を構成文字と見なすと、 7つの感嘆符が付いたfreeのスパム確率がなくても、 2つの感嘆符が付いたfreeの確率が99.99%であることはわかっています。

これに対する1つの解決策は、 私が退化と呼ぶものです。 トークンの完全一致が見つからない場合は、 それがより一般的なバージョンであるかのように扱います。 私は、 末尾の感嘆符、大文字、 および5つのマークされたコンテキストのいずれかにあることを、 トークンをより特定のものと見なします。 たとえば、 Subject*free!''の確率が見つからない場合は、 Subject*free''、free!''、 およびfree''の確率を探し、 0.5から最も遠いものを採用します。

フィルターがSubject行に``FREE!!!''を見つけ、 その確率を持っていない場合に考慮される 代替案を以下に示します[7]。

SubjectFree!!! Subjectfree!!! SubjectFREE! SubjectFree! Subjectfree! SubjectFREE SubjectFree Subjectfree FREE!!! Free!!! free!!! FREE! Free! free! FREE Free free

これを行う場合は、 すべて大文字とすべて小文字だけでなく、 先頭が大文字のバージョンも考慮してください。 スパムは、 命令形が多い傾向があり、 それらの最初の単語は動詞です。 そのため、 先頭が大文字の動詞は、 すべて小文字の動詞よりもスパム確率が高くなります。 私のフィルターでは、 Act''のスパム確率は98%、 act''のスパム確率は62%です。

フィルターの語彙を増やすと、 古い ``同じ''の定義に従って、 同じ単語を複数回カウントすることになります。 論理的には、 それらはもはや同じトークンではありません。 しかし、 それでも気になる場合は、 経験から、 複数回カウントしているように見える単語は、 まさにあなたが望む単語であることが多いことを付け加えておきます。

語彙が大きいことのもう1つの効果は、 受信メールを見ると、 より興味深いトークンが見つかることです。 つまり、 0.5から遠い確率を持つトークンです。 私は、 メールがスパムかどうかを判断するために、 最も興味深い15個のトークンを使用しています。 しかし、 このように固定された数値を使用すると、 問題が発生する可能性があります。 最大限に興味深いトークンをたくさん見つけると、 結果が、 同じように興味深いトークンの順序を決定する ランダムな要因によって決まってしまう可能性があります。 これに対処する1つの方法は、 一部のトークンを他のトークンよりも 興味深いものとして扱うことです。

たとえば、 トークンdalco''は、 私のスパムコーパスに3回出現し、 私の正当なコーパスには出現しません。 トークンUrl*optmails'' （URL内の``optmails''を意味します）は、 1223回出現します。 しかし、 私がトークンの確率を計算していたように、 両方は同じスパム確率、0.99のしきい値を持つことになります。

それは正しいように感じられません。 これらの2つのトークンに大幅に異なる確率を与えるための 理論的な議論があります（PantelとLinはそうしています）。 しかし、私はまだそれを試していません。 少なくとも、 1つのコーパスにのみ出現するトークンを15個以上見つけた場合は、 多く出現するトークンを優先する必要があるように思えます。 そのため、 現在2つのしきい値があります。 スパムコーパスにのみ出現するトークンの場合、 確率は、 10回以上出現する場合は0.9999、 それ以外の場合は0.9998です。 正当なコーパスにのみ見つかったトークンの場合、 スケールの反対側でも同様です。

後でトークンの確率を大幅にスケールするかもしれませんが、 このわずかなスケーリングだけでも、 トークンが正しい順序でソートされることが保証されます。

もう1つの可能性は、 15個のトークンだけでなく、 特定の 興味深さのしきい値を超えるすべてのトークンを考慮することです。 Steven Hauserは、 彼の統計的スパムフィルター[8]でこれを行っています。 しきい値を使用する場合は、 非常に高く設定してください。 そうでなければ、 スパマーは、 より無害な単語でメッセージを詰め込むことで、 あなたを偽造することができます。

最後に、 HTMLについてどうすればよいでしょうか？ 私は、 無視することから、 すべてを解析することまで、 あらゆる選択肢を試してみました。 HTMLを無視するのは、 良い考えではありません。 なぜなら、 HTMLには役に立つスパムの兆候がたくさんあるからです。 しかし、 すべてを解析すると、 フィルターが単なるHTML認識器に 退化してしまう可能性があります。 最も効果的なアプローチは、 中庸の道であり、 一部のトークンに注目し、 他のトークンは無視することです。 私は、 a、img、 およびfontタグを見て、 残りは無視します。 リンクと画像は、 URLが含まれているため、 必ず確認する必要があります。

HTMLの処理について、 もっと賢くできるかもしれませんが、 私はそれに多くの時間を費やす価値はないと思います。 HTMLだらけのスパムは、 簡単にフィルタリングできます。 賢いスパマーは、 すでにそれを避けています。 そのため、 将来のパフォーマンスは、 HTMLの処理方法にあまり依存しないはずです。

パフォーマンス

2002年12月10日から2003年1月10日までの間に、 約1750件のスパムを受け取りました。 そのうち、 4件が通過しました。 これは、 約99.75%のフィルタリング率です。

見逃した4つのスパムのうち、 2つは、 私の正当なメールに頻繁に出現する単語を たまたま使用していたため、通過しました。

3つ目は、 安全でないCGIスクリプトを利用して、 第三者にメールを送信するスパムの1つでした。 ヘッダーは無害で、 使用する単語にも注意しているため、 コンテンツのみを基にフィルタリングするのは困難です。 それでも、 通常は捕捉できます。 このスパムは、 0.88の確率で通過し、 0.9のしきい値をわずかに下回りました。

もちろん、 複数のトークンシーケンスを見ると、 簡単に捕捉できます。 ``Below is the result of your feedback form''は、 すぐにわかるスパムです。

4つ目のスパムは、 私が将来のスパムと呼ぶものです。 なぜなら、 これはスパムが進化すると予想されるものだからです。 完全に中立なテキストの後にURLが続きます。 この場合、 それは、 自分のホームページを完成させたので、 見てほしいという内容のメールでした。 （そのページは、 もちろんポルノサイトの広告でした。）

スパマーがヘッダーに注意し、 新しいURLを使用した場合、 将来のスパムには、 フィルターが認識できるものはありません。 もちろん、 クローラーを送信してページを確認することで、 対処できます。 しかし、 それは必要ないかもしれません。 将来のスパムに対する応答率は、 低くなければなりません。 そうでなければ、 誰もがそれを実行するでしょう。 応答率が十分に低ければ、 スパマーにとって送信する価値がなくなり、 私たちはフィルタリングにあまり苦労する必要はありません。

さて、 本当に衝撃的なニュースです。 同じ1ヶ月の間に、 3件の偽陽性を受け取りました。

ある意味、 偽陽性を受け取るのは安心です。 ``A Plan for Spam''を書いたとき、 私は偽陽性を持っておらず、 偽陽性がどうなるのかわかりませんでした。 いくつか経験した今、 私は、 偽陽性が私が恐れていたほど悪くはないことに安心しています。 統計的フィルターによって生じる偽陽性は、 スパムによく似たメールであることが判明し、 これらのメールは、 見逃してもそれほど気にならないメールである傾向があります[9]。

2つの偽陽性は、 私が何かを購入した会社のニュースレターでした。 私はそれらを受け取るように頼んだことは一度もありません。 そのため、 議論の余地はありますが、 それらはスパムでした。 しかし、 私はそれらを偽陽性としてカウントしています。 なぜなら、 私は以前はそれらをスパムとして削除していなかったからです。 フィルターがそれらを捕捉した理由は、 両方の会社が1月に、 独自のサーバーからメールを送信するのではなく、 商用メール送信者に切り替えたため、 ヘッダーと本文の両方がはるかにスパムっぽくなったからです。

3つ目の偽陽性は、 ひどいものでした。 それは、 エジプトの人からのメールで、 すべて大文字で書かれていました。 これは、 トークンを大文字と小文字を区別するようにした直接的な結果です。 Plan for Spamフィルターは、 それを捕捉していませんでした。

偽陽性率全体がどのくらいかは、 統計的にノイズの範囲にあるため、 断言できません。 フィルターに取り組んだことがある人（少なくとも、効果的なフィルターに取り組んだことがある人）は、 この問題に気づいているでしょう。 一部のメールは、 スパムかどうか判断するのが難しく、 フィルターを 非常に厳しく設定すると、 最終的にこれらのメールを見ることになります。 たとえば、 これまでのところ、 フィルターは、 誤字脱字のために私のアドレスに送信されたメールを2件、 私が別人であると信じられて私に送信されたメールを1件、 捕捉しています。 議論の余地はありますが、 これらは私のスパムでも非スパムメールでもありません。

もう1つの偽陽性は、 Virtumundoの副社長からのメールでした。 私は顧客になりすまして彼らにメールを書きました。 そして、 返信がVirtumundoの メールサーバーを経由して返ってきたため、 考えられる限り最も犯罪的なヘッダーが付いていました。 議論の余地はありますが、 これも本当の偽陽性ではなく、 一種のハイゼンベルクの不確定性効果です。 私がスパムフィルタリングについて書いているからこそ、 私はそれを受け取ったのです。

これらをカウントせずに、 これまで合計5件の偽陽性がありました。 約7740件の正当なメールのうち、 0.06%の割合です。 他の2つは、 私が購入したものがバックオーダーになったという通知と、 Eviteからのパーティーのリマインダーでした。

この数値は、 サンプルサイズが小さいため、 信頼できないと考えています。 また、 フィルターを修正して、 これらのいくつかを捕捉しないようにできると思うからです。

偽陽性は、 偽陰性とは異なる種類のエラーのように思えます。 フィルタリング率は、 パフォーマンスの尺度です。 偽陽性は、 バグのように考えています。 フィルタリング率の向上は、 最適化として取り組み、 偽陽性の減少は、 デバッグとして取り組みます。

そのため、 これらの5つの偽陽性は、 私のバグリストです。 たとえば、 エジプトからのメールは、 大文字のテキストが、 フィルターにナイジェリアのスパムのように見えたため、 捕捉されました。 これは、 実際には一種のバグです。 HTMLと同様に、 メールがすべて大文字であることは、 実際には概念的に1つの機能であり、 単語ごとに1つではありません。 私は、 より洗練された方法で大文字と小文字を処理する必要があります。

では、 この0.06%をどう解釈すればよいでしょうか？ あまり意味がないと思います。 サンプルサイズが小さいことを考慮して、 上限として扱うことができます。 しかし、 この段階では、 これは、 ベイズフィルタリングの固有の偽陽性率ではなく、 私の実装のバグの尺度です。

将来

次は何でしょうか？ フィルタリングは、 最適化問題であり、 最適化の鍵は、 プロファイリングです。 コードがどこで遅いかを推測しないでください。 なぜなら、 間違った推測をするからです。 コードがどこで遅いかを確認し、 それを修正してください。 フィルタリングでは、 これは次のように解釈されます。 見逃したスパムを確認し、 捕捉するために何ができるかを考え出すことです。

たとえば、 スパマーは現在、 フィルターを回避するために積極的に活動しており、 彼らが行っていることの1つは、 フィルターが認識できないように、 単語を分割したり、 スペルミスをしたりすることです。 しかし、 これは私の最初の優先事項ではありません。 なぜなら、 私はまだこれらのスパムを捕捉することに苦労していないからです[10]。

現在、 私が苦労しているスパムには、 2つの種類があります。 1つは、 女性からのメールを装って、 チャットに誘ったり、 出会い系サイトのプロフィールを見せたりするスパムです。 これらのスパムは、 セールストークを使わずにできる唯一の種類のセールスキャンペーンであるため、 通過します。 それらは、 通常のメールと同じ語彙を使用しています。

もう1つの種類は、 ブルガリアの企業からのスパムで、 契約プログラミングサービスを提供しています。 これらのスパムは、 私もプログラマーであり、 スパムには私の実際のメールと同じ単語がたくさん含まれているため、 通過します。

私は、 おそらく最初に個人広告タイプに焦点を当てるでしょう。 もっと詳しく調べれば、 これらのスパムと私の実際のメールの間に、 統計的な違いを見つけることができると思います。 書き方は確かに異なりますが、 それを捕捉するには、 複数単語のフィルタリングが必要になるかもしれません。 また、 これらのスパムは、 URLを繰り返す傾向があることに気づきました。 正当なメールでURLを含める人は、 そうすることはありません[11]。

アウトソーシングタイプは、 捕捉するのが難しいでしょう。 たとえクローラーをサイトに送信しても、 決定的な統計的な証拠は見つかりません。 唯一の答えは、 スパムで宣伝されているドメインの中央リストを作成することかもしれません[12]。 しかし、 このタイプのメールはそれほど多くありません。 残っているスパムが、 ブルガリアからの契約プログラミングサービスの 勧誘のみであれば、 私たちは皆、 他の仕事に移ることができるでしょう。

統計的フィルタリングは、 実際に私たちをその地点に導くのでしょうか？ わかりません。 今のところ、 私個人にとって、 スパムは問題ではありません。 しかし、 スパマーは、 統計的フィルターを偽造するために、 まだ真剣な努力をしていません。 彼らがそうしたらどうなるでしょうか？

私は、 ネットワークレベルで動作するフィルター[13]に 楽観的ではありません。 乗り越える価値のある静的な障害物がある場合、 スパマーはそれを乗り越えるのが非常に効率的です。 すでにAssurance Systemsという会社があり、 あなたのメールをSpamassassinで実行し、 それがフィルターで除外されるかどうかを教えてくれます。

ネットワークレベルのフィルターは、 完全に役に立たないわけではありません。 それらは、 すべての「オプトイン」スパムを 排除するのに十分かもしれません。 つまり、 VirtumundoやEqualamailのような、 オプトインリストを実際に運用していると主張する 企業からのスパムです。 これらのスパムは、 本文に何を書かれていても、 ヘッダーに基づいてフィルタリングできます。 しかし、 ヘッダーを偽造したり、 オープンリレーを使用したりする意思のある人（おそらく、 ほとんどのポルノスパマーを含む）は、 ネットワークレベルのフィルターを 通過したいと思えば、 メッセージをいくつか通過させることができるはずです。 （ただし、 彼らが送りたいメッセージではありません。）

私が楽観視しているのは、 個々のユーザーのメールに基づいて確率を計算するフィルターです。 これらのフィルターは、 偽陽性を回避するだけでなく、 フィルタリングにおいてもはるかに効果的です。 たとえば、 メッセージのどこかに受信者のメールアドレスの ベース64エンコードを見つけることは、 非常に良いスパムの指標です。

しかし、 個々のフィルターの真の利点は、 すべてが異なることです。 すべてのフィルターが異なる確率を持っている場合、 スパマーの最適化ループ（プログラマーが 編集-コンパイル-テストサイクルと呼ぶもの）は、 恐ろしく遅くなります。 デスクトップにあるフィルターのコピーを 通過するまでスパムを調整するのではなく、 調整ごとにテストメールを送信する必要があります。 それは、 対話型のトップレベルのない言語でプログラミングするようなものであり、 私は誰にもそれを望みません。

注記

[1] Paul Graham. ``A Plan for Spam.'' August 2002. http://paulgraham.com/spam.html.

このアルゴリズムの確率は、 ベイズの定理の退化ケースを使用して計算されます。 2つの単純化された仮定があります。 特徴（つまり単語）の確率は独立していること、 メールがスパムである事前確率は何も知らないことです。

最初の仮定は、 テキスト分類では広く普及しています。 この仮定を使用するアルゴリズムは、 「ナイーブベイズ」と呼ばれます。

2番目の仮定は、 私の受信メールのスパムの割合が、 日ごと（実際には時間ごと）に大きく変動したため、 全体的な事前比率は、 予測因子として無価値であるように思えたため、行いました。 P(spam)と P(nonspam)の両方が0.5であると仮定すると、 それらは打ち消し合い、 式から削除できます。

スパムと非スパムの比率が、 常に非常に高いか（特に）非常に低い状況で、 ベイズフィルタリングを行っている場合は、 事前確率を組み込むことで、 フィルターのパフォーマンスを向上させることができる可能性があります。 正しく行うには、 スパムと正当なメールのボリュームの両方が、 明確な日々のパターンを持っているため、 時間帯別に比率を追跡する必要があります。

[2] Patrick Pantel and Dekang Lin. ``SpamCop-- A Spam Classification & Organization Program.'' Proceedings of AAAI-98 Workshop on Learning for Text Categorization.

[3] Mehran Sahami, Susan Dumais, David Heckerman and Eric Horvitz. ``A Bayesian Approach to Filtering Junk E-Mail.'' Proceedings of AAAI-98 Workshop on Learning for Text Categorization.

[4] 当時、 私は約4,000件の正当なメールのうち、 偽陽性は0件でした。 次の正当なメールが偽陽性だった場合、 これは0.03%になります。 これらの偽陽性率は、 後で説明するように、 信頼できません。 ここでは、 偽陽性率が 何であれ、 1.16%未満であることを強調するために、 数値を引用しています。

[5] Bill Yerazunis. ``Sparse Binary Polynomial Hash Message Filtering and The CRM114 Discriminator.'' Proceedings of 2003 Spam Conference.

[6] ``A Plan for Spam''では、 0.99と0.01のしきい値を使用しました。 コーパスのサイズに比例したしきい値を使用することは、 正当化できるようです。 現在、 私は各タイプのメールを約10,000件持っているので、 0.9999と0.0001を使用しています。

[7] ここには、 おそらく修正する必要がある欠陥があります。 現在、 Subject*foo''が単なるfoo''に退化すると、 それは、 私がマークした以外の本文またはヘッダー行の foo''の出現に関する統計を取得していることを意味します。 私がすべきことは、 foo''の統計を 全体として、 特定のバージョンだけでなく、 追跡し、 Subject*foo''をfoo''ではなく、 ``Anywhere*foo''に退化させることです。 大文字と小文字についても同様です。 大文字を任意のケースに退化させるべきであり、 小文字に退化させるべきではありません。

価格についても、 たとえば、 $129.99''を$--9.99''、$--.99''、 および$--''に退化させることは、 おそらく有効でしょう。

単語を語幹に退化させることもできますが、 これは、 コーパスが小さい初期段階でのみ、 フィルタリング率を向上させる可能性があります。

[8] Steven Hauser. ``Statistical Spam Filter Works for Me.'' http://www.sofbot.com.

[9] 偽陽性はすべて同じではなく、 スパムを阻止するためのテクニックを比較する際には、 それを覚えておく必要があります。 フィルターによって発生する偽陽性の多くは、 見逃しても構わないようなスパムに近いメールであるのに対し、 たとえば、 ブラックリストによって発生する偽陽性は、 単に間違ったISPを選んだ人からのメールです。 どちらの場合も、 スパムに近いメールを捕捉しますが、 ブラックリストの場合、 近さは物理的なものであり、 フィルターの場合、 近さはテキスト的なものです。

[10] スパマーがトークンを隠すのが上手くなり、 これが問題になる場合は、 空白、ピリオド、カンマなどを削除し、 辞書を使用して、 結果のシーケンスから単語を抽出するだけで対応できます。 そして、 もちろん、 元のテキストでは見えなかった単語をこのように見つけることは、 それ自体がスパムの証拠になります。

単語を抽出するのは、 簡単ではありません。 単語の境界を再構築するだけではありません。 スパマーは、 文字を追加したり（xHot nPorn cSite''）、 省略したり（P#rn''）します。 人間の視覚は、 このようなトリックが近づく限界であるため、 視覚研究が役立つ可能性があります。

[11] 一般的に、 スパムは通常のメールよりも反復的です。 彼らは、 そのメッセージを叩き込みたがっています。 現在、 私のフィルターでは、 トップ15のトークンに重複を許可していません。 なぜなら、 送信者が たまたま悪い単語を複数回使用した場合、 偽陽性になる可能性があるからです。 （私の現在のフィルターでは、 ``dick''のスパム確率は0.9999ですが、 それは名前でもあります。） しかし、 重複に気づく必要があるように思えるので、 Brian BurtonがSpamProbeで行っているように、 トークンを最大2つまで許可してみようと思います。

[12] これは、 スパマーが 他のすべてを生成するために、 マッドリブテクニックを使用するように追い込まれた場合、 Brightmailのようなアプローチが 退化していくものです。

[13] ネットワークレベルでフィルタリングに取り組むべきだという議論が しばしばされます。 なぜなら、 それはより効率的だからです。 人々が通常、 これを言うときに意味しているのは、 現在、 ネットワークレベルでフィルタリングしており、 最初からやり直したくないということです。 しかし、 解決策に合わせて問題を指示することはできません。

歴史的に、 リソース不足の議論は、 ソフトウェア設計に関する議論では、 敗北する側でした。 人々は、 それらを、 他の理由でなされた選択（特に不作為）を 正当化するためにのみ使用しがちです。

謝辞 Sarah Harlin、Trevor Blackwell、 およびDan Giffinに、 この論文の草稿を読んでいただき、 Danには、 このフィルターが動作するインフラストラクチャのほとんどを提供していただき、 感謝申し上げます。

関連:

SubjectFREE 0.9999 free!! 0.9999 Tofree 0.9998 Subjectfree 0.9782 free! 0.9199 Free 0.9198 Urlfree 0.9091 FREE 0.8747 From*free 0.7636 free 0.6546

SubjectFree!!! Subjectfree!!! SubjectFREE! SubjectFree! Subjectfree! SubjectFREE SubjectFree Subjectfree FREE!!! Free!!! free!!! FREE! Free! free! FREE Free free