[[boosting-by-popularity]]
=== Boosting by Popularity
Imagine that we have a website that hosts blog posts and enables users to vote for the
blog posts that they like.((("relevance", "controlling", "boosting by popularity")))((("popularity", "boosting by")))((("boosting", "by popularity"))) We would like more-popular posts to appear higher in the
results list, but still have the full-text score as the main relevance driver.
We can do this easily by storing the number of votes with each blog post:
[role="pagebreak-before"]
[source,json]
-------------------------------
PUT /blogposts/post/1
{
"title": "About popularity",
"content": "In this post we will talk about...",
"votes": 6
}
-------------------------------
At search time, we can use the `function_score` query ((("function_score query", "field_value_factor function")))((("field_value_factor function")))with the
`field_value_factor` function to combine the number of votes with the full-text relevance score:
[source,json]
-------------------------------
GET /blogposts/post/_search
{
"query": {
"function_score": { <1>
"query": { <2>
"multi_match": {
"query": "popularity",
"fields": [ "title", "content" ]
}
},
"field_value_factor": { <3>
"field": "votes" <4>
}
}
}
}
-------------------------------
<1> The `function_score` query wraps the main query and the function we would
like to apply.
<2> The main query is executed first.
<3> The `field_value_factor` function is applied to every document matching
the main `query`.
<4> Every document _must_ have a number in the `votes` field for
the `function_score` to work.
In the preceding example, the final `_score` for each document has been altered as
follows:
new_score = old_score * number_of_votes
This will not give us great results. The full-text `_score` range
usually falls somewhere between 0 and 10. As can be seen in <<img-popularity-linear>>, a blog post with 10 votes will
completely swamp the effect of the full-text score, and a blog post with 0
votes will reset the score to zero.
[[img-popularity-linear]]
.Linear popularity based on an original `_score` of `2.0`
image::images/elas_1701.png[Linear popularity based on an original `_score` of `2.0`]
==== modifier
A better way to incorporate popularity is to smooth out the `votes` value
with some `modifier`. ((("modifier parameter")))((("field_value_factor function", "modifier parameter")))In other words, we want the first few votes to count a
lot, but for each subsequent vote to count less. The difference between 0
votes and 1 vote should be much bigger than the difference between 10 votes
and 11 votes.
A typical `modifier` for this use case is `log1p`, which changes the formula
to the following:
new_score = old_score * log(1 + number_of_votes)
The `log` function smooths out the effect of the `votes` field to provide a
curve like the one in <<img-popularity-log>>.
[[img-popularity-log]]
.Logarithmic popularity based on an original `_score` of `2.0`
image::images/elas_1702.png[Logarithmic popularity based on an original `_score` of `2.0`]
The request with the `modifier` parameter looks like the following:
[source,json]
-------------------------------
GET /blogposts/post/_search
{
"query": {
"function_score": {
"query": {
"multi_match": {
"query": "popularity",
"fields": [ "title", "content" ]
}
},
"field_value_factor": {
"field": "votes",
"modifier": "log1p" <1>
}
}
}
}
-------------------------------
<1> Set the `modifier` to `log1p`.
[role="pagebreak-before"]
The available modifiers are `none` (the default), `log`, `log1p`, `log2p`,
`ln`, `ln1p`, `ln2p`, `square`, `sqrt`, and `reciprocal`. You can read more
about them in the
http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/query-dsl-function-score-query.html#_field_value_factor[`field_value_factor` documentation].
==== factor
The strength of the popularity effect can be increased or decreased by
multiplying the value((("factor (function_score)")))((("field_value_factor function", "factor parameter"))) in the `votes` field by some number, called the
`factor`:
[source,json]
-------------------------------
GET /blogposts/post/_search
{
"query": {
"function_score": {
"query": {
"multi_match": {
"query": "popularity",
"fields": [ "title", "content" ]
}
},
"field_value_factor": {
"field": "votes",
"modifier": "log1p",
"factor": 2 <1>
}
}
}
}
-------------------------------
<1> Doubles the popularity effect
Adding in a `factor` changes the formula to this:
new_score = old_score * log(1 + factor * number_of_votes)
A `factor` greater than `1` increases the effect, and a `factor` less than `1`
decreases the effect, as shown in <<img-popularity-factor>>.
[[img-popularity-factor]]
.Logarithmic popularity with different factors
image::images/elas_1703.png[Logarithmic popularity with different factors]
==== boost_mode
Perhaps multiplying the full-text score by the result of the
`field_value_factor` function ((("function_score query", "boost_mode parameter")))((("boost_mode parameter")))still has too large an effect. We can control
how the result of a function is combined with the `_score` from the query by
using the `boost_mode` parameter, which accepts the following values:
`multiply`::
Multiply the `_score` with the function result (default)
`sum`::
Add the function result to the `_score`
`min`::
The lower of the `_score` and the function result
`max`::
The higher of the `_score` and the function result
`replace`::
Replace the `_score` with the function result
If, instead of multiplying, we add the function result to the `_score`, we can
achieve a much smaller effect, especially if we use a low `factor`:
[source,json]
-------------------------------
GET /blogposts/post/_search
{
"query": {
"function_score": {
"query": {
"multi_match": {
"query": "popularity",
"fields": [ "title", "content" ]
}
},
"field_value_factor": {
"field": "votes",
"modifier": "log1p",
"factor": 0.1
},
"boost_mode": "sum" <1>
}
}
}
-------------------------------
<1> Add the function result to the `_score`.
The formula for the preceding request now looks like this (see <<img-popularity-sum>>):
new_score = old_score + log(1 + 0.1 * number_of_votes)
[[img-popularity-sum]]
.Combining popularity with `sum`
image::images/elas_1704.png["Combining popularity with `sum`"]
==== max_boost
Finally, we can cap the maximum effect((("function_score query", "max_boost parameter")))((("max_boost parameter"))) that the function can have by using the
`max_boost` parameter:
[source,json]
-------------------------------
GET /blogposts/post/_search
{
"query": {
"function_score": {
"query": {
"multi_match": {
"query": "popularity",
"fields": [ "title", "content" ]
}
},
"field_value_factor": {
"field": "votes",
"modifier": "log1p",
"factor": 0.1
},
"boost_mode": "sum",
"max_boost": 1.5 <1>
}
}
}
-------------------------------
<1> Whatever the result of the `field_value_factor` function, it will never be
greater than `1.5`.
NOTE: The `max_boost` applies a limit to the result of the function only, not
to the final `_score`.
- Introduction
- 入門
- 是什么
- 安裝
- API
- 文檔
- 索引
- 搜索
- 聚合
- 小結
- 分布式
- 結語
- 分布式集群
- 空集群
- 集群健康
- 添加索引
- 故障轉移
- 橫向擴展
- 更多擴展
- 應對故障
- 數據
- 文檔
- 索引
- 獲取
- 存在
- 更新
- 創建
- 刪除
- 版本控制
- 局部更新
- Mget
- 批量
- 結語
- 分布式增刪改查
- 路由
- 分片交互
- 新建、索引和刪除
- 檢索
- 局部更新
- 批量請求
- 批量格式
- 搜索
- 空搜索
- 多索引和多類型
- 分頁
- 查詢字符串
- 映射和分析
- 數據類型差異
- 確切值對決全文
- 倒排索引
- 分析
- 映射
- 復合類型
- 結構化查詢
- 請求體查詢
- 結構化查詢
- 查詢與過濾
- 重要的查詢子句
- 過濾查詢
- 驗證查詢
- 結語
- 排序
- 排序
- 字符串排序
- 相關性
- 字段數據
- 分布式搜索
- 查詢階段
- 取回階段
- 搜索選項
- 掃描和滾屏
- 索引管理
- 創建刪除
- 設置
- 配置分析器
- 自定義分析器
- 映射
- 根對象
- 元數據中的source字段
- 元數據中的all字段
- 元數據中的ID字段
- 動態映射
- 自定義動態映射
- 默認映射
- 重建索引
- 別名
- 深入分片
- 使文本可以被搜索
- 動態索引
- 近實時搜索
- 持久化變更
- 合并段
- 結構化搜索
- 查詢準確值
- 組合過濾
- 查詢多個準確值
- 包含,而不是相等
- 范圍
- 處理 Null 值
- 緩存
- 過濾順序
- 全文搜索
- 匹配查詢
- 多詞查詢
- 組合查詢
- 布爾匹配
- 增加子句
- 控制分析
- 關聯失效
- 多字段搜索
- 多重查詢字符串
- 單一查詢字符串
- 最佳字段
- 最佳字段查詢調優
- 多重匹配查詢
- 最多字段查詢
- 跨字段對象查詢
- 以字段為中心查詢
- 全字段查詢
- 跨字段查詢
- 精確查詢
- 模糊匹配
- Phrase matching
- Slop
- Multi value fields
- Scoring
- Relevance
- Performance
- Shingles
- Partial_Matching
- Postcodes
- Prefix query
- Wildcard Regexp
- Match phrase prefix
- Index time
- Ngram intro
- Search as you type
- Compound words
- Relevance
- Scoring theory
- Practical scoring
- Query time boosting
- Query scoring
- Not quite not
- Ignoring TFIDF
- Function score query
- Popularity
- Boosting filtered subsets
- Random scoring
- Decay functions
- Pluggable similarities
- Conclusion
- Language intro
- Intro
- Using
- Configuring
- Language pitfalls
- One language per doc
- One language per field
- Mixed language fields
- Conclusion
- Identifying words
- Intro
- Standard analyzer
- Standard tokenizer
- ICU plugin
- ICU tokenizer
- Tidying text
- Token normalization
- Intro
- Lowercasing
- Removing diacritics
- Unicode world
- Case folding
- Character folding
- Sorting and collations
- Stemming
- Intro
- Algorithmic stemmers
- Dictionary stemmers
- Hunspell stemmer
- Choosing a stemmer
- Controlling stemming
- Stemming in situ
- Stopwords
- Intro
- Using stopwords
- Stopwords and performance
- Divide and conquer
- Phrase queries
- Common grams
- Relevance
- Synonyms
- Intro
- Using synonyms
- Synonym formats
- Expand contract
- Analysis chain
- Multi word synonyms
- Symbol synonyms
- Fuzzy matching
- Intro
- Fuzziness
- Fuzzy query
- Fuzzy match query
- Scoring fuzziness
- Phonetic matching
- Aggregations
- overview
- circuit breaker fd settings
- filtering
- facets
- docvalues
- eager
- breadth vs depth
- Conclusion
- concepts buckets
- basic example
- add metric
- nested bucket
- extra metrics
- bucket metric list
- histogram
- date histogram
- scope
- filtering
- sorting ordering
- approx intro
- cardinality
- percentiles
- sigterms intro
- sigterms
- fielddata
- analyzed vs not
- 地理坐標點
- 地理坐標點
- 通過地理坐標點過濾
- 地理坐標盒模型過濾器
- 地理距離過濾器
- 緩存地理位置過濾器
- 減少內存占用
- 按距離排序
- Geohashe
- Geohashe
- Geohashe映射
- Geohash單元過濾器
- 地理位置聚合
- 地理位置聚合
- 按距離聚合
- Geohash單元聚合器
- 范圍(邊界)聚合器
- 地理形狀
- 地理形狀
- 映射地理形狀
- 索引地理形狀
- 查詢地理形狀
- 在查詢中使用已索引的形狀
- 地理形狀的過濾與緩存
- 關系
- 關系
- 應用級別的Join操作
- 扁平化你的數據
- Top hits
- Concurrency
- Concurrency solutions
- 嵌套
- 嵌套對象
- 嵌套映射
- 嵌套查詢
- 嵌套排序
- 嵌套集合
- Parent Child
- Parent child
- Indexing parent child
- Has child
- Has parent
- Children agg
- Grandparents
- Practical considerations
- Scaling
- Shard
- Overallocation
- Kagillion shards
- Capacity planning
- Replica shards
- Multiple indices
- Index per timeframe
- Index templates
- Retiring data
- Index per user
- Shared index
- Faking it
- One big user
- Scale is not infinite
- Cluster Admin
- Marvel
- Health
- Node stats
- Other stats
- Deployment
- hardware
- other
- config
- dont touch
- heap
- file descriptors
- conclusion
- cluster settings
- Post Deployment
- dynamic settings
- logging
- indexing perf
- rolling restart
- backup
- restore
- conclusion