Hatena::ブログ(Diary)

あまつぶ@はてなダイアリー RSSフィード

あまつぶWikiあまつぶ過去ログMacソフトWinソフト掲示板
<カレンダー>
2003 | 09 | 10 | 11 | 12 |
2004 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2005 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2006 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 12 |
2007 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2008 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2009 | 01 | 02 | 03 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2010 | 01 | 03 | 04 | 05 | 06 | 07 | 09 | 11 |
2011 | 02 | 07 | 08 | 11 |
2012 | 04 | 11 |
2013 | 07 | 09 | 10 |
2014 | 11 |
2015 | 11 |

<< 2009/08 >>
1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31

<最近の見出し>




POPFile の Mac OS X(Panther/Tiger/Leopard/Snow Leopard/Lion/Mountain Lion/Mavericks/Yosemite)用インストーラをお探しの方は、POPFile プロジェクトのダウンロードページへ。
 | 

2009-08-29 第09回まっちゃ445勉強会資料

[][]第09回まっちゃ445勉強会資料 第09回まっちゃ445勉強会資料を含むブックマーク

無事帰宅しました。

講師のみなさん、おつかれさまでした。たくさんのお話が聞けて刺激を受けました。最後はちょっとばたばたとしてしまいましたが、大変いい機会をいただいて、楽しめました。ぜひ定期的に集まりたいですね!

スタッフのみなさんも、タイトなスケジュールの中でいろいろと調整をいただき、ありがとうございました。

参加者のみなさんもご清聴ありがとうございました。自己紹介の雰囲気では、メールサーバの管理をされている方が多く、クライアント系の POPFile の話がどれだけ参考になったかはわかりませんが、何か役に立つことがあれば幸いです。

とりあえず資料あげておきます(OOo Impress 版PDF 版)。もう少しネタをしぼるべきだったかなと反省です。

[]質問や要望いただいたことメモ 質問や要望いただいたことメモを含むブックマーク

  • 初期に既存のメールを用いて学習させるツール

標準では、「insert.pl」というユーティリティ・スクリプトが用意されていて、機械的に学習させることができます。ですが、このツールは「とにかく学習させる」だけなので、コーパスの肥大化を招いたり、学習させるメールの量によってはアンバランスな状態になってしまう可能性があります。また、Perl のスクリプトが用意されているだけなので、誰にでも使えるというものではありません。

一方、サードパーティ(といっても、これを書いた Joseph は POPFile Core Team のメンバーですが)のスクリプトには、「xmltraintest.py」というものがあり、KakasiMeCab、内蔵パーサの分類精度比較はこのスクリプトを若干改造したものを用いて行いました。このスクリプトは非常に便利なのですが、こちらは Python で書かれており、標準のスクリプトよりも敷居が高い感じです。

もっと簡単に使えるように……ということで、考えてみます。とりあえず、xmltraintest.py と同じように、XMLRPC インターフェースを使う方向でしょうか。

  • ある程度学習済みのコーパス(分類ごとの単語のデータベース)を提供する

これは私が使っているものを少し整理すれば簡単に実現できそうですが、考えてみると、このコーパスで「非スパム」に分類されている単語を大量にメールに含めたメールを送られたりすると、見逃しが起こる可能性が出てきてしまいます。日本語スパムの状況を見る限りでは、そこまで手をかけたことをしてくるとは思えませんが、若干気になるところではあります。

コーパスの内容は関係なく、)一般的な単語の羅列を本文に含めるという手法は、Word Salad というテクニックとして知られていますが、POPFile では、個々のコーパスの内容は異なるため、あまり意味をなしません。ですが、共通で使われているコーパスがあれば、この手法はより有効に働くことになります。

とはいえ、初期状態では上記のような危険性はあっても、学習を続けていくことでその影響は小さくなっていくはずですから、導入の敷居を下げるという意味では有効かもしれません。

stealthinustealthinu 2009/08/31 19:05 ぜひ定期的にしたいですね。
それにより、次に向けてなんか新ネタ仕込まなくちゃ… という心理的圧迫を作るのが目的の一つだったりしますし。
「肉リリース」みたいなみんですね。

せいぜい95%くらい選り分けれる学習済みコーパスを提供してはどうでしょうか。
僕らはメール数が多いので、学習もすぐさせることできますが、メール数が(スパム・ハム共)それほどでもない人は、なかなか学習が進まなくて、学習が進む前に飽きてちゃんと使わなくなるとか、あるかなと。
でもスパムがたくさん来てて困ってるからPOPFile導入するわけで、そんなこともないのかな?とも思いますが。

amatubuamatubu 2009/08/31 22:11 先日はどうもです。
そうですね。モチベーションの維持にもつながりますよね。私も話すネタを作らないと。
肉リリース、いいですね(笑) 月一は厳しそうですが、私も何か新しいことに取り組もうと思いました。

