Jhon Guzmán - Elasticsearch Labs

판단 목록을 사용하여 검색 쿼리의 관련성을 평가합니다.

Jhon Guzmán — Thu, 11 Dec 2025 00:00:00 GMT

검색 엔진을 개발하는 개발자들은 종종 같은 문제를 겪습니다. 비즈니스 팀이 특정 검색 결과에 만족하지 못하는데, 기대했던 문서가 검색 결과 상단이 아니라 3~4번째에 표시되기 때문입니다.

그러나 모든 케이스를 수동으로 테스트할 수 없기 때문에, 한 가지 문제를 해결하면 실수로 다른 쿼리가 손상될 수 있습니다. 하지만 특정 쿼리를 변경했을 때 다른 쿼리에 파급 효과를 미치는지 사용자 또는 QA 팀이 어떻게 테스트할 수 있을까요? 더 중요한 것은 변경 사항이 실제로 쿼리를 개선했는지 어떻게 확인할 수 있을까요?

체계적인 평가를 향해

이때 판단 목록이 유용하게 작용합니다. 변경할 때마다 수동 및 주관적 테스트에 의존하는 대신, 비즈니스 사례와 관련된 고정된 쿼리 세트와 해당 결과를 정의할 수 있습니다.

이 세트가 기준이 됩니다. 변경 사항을 구현할 때마다 검색이 실제로 개선되었는지 여부를 평가합니다.

이 접근 방식의 가치는 다음과 같습니다:

불확실성 제거: 변경 사항이 다른 쿼리에 영향을 미치는지를 데이터가 알려줍니다.
수동 테스트 중지: 판단 세트가 기록되면 테스트가 자동으로 진행됩니다.
변경 지원: 변경의 이점을 뒷받침하는 명확한 메트릭을 표시할 수 있습니다.

판단 목록을 만드는 방법

가장 쉽게 시작하는 방법 중 하나는 대표 검색어를 선택하고 관련 문서를 수동으로 고르는 것입니다. 이 목록을 작성할 때 두 가지 방법을 사용할 수 있습니다.

이진 판단: 쿼리와 연관된 각 문서에 관련 있음(보통 점수 1)과 관련 없음(0)이라는 간단한 태그가 붙습니다.
등급별 판단: 여기서는 문서마다 다른 수준의 점수가 매겨집니다. 예를 들어, Likert 척도와 유사하게 0~4 척도를 설정해 0은 '전혀 관련 없음', 4는 '매우 관련 있음'으로 정의하고, 그 사이에 '관련 있음', '어느 정도 관련 있음'과 같은 단계를 둘 수 있습니다.

이진 판단은 '이 문서가 결과에 포함되어야 하는가?'처럼 검색 의도에 명확한 한계가 있을 때 잘 작동합니다.

등급별 판단은 결과가 애매한 영역이 있을 때 더 유용합니다. 어떤 결과는 다른 결과보다 더 좋으므로 '매우 좋음', '좋음', '쓸모없음' 결과를 얻고, 결과의 순서와 사용자의 피드백을 중요시하는 메트릭을 사용할 수 있습니다. 그러나 등급 척도는 검토자마다 점수 수준을 다르게 사용해 판단의 일관성이 떨어질 수 있다는 단점도 갖고 있습니다. 또한 등급별 메트릭은 점수가 높으면 가중치를 더 많이 부여하기 때문에 작은 변화(예: 4점 대신 3점으로 평가)로도 검토자가 의도한 것보다 훨씬 더 큰 변화를 일으킬 수 있습니다. 이렇게 주관적인 요소가 추가되면 시간이 지남에 따라 등급별 판단이 더 복잡하고 관리하기 어려워집니다.

문서를 직접 분류해야 하나요?

반드시 그렇지는 않습니다. 판단 목록을 만드는 데는 여러 가지 방법이 있고 각각 고유한 장점과 단점이 있기 때문입니다.

