Kuromoji on @johtaniの日記 3rd

Azure Cognitive Searchでの日本語向けAnalyzerの違い

Tue, 09 Jun 2020 17:44:00 +0900

Azure Cognitive Searchで日本語を扱うときに、形態素解析器を使いたい場合、2種類のAnalyzerが用意されています。今回はこれらの違いがどんなものかを見ていくことにします。

Analyzerとは?

まずは、その前にAnalyzerとは何者か?というのを少しだけ。 Azure Cognitive Searchは転置インデックスを内部で作成して、検索を行っています。この、転置インデックスは、「単語」がどのドキュメントに入っているか?を素早く見つけることができるデータ構造となっています。

Azure Cognitive Searchは、この「単語」を入力された文章から生成するときに、Analyzerというものを利用します。 Analyzerは入力された文章をある規則に則って単語に分割する機能です。この「ある規則」が、各種言語や用途によって様々に用意されています。今回はこの中のja.luceneとja.microsoftという2種類のAnalyzerについて違いを見ていきます。

2種類のAnalyzerの違いはどんなもの?

このAnalyzerの挙動を見るためのエンドポイントとしてanalyzeというAPIがあります(詳細は昔のブログを参照)。

このAPIを利用して、Wikipediaのいくつかの文章を単語に区切って見て、 ja.microsoftがどんな動きをしているのか想像してみます(残念ながらja.microsoftの仕様?や挙動についてはページが見つからないため)。

もとの文章と解析結果(一部抜粋)

文章は、手元のElasticsearchに登録したjawikiのデータからランダムに抽出しています。また、自前のツールで生成したWikipediaのデータなので、まだ一部、見苦しい文字列になっています(そっちもなおさないと)。

1. 砂川（熊本県）

thumb|250px|right|上砂川橋より上流方砂川（すながわ）は、熊本県宇城市・八代郡氷川町を流れる二級河川。

この文字列から抽出された単語で特徴的なものを一部抜粋しました。

`ja.microsoft`	`ja.lucene`
250px	250
	px
上砂	上, 上砂川
川橋	砂川
	橋
宇城	宇
市	城市
二級	二
^	級

まず、最初の250pxですが、ja.microsoftでは、pxが単位であると判定しているのか、数値と合わせた単語として抽出されています。この場合、250で検索しても、この文字列はヒットしない形になるので、ノイズが減ることが考えられるかと。

上砂川橋という文字は、分割の仕方が別れました。 ja.luceneでは、上砂川という単語が地名として辞書に存在するために、このような分割になっています。ja.microsoftのデータは品詞の情報が取れないのですが、上砂、川橋ともに、名詞として辞書に存在しているのではないかなと。ja.luceneには川橋という単語は存在していないようでした。

宇城市(うきし)については、2005年に合併でできた市のようで、ja.luceneが利用している辞書には存在しない可能性があり、宇城という文字が抽出できてないと思われます。

最後は二級です。ja.luceneでは、数字と助数詞として分割されています。こちらも何かしらのロジックにより、二級という1単語でヒットできるように数字と単位?が合わせた単語で出てくる仕組みがja.microsoftなのかなと。

2. UEFA U-18女子選手権2000

UEFA U-18女子選手権2000は第3回目のUEFA U-18女子選手権である。決勝トーナメントは2000年7月27日から8月4日までフランスで行われ、ドイツが初優勝を果たした。

この文字列から抽出された単語で特徴的なものを一部抜粋しました。

`ja.microsoft`	`ja.lucene`
u-18, u	u
18, nn18	18
第3回目	第
	3
	回
	目
トーナメント, トナメント	トーナメント
2000年	2000
	年
7月	7
	月
27日	27
	日

数字を含む単語第3回目や2000年、7月などは、ja.microsoftは先程と同様、数字と単位の組み合わせを1単語として出力しています。

