Support #2124

[日本語版] Mroonga Search with Chinese, Japanese, and Korean language documents

Added by Kenji Maruyama about 4 years ago. Updated about 4 years ago.

Status:ドキュメント中Start date:12/09/2013
Priority:NormalDue date:
Assignee:Kenji Maruyama% Done:

0%

Category:-
Target version:-

Description

[日本語版] Mroonga Search with Chinese, Japanese, and Korean language documents : CJK における分かち書きの説明になります。

http://redmine.groonga.org/projects/mroonga/wiki/Mroonga_Search_with_Chinese_Japanese_and_Korean_language_documents

http://redmine.groonga.org/issues/2111 を 補完する位置づけになります。英語版に翻訳される原本でもあります。

History

#1 Updated by Kouhei Sutou about 4 years ago

  • Status changed from 完了チェック待ち to ドキュメント中

N-gramと比べ優れている点として、"東京都"のようにN-gramだと"東京"と"京都"とが切りだされてそのまま転置インデックスに登録されてしまうと、 "京都"という検索キーワードに東京都を含む文章が検索結果として表示されてしまいます。

の文章がつながっていないように感じました。

形態素解析を用いれば辞書によって"東京都"を分割せず、そのまま"東京都"として転置インデックスに登録しますので、そのような検索ノイズが生じる可能性を低くします。

の文章がこなれていないように感じました。「辞書によって」が野暮ったいんですかねぇ。

切り出す精度が形態素解析辞書に依存するため、一般的には、固有名詞(専門用語)、人名,新語を沢山含むような検索対象に対して辞書を編集する必要があります。

文章がうまくつながっていないように感じます。「固有名詞(専門用語)、人名,新語を沢山含むような検索対象に対して辞書を編集する必要があります。」がピンとこないんですかねぇ。「検索対象に対して辞書を編集」という言い回しをあまり聞かないからかもしれません。

また、検索結果の完全一致が求められる場合は後に述べるN-gramをお薦めします。

ここの接続詞は「また」ではない気がします。

形態素解析に比べて、N-gramは単語ごとの意味を考慮せずに機械的にN文字ずつ分割するので、辞書を必要としない上に新語などに対しも検索の漏れも生じません。

最初の「形態素解析に比べて、」という修飾が、この文全体にあんまり寄与していない気がします。「形態素解析に比べて、N-gramは…分割する」というのがモヤっとします。「形態素解析と違って」ならモヤっとしません。(でも、その後の「辞書を…」までつなげて読むともやっと感は残ります。)

さらにMroongaにて用意されている分かち書きの他のパーサは http://mroonga.org/docs/userguide/storage.html#how-to-specify-the-parser-for-full-text-search をご覧ください。

接続詞は「さらに」じゃない気がするんですよねぇ。。。

中国語


N-gram による分かち書き

え!?N-gramにすると単語とか文節を無視するのでわかち書きじゃない気がします。。。

#2 Updated by Kazuhiko Shiozaki about 4 years ago

え!?N-gramにすると単語とか文節を無視するのでわかち書きじゃない気がします。。。

Tokenizeの訳語としての「分かち書き」だと思うのですが、やや違和感はありますよね。「トークナイズ」とか「トークン化」とかにしますか? たとえばこんな感じ:

転置インデックスの作成のために、検索対象となる文章を適切な単位で区切る必要があります。これをトークン化といいます。 単語間がスペース区切りになっている英語や韓国語では、スペースごとに単語を切り分けることでトークン化を行います。 しかし日本語や中国語では、単語間の明示的な区切りがないため、Mroongaでは形態素解析 と N-gram という二つの方法によるトークン化をサポートしています。 ここでは、形態素解析 と N-gram について簡潔に説明し、Mroongaにおける中国語、日本語、韓国語の文章に対する分かち書きの利用法を例示します。

あと、少し分かりにくかったのですが、韓国語ではスペース区切りになってもいるけれど、実際はスペースで切り分けるトークン化では不十分で、N-gramの利用(併用?)が望ましいということでしょうか?

#3 Updated by Kenji Maruyama about 4 years ago

レビューありがとうございます。出来る限り直しました。

