Naoya Murakami
visio****@gmail*****
2013年 8月 5日 (月) 18:24:33 JST
groongaのトークナイザの改善について お世話になっております。村上と申します。 groonga3.06、mroonga3.06をMYISAMのラッパーモードで利用しています。 現在、以下を参照すると、TokenBigram、TokenTrigram等では、連続した アルファベット・連続した数字・連続した記号はそれぞれ1つの トークンとして扱うという仕様になっていると思います。 http://mroonga.org/ja/docs/userguide/storage.html また、以下を参照すると、1つのトークンの最大サイズは、4Kbyteという仕様が あると思います。 http://mroonga.org/ja/docs/reference/limitations.html#limitations-of-table そこで、4Kbyte以上になるほどアルファベットが連続する文書をトークナイズする ためには、TokenBigramSplitSymbolAlpha等を選択する必要があります。 しかしながら、TokenBigramSplitSymbolAlphaを利用すると、 漏れが減る変わりに、トークン数が増えることで検索性能が劣化します。 トレードオフの関係にあるので、仕方がないかもしれませんが、 英語のみの文章である場合であっても、アルファベット単位で バイグラムされることとなり、トークン数が増え、文章が増えるに したがって、検索性能が大きく劣化します。 行数15万、MYDが10GB程度の英文のみのテーブルで、トークナイザ の違いによって、countに以下の性能差がでます。 ・TokenBigramSplitSymbolAlphaDigit +----------+ | count(*) | +----------+ | 76206 | +----------+ 1 row in set (4.08 sec) ・TokenBigram +----------+ | count(*) | +----------+ | 76097 | +----------+ 1 row in set (0.14 sec) ※mysql5.5.14にてブール検索を実行。 TokenBigramの方は、カラムを1個増やしているため、完全にトークナイザの違いだけの 比較となっていませんが、おそらくトークナイザの違いによるものと考えています。 このテーブルでは、TokenBigramでも問題ありませんでしたが、非常に長い記号列(遺伝子配列等) が含まれている英語のみのテーブルが存在します。 日本語の場合、漏れのないという観点の利点がありますが、英語のみのテーブルで、 TokenBigramSplitSymbolAlphaDigitを使うのは、性能の観点からもったいない気がしています。 <質問> (1)TokenBigram、TokenTrigram等において、4Kbyteの制限以上となる長い記号列が出現した場合に 無視または所定の文字数でカットするようトークナイザに実装していただくのは可能でしょうか? これにより、長い記号列が出現する文章であっても、原則、空白区切りでトークナイズできるため、 英語文書での飛躍的な性能向上につながり、非常にうれしいです。 (2)これは、願望なのですが、英文を空白区切りでトークナイズした場合、トークン数が 減る一方、複数系等のゆらぎ(These are cars.は、TokenBigramSplitSymbolAlphaの場合、 carsで検索しないとヒットしない。)に対応できなくなると思います。 空白区切りでトークナイズしても複数系や活用形が原型で検索できるよう、ゆらぎを 原型にするトークナイザがあると素敵だなと考えました。 Apache Luceneは、以下のようなフィルタがあるようですが、 今後、groongaでこのあたりの機能の実装の展開の予定はないですか? http://www.mwsoft.jp/programming/lucene/lucene_filter.html http://www.mwsoft.jp/programming/hadoop/mapreduce_with_lucene_filter.html (3)トークナイザを自作するのは以下のチケットの通り、今も難しいままでしょうか? http://redmine.groonga.org/issues/1257 以上、よろしくお願いします。