また、トーナメントという単語をトナメントという形で、長音を除去した形で出力しています。今回の文字列ではないですが、この他に、センターをセンターとセンタの2パターンの単語で出力するといったことを行っています。 ja.luceneの場合、単語の最後に長音がある場合だけセンタとして、長音を除去した単語が出力されます。これは、長音の表記ゆれに対応するためではないかなと。たとえば、インターフェースとインタフェース、インターフェイスのように、人や文章によって、間にでてくる長音を使ったり使わなかったりという表記ゆれに対応するためだと思われます。その他にも、イプロゥヴェトをイプロゥベトに、ネクストをネキストに、バラエティをバラエチにも変換するなどといった処理をしてくれるようです。カタカナの表記ゆれには強そうですね(これどうやってるんだろう?)。

ja.microsoftでは、nn18というちょっと変わった単語も出てきていました。純粋な数字の場合はnnと入力してくれるようで、数字だけで検索したい場合に利用できるのかな?これはドキュメントに書いておいてほしいかも?

共通点

ja.lucene、ja.microsoftともに、共通している動作として、「てにをは」といった単語は除去されていました。違いがあるものとしては、「より」(助詞-格助詞-一般)、「されている」(動詞-自立、動詞-接尾、助詞-接続助詞、動詞-非自立)、「ある」(助動詞)といったものはja.microsoftでは除去されずに出てきていました。ストップワード的に「てにをは」あたりを除去をしている感じでしょうか?

アルファベットで構成されている単語についても、基本はそのまま出力される挙動のようでした。

じゃあどっちがいいの?

残念ながらどちらがいいかは、一長一短かなぁと。 ja.luceneに関しては、Luceneの仕組みを利用しているので、Elasticsearchなどを使えば、個別の単語についてより詳細の情報を取得することが可能です(品詞、読みなど)。ja.microsoftについては、残念ながら手の入れようがないので、そういう動きのものだという割り切った使い方になるでしょうか? ただ、長音の除去による表記ゆれなどについては、便利な機能なので、そのあたりの問題に対応したい場合は、ja.microsoftを活用するのも良いかと思います。

個人的には、より細かい単語としてインデックスに登録できるもののほうが、柔軟な検索には対応できるのではないかなぁと考えています(Kuromojiの辞書をUniDicにするとか?も考えますが、これはAzure Searchではできないですが)。

まとめ

Wikipediaのデータをいくつか使って、ja.microsoftとja.luceneの違いについて、考察してみました。何かの役に立てばと。他に、これはどんな感じになるの?などありましたら、コメントいただければと。

Elasticsearch 0.90.8がリリースされました＆注意点（2013/12/20追記）

Fri, 20 Dec 2013 16:24:00 +0900

昨夜、Elasticsearchの0.90.8がリリースされました。

リリースされた内容などについては、本家のブログ「0.90.8 released」をご覧いただくこととして。 1点注意したほうが良い点があります。

elasticsearch-analysis-kuromojiを利用している場合は、0.90.8に対応したバージョンがリリースされるのを待つ必要があります。

elasticsearch 0.90.8はLuceneのバージョンが4.6.0に変更されています。 Lucene 4.6.0では、TokenStreamというTokenizerのI/Fに変更があり、Tokenizerの実装を変更する必要があります。

現時点（2013年12月19日現在）のelasticsearch-analysis-kuromojiの1.6.0にはlucene-analyzers-kuromoji-4.5.1.jarが含まれており、この部分でI/Fが異なるためエラーが発生してしまいます。プラグインをインストールする時点ではエラーは発生せず、実際にKuromojiのTokenizerやAnalyzerを利用するタイミングでエラーが出ます。以下、0.90.8にanalysis-kuromojiの1.6.0をインストールした状態で_analyzeを実行した時のエラー。

curl -XPOST 'localhost:9200/_analyze?tokenizer=kuromoji_tokenizer&filters=kuromoji_baseform&pretty' -d '寿司が美味しかった'
{
  "error" : "IllegalStateException[TokenStream contract violation: reset()/close() call missing, reset() called multiple times, or subclass does not call super.reset(). Please see Javadocs of TokenStream class for more information about the correct consuming workflow.]",
  "status" : 500
}