え!?N-gramにすると単語とか文節を無視するのでわかち書きじゃない気がします。。。

形態素解析の場合、分かち書きにし、N-gramの場合トークン化にしてみました。う〜ん、日本語に訳すのが難しい。。。

あと、少し分かりにくかったのですが、韓国語ではスペース区切りになってもいるけれど、実際はスペースで切り分けるトークン化では不十分で、N-gramの利用(併用?)が望ましいということでしょうか?

いいえ。必要ないと思います。韓国語のトークン化の話を削除しました。 韓国語のN-gramの利用例は、多分Mroongaでは韓国語をN-gramにかけて検索してみたことがないと思ったので、試しにやってみたものです。特に問題ないようでした。

最初韓国語は分かち書きされていないと思い、例文を韓国語ご存知の翻訳者に訳してもらいました。 で、その結果分かち書きされていました。

韓国のニュースサイトをみると、分かち書きされていることがわかりました。 分かち書きされていないというのは、漢字ハングル混じりの時代だったようです。

今の文章は表音文字のハングルのみになり、分かち書きしないと文章の意味を把握することが困難になるので、分かち書きするのが一般的のようです。

#4 Updated by Kenji Maruyama about 4 years ago

  • Status changed from ドキュメント中 to 完了チェック待ち

#5 Updated by Susumu Yata about 4 years ago

Chinese, Japanese, Korean ともに○○語という意味があるので, language は不要です. 具体的には, Fulltext search for CJK documents とでもすればスッキリすると思います.

それから,この文書の位置付けをハッキリさせた方がいいです. どういう人を対象と考えているのかによって,どこからどこまで説明するのかが変わります. たとえば,全文検索に転置インデックスを使うことは知っているという前提で説明するかどうかによって,書くべき内容は変わります.

細かい話ですが,「文書」と「文章」はどちらかに統一した方がいいです. FAQ では「文書」が使われているので,「文書」に統一でいいんじゃないかと思います.

分かち書きとトークン化が混じっています.

ちなみに, Groonga のドキュメントでは「トークナイズ」が使われているようです.

形態素解析のところで突然 2-gram の説明を始めちゃってますが,こういうのは混乱を招くので避けるべきです.

「新語などに対しも」は typo でしょう.

「N に比例してインデックスのサイズが大きくなってしまう」と書かれていますが,比例ではありません. 最悪で N 乗となります.

「以下、日本語については…、中国語については…」と説明するのであれば,日本語,中国語の順に例を挙げるべきです. CJK という順序にこだわるのであれば,説明の順序を逆にすべきです.

「利用例をを挙げます」は typo でしょう.

「結果は以下のようになります」の後で,どこに着目すれば良いのか説明しましょう.

一部 Mecab になっていますが, MeCab に統一しましょう.

#6 Updated by Kouhei Sutou about 4 years ago

  • Status changed from 完了チェック待ち to ドキュメント中

#7 Updated by Kenji Maruyama about 4 years ago

Chinese, Japanese, Korean ともに○○語という意味があるので, language は不要です. 具体的には, Fulltext search for CJK documents とでもすればスッキリすると思います.

直しました。wikiリンク先に変わりました: http://redmine.groonga.org/projects/mroonga/wiki/Mroonga_Fulltext_search_for_CJK_documents_%28jp%29_

それから,この文書の位置付けをハッキリさせた方がいいです. どういう人を対象と考えているのかによって,どこからどこまで説明するのかが変わります. たとえば,全文検索に転置インデックスを使うことは知っているという前提で説明するかどうかによって,書くべき内容は変わります.

転置インデックスの簡単な説明を入れました。詳細はGroongaのドキュメント http://groonga.org/ja/docs/tutorial/introduction.html#create-a-lexicon-table-for-full-text-search に飛ばした方が良いと思い、省きました。

細かい話ですが,「文書」と「文章」はどちらかに統一した方がいいです. FAQ では「文書」が使われているので,「文書」に統一でいいんじゃないかと思います.

文書に統一しました。

分かち書きとトークン化が混じっています.

Groongaのドキュメントに従ってトークナイズにしました。