명시적 판단: 여기서 중소기업은 각 쿼리/문서를 검토하고 관련성 여부(또는 방법)를 수동으로 결정합니다. 이는 품질과 제어 측면에서 장점을 제공하지만 확장성이 떨어집니다.
암묵적 판단: 이 방법은 클릭, 이탈률, 구매 등 실제 사용자 행동을 기반으로 관련 문서를 추론합니다. 이 방식을 사용하면 데이터를 자동으로 수집할 수 있지만 편향적일 수 있습니다. 예를 들어, 사용자들은 관련성이 없더라도 검색 결과 상단에 있는 항목을 더 자주 클릭하는 경향이 있습니다.
AI 생성 판단: 이 마지막 옵션은 모델(예: LLM)을 사용하여 쿼리와 문서를 자동으로 평가하며, 흔히 LLM 배심원단이라고도 합니다. 빠르고 쉽게 확장할 수 있지만, 데이터의 품질은 사용 중인 모델의 품질과 LLM 학습 데이터가 비즈니스 관심사와 얼마나 잘 부합하는지에 달려 있습니다. 인간의 평가와 마찬가지로, LLM 배심원단 역시 편향이나 불일치를 도입할 수 있으므로 신뢰할 수 있는 소규모의 판단과 비교하여 결과를 검증하는 것이 중요합니다. LLM 모델은 본질적으로 확률적이기 때문에 온도 파라미터를 0으로 설정해도 같은 결과에 대해 서로 다른 등급을 부여하는 경우가 많습니다.

다음은 판단 세트를 만드는 가장 좋은 방법을 선택하기 위한 몇 가지 권장 사항입니다.

가격, 브랜드, 언어, 스타일, 제품 세부정보 등 사용자만 제대로 판단할 수 있는 일부 기능의 중요도를 결정합니다. 중요한 사항이라면 최소한 판단 목록의 일부에 대한 명시적인 판단이 필요합니다.
검색 엔진 트래픽이 이미 충분하여 클릭, 전환, 체류 시간 등의 지표를 활용해 사용 추세를 파악할 수 있는 경우, 암묵적 판단을 사용하세요. 하지만 편향(예: 사용자는 하위 순위의 결과가 더 관련성이 높더라도 상위 순위의 결과를 더 자주 클릭하는 경향이 있음)을 방지하기 위해 명시적인 판단 기준과 대조하여 신중하게 해석해야 합니다.

이를 해결하기 위해, 위치 편향 제거 기술이 클릭 데이터를 조정하거나 가중치를 조정하여 사용자의 진정한 관심을 더 잘 반영합니다. 몇 가지 접근 방식은 다음과 같습니다.

결과 순서 변경: 일부 사용자를 대상으로 검색 결과 순서를 변경하여 순위가 클릭에 미치는 영향을 추정합니다.
클릭 모델에는동적 베이지안 네트워크 DBN, 사용자 브라우징 모델 UBM이 포함됩니다. 이러한 통계 모델은 스크롤, 체류 시간, 클릭 순서 및 결과 페이지로 돌아가는 등의 패턴을 사용하여 클릭이 단순한 위치가 아니라 실제 관심을 반영할 확률을 추정합니다.

예시: 영화 평점 앱

필수 구성 요소

이 예시를 실행하려면 Elasticsearch 8.x 클러스터가 로컬이나 Elastic Cloud Hosted(호스팅 또는 서버리스)를 실행하고, REST API 또는 Kibana에 접근할 수 있어야 합니다.

사용자가 영화에 대한 의견을 업로드하고 볼 영화를 검색할 수 있는 앱을 생각해 보세요. 사용자들이 직접 작성한 글이기 때문에 오타가 있거나, 표현 방식이 다양할 수 있습니다. 따라서 검색 엔진은 이러한 다양성을 해석하고 사용자에게 유용한 결과를 제공할 수 있어야 합니다.

전반적인 검색 동작에 영향을 주지 않고 쿼리를 반복적으로 수정할 수 있도록, 비즈니스 팀에서 가장 빈번하게 발생하는 검색어를 기반으로 다음과 같은 이진 판단 기준을 만들었습니다.

쿼리

DocID

텍스트

디카프리오의 연기

doc1

디카프리오의 '레버넌트: 죽음에서 돌아온 자'에서의 연기는 놀라웠다.

디카프리오의 연기

doc2

인셉션에서는 레오나르도 디카프리오가 그의 가장 상징적인 연기를 보여줍니다.

디카프리오의 연기

doc3

브래드 피트는 이 범죄 스릴러에서 탄탄한 연기를 선보입니다.

디카프리오의 연기

doc4

놀라운 시각 효과와 함께 액션으로 가득한 모험을 경험할 수 있다.

눈물을 흘리게 하는 슬픈 영화

doc5

가슴 아픈 사랑과 상실에 대한 이야기로 몇 시간 동안 눈물을 흘렸습니다.

눈물을 흘리게 하는 슬픈 영화

doc6

휴지가 꼭 필요한 슬픈 영화

눈물을 흘리게 하는 슬픈 영화

doc7

웃음을 자아내는 경쾌한 코미디 영화

눈물을 흘리게 하는 슬픈 영화

doc8

액션과 흥분으로 가득 찬 SF 대작.

인덱스 생성:

PUT movies { "mappings": { "properties": { "text": { "type": "text" } } } }