既存のメールから簡単に学習させるツールができれば、サンプルのメールとの組み合わせでもいけるかなと思いました。
サンプルだけを使ってもいいし、受信済みのメールを追加してもいいという感じで。
XMLRPC インターフェースを使えばそれほど難しくはなさそうなので、考えてみます。サンプルメールを用意するのが難しそうですが、うまくいけば次回のネタに……(^^;

stealthinustealthinu 2009/09/03 13:54 XMLRPCについてはPukiWikiのスパムフィルタでPOPFile使えないかな〜と考えてた時に一回テストして、なんかの理由でうまく使えなかったんですよ。でもそんなに大した問題じゃなかったので、amatubuさんに聞けばきっと即解決できそうな問題だったはず。
で、POPFileのサーバ版をそういうコメントスパムやWikiスパムのフィルタリングにも使うっていう需要、結構ありそうに思うんですがどうでしょ?
次回のネタに向けて :)

stealthinustealthinu 2009/09/03 16:21 なにが出来なかったかわかりました。
PukiWiki使ってる人ってレンタルサーバの人が多いので、POPFileをデーモンとして起動して独自httpd経由で利用する、というような運用出来ない場合が多いのです。
なので、POPFileをCGIとして呼び出せるように改造してるような実装どっかにないかな〜、と探したんですがなくって。
さすがにこれは即解決とはいかないか…

amatubuamatubu 2009/09/03 18:32 なるほど、確かにレンタルサーバで POPFile をデーモンとして動かすというのは敷居が高そうですね。
POPFile には、コマンドラインから動かすユーティリティスクリプトがいくつかありますので、そのあたりを改造すれば比較的容易に実現できるのではないかと思います。近いのは bayes.pl ですかね。
http://getpopfile.org/docs/jp:utilityscripts:bayes
入力の部分は、標準入力からの方がいいかもしれませんので、そこは pipe.pl が参考になるかもしれませんね。
http://getpopfile.org/docs/jp:utilityscripts:pipe
CGI からだとどういうインターフェースがいいでしょう。

stealthinustealthinu 2009/09/03 18:58 あ、なんか過去の記憶が呼び覚まされてきた感じです。
確かbayes.pl/pipe.plってXMLRPC呼んで判定したりしてるんじゃなかったでしたっけ?そこのソース見て、こりゃ簡単、と思ってPukiWikiからの呼び出しを試した記憶が有ります。
判定に回す部分は、スパム判定用のプラグイン的なモノをつくってやり、そこからXMLRPC呼び出して行うということでいけるので、その点についてはPOPFile側の修正は現状のままでいけると思います。
スパムコメントの管理、つまり投稿されたものをスパム・ハムに選り分ける部分をPOPFileのWebUI使ってやりたかったのですが、そのあたりはどうしたら良さそうでしょうか。

amatubuamatubu 2009/09/03 20:15 いえ、bayes.pl とか pipe.pl は XMLRPC とは関係ないです。POPFile のモジュールに直接アクセスしています。
POPFile の UI を使うには、やはり POPFile をデーモンとして動かしておく必要がありますので、そのまま使うのは難しいと思います。
投稿されたコメントは別に管理しておいて、学習させるのは insert.pl を使うというのではどうでしょう。
http://getpopfile.org/docs/jp:utilityscripts:insert

XMLRPC で学習させるツールを作りかけていますが、結構おもしろいですね。ドキュメントに書かれていない(書き忘れ?)コマンドなんかもあるので、一度そのあたりもまとめてみようかなと思っています。

amatubuamatubu 2009/09/03 21:44 うちで借りているサーバに POPFile を入れて試してみました。
意外とあっさり動いてしまって驚きましたが、結構おもしろいですね、これ。
とりあえず、投稿したメッセージにちょっとしたヘッダを加えて bayes.pl で判定させるもの。
http://amatubu.skr.jp/popfile/test/post.cgi
(ソース)
http://amatubu.skr.jp/popfile/test/post.pl

insert.pl も問題なく動きますね。
あまり考えたことはなかったですが、この使い方はいろいろと使えそうですね〜。

stealthinustealthinu 2009/09/04 10:22 bayes.plとかはそのままモジュール呼んでるんですね。確認しました。
なんか自分の書いたテストコードが出てきたんでみたら、やっぱXMLRPC呼んでやってました。短いんで、ここにそのまま書けるかな?

#!/usr/bin/perl

use strict;
use XMLRPC::Lite;

my $sk = XMLRPC::Lite ->proxy('http://localhost:8081/RPC2')
-> call('POPFile/API.get_session_key','admin','')
-> result;

print "session key: $sk\n";

