形態素解析ライブラリ Gomoku でマイクロブログの全文検索をはじめました。
209 views
Skip to first unread message
nakajiman
Feb 18, 2011, 2:48:15 AM2/18/11
to Google-App-Engine-Japan
こんにちは。なかじまんです。
3arrows という、いわゆる社内ツイッターを自社サービスで提供していて、AppEngine Java で
実現しています。-- 現在はαリリース
基本的には Yammer や Salesforce Chatter のクローンなのですが、OpenSocial をサポート
していて、マイクロブログと連携したアプリを開発＆追加できる特徴があります。
3arrows - Enterprise Microblogging and Applications
http://www.3arrows.jp/
そのマイクロブログの全文検索を、形態素解析ライブラリ Gomoku で実現してみましたので、
簡単に方法などをシェアします。
3arrows アップデート! 多数のご要望を受けて、
マイクロブログをキーワード検索できるようにしました!
http://socialprise-association.blogspot.com/2011/02/3arrows_18.html
=== 基本方針 ===
形態素解析ライブラリ Gomoku の存在は、次のブログで知りました。
実際に試せる環境も用意してくださっていて、コーディングしなくても、おおよその使い勝手が
把握できます。
Twitterのタイムラインを分かち書きにする - GeekFactory
http://d.hatena.ne.jp/int128/20110129/1296330196
基本的な方式は、マイクロブログへの投稿を Gomoku で形態素解析し、その形態素をエンテ
ィティのコレクションとして格納し、クエリでたたくというものです。よくあるパターンです。
=== 格納 ===
格納する形態素は、主品詞、副品詞で吟味しています。つまり、一般的に検索するだろう語の
みを格納しています。また、一部、形態素間の関係を見て、複数の形態素をひとつの語として
格納するということもしています。
また、#hashtag @username http(s)://... などは、別途、正規表現などで抜き出し、ひとつの
語として格納しています。あらかじめハッキリできる語は、別途抜き出すというハイブリット辞書
方式です。
結果、マイクロブログへの投稿は500文字上限なので、格納される語はそれほど多くなりませ
ん。数十語オーダーです。
=== 検索 ===
検索語は、だいたんにキーワードを1語に絞っています。
検索語に #hashtag @username http(s)://... が含まれるときは、そのまま完全一致でコレク
ションをマッチさせます。
それ以外のときは、検索語を Gomoku で形態素解析して、前述どおり吟味した語の内、はじ
めに出現する1語の完全一致でコレクションをマッチさせます。
=== 実用性 ===
Gomoku の Spin-up は 2,000ms 前後のようです。初期化は Warmup リクエストに含めて
いるので、うまく機能すれば、ユーザの遅延はほとんどないです。もしも間に合わないときは、
ユーザが 2,000ms の遅延を食らうことになります。
Gomoku の形態素解析は、CPU を使います。200字前後で黄色となり、400文字前後で赤
色になります。ただし、これは投稿時なので、参照に比べればずっと少ないケースなので、
今のところ問題なしと判断しています。また、検索クエリに対する形態素解析もしますが、
対象の文字数がぐっと少ないので CPU はあまり使われません。
検索の精度は、1語マッチなので疑問を持つ方も多いかと思いますが、
#hashtag @username http(s)://... で検索するときは、そもそも完全一致でよいので、ユー
ザの期待どおりです。
それ以外のときも、形態素解析の吟味後の先頭語を使うため、ヒットし過ぎるときはあります
が、入力した語から何かがヒットして、検索結果にその語が含まれているので、それほどネ
ガティブな印象は持ちにくいと今は結論付けています。
ただし AND 検索ができないので、さらなる絞り込み検索ができないのが最大の欠点です。
ですので、検索ボックスを意図的に小さくして、心理的に入力字数を抑制しています。
また、検索後は、検索ボックスの内容をクリアして、さらに検索語を追加するという流れを
意図的に切っています。
=== 結論 ===
技術的にみると、まったく使えないという判断をされそうですが、思いのほか期待どおりヒッ
トします。使っていく内に、不満が出てくるかもしれませんし、もしかすると、ユーザがコツ
を掴んで慣れてしまうかもしれません。
まだ、検索精度のチューニングの余地はありますので、何かよい方法が見つかりましたら
またシェアします。
何かの参考になれば幸いです。
# Fulltext Search がアナウンスされていましたが、日本語インデックスのサポートがどの
# くらいになるのか、少し心配＆期待大です。
3arrows という、いわゆる社内ツイッターを自社サービスで提供していて、AppEngine Java で
実現しています。-- 現在はαリリース
基本的には Yammer や Salesforce Chatter のクローンなのですが、OpenSocial をサポート
していて、マイクロブログと連携したアプリを開発＆追加できる特徴があります。
3arrows - Enterprise Microblogging and Applications
http://www.3arrows.jp/
そのマイクロブログの全文検索を、形態素解析ライブラリ Gomoku で実現してみましたので、
簡単に方法などをシェアします。
3arrows アップデート! 多数のご要望を受けて、
マイクロブログをキーワード検索できるようにしました!
http://socialprise-association.blogspot.com/2011/02/3arrows_18.html
=== 基本方針 ===
形態素解析ライブラリ Gomoku の存在は、次のブログで知りました。
実際に試せる環境も用意してくださっていて、コーディングしなくても、おおよその使い勝手が
把握できます。
Twitterのタイムラインを分かち書きにする - GeekFactory
http://d.hatena.ne.jp/int128/20110129/1296330196
基本的な方式は、マイクロブログへの投稿を Gomoku で形態素解析し、その形態素をエンテ
ィティのコレクションとして格納し、クエリでたたくというものです。よくあるパターンです。
=== 格納 ===
格納する形態素は、主品詞、副品詞で吟味しています。つまり、一般的に検索するだろう語の
みを格納しています。また、一部、形態素間の関係を見て、複数の形態素をひとつの語として
格納するということもしています。
また、#hashtag @username http(s)://... などは、別途、正規表現などで抜き出し、ひとつの
語として格納しています。あらかじめハッキリできる語は、別途抜き出すというハイブリット辞書
方式です。
結果、マイクロブログへの投稿は500文字上限なので、格納される語はそれほど多くなりませ
ん。数十語オーダーです。
=== 検索 ===
検索語は、だいたんにキーワードを1語に絞っています。
検索語に #hashtag @username http(s)://... が含まれるときは、そのまま完全一致でコレク
ションをマッチさせます。
それ以外のときは、検索語を Gomoku で形態素解析して、前述どおり吟味した語の内、はじ
めに出現する1語の完全一致でコレクションをマッチさせます。
=== 実用性 ===
Gomoku の Spin-up は 2,000ms 前後のようです。初期化は Warmup リクエストに含めて
いるので、うまく機能すれば、ユーザの遅延はほとんどないです。もしも間に合わないときは、
ユーザが 2,000ms の遅延を食らうことになります。
Gomoku の形態素解析は、CPU を使います。200字前後で黄色となり、400文字前後で赤
色になります。ただし、これは投稿時なので、参照に比べればずっと少ないケースなので、
今のところ問題なしと判断しています。また、検索クエリに対する形態素解析もしますが、
対象の文字数がぐっと少ないので CPU はあまり使われません。
検索の精度は、1語マッチなので疑問を持つ方も多いかと思いますが、
#hashtag @username http(s)://... で検索するときは、そもそも完全一致でよいので、ユー
ザの期待どおりです。
それ以外のときも、形態素解析の吟味後の先頭語を使うため、ヒットし過ぎるときはあります
が、入力した語から何かがヒットして、検索結果にその語が含まれているので、それほどネ
ガティブな印象は持ちにくいと今は結論付けています。
ただし AND 検索ができないので、さらなる絞り込み検索ができないのが最大の欠点です。
ですので、検索ボックスを意図的に小さくして、心理的に入力字数を抑制しています。
また、検索後は、検索ボックスの内容をクリアして、さらに検索語を追加するという流れを
意図的に切っています。
=== 結論 ===
技術的にみると、まったく使えないという判断をされそうですが、思いのほか期待どおりヒッ
トします。使っていく内に、不満が出てくるかもしれませんし、もしかすると、ユーザがコツ
を掴んで慣れてしまうかもしれません。
まだ、検索精度のチューニングの余地はありますので、何かよい方法が見つかりましたら
またシェアします。
何かの参考になれば幸いです。
# Fulltext Search がアナウンスされていましたが、日本語インデックスのサポートがどの
# くらいになるのか、少し心配＆期待大です。
dev3lines
Feb 18, 2011, 10:46:09 AM2/18/11
to Google-App-Engine-Japan
なかじまんさん、こんにちは。dev3linesと申します
http://twitter.com/#!/dev3lines/
GAEでの全文検索は、個人的にホットな話題ですので、
興味深く読ませて頂きました。
私も試行錯誤の上、以前GAEで全文検索を実装してみたのですが、
この場を借りて（あまり役に立たないかもしれませんが）
私もシェアさせていただきます。
=== 形態素解析エンジン ===
igo-gaeを使わせて頂いております。
https://github.com/sile/igo-gae
http://d.hatena.ne.jp/sile/20101006/1286374552
=== 格納 ===
格納する形態素は、記号、助詞、動詞、助動詞を除いています。
cron + taskqueueを使って、一定時間ごとにバックグラウンドで収集しています。
（10分ごとに収集するようにしていたのですが、翌日コンソールを見るとリソース
を使い切ってましたorz）
クロールのたびに、いったんすべてのインデックスを削除して、すべての
エントリを１から解析していくという、非効率極まりない方法をとって
いるのが原因ですが、どう差分をとるのか？データに不整合が出てしまった
場合、大掃除のタイミングは？
を考えているうちに、結局安易な手段をとってしまっています。
社内システムとして構築し、1エントリ300文字前後で、現在100エントリ
でこれですから、今後解析対象が増えていったときに必ずぶち当たる問題
なので、改善の余地があります。
何か良いアイデアがあれば、教えて頂けると嬉しいです。
=== インデックスを格納するkind ===
解析した結果を格納するkindのプロパティは2つ用意しています。
・String word ： 解析した単語を格納。
・List<String> index ：単語を含むエントリへのkeyをkeytoStringして格納
こんな感じになっています
東京都 | aglkZXYzbGluZXNy・・,ag・・・,・・・
京都 | aglkZXYzbGluZXNy・・,ag・・・,・・・
=== 検索 ===
いちおうAND検索はできます。検索時の形態素解析はしていません。
（正しくは、検索時に解析する発想がありませんでした。早速実装してみます。
ありがとうございます！）
流れは
1. 検索ワードをスペースでsplit
2．splitした単語ごとにインデックスから検索
3．マッチしたEntityからエントリへのキーを、重複を排除して配列に格納
4. 配列をまわしてエントリget
=== 所感 ===
ライブラリのおかげですが、既存のシステムに思ったよりもすんなりと実装できました。
リソース消費量をどうやって節約するかが、今後の課題です。
On 2月18日, 午後4:48, nakajiman <nakaji...@lrlab.to> wrote:
> こんにちは。なかじまんです。
>
> 3arrows という、いわゆる社内ツイッターを自社サービスで提供していて、AppEngine Java で
> 実現しています。-- 現在はαリリース
>
> 基本的には Yammer や Salesforce Chatter のクローンなのですが、OpenSocial をサポート
> していて、マイクロブログと連携したアプリを開発＆追加できる特徴があります。
>
> 3arrows - Enterprise Microblogging and Applicationshttp://www.3arrows.jp/
http://twitter.com/#!/dev3lines/
GAEでの全文検索は、個人的にホットな話題ですので、
興味深く読ませて頂きました。
私も試行錯誤の上、以前GAEで全文検索を実装してみたのですが、
この場を借りて（あまり役に立たないかもしれませんが）
私もシェアさせていただきます。
=== 形態素解析エンジン ===
igo-gaeを使わせて頂いております。
https://github.com/sile/igo-gae
http://d.hatena.ne.jp/sile/20101006/1286374552
=== 格納 ===
格納する形態素は、記号、助詞、動詞、助動詞を除いています。
cron + taskqueueを使って、一定時間ごとにバックグラウンドで収集しています。
（10分ごとに収集するようにしていたのですが、翌日コンソールを見るとリソース
を使い切ってましたorz）
クロールのたびに、いったんすべてのインデックスを削除して、すべての
エントリを１から解析していくという、非効率極まりない方法をとって
いるのが原因ですが、どう差分をとるのか？データに不整合が出てしまった
場合、大掃除のタイミングは？
を考えているうちに、結局安易な手段をとってしまっています。
社内システムとして構築し、1エントリ300文字前後で、現在100エントリ
でこれですから、今後解析対象が増えていったときに必ずぶち当たる問題
なので、改善の余地があります。
何か良いアイデアがあれば、教えて頂けると嬉しいです。
=== インデックスを格納するkind ===
解析した結果を格納するkindのプロパティは2つ用意しています。
・String word ： 解析した単語を格納。
・List<String> index ：単語を含むエントリへのkeyをkeytoStringして格納
こんな感じになっています
東京都 | aglkZXYzbGluZXNy・・,ag・・・,・・・
京都 | aglkZXYzbGluZXNy・・,ag・・・,・・・
=== 検索 ===
いちおうAND検索はできます。検索時の形態素解析はしていません。
（正しくは、検索時に解析する発想がありませんでした。早速実装してみます。
ありがとうございます！）
流れは
1. 検索ワードをスペースでsplit
2．splitした単語ごとにインデックスから検索
3．マッチしたEntityからエントリへのキーを、重複を排除して配列に格納
4. 配列をまわしてエントリget
=== 所感 ===
ライブラリのおかげですが、既存のシステムに思ったよりもすんなりと実装できました。
リソース消費量をどうやって節約するかが、今後の課題です。
On 2月18日, 午後4:48, nakajiman <nakaji...@lrlab.to> wrote:
> こんにちは。なかじまんです。
>
> 3arrows という、いわゆる社内ツイッターを自社サービスで提供していて、AppEngine Java で
> 実現しています。-- 現在はαリリース
>
> 基本的には Yammer や Salesforce Chatter のクローンなのですが、OpenSocial をサポート
> していて、マイクロブログと連携したアプリを開発＆追加できる特徴があります。
>
>
> そのマイクロブログの全文検索を、形態素解析ライブラリ Gomoku で実現してみましたので、
> 簡単に方法などをシェアします。
>
> 3arrows アップデート! 多数のご要望を受けて、
> マイクロブログをキーワード検索できるようにしました!http://socialprise-association.blogspot.com/2011/02/3arrows_18.html
> そのマイクロブログの全文検索を、形態素解析ライブラリ Gomoku で実現してみましたので、
> 簡単に方法などをシェアします。
>
> 3arrows アップデート! 多数のご要望を受けて、
>
> === 基本方針 ===
>
> 形態素解析ライブラリ Gomoku の存在は、次のブログで知りました。
> 実際に試せる環境も用意してくださっていて、コーディングしなくても、おおよその使い勝手が
> 把握できます。
>
> Twitterのタイムラインを分かち書きにする - GeekFactoryhttp://d.hatena.ne.jp/int128/20110129/1296330196
> === 基本方針 ===
>
> 形態素解析ライブラリ Gomoku の存在は、次のブログで知りました。
> 実際に試せる環境も用意してくださっていて、コーディングしなくても、おおよその使い勝手が
> 把握できます。
>
nakajiman
Feb 18, 2011, 7:06:54 PM2/18/11
to Google-App-Engine-Japan
dev3lines さん。みなさん。おはようございます。なかじまんです。
比較しやすいように補足します。
エンティティをざっくりと表現すると、次のとおりです。
・Key id : Activity ID (マイクロブログのステータスID)
・Set<String> tags : 解析した単語を格納
単語ごとの集計が必要であれば、Cron/TaskChain で実現します。
すぐに検索できること(=即時反映)が重要なので、
dev3lines さんとは、逆の格納方法になっているのかもです。
On 2月19日, 午前12:46, dev3lines <ad...@3lines.in> wrote:
> なかじまんさん、こんにちは。dev3linesと申しますhttp://twitter.com/#!/dev3lines/
比較しやすいように補足します。
エンティティをざっくりと表現すると、次のとおりです。
・Key id : Activity ID (マイクロブログのステータスID)
・Set<String> tags : 解析した単語を格納
単語ごとの集計が必要であれば、Cron/TaskChain で実現します。
すぐに検索できること(=即時反映)が重要なので、
dev3lines さんとは、逆の格納方法になっているのかもです。
On 2月19日, 午前12:46, dev3lines <ad...@3lines.in> wrote:
> なかじまんさん、こんにちは。dev3linesと申しますhttp://twitter.com/#!/dev3lines/
>
> GAEでの全文検索は、個人的にホットな話題ですので、
> 興味深く読ませて頂きました。
>
> 私も試行錯誤の上、以前GAEで全文検索を実装してみたのですが、
> この場を借りて（あまり役に立たないかもしれませんが）
> 私もシェアさせていただきます。
>
> === 形態素解析エンジン ===
>
> igo-gaeを使わせて頂いております。https://github.com/sile/igo-gaehttp://d.hatena.ne.jp/sile/20101006/1286374552
> GAEでの全文検索は、個人的にホットな話題ですので、
> 興味深く読ませて頂きました。
>
> 私も試行錯誤の上、以前GAEで全文検索を実装してみたのですが、
> この場を借りて（あまり役に立たないかもしれませんが）
> 私もシェアさせていただきます。
>
> === 形態素解析エンジン ===
>
Reply all
Reply to author
Forward
0 new messages