대량 요청:

POST /movies/_bulk { "index": { "_id": "doc1" } } { "text": "DiCaprio performance in The Revenant was breathtaking." } { "index": { "_id": "doc2" } } { "text": "Inception shows Leonardo DiCaprio in one of his most iconic roles." } { "index": { "_id": "doc3" } } { "text": "Brad Pitt delivers a solid performance in this crime thriller." } { "index": { "_id": "doc4" } } { "text": "An action-packed adventure with stunning visual effects." } { "index": { "_id": "doc5" } } { "text": "A heartbreaking story of love and loss that made me cry for hours." } { "index": { "_id": "doc6" } } { "text": "One of the saddest movies ever made -- bring tissues!" } { "index": { "_id": "doc7" } } { "text": "A lighthearted comedy that will make you laugh." } { "index": { "_id": "doc8" } } { "text": "A science-fiction epic full of action and excitement." }

아래는 앱이 사용하는 Elasticsearch 쿼리입니다.

GET movies/_search { "query": { "match": { "text": { "query": "DiCaprio performance", "minimum_should_match": "100%" } } } }

판단에서 지표로

판단 목록은 그 자체로 많은 정보를 제공하지 않으며, 단지 쿼리 결과를 예상할 수 있을 뿐입니다. 그러나 검색 성능을 측정하기 위해 객관적인 메트릭을 계산할 때가 되면 판단 목록이 그 진가를 발휘합니다.

요즘 가장 많이 사용되는 메트릭은 다음과 같습니다.

정확도: 전체 검색 결과 중 실제 관련성이 있는 결과의 비율을 측정합니다.
리콜: 검색 엔진이 찾은 x개의 결과 중에서 관련성 있는 결과의 비율을 측정합니다.
할인 누적 이득(DCG):결과 순위의 품질을 측정하며, 가장 관련성이 높은 결과가 최상위에 있어야 한다고 판단합니다.
평균 상호 순위(MRR): 첫 번째 관련 결과의 위치를 측정합니다. 목록에서 높은 위치에 있을수록 점수가 높아집니다.

동일한 영화 평점 앱을 예로 들어 리콜 메트릭을 계산하여 쿼리에서 누락된 정보가 있는지 확인해 보겠습니다.

Elasticsearch에서는 판단 목록을 사용하여 순위 평가 API를 통해 메트릭을 계산할 수 있습니다. 이 API는 판단 목록, 쿼리, 평가하려는 메트릭을 입력으로 받아 쿼리 결과와 판단 목록을 비교한 값을 반환합니다.

두 개의 쿼리에 대한 판단 목록을 실행해 보겠습니다.

POST /movies/_rank_eval { "requests": [ { "id": "dicaprio-performance", "request": { "query": { "match": { "text": { "query": "DiCaprio performance", "minimum_should_match": "100%" } } } }, "ratings": [ { "_index": "movies", "_id": "doc1", "rating": 1 }, { "_index": "movies", "_id": "doc2", "rating": 1 }, { "_index": "movies", "_id": "doc3", "rating": 0 }, { "_index": "movies", "_id": "doc4", "rating": 0 } ] }, { "id": "sad-movies", "request": { "query": { "match": { "text": { "query": "sad movies that make you cry", "minimum_should_match": "100%" } } } }, "ratings": [ { "_index": "movies", "_id": "doc5", "rating": 1 }, { "_index": "movies", "_id": "doc6", "rating": 1 }, { "_index": "movies", "_id": "doc7", "rating": 0 }, { "_index": "movies", "_id": "doc8", "rating": 0 } ] } ], "metric": { "recall": { "k": 10, "relevant_rating_threshold": 1 } } }

'디카프리오' 쿼리와 '슬픈 영화' 쿼리, 두 가지 요청을 _rank_eval에 사용하겠습니다. 각 요청에는 쿼리와 해당 판단 목록(평가)이 포함됩니다. 평가에 포함되지 않은 문서는 판단이 없는 것으로 간주되므로 모든 문서에 등급을 매길 필요는 없습니다. 계산을 수행할 때 리콜은 평가에서 관련성이 있는 것으로 간주되는 문서인 '관련 세트'만 고려합니다.

이 경우, '디카프리오' 쿼리의 리콜은 1이고 '슬픈 영화'는 0입니다. 즉, 첫 번째 쿼리에서는 모든 관련 결과를 얻을 수 있었지만 두 번째 쿼리에서는 아무런 결과도 얻지 못했습니다. 따라서 평균 리콜은 0.5입니다.