形態素解析のところで突然 2-gram の説明を始めちゃってますが,こういうのは混乱を招くので避けるべきです.

説明をいれました。

「新語などに対しも」は typo でしょう.

直しました。

「N に比例してインデックスのサイズが大きくなってしまう」と書かれていますが,比例ではありません. 最悪で N 乗となります.

はい。Nに関係ない文書サイズとインデックスサイズのグラフをみながらとんだボケをかましました。

「以下、日本語については…、中国語については…」と説明するのであれば,日本語,中国語の順に例を挙げるべきです. CJK という順序にこだわるのであれば,説明の順序を逆にすべきです.

順序逆にしました。

「利用例をを挙げます」は typo でしょう.

恥ず。。。直しました。

「結果は以下のようになります」の後で,どこに着目すれば良いのか説明しましょう.

説明をいれました。ただ、「クエリのマッチしたトークンの中で重みが大きい上位3個のトークンを取り出します。ここの"3"は"マッチしたトークン数 / 1 + 1"によって求められます。」のところの "マッチしたトークン数 / 1"の分母1は http://redmine.groonga.org/projects/mroonga/wiki/Search_and_Scoring_in_Mroonga_%28jp%29_ では説明していなかった(そこでは8となっていて、いかなる場合も8のままと思っていましたが)のですが、ここでは複数の概算値の最小でないとつじつまがあわない、再度要確認です。

一部 Mecab になっていますが, MeCab に統一しましょう.

直しました。ただ、select mroonga_command("tokenize TokenMecab '明日の東京都の天気は晴れでしょう'") の中の TokenMecab のMecab は現状の仕様なので、公式表記に従うならソースコードの方でMeCabに直した方がよいかもしれませんが、Mecabとした方がタイプしやすい。。。

#8 Updated by Kenji Maruyama about 4 years ago

  • Status changed from ドキュメント中 to 完了チェック待ち

説明をいれました。ただ、「クエリのマッチしたトークンの中で重みが大きい上位3個のトークンを取り出します。ここの"3"は"マッチしたトークン数 / 1 + 1"によって求められます。」のところの "マッチしたトークン数 / 1"の分母1は http://redmine.groonga.org/projects/mroonga/wiki/Search_and_Scoring_in_Mroonga_%28jp%29_ では説明していなかった(そこでは8となっていて、いかなる場合も8のままと思っていましたが)のですが、ここでは複数の概算値の最小でないとつじつまがあわない、再度要確認です。

再度要確認以外完了チェック待ちです。

#9 Updated by Kenji Maruyama about 4 years ago

再度要確認以外完了チェック待ちです。

ソースコードを確認したところ、Groonga lib/ii.cの grn_ii_similar_search をみると、以下になっています。 "マッチしたトークン数 / 1"の分母1は 下記 pos & 1 のビットAND演算で0にならなければ分母1となるようなので、いかなる場合も8のまま固定値ではないですね。

