[Elasticsearch] 제어 상관 관계 (4) - TF/IDF 무시

이 장은 Elasticsearch 공식 안내서의 Controlling Relevance 장에서 번역되었습니다.

TF/IDF 무시

때로는 TF/IDF가 필요하지 않습니다.우리가 알고 싶은 것은 단지 특정한 단어가 필드에 나타났는지 여부일 뿐이다.예를 들어 우리는 리조트 호텔을 검색하고 있는데 그것이 가지고 있는 매점이 많을수록 좋기를 바란다.

WiFi

Garden

수영장

리조트 호텔에 대한 문서는 다음과 같다.

{ "description": "A delightful four-bedroomed house with ... " }

간단한 match 쿼리를 사용할 수 있습니다.

GET /_search
{
  "query": {
    "match": {
      "description": "wifi garden pool"
    }
  }
}

그러나 우리가 필요로 하는 것은 진정한 전문 검색이 아니다.이때 TF/IDF는 방해만 됩니다.우리는 와이파이가 흔히 볼 수 있는 단어인지, 문서에 자주 등장하는지 신경 쓰지 않는다.우리가 신경 쓰는 것은 단지 그것이 나타났는지의 여부일 뿐이다.실제로 우리는 단지 판매점을 통해 이 리조트 호텔들을 정렬하고 싶을 뿐이다. - 많을수록 좋다.만약 판매점을 가지고 있다면, 그것의 점수는 1이고, 그것의 점수가 없다면 0이다.

constant_score 조회

먼저 constant_ 소개score 조회.쿼리에는 TF/IDF를 고려하지 않고 일치하는 모든 문서의 상관 관계 구분 값이 1인 쿼리나 필터가 포함될 수 있습니다.

GET /_search
{
  "query": {
    "bool": {
      "should": [
        { "constant_score": {
          "query": { "match": { "description": "wifi" }}
        }},
        { "constant_score": {
          "query": { "match": { "description": "garden" }}
        }},
        { "constant_score": {
          "query": { "match": { "description": "pool" }}
        }}
      ]
    }
  }
}

아마도 모든 매점이 똑같이 중요한 것은 아닐 것이다. - 그중의 일부는 더욱 가치가 있다.만약 가장 마음에 드는 포인트가 수영장이라면 우리는 그것에 대해 상응하는 향상을 진행할 수 있다.

GET /_search
{
  "query": {
    "bool": {
      "should": [
        { "constant_score": {
          "query": { "match": { "description": "wifi" }}
        }},
        { "constant_score": {
          "query": { "match": { "description": "garden" }}
        }},
        { "constant_score": {
          "boost":   2 
          "query": { "match": { "description": "pool" }}
        }}
      ]
    }
  }
}

NOTE
모든 결과의 최종 값은 모든 일치하는 자구의 값을 누적해서 얻을 수 있는 것이 아니다.Coordination 인자와 쿼리 요약 인자(Query Normalization Factor)는 여전히 고려될 것이다.
우리는 리조트 호텔 문서에 not_를 추가할 수 있다analyzed 형식의 features 필드:

{ "features": [ "wifi", "pool", "garden" ] }

기본적으로 not_analyzed 필드의 필드 길이 요약(Field-length Norm)은 비활성화되며 index_옵션도 docs로 설정되어 단어 주파수 (Term Frequencies) 를 사용하지 않지만, 문제는 여전히 존재합니다. 단어마다 역렬 문서 주파수 (Inverse Document Frequency) 가 고려됩니다.
여전히 constant_ 사용score 쿼리:

GET /_search
{
  "query": {
    "bool": {
      "should": [
        { "constant_score": {
          "query": { "match": { "features": "wifi" }}
        }},
        { "constant_score": {
          "query": { "match": { "features": "garden" }}
        }},
        { "constant_score": {
          "boost":   2
          "query": { "match": { "features": "pool" }}
        }}
      ]
    }
  }
}

실제로 모든 판매점은 필터로 간주되어야 한다.리조트 호텔은 이 매장이 있거나 없거나 필터를 사용하는 것이 더 자연스러운 선택인 것 같다.그리고 만약 우리가 필터를 사용했다면, 필터 캐시 기능 덕분일 것이다.
필터를 사용하지 않는 근원은 필터가 관련도 값을 계산하지 않는다는 데 있다.우리가 필요로 하는 것은 필터와 조회를 연결하는 다리이다.반면 function_score 조회는 이 점을 할 수 있을 뿐만 아니라 더 많은 기능을 제공할 수 있다.