{ "metric_score": 0.5, "details": { "dicaprio-performance": { "metric_score": 1, "unrated_docs": [], "hits": [ { "hit": { "_index": "movies", "_id": "doc1", "_score": 2.4826927 }, "rating": 1 }, { "hit": { "_index": "movies", "_id": "doc2", "_score": 2.0780432 }, "rating": 1 } ], "metric_details": { "recall": { "relevant_docs_retrieved": 2, "relevant_docs": 2 } } }, "sad-movies": { "metric_score": 0, "unrated_docs": [], "hits": [], "metric_details": { "recall": { "relevant_docs_retrieved": 0, "relevant_docs": 2 } } } }, "failures": {} }

쿼리의 모든 단어가 문서에 100% 포함되어야 한다고 요구하면 minimum_should_match 매개변수를 너무 엄격하게 적용해 관련성 있는 결과를 놓치고 있는 것일지도 모릅니다. 쿼리에서 단어가 하나만 발견되면 문서가 관련성이 있는 것으로 간주되도록 minimum_should_match 매개변수를 제거해 보겠습니다.

POST /movies/_rank_eval { "requests": [ { "id": "dicaprio-performance", "request": { "query": { "match": { "text": { "query": "DiCaprio performance" } } } }, "ratings": [ { "_index": "movies", "_id": "doc1", "rating": 1 }, { "_index": "movies", "_id": "doc2", "rating": 1 }, { "_index": "movies", "_id": "doc3", "rating": 0 }, { "_index": "movies", "_id": "doc4", "rating": 0 } ] }, { "id": "sad-movies", "request": { "query": { "match": { "text": { "query": "sad movies that make you cry" } } } }, "ratings": [ { "_index": "movies", "_id": "doc5", "rating": 1 }, { "_index": "movies", "_id": "doc6", "rating": 1 }, { "_index": "movies", "_id": "doc7", "rating": 0 }, { "_index": "movies", "_id": "doc8", "rating": 0 } ] } ], "metric": { "recall": { "k": 10, "relevant_rating_threshold": 1 } } }

보시다시피, 두 쿼리 중 하나에서 minimum_should_match 매개 변수를 제거하면 두 쿼리 모두에서 평균 호출 횟수가 1이 됩니다.

{ "metric_score": 1, "details": { "dicaprio-performance": { "metric_score": 1, "unrated_docs": [], "hits": [ { "hit": { "_index": "movies", "_id": "doc1", "_score": 2.0661702 }, "rating": 1 }, { "hit": { "_index": "movies", "_id": "doc3", "_score": 0.732218 }, "rating": 0 }, { "hit": { "_index": "movies", "_id": "doc2", "_score": 0.6271719 }, "rating": 1 } ], "metric_details": { "recall": { "relevant_docs_retrieved": 2, "relevant_docs": 2 } } }, "sad-movies": { "metric_score": 1, "unrated_docs": [], "hits": [ { "hit": { "_index": "movies", "_id": "doc7", "_score": 2.1307156 }, "rating": 0 }, { "hit": { "_index": "movies", "_id": "doc5", "_score": 1.3160692 }, "rating": 1 }, { "hit": { "_index": "movies", "_id": "doc6", "_score": 1.190063 }, "rating": 1 } ], "metric_details": { "recall": { "relevant_docs_retrieved": 2, "relevant_docs": 2 } } } }, "failures": {} }

요약하면, minimum_should_match: 100% 절을 제거하면 두 쿼리 모두에 대해 완벽한 리콜을 얻을 수 있습니다.

됐습니다! 성공하셨죠?

그렇게 어렵지 않아요!

리콜을 개선함으로써 더 폭넓은 결과를 확보할 수 있게 됩니다. 그러나 각 조정에는 상충되는 부분이 있습니다. 따라서 다양한 메트릭을 사용해 변경 사항을 평가하는 완전한 테스트 케이스를 정의해야 합니다.

판단 목록과 메트릭을 사용하면 변경 사항을 적용할 때 근거 데이터가 생기므로, 감에 의존해 판단하는 일을 피할 수 있습니다. 검증은 더 이상 수동적이고 반복적이지 않으며, 한 가지 사용 사례뿐만 아니라 여러 사용 사례에서 변경 사항을 테스트할 수 있습니다. 번역:또한 A/B 테스트를 통해 어떤 설정이 사용자와 비즈니스 사례에 가장 적합한지 실제 환경에서 검증할 수 있어, 기술적 메트릭에서 출발해 실제 메트릭으로 다시 연결되는 선순환을 완성할 수 있습니다.

판단 목록 사용에 대한 최종 권장 사항

