# Dec 6th, 2018: \[JP\]\[Elasticsearch\] 検索順位を自在に操る **URL:** \ **Category:** Advent Calendar\ **Created:** [December 6, 2018, 12:00am UTC](https://discuss.elastic.co/t/dec-6th-2018-jp-elasticsearch/159442 "2018-12-06T00:00:03Z")\ **Posts on this page:** 2\ **Page:** 1
**Author:** ![Kosho\_Owa](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/kosho_owa/32/38546_2.png) [@Kosho\_Owa](https://discuss.elastic.co/u/Kosho_Owa)\ **Post date:** [December 6, 2018, 12:00am UTC](https://discuss.elastic.co/t/dec-6th-2018-jp-elasticsearch/159442/1 "2018-12-06T00:00:03Z")
# 検索順位を自在に操る ## 検索順位を決める要素 Elasticsearchは、スケーラブルで高速なリアルタイムの検索・分析エンジンです。文字列、数値、日時、地理情報など、指定された条件にしたがってインデックスされたドキュメントを検索し、一致するものを利用者に返します。数値、日時、地理情報であれば、「価格が1000円」以上、「今週入荷した商品」、「東京都庁から100km以内」などといった条件をもとに検索ができ、条件に一致するドキュメントのスコアは全て同一です。文字列を条件に指定した場合には、検索対象の文字列の長さや、条件に一致した句の数や頻度などに応じて、それぞれのドキュメントのスコアは異なり、順位付けがなされます。 ただ、検索機能をアプリケーションに実装する場合、検索順位を制御したい場合が多々あります。「1000円以上の商品を安い順」「今週入荷した商品を新しい順」「東京都庁から近い順」に並べるといった場合です。それらのうち、複数の条件を組み合わせたい場合もあるでしょう。Elasticsearchを使用して、どのように実装したら良いでしょうか。 フルーツのオンラインショッピングサイトを想定し、以下のような商品テーブルを用意します。 | arrival\_date | name | origin.prefecture | origin.location | price | promotion | | --- | --- | --- | --- | --- | --- | | 2018-12-02T00:00:00.000Z | Tsugaru Apple | Aomori | 40.82,140.73 | 310 | 2 | | 2018-11-29T00:00:00.000Z | Shinano Apple | Nagano | 36.65,138.17 | 280 | 10 | | 2018-12-04T00:00:00.000Z | Fuji Apple | Akita | 39.69,139.78 | 150 | 1 | | 2018-12-04T00:00:00.000Z | Mikkabi Mandarine Orange | Shizuoka | 34.97,138.38 | 80 | 1 | 商品の「入荷日（arrival\_date ）」、「商品名（name）」、「生産地（origin.location）」、「価格（price）」、「販促度（promotion）」フィールドを用意しました。利用者は「商品名」のみで検索しますが、「入荷日」が新しいもの、フラッシュセール用の「販促度」が高いものが、より上位に表示されるように試みてみます。 注意：本項に使用しているインデックスやクエリは[こちら](https://gist.github.com/kosho/49cb0b17cbfbbf65e61d8292b175a4d3)で入手できます。予期した通り動作させるためには、適切に「入荷日（arrival\_date ）」などを調整する必要があります。クエリの`now`を`2018-12-06`とすることもできます。 ## 好ましくない方法 - スクリプトスコア(Script Score) まずはじめに思いつくのは、ユーザが検索したキーワードに該当するドキュメントから、「入荷日（arrival\_date）」と「販促度（promotion）」を要素としてスクリプトにより点数付けし、各ドキュメントのスコアを上書きするものです。これは、[Function Score](https://www.elastic.co/guide/en/elasticsearch/reference/current/query-dsl-function-score-query.html)クエリの、[Script Score](https://www.elastic.co/guide/en/elasticsearch/reference/current/query-dsl-function-score-query.html#function-script-score)を用いて実現できます。 アプリケーションは、Elasticsearchに以下のようなクエリをリクエストすることができます。 ```auto GET items/_search { "query": { "function_score": { "score_mode": "sum", "query": { "match": { "name": "apple" } }, "script_score": { "script": "doc['promotion'].value - (new Date().getTime() - doc['arrival_date'].value.toInstant().toEpochMilli()) / 1000000 / 60" } } } } ``` `script_score`で、「入荷日（arrival\_date）」から現在の経過日数を求め、「販促度（promotion）」から引いています。「販促度（promotion）」が高く、より新鮮な商品が上位に表示されることになります。 実際に多くElasticsearchユーザーが、このような方法を用いています。では、なぜ好ましくないのでしょうか。それは、Elasticsearchはスクリプトを実行するために、マッチクエリーで一致したドキュメント全ての、「入荷日（arrival\_date）」フィールドと、「販促度（promotion）」にアクセスし、それぞれのドキュメントでスクリプトを用いて計算を行い、求められた値にしたがって検索順位を並べ替える必要があるからです。[プロファイルAPI](https://www.elastic.co/guide/en/elasticsearch/reference/current/search-profile.html)を用いて観察してみると、`score`に多くの時間が割かれていることがわかります。 # 減衰（Decay）関数を検討する Function Scoreクエリでは、指定した値から遠ざかるほどスコアが下がる、[Decay Function](https://www.elastic.co/guide/en/elasticsearch/reference/current/query-dsl-function-score-query.html#function-decay)を利用できます。指定した原点から遠ざかるほど、検索スコアが下がり、複数の条件を指定したり、減衰度を調整することができます。以下のようなクエリで実現することができます。 ```auto GET items/_search { "query": { "function_score": { "score_mode": "sum", "query": { "match": { "name": "apple" } }, "functions": [ { "linear": { "arrival_date": { "origin": "now", "scale": "7d", "offset": "0d" } } }, { "linear": { "promotion": { "origin": "10", "scale": "10", "offset": "0" } } } ] } } } ``` まず、「商品名（name）」に`apple`が含まれるものを検索します。さらに「入荷日（arrival\_date）」が現在より遠ざかるほど、直線的（Linear）にスコアが下がります。そして同様に、「販促度（promotion）」が10から遠ざかるに連れて、スコアが下がり、これら3つのスコアを足した（sum）ものをスコアとします。スコア自身は`script_score`とは異なりますので、検索の順位は異なる可能性がありますが、「入荷日」が新しいもの、フラッシュセール用の「販促度」が高いものを上位にするという要件を満たせることがわかります。 さらに、プロファイルAPIを使用すると、より少ないコスト（計算時間）の`score`でレスポンスが得られることが確認できます。 # 減衰（Decay）関数を地理情報に応用する 減衰（Decay）ファンクションが適用可能なのは、数値や日付時刻だけに限らず、地理情報にも適用できます。ある地点から遠ざかるほどスコアが下がるという検索は、[タクシーの配車](https://www.elastic.co/jp/use-cases/grab)や[イベントのチケット販売](https://www.elastic.co/elasticon/tour/2017/los-angeles/revolutionizing-the-fan-experience-with-search-at-ticketmaster)、[デーティング](https://www.elastic.co/elasticon/conf/2017/sf/tinder-using-the-elastic-stack-to-make-connections-around-the-world)アプリケーションなど、様々なケースで容易に応用できます。フルーツのオンラインショッピングサイトにおいて、生産者直送の地産地消を推進するのであれば、以下のようなクエリで、購入者から地理的に近い商品を勧めることもできます。 ```auto GET items/_search { "query": { "function_score": { "score_mode": "sum", "query": { "match": { "name": "apple" } }, "linear": { "origin.location": { "origin": "35.68,139.69", "offset": "0", "scale": "300km" } } } } } ``` ## まとめ 検索順位を柔軟に、かつ自在に制御するヒントは得られましたでしょうか。パフォーマンスの観点からは、なるべくスクリプトによるスコア計算は、避けることが望ましいですし、Elasticsearchが提供している減衰（Decay）ファンクションは、より低コストで検索順位を制御できる機会を提供しますので、第一の候補として検討してください。 また、アプリケーション検索に特化した当社のサービスである、[Elastic App Search](https://swiftype.com/app-search)を用いると、GUIを用いて[関連性をチューニング](https://swiftype.com/documentation/app-search/guides/relevance-tuning)することができます。条件に応じた検索結果をその場でリアルタイムに確認できたり、アプリケーション開発者の手を煩わせることなく検索順位を制御することができます。この他にも便利なAPIや検索UIのリファレンスなども提供していますので、アプリケーション開発の工数を著しく削減します。ぜひ[お試し](https://app.swiftype.com/signup?utm_channel=web-home)ください。 ---
**Author:** ![warkolm](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/warkolm/32/39224_2.png) [@warkolm](https://discuss.elastic.co/u/warkolm)\ **Post date:** [December 1, 2019, 10:36pm UTC](https://discuss.elastic.co/t/dec-6th-2018-jp-elasticsearch/159442/2 "2019-12-01T22:36:18Z")