5649       if ((es = grn_ii_estimate_size(ctx, ii, *tp))) {
5650         *w1 += max_size / es;

4364 uint32_t
4365 grn_ii_estimate_size(grn_ctx *ctx, grn_ii *ii, grn_id tid)
4366 {
4367   uint32_t res, pos, *a;
4368   a = array_at(ctx, ii, tid);
4369   if (!a) { return 0; }
4370   if ((pos = a[0])) {
4371     if (pos & 1) {
4372       res = 1;
4373     } else {
4374       buffer *buf;
4375       uint32_t pseg;
4376       buffer_term *bt;
4377       if ((pseg = buffer_open(ctx, ii, pos, &bt, &buf)) == NOT_ASSIGNED) {
4378         res = 0;
4379       } else {
4380         res = a[1] + bt->size_in_buffer + 2;
4381         buffer_close(ctx, ii, pseg);
4382       }
4383     }
4384   } else {
4385     res = 0;
4386   }
4387   array_unref(ii, tid);
4388   return res;
4389 }

#11 Updated by Kouhei Sutou about 4 years ago

  • Status changed from 完了チェック待ち to ドキュメント中

IN BOOLEAN MODEを使うのがよいと思いました!

理由は、IN BOOLEAN MODEの方がよく使う使い方だということと、CJKとは関係ないIN NATURAL LANGUAGE MODEの説明を省けるからです。このドキュメントはCJKに関するドキュメントだと思うので、それに関係あることだけを説明できたほうがわかりやすいと思います!

あと、「トークナイズのパーサー」の参照先を作ったほうがよいと思いました。今は、ストレージモードのドキュメントの中にありますけど、これはモードに関係がないことなので別ドキュメントになっている方がよいと思います。場所は、 リファレンス の下が適切でしょうか。

N-gramの一つである2文字ずつトークナイズする2-gramでは、"東京都"は"東京"と"京都"とにトークナイズされてしまいますが、 形態素解析を用いれば上記の形態素解析の結果でわかるように"東京都"は"東京"と"都"にトークナイズするので検索ノイズが生じる可能性が低くなります。

「検索ノイズが生じる可能性が低くなる」ことの説明が不十分だと思いました。"東京"と"都"に分割するとなぜ低くなるのかが書かれていないこと、および、「検索ノイズ」とは何かについて説明していないことが原因だと思います。

N-gramと形態素解析器での違いはMroongaではなくGroongaのドキュメントにした方がよいのかもしれませんねぇ。パーサーの指定方法はMroongaに依存した話なのでMroongaのドキュメントにあるのが適切だと思いますが、パーサーの違いはMroongaに依存した話ではないのでGroongaの方が適切だと思いました。で、Mroongaの方では概要を説明するにとどめて詳細はGroongaの方を読んでね、とリンクを張るとか。

#12 Updated by Kenji Maruyama about 4 years ago

レビューありがとうございます。

IN BOOLEAN MODEを使うのがよいと思いました!
理由は、IN BOOLEAN MODEの方がよく使う使い方だということと、CJKとは関係ないIN NATURAL LANGUAGE MODEの説明を省けるからです。このドキュメントはCJKに関するドキュメントだと思うので、それに関係あることだけを説明できたほうがわかりやすいと思います!

了解です。IN BOOLEAN MODEの方がよく使う使い方ということであればそちらのサンプルを用いて説明したほうが良さそうですね。

あと、「トークナイズのパーサー」の参照先を作ったほうがよいと思いました。今は、ストレージモードのドキュメントの中にありますけど、これはモードに関係がないことなので別ドキュメントになっている方がよいと思います。場所は、 リファレンス の下が適切でしょうか。

はい。トークナイズのパーサーのドキュメントをリファレンスの下にして、参照する形にした方が親切だと思います。

「検索ノイズが生じる可能性が低くなる」ことの説明が不十分だと思いました。"東京"と"都"に分割するとなぜ低くなるのかが書かれていないこと、および、「検索ノイズ」とは何かについて説明していないことが原因だと思います。

説明追加します。

N-gramと形態素解析器での違いはMroongaではなくGroongaのドキュメントにした方がよいのかもしれませんねぇ。パーサーの指定方法はMroongaに依存した話なのでMroongaのドキュメントにあるのが適切だと思いますが、パーサーの違いはMroongaに依存した話ではないのでGroongaの方が適切だと思いました。で、Mroongaの方では概要を説明するにとどめて詳細はGroongaの方を読んでね、とリンクを張るとか。

はい。N-gramと形態素解析器の使い方の詳細説明はGroongaドキュメント (http://groonga.org/docs/spec/search.html ) にありますが、違いの一般的な説明もGroongaドキュメントにもあった方が親切だと思いました。(Mroongaを使う方はこの一般的な違いを説明する必要あるかどうか迷いました。というのは、Mroongaを使う人はGroongaを知っている前提で使うべきなのか、それとも、Groongaについてあまり知らなくともMySQLの全文検索の使い方については知っている+Mroonga独自の機能を知っているだけで使えるようにしたいのか、ターゲットユーザにどこまで知っていて欲しいのかで書くことがかなり違うと思いますので。)

Mroongaの方では違いの概要を説明するにとどめて詳細はGroongaの方を読んでね、とリンクを張る ということにしたいと思います。

Also available in: Atom PDF