판단 목록을 활용하는 것은 단순히 측정하는 것뿐만 아니라, 자신 있게 반복할 수 있는 프레임워크를 만드는 것이기도 합니다. 이를 위해 다음 권장 사항을 따르세요:

작은 시작이라도, 시작하세요. 각각 50개의 판단 목록이 있는 10,000개의 쿼리가 필요하지 않습니다. 비즈니스에 가장 중요한 쿼리를 5~10개 식별하고 결과의 상단에 표시할 문서를 정의하기만 하면 됩니다. 이것으로 이미 기반이 갖춰집니다. 일반적으로 상위 쿼리와 결과가 없는 쿼리부터 시작하는 것이 좋습니다. Precision과 같이 쉽게 구성할 수 있는 메트릭으로 테스트를 시작한 후, 복잡성을 높여 나갈 수 있습니다.
사용자 검증을 통해 타당성을 검증하세요. 프로덕션 환경에서 A/B 테스트를 통해 수치를 보완하세요. 이렇게 하면 메트릭에서 좋아 보이던 변경 사항이 실제 영향을 발휘하고 있는지 알 수 있습니다.
목록을 계속 유지하세요. 비즈니스 사례는 진화할 것이며 중요한 쿼리도 진화할 것입니다. 정기적으로 판단을 업데이트하여 새로운 필요를 반영하세요.
워크플로의 일부로 만드세요. 판단 목록을 개발 파이프라인에 통합하세요. 각 구성 변경, 동의어 또는 텍스트 분석이 기본 목록에 대해 자동으로 검증되는지 확인하세요.
기술 지식을 전략과 연결하세요. 정확도나 리콜과 같은 기술적 메트릭을 측정하는 데서 멈추지 마세요. 평가 결과를 활용하여 비즈니스 성과에 전달하세요.

Kibana의 Elasticsearch 쿼리 규칙 UI 소개

Jhon Guzmán — Fri, 07 Nov 2025 00:00:00 GMT

검색 엔진의 역할은 관련성 높은 결과를 반환하는 것입니다. 그러나 세일 강조, 시즌 상품 우선순위 지정, 스폰서 상품 소개 등 그 이상의 비즈니스 요구사항이 있으며, 개발자가 검색 쿼리에서 이를 항상 수행할 수는 없습니다.

또한 이러한 사용 사례는 일반적으로 시간에 민감하며 일반적인 개발 단계(코드 브랜치를 생성한 다음 새 릴리스를 기다리는 과정)를 거치는 것은 시간이 많이 소요되는 프로세스입니다.

그렇다면 이 모든 프로세스를 API 호출만으로, 더 나아가 Kibana에서 클릭 몇 번으로 수행할 수 있다면 어떨까요?

쿼리 규칙 UI

Elasticsearch 8.10에는 쿼리 규칙과 규칙 검색기가 도입되었습니다. 규칙에 따라 자연 검색 결과의 순위에 영향을 주지 않고 고정된 결과를 쿼리에 삽입하기 위해 고안된 도구입니다. 선언적이고 단순한 방식으로 결과 위에 비즈니스 로직을 추가할 뿐입니다.

쿼리 규칙의 몇 가지 일반적인 사용 사례는 다음과 같습니다:

프로모션 목록 또는 판매 강조 표시: 세일 중이거나 스폰서된 품목을 상단에 표시합니다.
문맥 또는 지리적 위치에 따라 제외: 현지 규정으로 인해 특정 항목을 표시할 수 없는 경우 숨기기.
주요 결과의 우선순위 지정: 자연 검색 순위와 관계없이 인기 검색어 또는 고정 검색어가 항상 상단에 표시되도록 합니다.

인터페이스에 액세스하고 이러한 도구와 상호 작용하려면 Kibana 사이드 메뉴를 클릭하고 관련성아래의 쿼리 규칙으로 이동해야 합니다:

쿼리 규칙 메뉴가 나타나면 첫 번째 규칙 집합 만들기를 클릭합니다:

다음으로 규칙 집합의 이름을 지정해야 합니다.

각 규칙을 정의하는 양식에는 세 가지 주요 구성 요소가 있습니다:

기준: 조건: 규칙을 적용하기 위해 충족해야 하는 조건입니다. 예를 들어, "쿼리 문자열 필드에 크리스마스값이 포함된 경우" 또는 "국가 필드가 CO인경우"와 같은 예입니다.
액션: 조건이 충족될 때 수행하려는 작업입니다. 고정(문서를 최상위 결과에 고정)하거나 제외(문서를 숨김)할 수 있습니다.
메타데이터: 쿼리가 실행될 때 쿼리와 함께 제공되는 필드입니다. 여기에는 위치나 언어와 같은 사용자 정보뿐만 아니라 검색 데이터(쿼리 문자열)도 포함될 수 있습니다. 규칙 적용 여부를 결정하기 위해 기준에서 사용하는 값입니다.

