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

Elasticsearch는 여러분의 사용 사례에 가장 적합한 검색 솔루션을 구축하는 데 도움이 되는 새로운 기능으로 가득 차 있습니다. 최신 검색 AI 경험 구축에 관한 실습형 웨비나에서 이러한 기능을 실제로 활용하는 방법을 배워 보세요. 지금 무료 클라우드 체험을 시작하거나, 내 로컬 기기에서 Elastic을 사용해 볼 수 있습니다.

검색 엔진을 개발하는 개발자들은 종종 같은 문제를 겪습니다. 비즈니스 팀이 특정 검색 결과에 만족하지 못하는데, 기대했던 문서가 검색 결과 상단이 아니라 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에 접근할 수 있어야 합니다.

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

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

인덱스 생성:

대량 요청:

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

판단에서 지표로

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

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

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

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

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

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

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

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

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

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

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

됐습니다! 성공하셨죠?

그렇게 어렵지 않아요!

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

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

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

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

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