関口宏司のLuceneブログ

OSS検索ライブラリのLuceneおよびそのサブプロジェクト(Solr/Tika/Mahoutなど)について
スポンサーサイト

一定期間更新がないため広告を表示しています

| スポンサードリンク | - | | - | - |
Lucene 2.3のリリース
昨日Lucene 2.3が公開された:

http://lucene.apache.org/java/2_3_0/

主な新機能は次があげられている:



* significantly improved indexing performance
* segment merging in background threads
* refreshable IndexReaders
* faster StandardAnalyzer and improved Token API
* TermVectorMapper to customize how term vectors are loaded
* live backups (without pausing indexing) with SnapshotDeletionPolicy
* CheckIndex tool to test & recover a corrupt index
* pluggable MergePolicy & MergeScheduler
* "partial" optimize(int maxNumSegments) method
* New contrib module for working with Wikipedia content



具体的な内容は、次のようにこのブログでほとんど紹介している。

>* 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


その他の機能についても、このブログで順次取り上げていく予定だ。
| 関口宏司 | Luceneリリース | 20:05 | comments(1) | trackbacks(0) |
類義語検索のデモ公開
類義語検索のデモを公開した:

http://www.rondhuit-demo.com/syndemo/search/index

「松下電器」で「パナソニック」を含む文書がヒットしたりする。

類義語検索というと、商用検索エンジンでは類義語データを辞書メーカーから買って使ったりしているようだ(そうでないものもあるかもしれない)。

弊社のソリューションは、類義語辞書はお客さんに自分で用意してもらう、というものである。そしてこれで十分間に合っている。というのも、アプリケーションがサービスしているコンテンツやそのサイトの性格によって必要な類義語リストはかなり偏ると考えられるからだ。一般的な類義語定義(たとえば、「首相」と「内閣総理大臣」など)がぜひとも必要だ、というのはあまり聞かない。それよりも、そのアプリケーションで頻繁に検索される言葉の類義語定義の充実がはるかに重要である。そのため、結局のところ一般的な類義語データを持っていたとしても、それ以外にそのサイト固有のことばとその類義語をユーザ辞書として持つことになる。

このユーザ辞書にはイニシャルで数十〜数百も定義すれば類義語が思いつかなくなる。あとは運用を継続していく中で必要に応じて徐々に類義語リストを充実していけばよい。これでたいていは問題ない。

このデモはリンクをクリックするだけで検索ができるようになっているので、一度やってみていただきたい。そのとき、スコアにも注目して欲しい。このデモでは、類義語でヒットさせるだけでなく、オリジナルの検索語を尊重したスコア計算を行っている。たとえば、「松下電器」で検索した場合に「パナソニック」を含む文書も検索できるが、「パナソニック」を含む文書よりも「松下電器」を含む文書のスコアを高くして上位表示する、ということを行っている。
| 関口宏司 | Luceneデモ | 02:49 | comments(5) | trackbacks(0) |
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と注釈がついている。
| 関口宏司 | その他(分類不能) | 19:14 | comments(0) | trackbacks(0) |
Lucene/Solr/Nutch - 入門者向けスライド
LuceneとSolrとNutchの入門者向けスライド(英語)。

http://www.slideshare.net/dnaber/apache-lucene-searching-the-web-and-everything-else-jazoon07/
| 関口宏司 | Luceneとは? | 18:57 | comments(0) | trackbacks(0) |
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
| 関口宏司 | その他のOSS検索エンジン | 21:28 | comments(1) | trackbacks(0) |
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を使ってエンティティ抽出を行うサンプルプログラムを次に示す:



public class SampleEntityExtraction {

static final String SEN_CONF = "c:/sen-1.2.2.1/conf/sen.xml";
static final String INDEX = "index";
static final String F_BODY = "body";
static final String F_PERSON = "person";
static final String F_ORG = "org";
static final String T_PERSON = "名詞-固有名詞-人名";
static final String T_ORG = "名詞-固有名詞-組織";
static final String CONTENT = "ここに適当な記事を入れる";

public static void main(String[] args) throws IOException {

final SinkTokenizer sinkPerson = new SinkTokenizer( null );
final SinkTokenizer sinkOrg = new SinkTokenizer( null );

Analyzer analyzer = new Analyzer() {
public TokenStream tokenStream(String field, Reader in) {
try {
return new TeeTokenFilter( new TeeTokenFilter( new SenTokenizer( in, SEN_CONF ), sinkPerson ), sinkOrg );
} catch (IOException e) {
throw new RuntimeException( e );
}
}
};

TokenFilter exPerson = new EntityExtractor( sinkPerson, T_PERSON );
TokenFilter exOrg = new EntityExtractor( sinkOrg, T_ORG );

IndexWriter writer = new IndexWriter( INDEX, analyzer, true );
Document doc = new Document();
doc.add( new Field( F_BODY, CONTENT, Store.YES, Index.TOKENIZED ) );
doc.add( new Field( F_PERSON, exPerson ) );
doc.add( new Field( F_ORG, exOrg ) );
writer.addDocument( doc );
writer.close();

System.out.println( "===== 抽出された人名エンティティ =====" );
printTerms( F_PERSON );

System.out.println( "¥n===== 抽出された組織エンティティ =====" );
printTerms( F_ORG );
}

static void printTerms( String field ) throws IOException {
IndexReader reader = IndexReader.open( INDEX );
TermEnum terms = reader.terms( new Term( field, "" ) );
while( terms.next() ){
Term t = terms.term();
if( !t.field().equals( field ) ) break;
System.out.println( t.text() );
}
terms.close();
reader.close();
}

static class EntityExtractor extends TokenFilter {

String type;

protected EntityExtractor(TokenStream stream, String type ) {
super(stream);
this.type = type;
}

public Token next() throws IOException {
Token t;
while( true ){
t = input.next();
if( t == null ) return null;
if( t.type().startsWith( type ) )
return t;
}
}
}
}



