Lucene’s Practical Scoring Function

https://www.elastic.co/guide/en/elasticsearch/guide/current/practical-scoring-function.html
For multiterm queries, Lucene takes the Boolean model, TF/IDF, and the vector space model and combines them in a single efficient package that collects matching documents and scores them as it goes.
여러 단어로 구성된 조회에 대해 Lucene은 일치하는 결과집을 봉인하고 boolean모델, tf/idf, 벡터 공간모델 등 조건을 결합하여 그들의 값을 계산했다
다음querydsl,multitermquery

GET /my_index/doc/_search
{
  "query": {
    "match": {
      "text": "quick fox"
    }
  }
}

es 내부에서는 다음과 같이 다시 쓰여집니다.

GET /my_index/doc/_search
{
  "query": {
    "bool": {
      "should": [
        {"term": { "text": "quick" }},
        {"term": { "text": "fox"   }}
      ]
    }
  }
}

이boolquery는boolean모델을 실현하였으며, 이 예에서는quick과fox를 포함하는 문서만 명중할 수 있습니다.
문서가 검색에 일치하면, 루틴은 모든 일치하는 단어를 결합시키기 위해 이query의 값을 계산합니다.이 계산 값의 공식은practical 값 함수라고 불린다.그것은 보기에는 매우 무섭지만, 실제로, 일부 구성 요소는 네가 이미 알고 있는 것이다. 다음은 새로운 요소를 토론할 것이다.

score(q,d)  =    # is the relevance score of document d for query q.
            queryNorm(q)  #  .
          · coord(q,d)    # .
          · ∑ (           # query term .
                tf(t in d)   #  
              · idf(t)²      
              · t.getBoost() 
              · norm(t,d)    
            ) (t in q)    

Query Normalization Factor

The query normalization factor (queryNorm) is an attempt to normalize a query so that the results from one query may be compared with the results of another. 서로 다른query 사이를 더욱 잘 비교하다.
그것은 좋은 일을 할 수 없으니, 그것으로 다른query의 결과를 비교할 필요가 없다.This factor is calculated at the beginning of the query. The actualcalculation depends on the queries involved,but a typical implementation is as follows: 이 인자는query가 시작될 때 계산합니다.

queryNorm = 1 / √sumOfSquaredWeights 

sumOfSquaredWeights의 계산 방법은query에 있는 모든term의 idf값을 합쳐서 제곱을 구하는 것이다
모든 문서의 귀일화 인자는 같고, 너는 그것의 값을 바꿀 수 없다.네가 무엇을 하든지 간에 너는 그것을 소홀히 할 수 있다

Query Coordination

조율 인자는 비교적 높은 비율term을 포함하는 문서를 장려하는 데 쓰인다.문서에 나타나는terms가 많을수록document가query와 일치하는 비율이 크다는 것을 의미합니다.
만약에 우리가query'quick brown fox'를 가지고 있다면, 각각term의 권한은 1.5이고, 조율 인자가 없다면, 점수는 각각term의

Document with fox → score: 1.5

Document with quick fox → score: 3.0

Document with quick brown fox → score: 4.5

조율 인자는 문서에 일치하는term의 수량을 곱하고 일치하는term의 총수를 나눈다.조화 인자가 있으면 점수는 다음과 같은 구법으로 변한다.

Document with fox → score: 1.5 * 1/3 = 0.5

Document with quick fox → score: 3.0 * 2/3 = 2.0

Document with quick brown fox → score: 4.5 * 3/3 = 4.5

조화 인자의 역할은 3개의term를 포함하는 문서를 두 단어를 포함하는 문서보다 더 관련시키는 것이다.
Quick brown fox는 boolquery에 다시 기록됩니다. 이렇게.

GET /_search
{
  "query": {
    "bool": {
      "should": [
        { "term": { "text": "quick" }},
        { "term": { "text": "brown" }},
        { "term": { "text": "fox"   }}
      ]
    }
  }
}

boolquery는 기본적으로 모든should 조건에 조화 인자를 적용합니다.coordination을 비활성화할 수 있지만, 일반적으로 이렇게 하지 않습니다.query 조화인자의 작용은 긍정적이다.예를 들어 일치하는 검색을 포장하기 위해boolquery를 사용하면 조화로운 사용도 의미가 있습니다.더 많은 조건이 일치하기 때문에 검색 요청과 일치하는 문서가 되돌아옵니다.
그러나 일부 고급 용례에서 조화를 사용하지 않는 것은 의미가 있을 수 있다.같은 의미의jump,leap,hop를 찾고 있다고 가정하십시오.너는 이 동의어들이 얼마나 많은지 관심을 갖지 않는다. 왜냐하면 그들은 모두 같은 개념을 대표하기 때문이다.사실상 동의어 하나만 나올 가능성이 높다.이것은 조화 인자를 사용하지 않는 좋은 예가 될 것이다.

GET /_search
{
  "query": {
    "bool": {
      "disable_coord": true,
      "should": [
        { "term": { "text": "jump" }},
        { "term": { "text": "hop"  }},
        { "term": { "text": "leap" }}
      ]
    }
  }
}

동의어를 사용할 때query에서 다시 쓸 때es 내부에서 자동으로 동의어에 대해coordination을 사용하지 않습니다.대부분의 경우 조율을 사용하지 않는 것은 자동으로 처리된다.걱정할 필요 없어.

Index-Time Field-Level Boosting

Query-Time Boosting을 통해 조회할 때 다른 필드보다 한 필드의 권한을 높이는 방법을 토론할 것입니다.색인 시간에 필드에 Boost를 적용할 수도 있습니다. 실제로 이 권한은 이 필드의 모든 term에 적용되며, 필드 자체에 적용되지 않습니다.
To store this boost value in the index without using more space than necessary, this field-level index-time boost is combined with the field-length norm (see Field-length norm) and stored in the index as a single byte. This is the value returned by norm(t,d) in the preceding formula.
We strongly recommend against using field-level index-time boosts for a few reasons:

Combining the boost with the field-length norm and storing it in a single byte means that the field-length norm loses precision. The result is that Elasticsearch is unable to distinguish between a field containing three words and a field containing five words.

To change an index-time boost, you have to reindex all your documents. A query-time boost, on the other hand, can be changed with every query.

If a field with an index-time boost has multiple values, the boost is multiplied by itself for every value, dramatically increasing the weight for that field.

Query-time boosting is a much simpler, cleaner, more flexible option.Query-time boosting is a much simpler, cleaner, more flexible option.
With query normalization, coordination, and index-time boosting out of the way, we can now move on to the most useful tool for influencing the relevance calculation: query-time boosting.