Search Ranking of Airbnb
Tech Review of Airbnb #2
이번 Tech Review는 Global 숙박 공유 서비스 Airbnb에서 사용하고 있는 Machine Learning 기반의 Search Ranking Algorithm에 관한 것입니다. 그중에서도 특히 Airbnb Experience(Airbnb Trip)으로 알려진 현지 사람들이 만드는 Experience를 검색해주는 서비스에 대한 Review입니다.
Airbnb에 대한 1번째 Tech Review에서는 Airbnb의 데이터 인프라에 대해 살펴보았습니다.
https://brunch.co.kr/@sonjoosik/2
Machine Learning-Powered Search Ranking of Airbnb Experience
어떻게 Machine Learning을 기반으로 한 Search Ranking Platform(검색 랭킹 플랫폼)을 만들고, 어떻게 시장에 적용하여 회사가 성장하였는지에 대한 이야기이다.
Airbnb Experience의 소개
Airbnb Experience는 그 지역만의 특별한 풍경과 문화를 느낄 수 있도록 지역 전문가가 직접 구성하고 이끄는 그런 activity이다. 각 experience는 Airbnb 플랫폼에 업로드되기 전에 editor 팀에 의해 심사받는다.
2016년 11월, 12개 도시에 500여 개의 Experience로 Airbnb Experience 서비스를 런칭하였다. 2017년에는 60개 도시에 5000여 개의 Experience로 확장하였다. 2018년에는 Easter Island, Tasmania, Iceland와 같이 특별한 지역을 포함하여, 총 1000여 개의 도시로 확대하였으며, 총 20000여 개의 Experience로 확장하였다.
Airbnb Experience는 Airbnb Trip으로 알려져 있는 서비스입니다. Airbnb를 이용해, Home을 예약하는 경우 많이 사용하게 됩니다. 심지어 Airbnb Home을 이용하지 않는 경우에도 사용하게 되는 것 같습니다. 저는 이 서비스를 이용해, 현지 투어를 많이 찾습니다. Host가 직접 기획하는 Trip(Experience)를 등록하기 때문에 더 개성 있는 여행을 할 수 있게 되기 때문입니다. 또한 다양한 Host들끼리 Trip의 경쟁을 하기 때문에, 더 좋은 품질의 Trip만 살아남게 되지요. 좋은 품질의 Trip(Experience)가 유지되는 것은 아마도 Airbnb에서 Ranking을 잘 관리하여, Host들로 하여금 더 열심히 하게 만들도록 자극하기 때문인 것 같습니다.
Machine Learning-based Search Ranking의 필요성
Experience가 늘어남에 따라, 검색 기능뿐 아니라 개인화된 결과를 제공하는 것이 플랫폼의 성장과 성공에 중요한 요소로 작용하고 있다.
사용자의 검색 과정에는 개인의 의도가 담겨 있습니다. 동일한 검색 질의라 하더라고, 각자의 검색 목적과 그가 원하는 정답은 다를 것입니다. 그렇기 때문에 검색의 결과(Ranking) 자체를 개인화하는 것은 매우 중요하다고 할 수 있습니다.
이번 글에서는 Machine Learning을 이용한 Experience Ranking 개발 과정을 각 단계별로 설명하고, 각 단계에서 어떻게 성장을 이루었는지 설명하도록 하겠다.
Machine Learning-based Search Ranking을 서비스에 적용함으로써 얻는 가장 큰 이점은 이용 가능한 데이터의 양과 순위를 매겨야 할 Experience들의 규모의 복잡성을 고려하여, 적절한 Machine Learning model과 infrastructure를 선정할 수 있다는 점이다. 복잡한 모델은 작은 양의 데이터에 적합하지 않고, 간단한 baseline 모델은 많은 데이터가 사용 가능할 때 보완책으로 사용될 수 있다.
Stage 1 : Build a Strong Baseline
Baseline 모델은 무언가를 평가하는 실험에 있어 대조군으로 작용하기에 매우 중요합니다. 명확한 대조군과 그에 대한 평가 지표가 있어야, 지금 하고 있는 실험이 제대로 된 방향으로 나아가고 있는지 명확히 할 수 있기 때문입니다.
Airbnb Experience가 런칭하였을 때, 검색 랭킹이 적용되어야 하는 Experience 수가 적었고, 우리는 Experience에서 일어나는 user interaction data를 수집하였다. 첫 번째 ML 모델을 개발하는 데 있어 가장 좋은 선택은, 작은 dataset이 수집될 때까지 무작위로 Experience들의 순위를 매겨 매일 노출하는 것이다.
User interaction data란 어떤 서비스에서 이루어지는 user의 모든 행동을 의미합니다. 예약, 좋아요, 클릭 등이 있습니다. User가 얼마나 의도를 가지고 한 행동이냐에 따라 Explicit data와 Implicit data로 분류할 수 있습니다. 사용자의 취향이 많이 반영된 예약(Explicit data)부터, 상대적으로 덜 반영된 클릭(Implicit data), 그리고 그 중간인 좋아요 등이 있을 수 있습니다. Data를 이용하는 데 있어서, 그 Data의 본질적 특성을 잘 이해하는 것이 중요하기에 사용자의 의도가 얼마나 담겨있는지 이해하는 것은 매우 중요합니다.
Collecting training data : 첫 번째 Experience를 ranking 하기 위한 Machine Learning 모델을 학습하기 위해, 최종적으로 예약을 한 사용자의 검색 로그(예를 들어, 클릭 등)를 수집하였다.
Labeling training data : 학습 데이터를 labeling 할 때, label을 두 개로 구성하였다. 첫 번째는 positive label인 예약을 한 experience이다. 두 번째는 negative label인 클릭을 하였지만 예약을 하지 않은 experience이다. 이 단계에서 총 50000여 개의 data를 수집하였다.
Building signals based on which we will rank : Stage 1의 ML model에서, Experience Feature들만을 기반으로 그 순위를 정해야 한다. 이때 사용한 Feature의 수는 총 25개이다. (example. Experience duration, Price, Category, Reviews, Number of booking,...)
(추가적인 Feature들에 관심이 있으신 분들을 한번 본문을 보시면 좋을 것 같습니다.)
Training the ranking model : 학습 데이터, Label, 그리고 Feature들이 주어졌을 때, 우리는 Gradient Boosted Decision Tree(GBDT) model을 사용하였다. 우리는 우리가 풀고자 하는 문제를 Binary Classification으로 정의하여 Log-loss를 loss function으로 사용하였다.
Airbnb Experience에서 Experience들을 예약할지 / 예약하지 않을지 두 개의 Label로 분류하는 문제이므로 Binary Classification 문제로 변환하여 풀었다고 볼 수 있습니다.
GBDT를 사용할 때, feature value의 크기나 누락된 값에 대해서 걱정할 필요가 없다. 하지만 이 모델을 사용할 때 고려해야 하는 중요한 요소 중 하나는, 선형 모델과 다른 부분에 있다. Tree-based 모델은 count 값을 있는 그대로 사용하기 때문에 증가하는 시장 규모에 급진적으로 변화한다. 이러한 경우, 분수의 비율을 사용하는 것이 좋다. (Normalization을 하는 효과와 같은 효과를 보일 것 같습니다.) 예를 들어, 지난 7일간의 예약 숫자를 사용하기보다는 예약의 비율(예를 들어, 살펴본 사람들 중 비율 등)을 사용하는 것이 좋다.
Testing the ranking model : 오프라인 hyper parameter 튜닝과 re-ranking의 생산력을 평가하기 위해, training에 사용되지 않은 hold-out 데이터를 사용하였다. 우리가 사용한 평가 metrics는 AUC와 NDCG이다. 특히, 우리는 model 점수(예약할 확률)에 기반하여 Experience를 re-ranking 하고, 사용자가 클릭한 것들 중 예약한 Experience가 어디에 rank 되어 있는지를 테스트했다.
게다가, 학습한 모델이 무엇을 배웠는지 알기 위해, 중요한 몇 가지 Experience feature들에 대한 partial dependency plot을 그렸다. 이 plot들은 단일 feature를 조정할 경우, score가 어떻게 변화되는지를 그렸다. 아래와 같이 모델은 feature들을 학습하였다.
1000명당 예약률이 높은 Experience의 rank가 높을 것이다.
높은 평균 리뷰 점수의 Experience의 rank가 높을 것이다.
낮은 가격의 Experience의 rank가 높을 것이다.
오프라인 테스트는 너무 많은 가정을 필요로 하기 때문에, 우리는 A/B 테스트와 같은 온라인 테스트를 수행하였다. 우리는 첫 번째 단계의 ML 모델을 랜덤 random ranking 모델과 예약수 측면에서 비교하였다. 그 결과 13%가량의 예약률이 상승하였다.
Implementation details : 이 단계에서, 우리의 ML 모델은 Experience Feature들만 사용하였다는 한계가 있어서, 모든 사용자들에게 같은 Experience의 랭킹이 보였다. 게다가 모든 query parameters(게스트 수, 날짜, 위치 등)는 결과의 filtering 요소로 사용되었고, Experiece의 ranking은 변화시키지 않았다.
Filter란 검색 결과에서 해당 특징을 지닌 결과만 추출하여 보여주는 기능을 말합니다. 사용자의 의도를 반영하여 Ranking을 만들기 어려운 경우, 공통의 Ranking을 제공하고 사용자가 자신의 의도대로 선별하여 쉽게 추출할 수 있게 해주는 기능이 Filter입니다.
이 단계를 세팅하는 데 있어, training과 scoring을 포함한 전체 ranking 과정을 오프라인으로 매일 Airflow를 기반으로 수행하였다. 이것의 결과는 전체 Experience의 순서(정렬된 리스트)이며, 이 리스트는 서비스 머신에 업로드되어, 매 검색마다 검색 조건에 맞는 Experience subset을 정렬하는 데 사용되었다.
Stage 2 : Personalize
Search Ranking 개발의 다음 단계는 Personalization(개인화) 기능을 넣은 ML ranking 모델이다.
우리는 각 게스트의 관심도와 Experiece의 재고가 다양하게 때문에, Experience의 ranking을 Personalization 하는 것은 매우 중요한 일이라는 것을 알고 있었다.
같은 도시에 비슷한 도시에 있는 두 개의 집이 굉장히 비슷할 확률을 지닌 우리의 Home 비즈니스와 다르게, 무작위로 선정된 2개의 Experience는 굉장히 다르다. (쿠킹 클래스 vs 서핑 레슨) 동시에 게스트들은 그들의 여행에 있어 관심을 가지는 부분이 다를 것이고, 이러한 관심을 잘 포착하여 검색 결과에서 더 잘 반영하는 것이 우리의 목표이다.
우리는 두 개의 다른 personalization을 설명하겠다.
1. Personalized based on booked Airbnb Homes
대부분의 Experience 예약을 하는 사람들은 이미 Airbnb Home을 예약한 사람이다. 그러므로 Personalization에 사용되는 feature들을 구축하는데 용이하다.
예약한 Home의 위치
여행 날짜 및 기간
게스트 수
여행 가격
여행 유형 (가족 여행, 비즈니스)
첫 번째 여행인지, 다시 온 여행인지
국내 여행, 국제 여행
etc
Ranking을 가이드하는 모델을 생성하는 예시를 설명하기 위해, 우리는 두 가지 요소를 설명하려 한다.
1. 예약한 Home과 Experience 사이의 거리. 예약한 Home의 위치뿐 아니라 Experience의 만남 위치를 알기 때문에, 우리는 그 사이의 거리를 계산할 수 있다. Data를 통해 보면, 사용자들은 편의성을 중요하게 여긴다. 즉, 많은 수의 Airbnb Experience 예약이 Airbnb Home 근처에서 발생했다.
2. 예약한 여행 기간 내에 가능한 Experience. Home의 체크인 및 체크아웃 날짜가 주어지면, 우리는 게스트가 원하는 Experience의 예약 일자를 알 수 있고, 그 기간 내의 Experience를 available 혹은 not으로 표시할 수 있다.
이러한 두 feature는 새로운 ML ranking 모델을 학습하는 데 사용되었다. 아래는 우리가 그린 partial dependency plot이다.
위의 plot들은 우리가 직관적으로 모델이 배우기를 기대하는 것과 Feature들의 의존성이 일치하는 것을 확인할 수 있게 해 준다. 예를 들어, 예약한 Home에 가까운 Experience가 더 높은 rank를 가질 것이며, 예약 가능한 여행 날짜의 Experience가 더 높은 rank를 가질 것이다.
2. Personalize based on the user's clicks
사용자의 단기간의 검색기록을 고려하여, 우리는 향후 검색을 개인화하는데 도움을 줄 수 있는 정보를 추론할 수 있다.
특정 category들에 대한 사용자 관심 : 만약 사용자가 Music 카테고리의 Experience를 많이 클릭했다면, 우리는 사용자는 Music에 관심 있다고 추론할 수 있다.
가능한 시간대에 대한 사용자 관심 : 만약 사용자가 Evening 시간대의 Experience를 많이 클릭했다면, 우리는 사용자가 그 시간에 Experience를 할 수 있다고 추론할 수 있다.
플랫폼에 올라오는 각 Experience들은 수동으로 category(예를 들면, 하이킹, 스키, 등)가 태그 된다. 이렇게 구조화된 Data는 Experience의 유형을 구분할 수 있게 해 준다. 또한 사용자가 관심 있어한 Experience들을 category별로 집계하여, 사용자 관심 프로필을 생성할 수 있게 해 준다.
이 목적에 있어, 우리는 두 feature를 사용자 클릭과 클릭한 Experience의 카테고리로부터 계산하였다.
Category Intensity : 특정 카테고리의 Experience에 대한 사용자 클릭의 가중합. 여기서 합계는 지난 15일에 대한 합계이고, A는 특정 카테고리를 d번째 날에 클릭한 수이다.
Category Recency : 사용자가 마지막으로 해당 카테고리의 Experience를 클릭한 후 지난 일 수.
사용자가 다른 강도과 대기 시간을 가지고 다양한 카테고리를 클릭했을 수도 있다. 하지만 우리는 Experience를 ranking 하는 데 있어 이러한 Experience 카테고리에 대한 클릭의 강도와 대기 시간을 사용해야 한다.
이 두 가지 특징에 대해 우리의 모델이 어떠한 것을 배우는지 설명하기 위해, 아래의 두 dependency plot을 그려보았다. 왼쪽 plot을 보면, 사용자가 더 높은 강도를 갖고 클릭한 카테고리의 Experience가 더 높은 rank를 가질 것이라는 것을 알 수 있다. 오른쪽 plot을 보면, 사용자가 클릭한 지 가장 오래된 카테고리의 Experience가 낮은 rank를 가질 것이라는 것을 알 수 있다.
(Recency과 Intensity에 대한 번역을 하기가 어려워, 대기 시간과 강도라고 의역하였습니다. Recency과 Intensity를 있는 그대로 받아들이면 조금 더 이해하기 편할 것 같습니다.)
우리는 Intensity와 Recency라고 하는 유형의 feature들을 다양한 유저 action(wishlisting, 예약, 등)에 대해 만들었다.
Time of Day Personalization : 서로 다른 Experience들은 서로 다른 시간대에 이루어진다. 우리가 여러 카테고리의 클릭을 추론하는 방법과 마찬가지로, 여러 시간대에 일어나는 클릭을 유추할 수 있을 것이다. 그리고 Time of Day Fit를 User's time-of-day 비율과 Experience's time-of-day 비율을 사용하여 계산할 수 있다.
여기에서 볼 수 있듯이, 모델은 사용자가 선호하는 시간대의 Experience를 높은 rank에 위치시키도록 학습하는데 이 Feature를 사용했다.
Training the ranking model : Personalization Feature들을 이용해 모델을 학습하기 위해, 우리는 우선 과거의 검색 로그를 재구성하여 해당 Feature들을 포함한 Train 데이터를 생성하였다. 총 4000여 개의 Experience라는 큰 규모가 되어있었고, 그로 인해 250K 개의 label 된 train 데이터를 얻을 수 있었다.
Personalization Feature들을 만들 때 "leak the label"하는 것이 중요하다. "leak the label"은 이벤트 이후 발생된 정보를 label을 만드는 데 사용하는 것을 의미한다. 그래서 우리는 예약 이전에 발생한 사용자의 클릭만을 사용하였다. 추가적으로, train 데이터를 생성할 때, 사용자가 두 개 이상의 Experience와 카테고리와 interaction을 한 경우에만 Personalization Feature를 생성하였다.
(이 부분은 어찌 보면 당연한 부분입니다. 너무 적은 클릭의 사용자는 개인화를 하기 어려우며, 오히려 잘못된 데이터가 들어감으로써 전체 모델 학습에 안 좋은 영향을 끼칠 수 있다는 생각이 듭니다.)
중요하게 고려해야 할 것 중 하나는 검색 로그에는 로그인 사용자와 로그인하지 않은 사용자의 검색기록이 섞여있다는 것이다. 이 부분을 고려하면, 두 가지 모델을 학습하는 것이 적절하다는 것을 알 수 있다. 하나는 로그인 사용자를 위한 Personalization 모델, 나머지 하나는 로그인하지 않은 사용자를 위한 non-Personalization 모델.
(이 역시도 당연한 일입니다. Personalization Feature를 사용하는데, 만약 사용자 개인의 기록이 없다면, 잘못된 검색 결과를 노출할 것입니다.)
Testing the ranking model : 우리는 Pesonalization 모델과 Stage 1의 모델을 비교하는 A/B 테스트를 수행하였다. 그 결과 Personalization 모델이 7.9%가량의 예약률 향상을 가져왔다.
Implementation details : Stage 2 모델을 제품에 적용하기 위해, 우리는 구현에 가장 적은 시간이 소요되는 간단한 솔루션을 선택하였다. 사용자 ID를 key로 하여 Experience들의 Personalized Ranking을 갖는 look-up table을 생성하였습니다. 이때, key값이 0인 것은 로그인한 사용자들에게 제공하는 기본 검색 ranking을 저장하였습니다.
우리는 최신 feature를 추출하고 두 모델의 점수 계산을 통해, 오프라인에서 Airflow로 모든 랭킹을 계산하였다. 모든 User에 대해 미리 Personalized Ranking을 계산해두는 것은 많은 비용(O(NM), N = 사용자 수, M = Experience 수)이 들어가므로 100만 명의 액티브 사용자만을 대상으로 했다.
Personalization Feature들은 매일 계산되므로, 업데이트에는 적어도 하루가 필요함을 의미한다.
Stage 2은 Personalization의 이익을 확인하기 위한 임시솔루션이다. Stage 3의 Online Scoring Infrastructure를 만들 기 전에 타당성을 입증하는 데 사용된다. Stage 3에서는 사용자 수와 Experience 수 모두 확대된다.
Stage 3 : Move to Online Scoring
ML ranking 모델을 반복하여 학습해 유의미한 예약률을 얻고, 더 복잡한 모델을 학습시킬 수 있을 만큼 Train 데이터가 확대되었을 때, 우리는 Online Scoring Infrastructure를 만드는데 엔지니어링 자원을 투자하여 더 높은 예약률을 얻을 준비가 되었다.
Online Scoring에서는 완전히 새로운 Feature들을 사용할 수 있다. "Query Features"
이는 우리가 입력되는 위치, 게스트 수, 날짜를 더 많은 Feature를 개발하는 데 사용할 수 있다는 것을 의미한다.
예를 들어, 우리는 입력된 위치를 Experience과 입력된 위치 사이의 거리를 계산하는 데 사용할 수 있다. 이러한 Feature는 입력한 위치에 더 가까운 Experience를 더 높은 rank를 부여하는데 도움을 준다.
Query라고 하는 것은 사용자가 서비스에서 입력을 하는 질의를 의미합니다. 실제 서비스에서 위치정보, 검색어 등 다양한 것들이 있을 수 있습니다. 이러한 Query는 그 시점의 사용자 의도가 담겨있기 때문에, Personalized 된 결과를 제공하는데 중요한 역할을 합니다.
사용자 브라우저 언어 세팅을 활용하여 language personalization을 할 수 있다. 어떤 Experience들은 다양한 언어와 번역을 제공한다. 만약 브라우저가 번역 기능을 제공한다면, 그것이 노출될 것이다. 온라인 ranking 상에서, 언어가 매칭 되는 Experience를 Engineering feature를 활용하여 더 높은 rank에 위치시킬 수 있다. 아래의 이미지는 Stage 3 ML 모델에서 러시아어로 브라우저 언어와 Experience가 제공하는 언어가 일치되는 Experience의 rank를 더 높게 만든 예시이다.
마지막으로, 우리는 사용자가 어느 국가에서 검색하고 있는지 알 수 있다. 해당 국가의 사용자들이 좋아하는 카테고리에 기반하여 Experience ranking을 개인화하는데 사용자가 현재 검색하고 있는 국가 데이터를 활용할 수 있다. 예를 들어, 과거 데이터를 살펴보았을 때, 파리를 방문하는 일본인들은 Class & Workshops 카테고리를 좋아하고, 미국 사람들은 Food & Drink 카테고리를 좋아하였다고 해보자. 우리는 이런 정보를 활용하여 Personalization Feature로 활용할 수 있다.
Training the ranking model : Query Feature들을 활용하여 모델을 학습하기 위해, 우리는 그것을 과거 데이터에 추가하였다. 그 시점에 총 16000여 개의 Experience들이 있었고, 2000000개의 labeled 데이터로 90개의 ranking feature들 학습할 수 있었다. 앞에서 언급한 것처럼 우리는 두 개의 GBDT 모델을 학습하였다.
Model for logged-in users : Experience Features, Query Features, User(Personalization) Features의 사용
Model for logged-out traffic : Experience & Query Features(로그인 사용자를 기반으로 학습된 Feature, 단 Personalization Feature는 아님)
Online scoring infrastructure의 장점은 logged-in 모델은 이전보다 많이 사용할 수 있다는 점이다. 왜냐하면 personalized ranking을 Stage 2처럼 미리 계산해둘 필요가 없기 때문이다. 우리는 User ID와 같은 Personalization 신호가 있을 때마다 logged-in 모델을 사용하면 되고, 없으면 logged-out 모델을 사용하면 된다.
Testing the ranking model : 우리는 Stage 3의 모델과 Stage 2의 모델을 비교하는 A/B 테스트를 수행하였다. 그 결과 Stage 3의 모델이 5.1%가량의 예약률 향상을 가져왔다.
Implementation details : 수천 대의 목록을 online scoring 하기 위해서는 검색 서비스에 자체 ML infra를 개발해야 한다. Infrastructure는 3가지 파트로 구성된다. 1) 다양한 입력은 여러 곳에서 받아 실시간으로 넣는 부분, 2) 학습된 모델을 배치하는 부분, 3) 모델을 통해 Scoring 하는 부분.
이 모델은 Scoring에 있어 총 3가지 signal을 필요로 한다. (Experience Features, Query Features, User Features) 업데이트 주기, 그들의 사이즈 등에 따라 서로 다른 signal은 서로 다르게 저장된다. 예를 들어, User Feature는 매우 거대하므로 online key-value store에 저장되며, 사용자 요청 시 검색 서버에서 검색되어 사용된다. Experience Feature는 그리 크지 않기 때문에, 검색 서버 메모리에 저장되고 즉시 읽어서 사용할 수 있다. 마지막으로 Query Feature는 저장되지 않으며, front end에서 발생하는 데로 읽어서 사용된다.
Experience and User Feature는 둘 다 매일 Airflow를 통해 생성되고 업데이트된다. 더 많은 데이터가 들어오기 시작하면서, 우리는 몇몇 feature들을 key-value store를 활용하여 즉시 업데이트하는 기능을 가진 읽기/쓰기가 가능하도록 하고 있다.
Model Deployment(모델 배포) 과정에서, GBDT 모델 파일을 Java GBDT 구조로 면환하고, Search Service Application에서 로드하여 사용한다.
Scoring 단계에서 우리는 모든 Feature(User, Experience, Query Feature)를 끌어모으고, concat 하여 벡터 형태로 모델에 집어넣는다. 다음으로 User Feature의 signal을 기반으로 logged-in 모델을 사용할지, logged-out 모델을 사용할지 결정한다. 최종적으로 우리는 모든 Experience에 대한 score를 계산하고, 그것들의 rank를 서비스 페이지에 보여준다.
Stage 1, 2, 3의 모델을 생성하는 과정을 보면서 느낀 것은 Airbnb는 정말 정석적인 Data Science의 과정을 거쳤다는 점입니다. 어쩌면 놓치기 쉬운 부분들을 하나도 놓치지 않고 꼼꼼하게 수행하였습니다. Data를 분석하고, 모델의 목적을 명확히 하고, 대조군과 실험군을 설정하여 성능의 변화를 관찰하고, 실제로 적용하는 과정에 있어 제약조건의 적용까지 모든 단계를 성실히 수행하였습니다. 모델의 고도화와는 별개로 이 단계를 모두 거쳐서 모델의 타당성을 입증하였기에, Business에 잘 적용할 수 있지 않았나 합니다.
Stage 4 : Handle Business Rules
이 시점까지 우리 ranking 모델의 복표는 예약률을 높이는 것이었다. 그러나 Airbnb Experience과 같은 시장에서는 Business Rules라 불리는 몇 가지 부차적인 목표가 있을 수 있다. 그리고 이러한 것들은 Machine Learning을 통해 달성할 수 있다.
중요한 Business Rule 중 하나는 Promote Quality이다. (좋은 품질의 Experience가 많이 생성되도록 유도하는 것을 의미하는 것 같습니다.) 처음부터 사용자들이 정말 좋은 Experience를 경험한다면, 가까운 미래에 다시 돌아와서 Experience를 예약할 것이라고 믿었다. 이러한 이유에서, 우리는 사용자 Feedback을 수집하였다. 1~5점의 star rating과 unique/better than expected/engaging과 같은 Structured multiple-response feedback을 수집하였다.
재예약에 대한 가설을 입증할 수 있는 데이터가 많아짐에 따라, 그 경향은 뚜렷해졌다. 아래 도식의 왼편에서 볼 수 있듯이, 5점의 별점을 남긴 좋은 경험을 한 게스트는 1.5배 이상의 재예약률은 보였으며, 재예약률은 다른 낮은 별점을 남긴 게스트들에 비해 두드러지게 높았다.
우리는 이 문제를 Binary Classification 문제(+1 = 예약, -1 = 클릭 & 안 예약)로 변환하였다. 이때, 다른 품질의 평가들에 대해, 어떠한 weight를 줘야 하는지를 학습하였다. 데이터를 분석하여 Experience의 품질 분류하고 정의할 수 있었다.
very high quality Experience : 50개 초과의 review, 4.95 초과의 review rating, 55% 초과의 게스트가 unique/better than expected라 한 경우
very low quality Experience : 10개 미만의 review, 4.7 미만의 review rating
위의 Machine Learing Ranking 모델을 활용하여, Very High Quality Experience의 예약은 높이고, Very Low Quality Experience의 예약은 낮출 수 있었다.
그 외에도 다양한 부차적인 문제들을 풀 수 있었다. (이 부분은 원문에서 자세히 보시면 좋을 것 같습니다.)
Discovering and promoting potential new hits early
Enforcing diversity in the top 8 results
Optimize Search without Location for Clickability
Monitoring and Explaining Rankings
다양한 측면에서 왜 Item들이 그렇게 ranking 되었는지 설명하는 것은 매우 중요하다. 이것은 우리에게 많은 가치를 준다.
호스트들에게 순위 향상과 감소에 이르는 요인에 대한 구체적인 피드백을 줄 수 있다.
Ranking 알고리즘이 야기하는 트렌드를 확인해서 우리가 원하는 방향으로 행동이 유도하고 있는지 확인할 수 있다.
우리는 이것을 확인하기 위해, Apache Superset과 Airflow를 사용하여 두 개의 dashboard를 생성하였다.
ML 모델에 사용되는 Feature들과 특정 Experience들의 ranking을 tracking 하는 Dashboard
서로 다른 그룹의 전체 ranking 트렌드를 보여주는 Dashboard
그 몇 가지 예시는 아래에 있다.
바로 아래 그림은 30위에서 1위로 rank가 올라간 Experience 예시이며, 그 이유는 ML 모델에 사용되는 다양한 Feature들의 변화를 통해 알 수 있다.
반대의 경우로 4위에서 94위로 rank가 떨어진 Experience의 예시이다.
각각의 Feature들의 변화와 그 Signal들을 살펴보면서 Ranking의 상승 요인과 연결시키며 이해하면 좋을 것 같습니다.
이 Dashboard는 호스트들과 자주 접촉하는 마켓 매니저들에게 특히 유용할 것이다.
특정 Experience의 그룹별 ranking의 변화를 Feature들과 연관 지어 살펴보는 것은 시장을 이해하는데 많은 도움을 줍니다. 아래의 예시를 보면, 리뷰수, 평균 Rating, Unique Percentage 등에 따라 Group을 분류하고, 그에 따라 Group의 Ranking이 어떠한 trend로 변화하는지 볼 수 있습니다.
이러한 Dashboard들을 잘 활용하면 더 좋은 Business Decision을 할 수 있고, Ranking 알고리즘을 변경하여 사용자의 행동을 유도할 수 있다. 예를 들어, 다른 가격대 그룹의 트렌드를 보여주는 도식을 보면, 우리는 낮은 가격이 Experience의 ranking에 너무 많은 이득을 얻는다는 것을 알 수 있다. 그래서 우리는 Ranking 모델에 있어 Price의 영향을 줄이기로 했다.
가격의 영향을 줄이면서도 전체적인 예약률에 영향을 미치지 않도록 모델을 개선할 수 있었다. 즉, 우리가 원하는 ranking을 생성하기 위해 Machine Learning 모델이 유용하게 사용되는 것을 확인할 수 있다.
(위의 Dashboard들을 이해하는데, 조금 더 상세한 설명이 필요하다면 원문에 잘 나와있습니다.)
Airbnb는 실제 서비스의 적용 이후, 유지보수에도 많은 노력을 기울인 것을 볼 수 있습니다. 꾸준히 지표를 확인할 수 있는 Dashboard를 만들었다는 것은 Business Intelligence 측면에서 매우 중요합니다. Business의 목표를 측정할 수 있는 지표를 명확히 하고, 그것을 쉽게 분석할 수 있게 하는 부분을 시스템적으로 갖추는 것은 매우 바람직하다고 생각이 듭니다. Dashboard를 쉽게 만들 수 있는 Kibana 등의 다양한 툴에 대해서도 앞으로 리뷰해볼 예정입니다.
Summary of Business Impact so far
Don't wait until you have big data, you can do quite a bit with small data to help grow and improve your business
이 글은 아래의 원문을 번역/의역 및 요약하였습니다. 중간중간 파란색으로 표시된 글씨는 번역자의 견해입니다.
