morit****@razil*****
morit****@razil*****
2014年 9月 9日 (火) 12:42:40 JST
森と申します。 そうですね。 scorerが評価されるときにはすでに全文検索を行う過程で得た値は消えてしまっているので、 できることに限りがあります。 grn_iiの中で処理した方が現実的だと思います。 おかげさまでgrn_ii_estimate_size()のバグも直ったので、 TF・IDFまではそれほど苦労せずに改造できると思います。 BM25については文書長を取ってこないといけないのですが、 現状ではそれを高速に取得する手段がないところが問題になります。 文書テーブルの方にトークナイズ後の文書データを格納できるカラムを作って、 文書毎の長さ・特徴量・スニペット等を高速に取り出せるようにしたいと ずっと考えていたのですが実装できていません。 とりあえずは文書長のみを数値カラムに記録するだけで良いのかもしれません。 文書長ファクタに該当する数値カラムを指定できる仕組みまで実装していれば、 あとは文書を格納するときに一工夫すればBM25まで持って行けるのではないかと思います。 以上参考になれば幸いです。 独自パッチ、もしよろしければフィードバックいただければ更に幸いです！ よろしくお願いします。 2014-09-08 12:40 GMT+09:00 Naoya Murakami <visio****@gmail*****>: > 村上と申します。 > > 現在、Groongaでは、クエリごとにマッチする出現数をカウントアップ > させるスコアリング方式をとっていると思います。 > > これは高速であるものの、クエリごとの重要度は考慮されません。 > どの文書にもたくさん含まれているクエリと、どの文書にもあまり > 現れないクエリが同じ重みでカウントアップされます。 > > こうすると、頻出用語の方のカウントが高くなりすぎて、重要語句が > 含まれるレコードの順位がかなり下の方に埋もれることになります。 > > 重みをあらかじめ計算しておけば、クエリ関数でクエリごとの重みを > 変更したり、adjusterで調整することもできますが、組み立てが大変 > でちょっと容易ではありません。 > > scorerで調整しようものの、scorerでいじれるものは、複数のクエリ > が合算されたスコア値のみで、クエリごとのTFがいくつだったのかは > 知ることができません（ですよね？）。 > > scorerの段階で、クエリごと(もしくはトークンごと)のTF値とDF値(概算 > でも良い)と望ましくは文書長(ドキュメントに含まれるトークン数)が > 取れると、ランキングにTF・IDFや文書長正規化が行えて嬉しいです。 > > SQLiteのFTSではmatchinfoという関数を利用することにより簡単に > スコアリングを調整することができるようです。 > > http://www.sqlite.org/fts3.html#matchinfo > > たとえば、以下のように、簡単にBM25(TF・IDFに文書長正規化を考慮 > させたようなもの)の関数を実装することもできるみたいです。 > > https://github.com/rads/sqlite-okapi-bm25/blob/master/okapi_bm25.c > > 速度的なデメリットもあるでしょうし、将来的な話で全然いいのですが、 > 今後の開発で考慮していただけると嬉しいです。 > （すでに考慮はされているものの、開発者の中で欲しい人がいないので > 実装されないのかもしれませんが。。） > > とりあえずは、色々取れる情報が少なくて適当な感じですが、grn_ii_select > を独自でパッチして対応してみようと思っています。 > > 以上です。 > _______________________________________________ > groonga-dev mailing list > groon****@lists***** > http://lists.sourceforge.jp/mailman/listinfo/groonga-dev >
