Naoya Murakami
visio****@gmail*****
2014年 9月 10日 (水) 12:44:24 JST
村上です。 色々ありがとうございます！非常に参考になります！ 文書長の方は今の私が理解できている範囲では、ちょっと簡単にほげ るのは難しそうで、今回は、TF・IDFとトークン数が多すぎるのをキャップ させるぐらいで逃げようかなぁと思っていました。 ii.cの中で完結できそうなら、少量の改造でいけるかもしれませんね。 全文インデックスに保存する方向でいい感じにできないか少し検討したい と思います。 （ただ、検討しても今の私の手には負えない可能性も高い気もしますが。。） もし、いい感じに拡張できそうな案が思いついたら、相談させていただきます！ ありがとうございます！ 2014年9月10日 11:54 <morit****@razil*****>: > 森と申します。 > > BM25の実装についてですがii.cの改造だけで済むかもしれません。 > > groongaの全文検索インデックスには、文書ID, セクション番号, TF, ポスティング情報の他に、 > トークンと文書の組み合わせ毎に重み情報を格納することができます。 > (索引を作るときにWITH_WEIGHTオプションを指定することで有効になります。) > ここにBM25の文書長等のファクタを保存してはどうかと思いました。 > 整数値なので工夫が必要ですし、ii.c内部のスコア計算ルーチンに手を入れる必要はあると思いますが、 > 改造箇所は少なくて済みそうです。 > > また、現状では重み情報はgrn_ii_updspecという構造体を通して受け渡されるのですが、 > tokenizer pluginから重みの値を引き継げるようにすれば、 > pluginでスコアリング方式を柔軟に拡張する道が広がりそうです。 > > > > > 2014-09-09 12:42 GMT+09:00 <morit****@razil*****>: > > > 森と申します。 > > > > そうですね。 > > 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 > >> > > > > > _______________________________________________ > groonga-dev mailing list > groon****@lists***** > http://lists.sourceforge.jp/mailman/listinfo/groonga-dev >
