2017.12.15 Friday
スポンサーサイト
一定期間更新がないため広告を表示しています
| スポンサードリンク | - | | - | - |
関口宏司のLuceneブログOSS検索ライブラリのLuceneおよびそのサブプロジェクト(Solr/Tika/Mahoutなど)について
2009.03.31 Tuesday
(メモ)Googleのポスティングリストに関する情報
Google's Postings Format
http://blogs.sun.com/searchguy/entry/google_s_postings_format http://research.google.com/people/jeff/WSDM09-keynote.pdf (Slides 47-63) 2009.03.31 Tuesday
IndexableBinaryStringToolsでバイナリのインデクシング!(2.9)
Lucene 2.9にバイナリデータをインデクシングするためのIndexableBinaryStringToolsクラスが追加された:
https://issues.apache.org/jira/browse/LUCENE-1434 同クラスのstaticメソッドのencode()/decode()で変換/逆変換を行う。Stringに変換後もバイナリのバイト列のソートオーダーが保たれるように変換される。 2009.03.29 Sunday
(メモ)ICU4J
International Components for Unicode
http://site.icu-project.org/ CharsetDetector http://icu-project.org/apiref/icu4j/com/ibm/icu/text/CharsetDetector.html ICU4Jのデモ http://icu-project.org/icu4jdemos.html 2009.03.22 Sunday
CJKTokenizerの全角>半角正規化のロジック修正(2.9)
Lucene contribのCJKTokenizerには全角英数字記号文字を半角文字に正規化するコードが含まれているが、変換できない範囲まで変換しようとしてしまうコードになっていた。
LUCENE-1490でこの部分が修正され、正しく動くようになった。 これまでの正規化対象とする文字の判定はUnicodeBlockのHALFWIDTH_AND_FULLWIDTH_FORMSかどうかだけだったが、これだと"⦅"といった文字までも対象になってしまう。そして正規化ロジックは65248をマイナスするという簡単なものである。 これを確認するプログラムを書くと、次のようになる:
実行結果は次のようになり、65375以降がおかしくなってしまう:
新しいCJKTokenizerのロジックでは、「65281以上65374以下のみ」65248をマイナスするという「」内の条件がつけられた。 2009.03.21 Saturday
setOmitTF()メソッドのリネーム(2.9)
先日書いたsetOmitTF()メソッドの件だが早速Lucene 2.9でリネームが行われ、setOmitTermFreqAndPositions()というなんとも長い名前となった。Lucene 2.4のsetOmitTF()(およびgetterメソッド)はそのまま使えるがdeprecatedとなっている。
2009.03.20 Friday
MatchAllDocsQuery使用時のランキング(2.9)
LuceneはクエリをQueryクラスのオブジェクトで表現するのでさまざまなクエリ表現を実装できる。
Queryの拡張の一つにMatchAllDocsQueryクラスというのがあり、それは「すべて検索する」というクエリである。 このクエリを使うとすべてのドキュメントがヒットする。このときドキュメントのランキングはスコアがすべて1.0となることからドキュメント番号順に並ぶようになる。 これについて特定のフィールドのNorm値(lengthNorm*boost)をスコアにしよう、という新機能が2.9に入ることとなった: https://issues.apache.org/jira/browse/LUCENE-1543 使い方は簡単で、MatchAllDocsQueryのコンストラクタにフィールド名を指定するだけである。 たとえば、"1 2 3", "2", "1"というような3つのドキュメントをそれぞれ重み(boost)1, 10, 1でこの順番でインデクシングしたとき、引数なしのMatchAllDocsQueryで検索すると返されるドキュメントはすべて1.0のスコアとなって、インデクシングした順番にドキュメントが返される。 そこで今度は引数にフィールド名を指定してMatchAllDocsQueryを作成し、再度検索すると順番は"2", "1", "1 2 3"となって返ってくる。 "2"が最初に返ってくるのは、重みが10というのが大きく効いているためである。次に同じ重みの"1 2 3"と"1"で"1"が先になるのは、LuceneのlengthNormが効くことで、fieldNormが単語数の少ない"1"をより重要である、とみなすためこのような結果となる。 2009.03.18 Wednesday
レコメンドについて
ある日客先に出勤すると、プロジェクトメンバーで隣の席のO谷さんがWEB+DB PRESSの記事を熱心に読んでいた。その記事は「レコメンドエンジン入門」なるもので、現在取り組んでいるプロジェクトに関係する内容であった。
検索エンジンの仕事をしていると、レコメンド機能も一緒につけて欲しい、ということが多い(多くなった)。 レコメンド機能とは、たとえばアマゾンのサイトで「この商品を買った人はこんな商品も買っています」というあの機能である。レコメンド機能=お勧め機能ということだ。 現在取り組んでいるプロジェクトはアクシデントやその一歩手前(ヒヤリハット)の被害等状況/情報を登録/検索/参照できるものである(保険会社のシステムのようなものを想像してみるといい)。 そんなシステムにどうやってレコメンド機能を組み込むのだろうとちょっと想像してみる。 ユーザ(当の被害にあった本人かもしれないし、その関係者かもしれない)はそのサイトに訪れ、被害を被った当時の状況を思い出しつつ、その内容をフォームに記入する。それは悲しい思い出なのだった。しかし「こんな被害は私で最後にして欲しい」そんな一心で悲しみを乗り越えフォームに記入することを決意したのだった。 登録ボタンをクリックすると、そのサイトはレコメンドロジックを使い、こう告げるのであった。 「この被害に遭った人は、こんな被害にも遭っています。」 いやだな、そんなレコメンド機能。 Solrを使ってレコメンドを行うには、以前にも書いたMoreLikeThisを使うと実現可能である。近々会社のデモサイトにレコメンド機能を使った検索のデモをオープンしようと考えている今日この頃である。その際はお勧めして喜ばれそうなネタを選びたいと思っている。 2009.03.17 Tuesday
多色タグハイライター
現在提案されているもう一つのハイライターがだんだん盛り上がってきた:
https://issues.apache.org/jira/browse/LUCENE-1522 いろいろコメントがついているが、きっかけは多色タグができることを視覚的に示したのが大きいのではないかと思っている。百聞は一見にしかず。多色タグハイライトは先日紹介したアスベル(Solrベースの仮想検索アプライアンス)にも搭載されている。 従来のハイライターがハイライト処理時にstoreされた文章を先頭から(指定された最大文字数まで)もう一度トークナイズしてスコアを計算しながら高スコアのスニペットを見つけ出そうとするのに対し、LUCENE-1522のハイライターはあたかも書籍の中の単語やフレーズに一瞬で多色蛍光ペンを使って印をつけ、印が集中していそうなところをから順番にスニペットにして取り出すようなもので、ある程度までの大きさのドキュメントについては高速に処理が可能なものである。ある程度以上になると一度に印をつけるために大きなドキュメントをインデックスから持ってくる際のI/Oが無視できなくなり速度は出なくなる場合がある。また、一度に印をつけるためにはTermVectorを使っているのでインデックスサイズは大きくなる。 2009.03.15 Sunday
setOmitTF()メソッドについて
Lucene 2.4からFieldableクラスに追加されたsetOmitTF()メソッドにtrueを設定すると、名前の通り当該フィールドのterm frequencyが保存されなくなる。返される値は常に1となるので、"a a a"というフィールドと"a b b"というフィールドについて"a"を検索しても、両者ともtf=1となって同点スコアとなる。
ここまではメソッド名から容易に想像できるが、setOmitTF(true)は同時にポジション情報も保存されなくなるので注意が必要だ。そのため、omitTFをしたフィールドについてPhraseQueryを実行しても何もヒットしなくなってしまう。ポジションと同じ.prxファイルを使用しているPayloadなども同様に保存されなくなる。 とまあそういうわけでomitTFという名前は紛らわしいのではないか、ということで名前を変えようか、という意見が早くも出ている: https://issues.apache.org/jira/browse/LUCENE-1561 ところでomitTFのフィールドはどんなときに使えばいいかというと、1単語(=String)だけの索引フィールドに用いることを検討すればいいだろう。そのようなフィールドは多くの場合ソートやフィルタリングのために使われる。たとえば商品カテゴリや性別や郵便番号やユーザ権限などである。 このようなフィールドにomitTFを適用するとCPUとIOの節約に役立つ。 |
+ 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 |