예: 인기 품목

다양한 품목이 있는 이커머스 사이트가 있다고 가정해 보겠습니다. 지표를 살펴보면 콘솔 카테고리에서 가장 많이 판매된 상품 중 하나는 '듀얼쇼크 4 무선 컨트롤러'로, 특히 사용자가 'PS4' 또는 'PlayStation 4' 키워드를 검색할 때 가장 많이 판매되는 상품임을 확인할 수 있습니다. 따라서 사용자가 해당 키워드를 검색할 때마다 이 제품을 결과 상단에 표시하기로 결정했습니다.

먼저 대량 API 요청을 사용하여 각 항목에 대한 문서를 색인해 보겠습니다:

POST _bulk { "index": { "_index": "products", "_id": "1" } } { "id": "1", "name": "PlayStation 4 Slim 1TB", "category": "console", "brand": "Sony", "price": 1200 } { "index": { "_index": "products", "_id": "2" } } { "id": "2", "name": "DualShock 4 Wireless Controller", "category": "accessory", "brand": "Sony", "price": 250 } { "index": { "_index": "products", "_id": "3" } } { "id": "3", "name": "PlayStation 4 Camera", "category": "accessory", "brand": "Sony", "price": 200 } { "index": { "_index": "products", "_id": "4" } } { "id": "4", "name": "PlayStation 4 VR Headset", "category": "accessory", "brand": "Sony", "price": 900 } { "index": { "_index": "products", "_id": "5" } } { "id": "5", "name": "Charging Station for DualShock 4", "category": "accessory", "brand": "Sony", "price": 80 }

쿼리에 개입하지 않으면 해당 항목은 일반적으로 네 번째 위치에 표시됩니다. 쿼리는 다음과 같습니다:

GET products/_search { "query": { "match": { "name": "PlayStation 4" } } }

결과는 다음과 같습니다.

{ "took": 1, "timed_out": false, "_shards": { "total": 1, "successful": 1, "skipped": 0, "failed": 0 }, "hits": { "total": { "value": 5, "relation": "eq" }, "max_score": 0.6973252, "hits": [ { "_index": "products", "_id": "3", "_score": 0.6973252, "_source": { "id": "3", "name": "PlayStation 4 Camera", "category": "accessory", "brand": "Sony", "price": 200 } }, { "_index": "products", "_id": "1", "_score": 0.6260078, "_source": { "id": "1", "name": "PlayStation 4 Slim 1TB", "category": "console", "brand": "Sony", "price": 1200 } }, { "_index": "products", "_id": "4", "_score": 0.6260078, "_source": { "id": "4", "name": "PlayStation 4 VR Headset", "category": "accessory", "brand": "Sony", "price": 900 } }, { "_index": "products", "_id": "2", "_score": 0.08701137, "_source": { "id": "2", "name": "DualShock 4 Wireless Controller", "category": "accessory", "brand": "Sony", "price": 250 } }, { "_index": "products", "_id": "5", "_score": 0.07893815, "_source": { "id": "5", "name": "Charging Station for DualShock 4", "category": "accessory", "brand": "Sony", "price": 80 } } ] } }

이를 변경하는 쿼리 규칙을 만들어 보겠습니다. 먼저 다음과 같이 규칙 집합에 추가해 보겠습니다:

또는 이에 상응하는 API 요청:

PUT _query_rules/my-rules { "rules": [ { "rule_id": "rule-1232", "type": "pinned", "criteria": [ { "type": "exact", "metadata": "query_string", "values": [ "PS4", "PlayStation 4" ] } ], "actions": { "docs": [ { "_index": "products", "_id": "2" } ] } } ] }

쿼리에서 규칙 집합을 사용하려면 쿼리 규칙 유형을 사용해야 합니다. 이러한 종류의 쿼리는 크게 두 부분으로 구성됩니다:

GET /products/_search { "retriever": { "rule": { "retriever": { "standard": { "query": { "match": { "name": "PlayStation 4" } } } }, "match_criteria": { "query_string": "PlayStation 4" }, "ruleset_ids": ["my-rules"] } } }

match_criteria: 사용자의 쿼리와 비교하는 데 사용되는 메타데이터입니다. 이 예에서는 쿼리 문자열 필드에 "PlayStation 4" 값이 있을 때 규칙 집합이 활성화됩니다.
쿼리: 검색 및 자연 검색 결과를 얻는 데 사용되는 실제 쿼리입니다.

