추천 시스템 모델을 개발하고 나면, offline metric을 통해 먼저 성능을 가늠해본다.
여기서는 각 offline metric의 정의와 장점, 단점, 단점보완법 등을 알아보자.
상황:
tester는 주어진 기간에 구매한 상품set이 존재하고 B = set(bitem_1, bitem_2, ..., bitem_N])
recommendation engine은 각 tester마다 추천 상품 list가 존재 R = [ritem_1, r_item2, ..., ritem_K]
Hit rate
-유저마다 Top-k recommendation에서 hit한게 존재하면 hit += 1
-#hit/#user
-고객의 내역 중 time-axis가 존재한다면
-train/test를 특정 time으로 나눠 계산 가능
-혹은 고객별 first J data를 활용하여 train후 J+1부터를 test로 삼아 계산 가능
-time-axis가 존재하지 않는다면 leave one out cross validation 사용
장점:
-해석이 아주 간편함
-time-axis가 존재하지 않을 때, 계산량은 많으며 굉장히 낮은 값을 가짐
단점:
-rank-unaware방식
ARHR
-Average Reciprocal Hit Rate
-sum(1/rank)/#user
장점:
-rank를 고려하지만...
단점:
-first의 rank만 고려함
P@K
-Precision at K
-R의 first K개 중 relevant items의 개수 비율
-Decision-support measure
ex)
B = set([티셔츠, 반바지])
R = [음료수, 거울, 티셔츠, 반바지]
P@1 = 0/1 # [음료수](1) 중에 set([티셔츠, 반바지])가 존재하는 개수(0)
P@2 = 0/2 # [음료수, 거울](2) 중에 set([티셔츠, 반바지])가 존재하는 개수(0)
P@3 = 1/3 # [음료수, 거울, 티셔츠](3) 중에 set([티셔츠, 반바지])가 존재하는 개수(1)
AP@K
-Average Precision at K
-P@1, P@2, ..., P@K의 평균
-Decision-support measure
장점:
-ranking에 sensitive하다, R 내에서 순서를 바꾸면 score값이 바뀜
-stable, R 내에서 순서를 "조금"만 바꾸면 AP@K값도 "조금"만 바뀜
-ranking이 높은 item이 큰 weight를 갖는다.
-recall-oriented factor가 존재, 즉 tester의 모든 relevant items를 고려해서 AP@K값이 나온다.
단점:
-해석이 어렵다, 이 숫자가 0.03이라고해서 즉각적인 해석이 되지 않는다. 게다가 기본적으로 작은 값들을 가질 때가 많은데, 프로젝트 보고서를 작성할 때 높으신 분에게 이 숫자를 보여주면 기겁할 수 있으니 PM들이 다른 수치가 없냐고 묻는다. 그럴 때엔 다른 수치를 대체하여 사용하거나, 비슷한 도메인에서의 paper에서의 metric을 들고와서 부연설명을 하는게 필요하다.
ex)(위의 예 이어서)
AP@1 = P@1/1 = 0
AP@2 = (P@1+P@2)/2 = (0+0)/2 = 0
AP@3 = (P@1+P@2+P@3)/3 = (0+0+1/3)/3 = 1/9
MAP@K
-Mean Average Precision at K
-각 tester마다 AP@K를 구하고, 전체 tester에 대한 AP@K값의 평균
-Decision-support measure
-장단점은 AP@K와 같다.
DCG(Discounted Cumulative Gain), IDCG(Ideal DCG), NDCG(Normalized DCG)
-Decision-support measure
-Gain = Relevancy level
장점
-MAP는 relevance에 대해서만 고려한다면, DCG형태의 concept은 relevancy의 level에 주목한다.
(즉 MAP는 관련이 있다vs없다 지만, DCG형태는 관련이 x(float)만큼 있다. 형태의 관점)
-
단점
-Bad recommendation에 대해서 penalty 부과를 하지 않는다. 대안책으로 bad에 대해 negative score(원래는 zero score를 부과하지만)를 부과하면 해결이 된다. 이 때 전반적으로 score가 낮아지는 경향을 띄며, precision이 recall보다 중요할 때 사용
-다 맞힌 NDCG@3과 다 맞힌 NDCG@5를 생각하면, 후자가 더 높은 점수여야하는데 보정이 안된다. 이 때, 전자는 missing 2 target으로 생각하고 minimum relevance를 설정하여 부과하여 전자도 NDCG@5로 계산하면 보정이 된다.
(즉 더 높은 k에 대해서 더 잘맞춘 경우 점수가 더 높게 설정이 필요)
MAE
-Mean Absolute Error
-tester마다 B의 rating과 R의 predicted rating간의 차이의 합(의 평균, 이 때 평균낼 때는 B 중에서도 tester가 rating한 상품들의 개수가 분모로 간다.)
-Error metrics
특징:
-모든 user를 만족할 필요 없을 때 사용, 즉 몇몇 유저에게는 bad recommendation이 등장할 수 있음
-여러 tester에 대해 MAE를 구할 때, 각 유저마다 상품마다 차이를 구하고, 개별tester기준으로 평균을 하는 이유는, 한 user에게 비교적 predict이 우수했음에도 불구하고 error계산하는 상품이 많았다면, 단순히 error값이 커지기 때문, 즉 all users contribute equally하기 위함
-전체 tester들의 B 중에서 rating한 items가 많은 경우, 그 중 popular item과 not popular item이 존재하는 경우 popular/not popular 으로 divide해서 측정하기도 한다. 이는 popular item이 not popular보다 prediction power가 높기 때문에, 비교적 not popular item이 얼마나 예측력을 가지는 것을 따로 보기 위함(long-tail item에 대한 평가)
-Error metrics이기 때문에, 모든 items를 동일한 weight를 갖고 error 측정, 즉 ranking이 중요하지 않은 형태, 즉 not rank-aware metric으로 Top-k recommendation 관점에서는 부적절
-Recommendation system을 평가할 때는 각 tester마다의 MAE를 구하고 전체 tester에 대해 평균
MSE, RMSE
-Mean Squared Error, Root Mean Squared Error
-Error metrics
특징:
-큰 error는 더 큰 error로 해석하기에, bad recommendation이 등장하지 않아야하는 조심스러울 때 유용
-여러 tester에 대해 MSE/RMSE를 구할 때, 각 유저마다 상품마다 차이를 구하고, 개별tester기준으로 평균을 하는 이유는, 한 user에게 비교적 predict이 우수했음에도 불구하고 error계산하는 상품이 많았다면, 단순히 error값이 커지기 때문, 즉 all users contribute equally하기 위함
-전체 tester들의 B 중에서 rating한 items가 많은 경우, 그 중 popular item과 not popular item이 존재하는 경우 popular/not popular 으로 divide해서 측정하기도 한다. 이는 popular item이 not popular보다 prediction power가 높기 때문에, 비교적 not popular item이 얼마나 예측력을 가지는 것을 따로 보기 위함(long-tail item에 대한 평가)
-Error metrics이기 때문에, 모든 items를 동일한 weight를 갖고 error 측정, 즉 ranking이 중요하지 않은 형태, 즉 not rank-aware metric으로 Top-k recommendation 관점에서는 부적절
-MSE는 단위가 rating의 제곱, RMSE는 rating과 같음
-Recommendation system을 평가할 때는 각 tester마다의 MAE를 구하고 전체 tester에 대해 평균
참고자료:
https://trec.nist.gov/presentations/TREC8/intro/tsld039.htm
https://www.vernier.com/til/1014
'ML > Recsys' 카테고리의 다른 글
[Recsys]Content-based filtering의 장단점 (0) | 2020.10.19 |
---|---|
[Recsys]Which similarity measure to choose? (0) | 2020.10.19 |
(미완)[Recsys][Paper]Deep Generative Ranking for Personalized Recommendation (0) | 2020.10.04 |
(미완)[Recsys][Metric]Offline metrics (0) | 2020.10.04 |
(미완)[Recsys]Learning to Rank (1) | 2020.10.04 |