第19回Lucene/Solr勉強会 #SolrJP
こんにちは!久しぶりの Lucene Solr 勉強会です。 メモを公開しますー。
NLP4Lを使ったランキング学習
株式会社シーマーク 山本 高志 様
www.slideshare.net
講演内容メモ
Apache Lucene のための自然言語処理ツール (OSS) github.com
何ができるか?
- 固有表現抽出
- 文書分類
- キーフレーズ抽出
- ランキング学習 (今日のテーマ)
- など・・
- 標準提供のランキング学習モデル
- PRank
- RankingSVM
- など・・
- ランキング学習のフロー
- クエリログ・アノテーションを教師データとして使用する (作成を支援するツールも含まれる)
- Feature の抽出、トレーニング、モデル配置までできる
- モデル評価の機能は未実装だが今後やっていきたい
- Featrure は Lucecene で取得できる値を利用する
- TF/IDF や BM25 など
- リランキングは Solr の標準の機能を使用している
- ランキングモジュール自体は NLP4L に含まれる PRank や RankingSVM をクエリで指定する
- Bloomberg 版 LTR との比較
- 負けてないぞと!
- Solr に依存していないので ES にも適用できるところがアピールポイント
- Bloomberg 版は以下。
- [SOLR-8542] Integrate Learning to Rank into Solr - ASF JIRA
一言・感想
- UI がついているので教師データの作成は非常にやりやすそうです。大規模なケースで複数人で手分けする場合にはどのようにできるかが気になった
- Bloomberg 版とのもう少し詳細な比較が見たいです。
Lucene/Solr Revolution 2016参加レポート
楽天株式会社 中田 晋平 様
www.slideshare.net
講演内容メモ
3点ピックアップして紹介
Working with Deeply Nested Documents in Apache Solr
- 昔は Solr はいまいちだったが、5系ならイケる
- 普通の入れ子の場合(2段階まで)
- Lucene は flat な index しか持てないので、連続した docid に親子のデータを配置する、親子の区別用にもう一つのフィールドを利用する (boolean の isParent みたいな)
- Block Join Query
- Deeply Nested Document の場合
- 基本的に Nested と同じ、どの階層でも独立した1つのドキュメント
- path という考え方を導入、親子の構造を string のフィールドに含める、簡単に処理できるように PreProcessor を用意した
- 親子孫含めて横断的に検索するには、v5.3 以降の ChildDocTransformerFactory を利用するとできる
Rebalancing API for SolrCloud
- SolrCloud の運用を楽にする API を作成した
- Rebalancing API を作成し、Solr に contribute (6系に含まれる?)
- Re-sharding
- 再インデキシング不要でシャードを増やす
- 別の shard を用意して一旦マージした後に再度分割する
- マイグレーション
- 冗長化 (レプリカを増やす)
- Reindexing なしなので速い、設定ファイルも一緒に配布する
The Evolution of Lucene Solr Numerics from Strings to Pints
- 数値の文字列表現について
- 最初は String で全て持っていた
- 2009 年、trie numerics に置き換え
- trie 木の一部にデータが集中するデータは非効率になっていた
- 2016 年、dimentional point に置き換えを予定 (lucene にはすでに入っている)
- k dimension tree を使用する
- それぞれの次元に対して繰り返し分割する、分割した結果を元に tree を作成する、分割は中央値で分割する
- ノードが一定数まで分割して終了する
- データの密度に応じてバランスする
- 数値の文字列表現について
一言・感想
- G1GC が OK というのがびっくりですね!私も参加していたのですが、知りませんでした。 (TODO: あとでしらべる)
Solrを活用した施設情報検索システムの取組み
株式会社NTTドコモ 榎園 健 様
講演内容メモ
- 施設情報検索に特化した検索エンジン
- 施設名称・所在地を考慮して検索 (横浜のコストコとか)
- 課題1:地名解釈
- 「横浜 ドコモ」で検索しても、ドコモショップ 戸塚店はヒットしない (戸塚店は、横浜市戸塚区にある)
- edismax は、スコアが最大のフィールドのみを採用するので、地名でヒットしてもスコアは採用されない場合がある
- プラグインを開発
- クエリ内に地名が存在している場合、クエリを拡張して地名のフィールドに対して OR 検索してスコアを加算する
- 課題2:施設人気度
- 例:「赤坂サカス」で検索したときに、「スターバックスコーヒー赤坂サカス店」などもヒットするので、「赤坂サカス」自体が埋もれる
- 施設に人気度や有名度が必要
- アプローチ1:ツイートを使って人気度付与
- 同名の施設は、共起語で判定 (北海道の円山公園か、京都の円山公園か)
- 人名か地名か、説明を用意しておき共起語を用意しておく
- アプローチ2:位置情報データ(モバイル空間統計)を活用した人気度付与
- 人口分布の時間変動を把握できるので、人がたくさん集まっているところに高いスコアを付与する
- 課題3:アプローチ3:パラメータ探索、フィールドごとに重みを設定してチューニングするが少し変えるだけで大きく変わるので難しい
- 機械学習に寄るパラメータ探索
- Hyperopt
一言・感想
- モバイル空間統計 が利用できるのはドコモならではのチートですね!w
AtomicUpdateを50000倍速くした話(SOLR-9592)
ヤフー株式会社 石川 貴大 様
講演内容メモ
- Atomic Update 部分更新などでよく使われる
- 一度検索し直すので余り速くない (Realtime Get)
- 実際に検証すると超遅い (0.1 dps ??)
- Remote Debug や、コードリーティング、FlameGraph などで調査
- SlowCompositeReaderWrapper
- Lucene 的にはセグメントごとに LeafReader を使って個別に検索することが推奨されている
- が Solr はそれに追いついておらず、SlowCompositeReaderWrapper ではこっそりこれをマージして横断して検索していた
- SolrIndexSearcher から SlowCompositeReaderWrapper が呼ばれる・・
- やったことは、LeafReader ごとに検索するように直した
- v6.3 以降取り込まれる
- 実は Lucene には一度取ってこなくても更新できる実装が進められている
- posting が貼れないので検索には使えない