my $word_count = XMLRPC::Lite ->proxy('http://localhost:8081/RPC2')
-> call('POPFile/API.get_word_count', $sk)
-> result;
print "word count: $word_count\n";


my $spam_classify = XMLRPC::Lite ->proxy('http://localhost:8081/RPC2')
-> call('POPFile/API.classify',$sk,'/home/stealth/spam.txt')
-> result;
print "spam classify: $spam_classify\n";

XMLRPC::Lite ->proxy('http://localhost:8081/RPC2')
-> call('POPFile/API.release_session_key',$sk);

でもやっぱこれだと、デーモンとして立ってなくっちゃいけないから、レンタルサーバだと使いにくいですね。
やっぱりCGIとして使えるように、amatubuさんのテストコードみたいな方向で進めたほうが良い感じです。
CGIからどっかの関数叩いたら、POPFileのUIが表示される、みたいな便利なのってないですかね :)

amatubuamatubu 2009/09/05 10:44 > CGIからどっかの関数叩いたら、POPFileのUIが表示される、みたいな便利なのってないですかね :)

そうですねー。
UI の表示は、UI::HTML で行っていますが、基本的にデーモンで動いていることを前提にしているのでそのままではうまく動かないですね。
モジュールをちゃんと初期化してあげて、UI::HTML の url_handler__ を呼べば UI の HTML ソースが得られるので、リンク先などを加工しつつ表示してあげればいけそうですが、すべてうまく動くようにするのはなかなか大変そうです。

stealthinustealthinu 2009/09/07 15:12 むむ、なかなか難しそうですね。残念。
でも、UI使わなければ利用出来そうだから、管理者がspam/hamの判定だけを行えるようなUIだけ用意できれば、いけるのかな?

amatubuamatubu 2009/09/09 00:05 UI についてはちょっと試してみましたが、なかなかうまく動かないですね。一応、ページが見られるところまではいったのですが、リンクの処理などを考えると結構大変そうでした。私が CGI にあまり慣れていないのも一因なのですが……。
とりあえず、試しにうちの掲示板に設置してみました。
http://amatubu.skr.jp/treebbs/treebbs.cgi
上でテストしていたものを既存のCGIに組み込んだという感じなので、まだまだ汎用というわけにはいきませんが、とりあえずは動いているようです。
ちょくちょく spam 書き込みが来ていますので、2、3適当に学習させてみました。普通の書き込みの情報があまりないので、うちでメールの判定用に使っているデータベースをそのまま使ってます。
しばらくテストして様子を見てみようと思います。

UI を使わなければ、比較的導入は容易だと思います。必要となるファイルも少ない(最低限必要なのは、Classifier フォルダと POPFile フォルダ、それと使いたいスクリプト(bayes.pl とか)で、それ以外はなくても動きます。
もう少しまとまったら、簡単な使い方を書いたり、判定や学習をさせるための汎用的な Perl モジュールを作成したりしてみたいと思います。

stealthinustealthinu 2009/09/09 01:18 さすが素早いですね。
POPFileのUIが使えない場合、誤判定したコメントをどうやって救済するか、救済用の仕組みを別で考えなくちゃいかんので、それを各コメントCGI毎に書かないといけないから、なんとか出来れば、と思ってました。
でも結局、救済したものを再度コメントに反映させるには、やはり各コメントCGI毎に実装しないといけないんで、手間は同じかもしれませんね。

あ、スパム判定された場合、CAPTCHA出すようにして、それ抜けた場合には、誤判定だったとして、ハムとして学習させればよいのかも。
それだったら事前フィルタとして汎用的なものが書けそう。

amatubuamatubu 2009/09/09 01:45 ですねー。今のままですと確かにちょっと不便ですね。
一応、UI は使えないものの、POPFile のデータベースに履歴としてつっこんでいくことは可能だと思いますので、それを表示させて学習させるインターフェースという感じであれば汎用的にいけるかもしれません。しかし、コードが複雑になるのが難点ですね。

おお、それいいですね〜。<CAPTCHA と組み合わせ
自動的に救済されるようになれば管理する側も楽ですもんね。また考えてみます〜。

stealthinustealthinu 2009/09/09 17:27 自分のPukiWiki用のスパムフィルタでは、reCAPTCHAっていうサービス使ってます。
これだとreCAPTCHAのAPI呼ぶだけなので簡単です〜

amatubuamatubu 2009/09/09 19:19 情報ありがとうございます。
Perl にも Captcha::reCAPTCHA というモジュールがあるようなので試してみようと思います!
プラグインのような形にできると一番いいのかなと思うのですが、そのあたりの知識がまったくないので、とりあえずは汎用的なモジュール(判定させる、学習させるだけ)と、実装方法をまとめたドキュメントの提供あたりでいこうと思います。

 | 
466176