이렇게 하면 먼저 오가닉 쿼리를 실행한 다음 Elasticsearch가 규칙 세트의 규칙을 적용합니다:

{ "took": 17, "timed_out": false, "_shards": { "total": 1, "successful": 1, "skipped": 0, "failed": 0 }, "hits": { "total": { "value": 5, "relation": "eq" }, "max_score": 1.7014122e+38, "hits": [ { "_index": "products", "_id": "2", "_score": 1.7014122e+38, "_source": { "id": "2", "name": "DualShock 4 Wireless Controller", "category": "accessory", "brand": "Sony", "price": 250 } }, { "_index": "products", "_id": "3", "_score": 0.6973252, "_source": { "id": "3", "name": "PlayStation 4 Camera", "category": "accessory", "brand": "Sony", "price": 200 } }, { "_index": "products", "_id": "1", "_score": 0.6260078, "_source": { "id": "1", "name": "PlayStation 4 Slim 1TB", "category": "console", "brand": "Sony", "price": 1200 } }, { "_index": "products", "_id": "4", "_score": 0.6260078, "_source": { "id": "4", "name": "PlayStation 4 VR Headset", "category": "accessory", "brand": "Sony", "price": 900 } }, { "_index": "products", "_id": "5", "_score": 0.07893815, "_source": { "id": "5", "name": "Charging Station for DualShock 4", "category": "accessory", "brand": "Sony", "price": 80 } } ] } }

예: 사용자 기반 메타데이터

쿼리 규칙의 또 다른 흥미로운 적용 사례는 메타데이터를 사용하여 사용자 또는 웹페이지의 문맥 정보를 기반으로 특정 문서를 표시하는 것입니다.

예를 들어, 사용자의 충성도 수준에 따라 숫자 값으로 표시되는 아이템이나 맞춤형 판매를 강조하고 싶다고 가정해 보겠습니다.

이 메타데이터를 쿼리에 직접 수집하여 해당 값이 특정 기준을 충족할 때 규칙이 활성화되도록 할 수 있습니다.

먼저, 충성도 수준이 높은 사용자만 볼 수 있는 문서를 색인화합니다:

POST _bulk { "index": { "_index": "products", "_id": "6" } } { "id": "6", "name": "PlayStation Plus Deluxe Card - 12 months", "category": "membership", "brand": "Sony", "price": 300 }

이제 동일한 규칙 집합 내에 새 규칙을 만들어 loyalty_level이 80 이상일 때 해당 항목이 결과 상단에 표시되도록 해 보겠습니다.

규칙과 규칙 집합을 저장합니다.

다음은 이에 상응하는 REST 요청입니다:

PUT _query_rules/my-rules { "rules": [ { "rule_id": "pin-premiun-user", "type": "pinned", "criteria": [ { "type": "gte", "metadata": "loyalty_level", "values": [ 80 ] } ], "actions": { "docs": [ { "_index": "products", "_id": "6" } ] } } ] }

이제 쿼리를 실행할 때 메타데이터에 새 매개변수 loyalty_level을 포함시켜야 합니다. 규칙의 조건이 충족되면 새 문서가 결과 위에 표시됩니다.

예를 들어 충성도_레벨이 80인 쿼리를 전송하는 경우입니다:

POST /products/_search { "retriever": { "rule": { "retriever": { "standard": { "query": { "match": { "name": "PlayStation" } } } }, "match_criteria": { "query_string": "PlayStation", "loyalty_level": 80 }, "ruleset_ids": ["my-rules"] } } }

결과 위에 로열티 문서가 표시됩니다:

{ "took": 31, "timed_out": false, "_shards": { "total": 1, "successful": 1, "skipped": 0, "failed": 0 }, "hits": { "total": { "value": 4, "relation": "eq" }, "max_score": 1.7014122e+38, "hits": [ { "_index": "products", "_id": "6", "_score": 1.7014122e+38, "_source": { "id": "6", "name": "PlayStation Plus Deluxe Card - 12 months", "category": "membership", "brand": "Sony", "price": 300 } }, { "_index": "products", "_id": "3", "_score": 0.5054567, "_source": { "id": "3", "name": "PlayStation 4 Camera", "category": "accessory", "brand": "Sony", "price": 200 } }, { "_index": "products", "_id": "1", "_score": 0.45618832, "_source": { "id": "1", "name": "PlayStation 4 Slim 1TB", "category": "console", "brand": "Sony", "price": 1200 } }, { "_index": "products", "_id": "4", "_score": 0.45618832, "_source": { "id": "4", "name": "PlayStation 4 VR Headset", "category": "accessory", "brand": "Sony", "price": 900 } } ] } }

