[[pluggable-similarites]]
=== Pluggable Similarity Algorithms
Before we move on from relevance and scoring, we will finish this chapter with
a more advanced subject: pluggable similarity algorithms.((("similarity algorithms", "pluggable")))((("relevance", "controlling", "using pluggable similarity algorithms"))) While Elasticsearch
uses the <<practical-scoring-function>> as its default similarity algorithm,
it supports other algorithms out of the box, which are listed
in the http://bit.ly/14Eiw7f[Similarity Modules] documentation.
[[bm25]]
==== Okapi BM25
The most interesting competitor to TF/IDF and the vector space model is called
http://en.wikipedia.org/wiki/Okapi_BM25[_Okapi BM25_], which is considered to
be a _state-of-the-art_ ranking function.((("BM25")))((("Okapi BM25", see="BM25"))) BM25 originates from the
http://en.wikipedia.org/wiki/Probabilistic_relevance_model[probabilistic relevance model],
rather than the vector space model, yet((("probabalistic relevance model"))) the algorithm has a lot in common with
Lucene's practical scoring function.
Both use of term frequency, inverse document frequency, and field-length
normalization, but the definition of each of these factors is a little
different. Rather than explaining the BM25 formula in detail, we will focus
on the practical advantages that BM25 offers.
[[bm25-saturation]]
===== Term-frequency saturation
Both TF/IDF and BM25 use <<idf,inverse document frequency>> to distinguish
between common (low value) words and uncommon (high value) words.((("inverse document frequency", "use by TF/IDF and BM25"))) Both also
recognize (see <<tf>>) that the more often a word appears in a document, the
more likely is it that the document is relevant for that word.
However, common words occur commonly. ((("BM25", "term frequency saturation"))) The fact that a common word appears
many times in one document is offset by the fact that the word appears many
times in _all_ documents.
However, TF/IDF was designed in an era when it was standard practice to
remove the _most_ common words (or _stopwords_, see <<stopwords>>) from the
index altogether.((("stopwords", "removal from index"))) The algorithm didn't need to worry about an upper limit for
term frequency because the most frequent terms had already been removed.
In Elasticsearch, the `standard` analyzer--the default for `string` fields--doesn't remove stopwords because, even though they are words of little
value, they do still have some value. The result is that, for very long
documents, the sheer number of occurrences of words like `the` and `and` can
artificially boost their weight.
BM25, on the other hand, does have an upper limit. Terms that appear 5 to 10
times in a document have a significantly larger impact on relevance than terms
that appear just once or twice. However, as can be seen in <<img-bm25-saturation>>, terms that appear 20 times in a
document have almost the same impact as terms that appear a thousand times or
more.
This is known as _nonlinear term-frequency saturation_.
[[img-bm25-saturation]]
.Term frequency saturation for TF/IDF and BM25
image::images/elas_1706.png[Term frequency saturation for TF/IDF and BM25]
[[bm25-normalization]]
===== Field-length normalization
In <<field-norm>>, we said that Lucene considers shorter fields to have
more weight than longer fields: the frequency of a term in a field is offset
by the length of the field. However, the practical scoring function treats
all fields in the same way. It will treat all `title` fields (because they
are short) as more important than all `body` fields (because they are long).
BM25 also considers shorter fields to have more weight than longer fields, but
it considers each field separately by taking the average length of the field
into account. It can distinguish between a short `title` field and a `long`
title field.
CAUTION: In <<query-time-boosting>>, we said that the `title` field has a
_natural_ boost over the `body` field because of its length. This natural
boost disappears with BM25 as differences in field length apply only within a
single field.
[[bm25-tunability]]
===== Tuning BM25
One of the nice features of BM25 is that, unlike TF/IDF, it has two parameters
that allow it to be tuned:
`k1`::
This parameter controls how quickly an increase in term frequency results
in term-frequency saturation. The default value is `1.2`. Lower values
result in quicker saturation, and higher values in slower saturation.
`b`::
This parameter controls how much effect field-length normalization should
have. A value of `0.0` disables normalization completely, and a value of
`1.0` normalizes fully. The default is `0.75`.
The practicalities of tuning BM25 are another matter. The default values for
`k1` and `b` should be suitable for most document collections, but the
optimal values really depend on the collection. Finding good values for your
collection is a matter of adjusting, checking, and adjusting again.
- 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