トップ «前の日記(2005-03-17 (Thu)) 最新 次の日記(2005-03-20 (Sun))» 編集   RSS 1.0 FEED  

Journal InTime


2005-03-18 (Fri) [長年日記]

_ [ソフトウェア] rast-mecab

なんてものを作ってみた。

Rastでは、N-gram(というかトークン)の切り出しをエンコーディングモジュール というものに独立させているが、この部分でMeCabによる形態素解析を 利用しているだけ。

RastとMeCabがインストールされている環境で、

$ ./configure
$ make
# make install

とすれば、インストールできる。

とりあえず、デモN-gram版より結果の件数が少ないのは1万件弱しか 登録してないから。

Rastは隣接チェックを行うので、 趣味の問題 のようなキーワードもちゃんと検索できる。 一方、隣接チェックがない検索エンジンでは 趣味 問題 のようなノイズの多い検索結果になると思う。 辞書も小さくなるし、N-gramよりもいいケースもあるかな。

N-gramの利点の一つに、顧客に 「○○という単語で検索できない」と言われた時に、「そんな文字列は もとの文書に含まれていませんから許してくださいよ」と説明できるということがある。 任意の部分文字列の検索(要はfgrep)ができるからだ。 「これは形態素解析器の辞書がですね...」という説明で納得してくれれば いいけれど、あなたの顧客はそんなに物分かりがよいですか? *1

ここでちょっと考えたのだが、基本的に形態素解析でトークンを切りだし、 未知語が表れたらその部分だけN-gramで処理するというのはどうだろうか。 大多数のケースで良好な結果を得られそうな気がする。

あと、Rastで使う時は、形態素解析器にはなるべく単語を細かく切ってほしい。 たとえば、「日本語」よりも「日本 語」の方が好ましい。 前者だと「日本語」で検索した場合はヒットするが、「日本」ではヒットしない。 一方、後者なら両方にヒットするし、隣接チェックがあれば「日本語」の検索結果 のノイズも増えない。 MeCabをこういう方向にチューニングすることができないかな。

*1  インデックス生成時に単語レベルで正規化したりすると、このメリットが 損なわれるので、曖昧検索などを実装する際はOR検索のような方向性の方が 望ましいかもしれない。 すでに、Rastでは、「tcl/tk」のように規定のN(アルファベットでは3) より短いトークン(「tk」)がある場合には、前方一致検索を行った結果を マージしているので、同様に語尾の揺れなどにも対応できそうだ。

本日のツッコミ(全2件) [ツッコミを入れる]
_ ty (2005-04-01 (Fri) 21:43)

mecabのN-bestでN=2にしたら以下のようになりました。<br>obiwan% echo '日本語' | mecab -N2<br>日本語 名詞,一般,*,*,*,*,日本語,ニホンゴ,ニホンゴ<br>EOS<br>日本 名詞,固有名詞,地域,国,*,*,日本,ニッポン,ニッポン<br>語 名詞,接尾,一般,*,*,*,語,ゴ,ゴ<br><br>もっと沢山の例で検証する必要があるとは思いますが分割数が<br>最も多いもので切り出す手がありそうです。

_ shugo (2005-04-03 (Sun) 04:41)

なるほど、そういう手がありましたか。