아래의 경우 충성도 레벨이 70이므로 규칙이 충족되지 않으므로 해당 아이템이 상단에 표시되지 않아야 합니다:

결과는 다음과 같습니다:

{ "took": 7, "timed_out": false, "_shards": { "total": 1, "successful": 1, "skipped": 0, "failed": 0 }, "hits": { "total": { "value": 4, "relation": "eq" }, "max_score": 0.5054567, "hits": [ { "_index": "products", "_id": "3", "_score": 0.5054567, "_source": { "id": "3", "name": "PlayStation 4 Camera", "category": "accessory", "brand": "Sony", "price": 200 } }, { "_index": "products", "_id": "1", "_score": 0.45618832, "_source": { "id": "1", "name": "PlayStation 4 Slim 1TB", "category": "console", "brand": "Sony", "price": 1200 } }, { "_index": "products", "_id": "4", "_score": 0.45618832, "_source": { "id": "4", "name": "PlayStation 4 VR Headset", "category": "accessory", "brand": "Sony", "price": 900 } }, { "_index": "products", "_id": "6", "_score": 0.3817649, "_source": { "id": "6", "name": "PlayStation Plus Deluxe Card - 12 months", "category": "membership", "brand": "Sony", "price": 300 } } ] } }

예: 즉시 제외

듀얼쇼크 4 무선 컨트롤러(ID 2) 를 일시적으로 사용할 수 없어 판매할 수 없다고 가정해 보겠습니다. 따라서 비즈니스 팀은 문서를 수동으로 삭제하거나 일부 데이터 프로세스가 시작될 때까지 기다리는 대신 그 동안 검색 결과에서 해당 문서를 제거하기로 결정합니다.

방금 인기 있는 항목에 적용한 것과 비슷한 프로세스를 사용하되 이번에는 고정됨을 선택하는 대신 제외를 선택합니다. 이 규칙은 일종의 블랙리스트 역할을 합니다. 쿼리가 실행될 때마다 제외가 작동하도록 기준을 항상으로 변경합니다.

규칙은 다음과 같이 표시되어야 합니다:

규칙과 규칙 집합을 저장하여 변경 사항을 적용합니다. 다음은 이에 상응하는 REST 요청입니다:

PUT _query_rules/my-rules { "rules": [ { "rule_id": "rule-6358", "type": "pinned", "criteria": [ { "type": "always" } ], "actions": { "docs": [ { "_index": "products", "_id": "2" } ] } } ] }

이제 쿼리를 다시 실행하면 이전 규칙이 항목을 고정하는 것이었음에도 불구하고 해당 항목이 더 이상 결과에 없는 것을 볼 수 있습니다. 이는 제외가 고정 결과보다 우선하기 때문입니다.

{ "took": 6, "timed_out": false, "_shards": { "total": 1, "successful": 1, "skipped": 0, "failed": 0 }, "hits": { "total": { "value": 4, "relation": "eq" }, "max_score": 2.205655, "hits": [ { "_index": "products", "_id": "3", "_score": 2.205655, "_source": { "id": "3", "name": "PlayStation 4 Camera", "category": "accessory", "brand": "Sony", "price": 200 } }, { "_index": "products", "_id": "1", "_score": 1.9738505, "_source": { "id": "1", "name": "PlayStation 4 Slim 1TB", "category": "console", "brand": "Sony", "price": 1200 } }, { "_index": "products", "_id": "4", "_score": 1.9738505, "_source": { "id": "4", "name": "PlayStation 4 VR Headset", "category": "accessory", "brand": "Sony", "price": 900 } }, { "_index": "products", "_id": "5", "_score": 0.69247496, "_source": { "id": "5", "name": "Charging Station for DualShock 4", "category": "accessory", "brand": "Sony", "price": 80 } } ] } }

결론

쿼리 규칙을 사용하면 코드를 변경하지 않고도 관련성을 매우 쉽게 조정할 수 있습니다. 새로운 Kibana UI를 사용하면몇 초 만에 이러한 변경을 수행할 수 있으므로, 여러분과 여러분의 비즈니스 팀이 검색 결과를 더 잘 제어할 수 있습니다.

쿼리 규칙은 전자상거래 외에도 지원 포털에서 문제 해결 가이드를 강조 표시하고, 지식창고에 주요 내부 문서를 표시하고, 뉴스 사이트에서 속보를 홍보하고, 만료된 작업 또는 콘텐츠 목록을 필터링하는 등 다양한 시나리오에 활용할 수 있습니다. 사용자 역할이나 지역에 따라 제한된 자료를 숨기는 등의 규정 준수 규칙을 적용할 수도 있습니다.