あるあるであるが、これも誤りである。条件追加による検索の絞り込みも、返される文書集合は同じである。文書の順番(ランキング)を見てみれば両者は異なることがわかる。使う方法だと絞り込むたびにランキングが異なってしまう。ユーザーから見ると、ファセットのリンクをクリックするたびに文書の表示順が異なってしまう。これではユーザーが混乱するだろう。うまく使われない、という別の問題もはらんでいる。使う、と覚えておこう。あるあるであるが、これもナンセンスであり、実施しようとして奮闘すること自体、時間の無駄である。あれ、クエリと各文書である。スコアはクエリを固定したときに、各文書に付与される当該クエリとの関連度合いを表現したものであるから、クエリが変わってしまうと相互に比較することに意味がない。関連しているとは見えない、ということがおおいにありえる。ハイライト機能があることを知らずに自前で実装してしまうパターン、Solrにハイライト機能があることは知っているが、自前の方がよいと信じて自前で実装してしまうパターンがあるようだ。前者は知らなかったということでお気の毒という他ない。後者は、なぜそのような発想になるのかよくわからない。ハイライト機能はそれほどよくできている。自前で頑張る方式のメリットをあえて上げるならば、たとえば、サーバ側のCPU負荷を下げるため、ユーザーのブラウザにてJavaScriptでハイライトする場合、が考えられるかもしれない。非常によくできたハイライト機能を使わないデメリットをアプリケーションに実装してしまっていることに気づいているだろうか。検索キーワードがなるべく多く含まれる任意長のスニペットを、任意の個数得ることができる。スニペットにもスコアがつけられ、スコアの高いスニペットから返される。同じ機能をアプリケーションで頑張ろうとすると、スニペットを作成するデータソースをすべて転送してこなければならない。ハイライト機能で作成したスニペットよりも大きなサイズになることが多く、ネットワーク負荷の原因となる。表記揺れを考慮した検索が可能であるが、ハイライトでも同じ表記揺れを考慮した上でハイライト表示が可能である。アプリケーションで頑張る場合は、同じ表記揺れ対応をしなければ検索にヒットしてもハイライト表示ができない場合が出てきてしまう。設定変更がアプリケーションの方に影響してしまうため管理が煩雑になる。スニペットは単語境界区切りなど、自然な単位でスニペット生成ができるようになっている。検索キーワードがフレーズの場合、フレーズが一致している場合のみハイライトさせたり、単語単独でハイライトさせたりといった細かな制御が可能である。同様のことをアプリケーションでやらせようとすれば、簡易であれNLP的機能をアプリケーションに持たせなければならない。スニペットが作れない場合の代替表示を指定することができる(大抵はハイライト表示しようとする当該フィールドの先頭100文字など)。ハイライト機能は検索アプリケーションのことをよく考慮して用意されており、大変よくできている。自前で用意するというのはたいていの場合誤っていると断言できる。ハイライトスニペットを作成せず、ユーザーのクリックにより当該文書表示時に検索キーワードを太字など目立つように表示する機能は、ここでいうハイライト機能とは異なる。ユーザーに適切な文書をすばやく選択してもらうためのアシスト機能に相当する。ハイライト機能はぜひ積極的に利用しよう(ただし、商品の写真を検索結果一覧に表示するようなECサイトの検索アプリのようなものは除く)。使うあるあるや、親子階層のファセットを自前で頑張るあるある、クエリを投げる際に常にダブルクォーテーションでくくってしまうあるあるなどもある。なって10年を超えるソフトウェアとなった。持っていることも多い。アプリケーションで頑張る前にぜひマニュアルや書籍等で該当する機能がないか、使い方がアーキテクチャに沿ったものになっているか、今一度考えてみることをお勧めしたい。今年はおそらく本記事が最後となるでしょう。更新頻度が少なくなったのにもかかわらず、本年もご愛読いただきありがとうございました。|コメントいつも参考にさせて頂いてます。ありがとうございます。記事中のハイライトについて質問があります。質問1)スニペットに対してのスコア付けは、どのように行うのでしょうか?質問2)スコアの算出方法は指定可能でしょうか?質問3)記事にはございませんが、スニペット作成時に、検索キーワードの前50文字を出す、後ろ50文字を出す、といったような指定は可能でしょうか?宜しくお願いします。|ハイライト時のスコア計算は検索のスコア計算のように複雑なものではありません。スニペットに当該単語がいくつ含まれているか(たくさん含まれているほどスコアが高い)という程度のものです。これをカスタマイズしたい場合は、Highlighter自体をすべて書くしかないと思います。スニペット作成時の細かい指定もそのままではできないと思います。|迅速なお返事ありがとうございます。こちらの確認が遅く、コメントが遅れてしまい失礼しました。>ハイライト時のスコア計算は検索のスコア計算のように複雑なものではありません。スニペットに当該単語がいくつ含まれているか(たくさん含まれているほどスコアが高い)という程度のものです。>既存のHighlighterは希望通りに動かないということでしょうか?そうなんですね、TF-IDFのようなイメージでしょうか。solrの管理画面から試してみた程度なのですが、単純に先頭のスニペットが出力されているように見えます。インデックスの作成時に位置情報を保存していないので、それが原因かなと考えているところです。記事とは無関係で大変恐縮なのですが、スニペットの作成時にキーワードの前後を指定する(質問3)についてはご存知ありませんか?こちらの答えが「スニペット作成時の細かい指定もそのままではできないと思います。できていますので、上で自作とは書きましたが、それを超えるものはなかなか作れないのではないかと思います。単純に先頭のスニペットが出力されているように見えます。これは試し方が足りないせいだと思います。検索キーワードが多く含まれるスニペットが得られます。|>こちらの答えが「スニペット作成時の細かい指定もそのままではできないと思います。お答えいただいていたのですね。気付かず申し訳ありません。>これは試し方が足りないせいだと思います。検索キーワードが多く含まれるスニペットが得られます。ありがとうございます。本格的に要件が決まってきたら、検索キーワードを増やしていろいろと試してみます。質問に快くお答えいただき、ありがとうございました。ご厚意に甘えるようで心苦しいのですが、また何かありましたらご教授頂けると幸いです。|コメントするname:email:url:comments:Cookieに登録この記事のトラックバックURLトラックバック機能は終了しました。比較のポイント商用検索エンジンを購入した企業担当者は読まないでください。McCandlessFastVectorHighlighterについて解説記事を寄稿しました。