リリースの投票がまもなく始まろうとしている。boosts?https://issues.apache.org/jira/browse/LUCENE-6819タイトルだけ見ると、「インデクシング時ブースト(重み付け)を止めよう」、もっと深読みすると「クエリ時に重み付けが指定できるからインデクシング時に重み付けしなくてもいんじゃね?」ととらえてしまう方もいるかもしれない。インデクシング時重み付けとクエリ時重み付けでは、大きく意味や目的が異なる。どのようになるか、簡単に解説しよう。LUCENE-6819このチケットでは、タイトル通り、インデクシング時のboostを止めよう、というものである。いう、各ドキュメントの各フィールド(ただし、omitNorms=trueのフィールドを除く)ごとに1バイトでエンコーディングされた値の、次の式からboostを取り除こう、というものである。標準であったベクトル空間モデルによるランキング計算(各ドキュメントのクエリに対する類似度計算)に強く依存している。考慮されている文書長はとっくに加味されている。[2]さて、これからboostを除けば、次のようになる。デフォルトで次のように計算される。sqrt(numTerms)numTermsは当該フィールドの単語数である。なってしまうことも考えられる。ほとんどのユーザーはインデクシング時重み付けなどしないので、上図グレーの部分がもったいない。boostがかけられる可能性を考えて1バイトの半分を残しているのだが、ほとんどのユーザーはboost=1なので、非常にもったいない、かつ、低精度な使い方になっている。し、boostに1でない値が投入されようとすると、「将来バージョンで使えなくなる」旨の警告が表示される。そのものが記録されるようになった。1バイトが有効活用されていない。そこでこのチケットでは、フィールド長(単語数)をSmallFloat.intoTobyte4(numTerms)でエンコードして保存するように修正された。単語数が1000のときは、SmallFloat.intoTobyte4(1000)が87となり、これが記録される。デコードにはSmallFloat.byte4ToInt()が使われる。SmallFloat.byte4ToInt(87)は984となる。ちなみに、1〜40はエンコードしても1〜40を出力する(変わらない)。長さ41から徐々にエンコードによる誤差が大きくなる(下図)。そのままエンコードされて1バイトに記録される。計算する意味自体がない、ということだ。指定は相変わらず有効である。ロンウイットの社内勉強会で説明に使用したスライドも公開しているので、合わせて読んで欲しい。ロンウイット主催のトレーニングコース「Solr基礎」では、このような大事な基礎を丁寧に教えています。お申し込みはこちらから。Sparkではじめる機械学習」では、機械学習のさまざまなモデルやアルゴリズムを丁寧に解説しています。ベーシックな機械学習の解説にとどまらず、本記事にあるような、検索エンジンのランキングの元になるスコア計算の考え方なども含み、ソフトウェア開発の実際の現場で役に立つ内容を網羅しています。お申し込みはこちらから。比較のポイント商用検索エンジンを購入した企業担当者は読まないでください。McCandlessFastVectorHighlighterについて解説記事を寄稿しました。