ということで、1.7.0がリリースされるのを待つか、自分でmvn packageしてビルドする必要があります。他にも独自でTokenizerなどを造られている方は注意が必要かと。

たぶん、すぐにリリースされるんじゃないかなぁと。

2013/12/20追記

とりあえず、masterブランチが0.90.8に変更されたみたいです。(と書いてるそばから、1.7.0がリリースされました) ということで、0.90.8では1.7.0を使うとエラーが出ないです。（あと、踊り字対応のcharfilterも追加されたみたいです）

日本語Wikipediaをインデクシング（Kuromojiバージョン）

Tue, 03 Sep 2013 01:15:00 +0900

前々回紹介した、日本語Wikipediaのデータをインデックス登録する記事の続きです。

今回は、Kuromojiのアナライザを利用してインデックス登録してみます。

余談（Proxy環境でのプラグインインストール）

ElasticSearchのpluginコマンドはJavaで実装されています。（org.elasticsearch.plugins.PluginManager）プラグインのダウンロードには、java.net.URL.openConnection()から取得URLConnectionを使用しています。

ですので、pluginのインストールを行う際に、Proxy環境にある場合は以下のようにコマンドを実行します。

./bin/plugin -DproxyPort=ポート番号 -DproxyHost=ホスト名 -i elasticsearch/elasticsearch-analysis-kuromoji/1.5.0

elasticsearch-analysis-kuromojiのインストール

WikipediaのデータをKuromojiを使って、形態素解析ベースの転置インデックスを作成していきます。まずは、Kuromojiを利用するために、Analysisプラグインのインストールです。 ElasticSearchのバージョンに対応したプラグインのバージョンがあります。（プラグインのページに対応したバージョンの記載あり）今回はElasticSearchの0.90.3を利用しているため、1.5.0をインストールします。

./bin/plugin -i elasticsearch/elasticsearch-analysis-kuromoji/1.5.0

インストール後は再起動しておきます。なお、Kuromojiを利用して、Wikipediaのデータを登録するばあい、デフォルトの設定では、ヒープが足りなくなるおそれがあります。 ElasticSearchの起動時に以下のオプションを指定して、最大ヒープサイズを2Gとしておきます。

export ES_HEAP_SIZE=2g;./bin/elasticsearch

Indexの作成（デフォルトでKuromojiのAnalyzerを利用する）

Wikipediaのデータを登録する際に、Kuromojiのアナライザを利用したいのが今回の趣旨でした。一番ラクな方法として、Wikipediaデータのインデックスの設定として、デフォルトのアナライザをKuromojiにしてしまいます。（きちんと設計する場合は、必要に応じてフィールドごとに指定しましょう）

curl -XPUT 'localhost:9200/ja-wikipedia-kuromoji' -d '{
    "settings": {
        "analysis": {
            "analyzer": {
                "default" : {
                    "type" : "kuromoji"
                }
            }
        }
    }
}'

これでkuromojiのアナライザがデフォルトで利用される形となります。あとは、Riverを起動して登録するだけです。

Riverの実行

前回と一緒です。インデックス名（_river/<インデックス名>/_meta）だけは、先ほど作成した「ja-wikipedia-kuromoji」に変更してください。

curl -XPUT localhost:9200/_river/ja-wikipedia-kuromoji/_meta -d '
{
    "type" : "wikipedia",
    "wikipedia" : {
        "url" : "file:/home/johtani/src/jawiki-latest-pages-articles.xml"
    },
    "index" : {
        "bulk_size" : 10000
    }
}'

あとは、インデックスされるのを待つだけです。

データ量とか

5.8gbになりました。Kuromojiを利用したため、形態素解析により単語にきちんとトークないずされた結果でしょう。 Uni-gramだと、転置インデックスのボキャブラリも単語に対してヒットするドキュメント数も大きくなるため、インデックスサイズも大きくなっているのかと。

検索クエリのサンプルなどはまた後日。（夜遅いので。。。）