jjeong

다국어 지원시 인덱스 모델링 시 type 을 사용하지 말라는 주의 문구가 있어서 기록 합니다.

혹시라도 type 을 통한 구성을 고민 하고 계셨다면 한번 읽어 보시면 좋을 것 같습니다.

원문링크)

원문 Snippet)

여러 필드에 질의 할 때 문서에 대한 score 계산시 가장 relevant 한 결과를 만들어 내기 위해 사용하는 기법이라고 보면 될 것 같습니다.

하지만 기능적으로 어떤의미를 갖는지를 알아야 응용이 가능 하겠습니다.

원문링크)

원문 Snippet)

가볍게 요약하면 이렇습니다.

- best fields 는 가장 적합한 field 의 score 를 리턴 합니다.

- most fields 는 field 들의 score 를 더한 값을 리턴 합니다.

- cross fields 는 field 들을 섞어서 score 를 계산 하여 리턴 합니다. (field 들 중 최소의 idf 값을 사용 합니다.)

여러 종류의 언어가 섞여 있는 경우에 대한 이야기 입니다.

다국어 지원 자체는 기능적 요건에 따라 구현 방법이 달라 질 수 있기 때문에 고민을 많이 할 수 밖에 없는 것 같습니다.

Elasticsearch 에서는 쉬운 접근법으로 _all 과 custom all (copy_to, multi fields) 기능을 제시해 주고 있습니다.

이 글에서는 저 한테 필요한 내용인 language detection 관련 링크가 있어 기록해 봅니다.

원문링크)

Language Detection)

글 제목과 비슷할 수도 다를 수도 있습니다.

precision 과 recall 에 대한 설명이 짧게 잘 표현이 되어 있어서 기록해 봅니다.

원문링크)

원문 Snippet)

원래 이 문서는 언어에 대한 처리 목적 이였습니다.

그래서 정의한 5가지 title 만 정리해 봤습니다.

- Normalizing Tokens

추출 된 token 에서 필요 없는 character를 제거 합니다.

- Reducing Words To Their Root Form

Word 에 붙은 불필요한 정보를 제거 합니다. (word의 origin을 만든다고 보시면 쉽습니다.)

- Stopwords

불용어 처리를 합니다. (즉, 색인 대상에서 제외 시킵니다.)

- Synonyms

동의어 또는 유의어 처리를 합니다.

- Typoes and Mispelings

오타 처리를 합니다.

Relevance 관련 글이 많아서 일단 한번쯤은 꼭 읽어 봐야 하는 글만 모아 봤습니다.

원문링크)

https://www.elastic.co/guide/en/elasticsearch/guide/current/query-scoring.html

- 이 글에서는 bool query에 대한 query competition 에 대한 내용이 포함 되어 있습니다.

https://www.elastic.co/guide/en/elasticsearch/guide/current/not-quite-not.html

- 이 글에서는 boosting query에 대한 내용이 포함 되어 있습니다.

https://www.elastic.co/guide/en/elasticsearch/guide/current/ignoring-tfidf.html

- 이 글에서는 constant_score query에 대한 내용이 포함 되어 있습니다.

- 즉, 모든 점수가 1로 나오며, boosting 설정 값에 따라 score 를 부여하게 됩니다.

https://www.elastic.co/guide/en/elasticsearch/guide/current/boosting-by-popularity.html

- 이 글에서는 function_score query에 대한 내용이 포함 되어 있습니다.

그냥 좋은 내용이라 기록 합니다.

원문링크)

원문 Snippet)

짧게 정리 하면)

- query-time operation 은 비용이 들지만 flexible 하다.

- index-time operation 은 색인 성능이 떨어지고 저장공간이 늘어 날 수 있지만 질의 성능이 좋아지고 더욱 유연하게 사용할 수 있게 해준다.

문서에 대한 relevance를 어떻게 구현해야 비용이 적게 들까? 고민 해보신 적이 있을 실겁니다.

꼭 이 글이 일치 하지는 않지만 match query 사용 시 비싼 비용을 지불하지 말고 indexing time 에 활용을 한번 해보면 어떨까 하는 아이디어에서 나온 글로 보시면 어떨까 합니다.

그런 의미에서 기록해 봤습니다.

원문링크)

원문 Snippet)

※ shingles 란? 쉽게 token(term)들에 대한 ngram 이라고 이해 하시면 쉽습니다.

결국 검색 질의 시 slop 이나 position_offset_gap 기능을 이용하는 것 보다 색인 시 shigles analyzed 를 통해 질의 비용을 줄이는 것이라고 보시면 됩니다.

단, 문서에도 있지만 저장 공간이 늘어 나게 됩니다.

검색 질의에 대한 성능 향상 관련 글 입니다.

한번 쯤 읽어 보시면 좋을 것 같아 기록 합니다.

원문링크)

요약)

- term query 가 match query 종류 보다 10배 에서 20배 빠릅니다.

- 그렇다고 해서 match query 종류가 느린것은 아닙니다. ( 수 밀리초 내 응답 합니다.)

- slop, position_offset_gap 과 같은 속성 사용에 대한 이해가 필요합니다.

Rescoring 이라는 것이 나오는데요.

이건 function_score 랑도 비슷합니다.

하지만 두 개의 목적은 비슷하지만 사용법은 다르죠.

결과적으로 두 API 다 개별 shard 에서의 top N 개의 문서를 가지고 다시 rescoring 하게 된다는 것입니다.

match query type 중 phrase 에 대한 이해를 돕기 위해 기록 합니다.

원문링크)

https://www.elastic.co/guide/en/elasticsearch/guide/current/phrase-matching.html

원문 Snippet)

What Is a Phraseedit

For a document to be considered a match for the phrase “quick brown fox,” the following must be true:

• quick, brown, and fox must all appear in the field.
• The position of brown must be 1 greater than the position of quick.
• The position of fox must be 2 greater than the position of quick.

If any of these conditions is not met, the document is not considered a match.

Internally, the match_phrase query uses the low-level span query family to do position-aware matching. Span queries are term-level queries, so they have no analysis phase; they search for the exact term specified.

Thankfully, most people never need to use the span queries directly, as the match_phrasequery is usually good enough. However, certain specialized fields, like patent searches, use these low-level queries to perform very specific, carefully constructed positional searches.

다시 한번 정리 하면,

- position-aware matching 을 이용하는 span query

- 첫번째 term 에 대한 position에 의해 나머지 term 들의 matching position 은 quick의 position 보다 커야 합니다.

주의 사항이라 기록해 봅니다.

원문링크)

원문 Snippet)