このプログラムを実行すると、次のようになる:



===== 抽出された人名エンティティ =====

梅田
熊谷
福田
章二


===== 抽出された組織エンティティ =====
公明党
共産党
大阪大
府連
民主党
社民
自民
自民党



分析対象の記事は、橋下徹弁護士、熊谷貞俊元大阪大大学院教授、梅田章二弁護士らが立候補するという大阪府知事選に関するもので、次を拝借した:

自民、橋下氏推薦見送り 大阪府知事選10日告示
http://www.tokyo-np.co.jp/s/article/2008010801000867.html


「橋下」が認識されていないこと、「熊谷貞俊」が「熊谷」「貞」と抽出されている以外は、きれいにエンティティが抽出できているのがわかるだろう(辞書をメンテナンスすればこれらも拾うことができる)。

この出力結果を漫然と見ているだけでは形態素解析器が出力している品詞情報との違いがわかりにくく、ありがたみが感じられないだろう。

このプログラムで重要なのは、抽出されたエンティティがオリジナルの文書と関連付けられて索引付けされているところだ。したがって、検索システムと組み合わせて次のような絞り込み検索用のリンクが自動的に作れるようになるのである:



===== 人名で絞り込む =====
梅田(1)
熊谷(1)
福田(2)

===== 組織名で絞り込む =====
公明党(1)
共産党(1)
大阪大(1)
民主党(3)
自民党(4)




| 関口宏司 | Lucene自由自在 | 01:49 | comments(1) | trackbacks(0) |
Lucene 2.3 RC1の公開
Lucene 2.3 RC1が公開された:
http://people.apache.org/~buschmi/staging_area/lucene_2_3/rc1/
| 関口宏司 | Luceneリリース | 12:42 | comments(0) | trackbacks(0) |
会社ホームページに検索窓の設置
新年あけましておめでとうございます。本年もよろしくお願いいたします。


前回記事でも予告したが、会社ホームページに検索窓を設置した。全文検索の会社なのに、会社設立から1年半かけてようやく自社のホームページに検索窓がついた、という格好だ。

言い訳すれば、ホームページのページ数が少ないので検索するまでもない、あるいは、検索結果件数が少なくなるに決まっているのでカッコがつかない、というのがこれまで対応しなかった理由である。

会社ホームページのページ数が少ないのはあいかわらずだが、今回はこのブログとの横断検索を可能にしている。そのためなんとか格好がつきそうなので、会社ホームページにも検索窓をつけたしだいである。

ついでにトップページも少し変えた:

http://www.rondhuit.com/
| 関口宏司 | 会社ホームページ | 19:32 | comments(0) | trackbacks(0) |
+ Solrによるブログ内検索
+ PROFILE
  12345
6789101112
13141516171819
20212223242526
2728293031  
<< January 2008 >>
+ LINKS
検索エンジン製品 - 比較のポイント
商用検索エンジンを購入した企業担当者は読まないでください。ショックを受けますから・・・
>>製品比較 10のポイント
+ Lucene&Solrデモ
+ ThinkIT記事
+ RECOMMEND
Apache Solr入門 ―オープンソース全文検索エンジン
Apache Solr入門 ―オープンソース全文検索エンジン (JUGEMレビュー »)
関口 宏司,三部 靖夫,武田 光平,中野 猛,大谷 純
+ RECOMMEND
Lucene in Action
Lucene in Action (JUGEMレビュー »)
Erik Hatcher,Otis Gospodnetic,Mike McCandless
FastVectorHighlighterについて解説記事を寄稿しました。
+ RECOMMEND
+ SELECTED ENTRIES
+ RECENT COMMENTS
+ RECENT TRACKBACK
+ CATEGORIES
+ ARCHIVES
+ MOBILE
qrcode
+ SPONSORED LINKS