2017.12.15 Friday
スポンサーサイト
一定期間更新がないため広告を表示しています
| スポンサードリンク | - | | - | - |
関口宏司のLuceneブログOSS検索ライブラリのLuceneおよびそのサブプロジェクト(Solr/Tika/Mahoutなど)について
2008.01.26 Saturday
Lucene 2.3のリリース
昨日Lucene 2.3が公開された:
http://lucene.apache.org/java/2_3_0/ 主な新機能は次があげられている:
具体的な内容は、次のようにこのブログでほとんど紹介している。 >* significantly improved indexing performance >* segment merging in background threads >* pluggable MergePolicy & MergeScheduler 現trunkでより速くなったLuceneのインデクシング処理 http://lucene.jugem.jp/?eid=142 なお、MergePolicyはセグメントのマージ方針、MergeSchedulerはマージのタイミングを決定するクラスであり、Lucene 2.3からIndexWriterから分離されたものである。これによりセグメントのマージ処理が"pluggable"となった。 そしてMergeSchedulerの実装クラスとしてConcurrentMergeSchedulerがデフォルトのMergeSchedulerとして提供された。このMergeSchedulerはマージを実行するバックグラウンドのスレッドが新たに生成されてそのスレッドでマージを実行することでadd()などのレスポンスを改善するのに役立つ。MergeSchedulerにはこれまでの互換としてSerialMergeSchedulerも提供されており、こちらはスレッドを起こさずにマージが行われる。 MergePolicyには現在LogMergePolicyという抽象クラスが提供されており、その具象クラスとしてLogByteSizeMergePolicyとLogDocMergePolicyがある。名前の"Log"の意味するところは、Loggingとかではなく対数関数のLogである。セグメントのマージはLucene 2.2までであればセグメント内のドキュメント数がマージのタイミングとして参照されており、そのタイミングはデフォルト(mergeFactor=10)で10個、100個、1000個、・・・という具合に指数的に増加する。よってポリシーとしてはそのタイミングを知るためにLogを計算する、ということである(より具体的には、LogMergePolicyのfindMerges()メソッドの実装を参照すると、Math.log()が使われていることがわかるだろう)。 Lucene 2.3ではドキュメント数ではなくセグメントのサイズを基準にマージを行うようになっており、LogByteSizeMergePolicyがデフォルトで指定されている。 >* refreshable IndexReaders IndexReader.reopen() http://lucene.jugem.jp/?eid=164 >* faster StandardAnalyzer and improved Token API Tokenの再利用で性能向上 http://lucene.jugem.jp/?eid=167 >* CheckIndex tool to test & recover a corrupt index インデックスの診断・修復ツールの登場 http://lucene.jugem.jp/?eid=148 >* "partial" optimize(int maxNumSegments) method optimize( maxNumSegments ) http://lucene.jugem.jp/?eid=168 その他の機能についても、このブログで順次取り上げていく予定だ。 2008.01.18 Friday
類義語検索のデモ公開
類義語検索のデモを公開した:
http://www.rondhuit-demo.com/syndemo/search/index 「松下電器」で「パナソニック」を含む文書がヒットしたりする。 類義語検索というと、商用検索エンジンでは類義語データを辞書メーカーから買って使ったりしているようだ(そうでないものもあるかもしれない)。 弊社のソリューションは、類義語辞書はお客さんに自分で用意してもらう、というものである。そしてこれで十分間に合っている。というのも、アプリケーションがサービスしているコンテンツやそのサイトの性格によって必要な類義語リストはかなり偏ると考えられるからだ。一般的な類義語定義(たとえば、「首相」と「内閣総理大臣」など)がぜひとも必要だ、というのはあまり聞かない。それよりも、そのアプリケーションで頻繁に検索される言葉の類義語定義の充実がはるかに重要である。そのため、結局のところ一般的な類義語データを持っていたとしても、それ以外にそのサイト固有のことばとその類義語をユーザ辞書として持つことになる。 このユーザ辞書にはイニシャルで数十〜数百も定義すれば類義語が思いつかなくなる。あとは運用を継続していく中で必要に応じて徐々に類義語リストを充実していけばよい。これでたいていは問題ない。 このデモはリンクをクリックするだけで検索ができるようになっているので、一度やってみていただきたい。そのとき、スコアにも注目して欲しい。このデモでは、類義語でヒットさせるだけでなく、オリジナルの検索語を尊重したスコア計算を行っている。たとえば、「松下電器」で検索した場合に「パナソニック」を含む文書も検索できるが、「パナソニック」を含む文書よりも「松下電器」を含む文書のスコアを高くして上位表示する、ということを行っている。 2008.01.14 Monday
FAST, Autonomyとならび、Luceneが2008年のTier 1の仲間入りに
Enterprise Searchのコンサルティング会社であるNew Idea Engineering, Inc.の下記レポートによると、2008年の予測でLuceneは一流製品の仲間入りを果たすと述べられている:
http://www.ideaeng.com/pub/entsrch/2008/number_01/article01.html 従来からのTier 1:FAST SearchとAutonomy IDOL Tier 1から脱落:K2とUltraseek Tier 1への仲間入り:GoogleとEndecaとLucene(およびNutchやSolr) Tier 1へはまだまだ:MicrosoftとOracleとIBM OmniFind ただし、先日のMicrosoftによるFASTの買収発表があったが、これが完了すればMicrosoftもTier 1と注釈がついている。 2008.01.12 Saturday
Lucene/Solr/Nutch - 入門者向けスライド
LuceneとSolrとNutchの入門者向けスライド(英語)。
http://www.slideshare.net/dnaber/apache-lucene-searching-the-web-and-everything-else-jazoon07/ 2008.01.09 Wednesday
Wikia開発者がLuceneメーリングリストに投稿したメール
Wikia Search(Search Wikia?)が公開されて話題となっている。まだアルファ版とのことで、日本語などの検索語は文字化けしてしまうようだ。
先日、LuceneのメーリングリストにWikia開発者のDennis Kubes氏からメールが投稿された。それによると、Wikiaではソースだけでなく、クロールしたデータも公開するとのこと。 なかなか興味深いので、以下その全文を紹介しよう。なお、翻訳はいい加減なので、必要ならば原文も同時に参照していただきたい: http://www.nabble.com/Wikia-search-goes-live-today-to14665259.html#a14665259 ちょっと忙しくて返事ができなくてすみません。^^;ゞ 私のことを知らない人のために自己紹介すると、私はNutchプロジェクトのコミッターです。Wikiaには7月前半からかかわっていて、11月からはより活発に活動しています。Wikiaの前はNutchベースのVisvo.comという別のサーチエンジンを支援していました。 念のため記しておくと、Search WikiaはNutch/Hadoop/Lucene/Solr/HBaseを使用しており、今後もサポートしていくでしょう。Search Wikiaはこれらのプロジェクトの開発とコミュニティを支援していくつもりです。また、変更部分を秘密にしておくこともしません。Search Wikiaが開発したすべてのものはオープンソースで無料で使えるものとみなされます。Apacheプロジェクトに対して行われた改良は、それぞれのプロジェクトを通じてコミュニティにすみやかにフィードバックいたします。 検索をオープンかつ透明にするにはソースコードだけでは十分ではありません。Search Wikiaのデータをも無償公開するつもりでいます。これはクロールしたデータ、リンクデータ、コンテンツの断片、そして完成したインデックスを人々がダウンロードできることを意味します。また、foowiと名づけられたSNS機能もおそらくApache Licenseでオープンソースプロジェクトとなり、ダウンロード・使用・改良がなされるでしょう。 Search Wikiaはそれ単独ではありません。Visvo.comとWikiaは協力し合ってすべてのデータとコードの改良をOSIに承認されたライセンスのもと、コミュニティーにリリースしてまいります。これには分散環境に配置されたhadoopの設定を管理するPythonのフレームワークや、フェッチとインデクシング処理の自動化や、分散検索サーバの管理を含みます。 Nutchの観点から、現在以下の2つの標準Nutchインストレーションとインデックスがあります。ひとつはISCにホスティングされているインデックスで、もうひとつはVisvoのオープンインデックスです。ISCインデックスにはおよそ3千5百万ページ、Visvoインデックスには5千万以上のページが格納されています。 http://search.isc.swlabs.org http://open-index.visvo.com メインのSearch Wikiaサイトはアイオワ州のバンカーにあるセキュアな地下ホスティング施設にホストされています(http://usshc.com/)。そしてこれらのインデックスを呼び出しています。したがってキャッシュされたページやexplain planが参照されたときは、リクエストはそれぞれのインデックスに飛んでいきます。 2つのインデックスはブラウザまたはWeb2.0ベースのクライアントでアクセス可能です。現在私たちはNUTCH-594を使ってXMLフォーマットとJSONフォーマットでこれらのインデックスの検索結果をサービスできるようにしています。たとえば、javaという検索語のリクエストは、次のようになります: http://search.isc.swlabs.org/nutchsearch?query=java&hitsPerSite=1&lang=en&hitsPerPage=10&type=json http://open-index.visvo.com/nutchsearch?query=java&hitsPerSite=1&lang=en&hitsPerPage=10&type=json そんなわけで、私たちはデータがダウンロードできるように忙しく働いています。数日のうちに可能になるよう、願っています。もし質問や特定のデータをご希望であれば、ご自由に私にメールをください。 Dennis Kubes 2008.01.09 Wednesday
Lucene 2.3でエンティティ抽出
現在、Lucene 2.3 RC1が公開中である。前回のリリースLucene 2.2からあっという間だった。
Lucene 2.2のリリース時は2.2の新機能を紹介しようと思い、サンプルプログラムを書きながら紹介記事を書いたりしたものだが、全部紹介しきらないうちにやがて新機能は「新」機能ではなくなり、そして今回の2.3のリリースを迎えることとなってしまった。 いったい、コミッターたちは自分たちの仕事をいつやっているのだろう。 ところで、Lucene 2.2のときは単語にペイロードを登録できるようになったので、それを中心に次のような利用例を紹介した: 記事から名詞だけを取り出す http://lucene.jugem.jp/?eid=133 人名がヒットしたときはスコアを上げる http://lucene.jugem.jp/?eid=134 今回は似たような雰囲気のする「エンティティ抽出」を、Lucene 2.3で新しく追加されたSinkTokenizerとTeeTokenFilterを使って実装する方法を紹介しよう。 エンティティ抽出とは? エンティティ抽出(entity extraction)とは文書から人名・地名・会社名・日付などを(自動)抽出することをいう。特に情報検索では抽出された「エンティティ」で絞り込み検索用のリンクを自動的に生成するなどの応用が可能となる。 つい先ほどマイクロソフトによる買収の発表があった検索エンジン大手のFAST社の製品はエンティティ抽出の機能を持つらしい。そんなFAST社による「Entity Extraction」という用語の説明はこうだ: http://www.fastsearch.com/glossary.aspx?m=48&amid=291 また、多言語形態素解析器などで知られるベイシス・テクノロジはエンティティ抽出のための製品も持っている: Rosette固有表現抽出システム http://www.basistech.co.jp/entity-extraction/ SinkTokenizerとTeeTokenFilter 今回紹介するエンティティ抽出のサンプルは、上記製品のように本格的なものではなく、形態素解析器(SenTokenizer)が出力するトークンのタイプを単純に判断して行うものとする。 ところで、Lucene 2.3になる前からSenTokenizerはトークンのタイプで「人名」や「地名」などとして品詞情報を出力できたので、やろうと思えば今までもエンティティ抽出は可能だった。今回あえてLucene 2.3でエンティティ抽出を紹介するのは、Lucene 2.3で追加されたSinkTokenizerとTeeTokenFilterでエンティティ抽出のようなプログラムを書くのが楽になった、ということがあげられる。 SinkTokenizerとTeeTokenFilterは必ず組み合わせて使うことが前提である。SinkTokenizerはトークンを保持するバッファを内蔵する。そのトークンはTeeTokenFilterを通じて受信(sink)する。TeeTokenFilterは他の一般のTokenFilterと同様、上流のTokenizerからTokenizeされたトークンを受け取り、あたかもLinuxのteeコマンドのようにトークンをコピーして一方をSinkTokenizerに渡す。もともとのトークンは下流のTokenFilterに渡す。そうしておいて、SinkTokenizerに滞留したトークンを別のTokenFilterで処理してエンティティ抽出を行うのだ。 SinkTokenizerとTeeTokenFilterを使ってエンティティ抽出を行うサンプルプログラムを次に示す:
このプログラムを実行すると、次のようになる:
分析対象の記事は、橋下徹弁護士、熊谷貞俊元大阪大大学院教授、梅田章二弁護士らが立候補するという大阪府知事選に関するもので、次を拝借した: 自民、橋下氏推薦見送り 大阪府知事選10日告示 http://www.tokyo-np.co.jp/s/article/2008010801000867.html 「橋下」が認識されていないこと、「熊谷貞俊」が「熊谷」「貞」と抽出されている以外は、きれいにエンティティが抽出できているのがわかるだろう(辞書をメンテナンスすればこれらも拾うことができる)。 この出力結果を漫然と見ているだけでは形態素解析器が出力している品詞情報との違いがわかりにくく、ありがたみが感じられないだろう。 このプログラムで重要なのは、抽出されたエンティティがオリジナルの文書と関連付けられて索引付けされているところだ。したがって、検索システムと組み合わせて次のような絞り込み検索用のリンクが自動的に作れるようになるのである:
2008.01.08 Tuesday
Lucene 2.3 RC1の公開
Lucene 2.3 RC1が公開された:
http://people.apache.org/~buschmi/staging_area/lucene_2_3/rc1/ 2008.01.07 Monday
会社ホームページに検索窓の設置
新年あけましておめでとうございます。本年もよろしくお願いいたします。
前回記事でも予告したが、会社ホームページに検索窓を設置した。全文検索の会社なのに、会社設立から1年半かけてようやく自社のホームページに検索窓がついた、という格好だ。 言い訳すれば、ホームページのページ数が少ないので検索するまでもない、あるいは、検索結果件数が少なくなるに決まっているのでカッコがつかない、というのがこれまで対応しなかった理由である。 会社ホームページのページ数が少ないのはあいかわらずだが、今回はこのブログとの横断検索を可能にしている。そのためなんとか格好がつきそうなので、会社ホームページにも検索窓をつけたしだいである。 ついでにトップページも少し変えた: http://www.rondhuit.com/ |
+ Solrによるブログ内検索
+ PROFILE
+ LINKS
+ Lucene&Solrデモ
+ ThinkIT記事
+ RECOMMEND
+ RECOMMEND
Lucene in Action (JUGEMレビュー »)
Erik Hatcher,Otis Gospodnetic,Mike McCandless FastVectorHighlighterについて解説記事を寄稿しました。
+ RECOMMEND
+ SELECTED ENTRIES
+ RECENT COMMENTS
+ RECENT TRACKBACK
+ CATEGORIES
+ ARCHIVES
+ MOBILE
+ SPONSORED LINKS
|
(C) 2024 ブログ JUGEM Some Rights Reserved.
|
PAGE TOP |