타닥타닥8: 협업 필터링(Collaborative Filtering, CF) 알고리즘
#추천시스템
업무에서 추천 알고리즘을 적용할 일이 있어 부랴부랴 어설프게 가져다가 흘깃 보고 적용은 해놨으나 정확하게 설명하지 못하는 순간이 몇 번 있었어서 여러 블로그들을 보며 전반적인 개요와 설명들을 참고하며 정리해 보았다.
기본적인 갈래를 따지자면, 메모리 기반 접근 방식과 모델 기반 접근 방식으로 나눌 수 있다고 한다.
- 메모리 기반의 접근 방식: 가장 전통적인 접근 방식으로, 유저 간/ 아이템 간 유사도를 메모리에 저장해두고 있다가(matrix형태로 만들어 바로 계산할 수 있는 prediction용 함수로 쓰듯이), 특정 유저에 대하여 추천이 필요할 때 해당 유저와 유사한 유저들의 소비 아이템을 추천하거나, 특정 아이템과 유사한 아이템을 rating으로 기반으로 하여 추정한다.
- 모델 기반의 접근 방식: Latent Factor 방식과 Classification/Regression 방식 및 딥러닝을 사용한 접근 등 다양한 접근 방식
- 추천 시스템의 한계
| 구분 | 한계점 | 한계점 세부 설명 |
| 협업 필터링 |
콜드 스타트 | – 새로운 항목 추천 한계 – 초기 정보 부족의 문제점 |
| 계산 효율 저하 | – 다수 사용자의 경우 비효율 – 행렬 분해 시 장기간 계산 |
|
| 롱테일 문제 | – 비대칭적 쏠림현상 발생 – 관심 저조 항목 정보 부족 |
|
| 콘텐츠기반 필터링 |
메타정보 함축 한계 |
– 한정된 메타정보로 사용자와 상품의 프로파일 함축 불가 |
| 추천시스템 공통 문제 |
필터버블 | – 전체 정보 접근 기회 박탈 – 정보의 편향적 제공, 양극화 |
- 추천 시스템 한계의 극복 방안
| 한계점 | 극복 방안 | 상세 방안 |
| 콜드스타트 | – 딥러닝 기반 필터링 |
– 항목 자체 내용 분석 기반 – KNN, DBSCAN 등 AI기술 |
| 계산 효율 저하 |
– 병렬 컴퓨팅 | – 행렬 계산 최적화 컴퓨팅 사용 – GPGPU, Grid Computing 등 |
| 롱테일 문제 |
– 모델기반 협력필터링 |
– 자료 내 사용자 패턴기반 추천 – LDA, 베이지안 네트워크 |
| 메타정보 함축한계 |
– 협업 필터링 유사도 계산 |
– 서로 다른 분야 수치 계산 – 피어슨, 자카드 유사도 측정 |
| 필터버블 | – RAA – 플립피드 |
– 경고 푸시, 반대 콘텐츠 노출 – 딥러닝, SNS 타임라인 분석 |
#메모리 기반 접근 방식
이번에는 서비스의 속도와 데이터의 형태 때문에 메모리 기반의 접근 방식으로 진행하게 되었다. 모델 기반의 접근 방식도 적용해 보았는데, 속도 문제는 해결할 수 있었으나 데이터의 형태가 rating이 있는 것이 아닌 유저들의 행동을 기반으로 유추해야 하는 식이었기에 한계점이 극명했고, 학습은 일어나지만 결과가 너무 엉뚱하게 튀어나와 사용할 수 없었다.
이를 통해 메모리 기반의 접근 방식은 확실히 모델 기반의 접근 방식에 비해 도메인 지식에 대한 이해가 덜 필요하다는 것을 느낄 수 있었다. 모델 기반으로 접근하기 위해서는 데이터 수집의 단계부터 어떠한 메트릭을 사용하여야 필요한 결과를 낼 수 있는지 이해하여야 하며, 해당 기준을 통해 처음부터 데이터를 가공 및 정제하여야 한다. 그렇기에 모델 기반은 메모리 기반과는 달리 단순히 벡터의 방향성 등을 이용한 유사도 추정이 아닌 latent factor를 학습 및 추론할 수 있도록 구조의 설계가 선행되어야 한다는 것을 이해할 수 있었다.
반면에, 메모리 기반 접근 방식에서의 문제점으로는 matrix 사이즈가 커질수록 연산속도가 너무 느려진다는 것이 있었고, matrix 사이즈가 더욱 심각하게 커져버리면 python 3.8, pandas 2.1.0 기준으로는 matrix 자체를 만드는 과정에서 프로세스가 멈춰 버리는 일도 발생 했다. 아마도 훨씬 큰 데이터를 다루는 다른 도메인들에서 메모리 기반 접근 방식만을 쓰지 않는데는 이와 같은 속도 및 자원 이슈가 있기 때문일 듯 하다.
| 알고리즘 | 측정기준 | 측정 방법 |
| 유클리디안 유사도 |
유사도 거리 |
– 선호도를 벡터값으로 표현하여 두 지점 간 거리 계산, 유사도 측정 |
| 코사인 유사도 |
벡터 각도 |
– 선호도를 벡터 각도 코사인 계산하여 유사도 측정, 방향 확인 |
| 피어슨 유사도 |
경향성 수치 |
– (X,Y 함께 변화)/(X,Y 따로 변화) – X, Y 상관 관계 해석, 경향성 측정 |
| 자카드 유사도 |
선호도 수치 |
– (X, Y 교집합 수)/(X, Y 합집합 수) – 선호도를 알기 어려울 경우 사용 |
이 중 코사인 유사도를 구하는 수식은 다음과 같다.
수식은 굉장히 단순하여 A와 B가 모두 가지고 있는 공통 컴포넌트로 A,B의 유사도를 구하는 방식이다.
식이 나타내는 바를 생각해보면, A와 B의 벡터가 가지는 방향성을 비교하여 다차원에서의 벡터값의 값과 방향으로 그 각도의 차이를 구하는 것으로 보인다.
둘 다 공통적으로 가지고 있는 컴포넌트로 유사도를 구하기 때문에 sparse한 matrix의 데이터에서도 잘 작동할 수 있다.
값이 아예 없는 경우만 공통 컴포넌트로 카운트하지 않기 때문에 0값이 들어 있더라도 공통 컴포넌트로 계산에 들어가게 된다. 별점이나 점수로 rating을 메길 때에 0점을 주는 건 극히 부정적인 반응이므로 당연히 카운트 해야 하는게 맞지 싶다.
메모리 기반의 장점을 정리하자면,
1. 모델 기반에 비해 상대적으로 구축과 사용이 매우 간단하다.
2. 유저와 아이템을 직접적으로 연관시키고 추천하기에 결과를 설명하기가 용이하다.
3. 도메인에 의존되지 않고 사용할 수 있기에 유저와 아이템의 매트릭스만 있다면, 어느 곳에도 적용해 볼 수 있다.
단점으로는,
1. 새로운 아이템이나 유저에 대한 추천이 어렵다. (Cold Start related)
2. 데이터가 sparse 한 경우 데이터 수집 및 클리닝에 공을 많이 들여야 한다. (Data Sparsity related)
3. 속도 및 메모리 이슈로 데이터가 많아질수록 확장하기가 힘들어진다. (Scalability related)
#별첨 multi processing
메모리 기반의 속도 이슈 중 한 가지를 해결하는 multi processing에 대한 소소한 정리를 하고자 한다.
CF알고리즘을 통해 만들어진 유사도 함수를 통해 추천을 수행할 때 실시간 서비스를 하려면 대상에 대한 추천 정보를 미리 결과로 만들어 놔야 했다. 이 때, 모든 대상에 대해서 추천을 수행하는 작업은 대상 수만큼 추천 알고리즘을 거쳐야 하기에 단일 함수의 작업이 대상수(e.g: 100만명의 고객)만큼 일어나야 했다. 이를 하나씩 진행한다면 1번의 추천 작업당 1초만 걸리더라도 100만초의 시간이 걸리기에 모든 대상에 대한 추천은 277시간이라는 괴랄한 작업시간이 걸리게 된다. 함수를 아무리 최적화하여 작업을 ms단위로 줄여도 40시간 이하로 줄일 수 없었기에 이를 multi processing을 적용하여 병렬처리를 진행하게 되었다.
해당 소스를 슈도로 간단하게 정리하자면,
def parallel_func(func, args, n_process=n):
with Pool(n_process) as p:
results = p.map(func, args)
return results
이 함수는 multi processing을 수행하기 위한 기본적인 함수 구현으로 인자인 func에는 병렬 처리 하고자 하는 함수를, args에는 func에들어갈 input을, n_process에는 병렬 처리할 cpu숫자를 넣게 된다.
def CF_recommend_func(customer_ID):
recommended_item_per_customer = get_item_based_cf_func(customer_ID)
이 함수는 CF알고리즘을 통한 대상별 추천 아이템을 뽑는 간단한 구조를 슈도로 쓴 것이다. 대상의 ID를 넣고 관련된 아이템의 유사도를 CF를 통해 스코어로 저장한다.
recommend_result =
parallel_func(CF_recommend_func, args=customer_ID[:], n_process=multiprocessing.cpu_count())
이는 multi processing 함수에 추천 함수를 넣어 병렬처리를 수행하는 방식이다. 함수이름, 함수input, 병렬처리 cpu순으로 집어 넣어 작동한다.
위와 같은 방식으로 40시간이 걸리던 작업을 80개의 cpu 병렬처리를 통해 1시간 이내로 줄일 수 있었다. 40시간을 80개로 병렬처리 하였지만 정수배인 30분으로 딱 줄지는 않았는데, 이는 multi processing을 하기 위해 각cpu로 작업 및 자원을 배분하는 데에 드는 처리비용이 생기기 때문인 듯 하다. 고로 너무 볼륨이 작업은 multi processing을 구현하면 오히려 오래 걸릴 수도 있다.
하드웨어가 점점 발전하고 기기의 성능이 좋아지기에 속도 및 자원 이슈를 좀 가볍게 생각하고 있었는데, 이와 같은 병렬처리 함수를 잘 적용할 수 있다면 어떤 코드에서도 속도 및 효율을 극적으로 끌어올릴 수 있다는걸 깨달을 수 있는 좋은 기회였다.
#모델 기반 접근 방식(카카오 블로그의 내용 거의 그대로 복붙이다.)
Latent Factor 방식: Matrix Factorization(행렬 분해)
-모델 기반의 접근 방식 중에서도 Latent Factor 기반의 방식, 특히 아이템 Latent Vector(잠재 벡터)와 유저 Latent Vector 간 Inner Product로 아이템에 대한 유저의 선호를 모델링 하는 Matrix Factorization 방식의 접근은, 간단하지만 강력한 추천이 가능합니다. Autoencoder를 추천에 활용하기도 하는데, 이는 Latent Factor 방식의 일반화(Generalization)라고 볼 수 있습니다.
Classification/Regression(분류/회귀) 방식
-Classification/Regression 방식은 콘텐츠 기반 추천 방식과 쉽게 융합이 가능합니다. 피처 X 가 주어졌을 때, 라벨 y를 예측하는 구조이기 때문에, 피드백 y를 예측하는 상황에서, X에 콘텐츠 관련 정보를 피처로 만들어서 추가하면, 피드백 데이터뿐만 아니라 콘텐츠 데이터를 활용한 추천이 가능합니다.
최신의 융합 모델 방식
최근에는 다양한 방식의 모델들이 제안되며, 단순하게 모델을 분류하기 어려운 부분도 있는데요, Latent Factor 모델과 Classification/Regression 모델의 특징을 모두 가지고 있는 Factorization Machine 계열의 모델들도 제안되어 왔고, 딥러닝을 활용하여 복잡한 Interaction을 모델링 하는 방향으로 Latent Factor 모델을 확장한 Neural Collaborative Filtering도 제시되었으며, 레이어 설계가 자유로운 딥러닝 모델 특성상 자연스럽게 콘텐츠 정보를 결합한 하이브리드 추천 방식의 모델도 많이 제안되었습니다.
이처럼, 다양한 CF 모델 중 어떤 CF 모델을 사용해야 할지는 크게 다음의 3가지 요소가 결정합니다.
Latent Factor(잠재 인수) : 사용자와 아이템 데이터에 숨어있는 특징을 잠재적인 차원(Factor)을 사용해 나타내고자 하는 모델로, Matrix Factorization(행렬 분해) 방식이 대표적.
Autoencoder : 학습 데이터에 레이블 데이터를 별도로 구축할 필요가 없는, 주어진 데이터만으로 학습이 가능한 비지도 학습 모델로, Encoder와 Decoder의 2개의 신경망으로 구성됨. Encoder는 입력 데이터에서 학습에 중요하다고 판단되는 정보만을 남기고 불필요하다고 판단되는 데이터는 제거함으로써 첫 입력 데이터보다 더 작은 크기의 데이터를 생성하는 역할을 하며, Decoder는 다시 처음의 입력 이미지로 복원하는 역할을 함. 이때, Encoder가 생성하는 더 작은 크기의 데이터를 Latent Vector(잠재 벡터)라고 칭함. 즉, Autoencoder가 학습하고 데이터를 생성하는 과정은 한 문장의 설명을 듣고 몽타주를 그리는 과정과 유사함.
Generalization(일반화) : 모델이 특정 데이터에 과 적합(Overfitting) 되지 않고 다양한 데이터에 모두 적용 가능한 상태가 되는 것을 말함.
어떤 CF 모델을 선택할 것인가(1): 피드백(Feedback) 데이터
CF 모델은 유저, 아이템 상호작용 데이터를 활용한다고 언급하였는데요, 이 피드백 데이터의 종류에 따라서 모델의 선택이 달라질 수 있습니다.
카카오에는 다양한 서비스가 존재하는 만큼 다양한 형태의 피드백이 존재합니다. 예를 들어, 선물하기의 경우, “이 선물 좋아요”, 다음 영화 “평점”과 같이 유저의 콘텐츠에 대한 선호를 직접 수집할 수 있는 경우가 있습니다. 이러한 피드백은 Explicit Feedback(명시적 피드백)이라고 합니다. 유저의 선호를 유저가 직접 표현한 데이터이기 때문에 정확도가 높습니다. 그러나 이러한 피드백을 애써 남기는 유저는 많지 않습니다. 흔히 말하는 MovieLens(영화 평점) 데이터와 같은 유형의 데이터를 얻을 수 있는 서비스는 한정적입니다.
반면, 클릭, 콘텐츠 소비, 구매와 같은 행동 패턴은 유저도 모르는 사이에 자연스럽게 유저의 선호를 유추할 수 있게 합니다. 선물하기에서는 “클릭”, “구매”, 픽코마의 경우, “클릭”, “콘텐츠 소비”, “코인 사용”과 같은 피드백, 다음 뉴스의 경우에는 “클릭” 및 “체류 시간”에 관한 피드백을 수집하기도 합니다. 이러한 피드백의 경우, 유저가 이 콘텐츠에 대해 싫어하는지는 알 수가 없습니다(Unary Rating). 즉, 유저가 해당 콘텐츠를 여러 번 소비한 경우에는 선호가 높다고 가정할 수 있지만, 유저가 클릭하지 않은 아이템이 유저가 선호하지 않아서 소비하지 않은 것인지, 알고 보니 취향인데 소비하지 않은 것인지는 알 수 없습니다.
Implicit Feedback(암시적 피드백)의 이러한 특성을 잘 고려한 모델이 흔히 Alternating Least Squares(ALS)5라 불리는 모델입니다. 유저가 스스로 밝힌 취향 그 자체인 Explicit Feedback과 달리 Implicit Feedback은 유저가 해당 아이템을 소비하고 불만족하였을 수도 있고, 소비하지 않은 아이템을 꼭 싫어한다고 볼 수도 없기 때문에, 이러한 불확실성을 반영하기 위해 Confidence 개념을 도입했습니다. Implicit Feedback이 존재하는 경우는 “선호가 있다”라고 해석하고, 반대의 경우는 “선호가 없다”라고 해석합니다. 다만, 그러한 판단이 얼마나 확신할 수 있는지는 Implicit Feedback을 바탕으로 계산하게 됩니다. 아무래도 특정 아이템을 소비한 횟수가 많으면 많을수록, 실수로 소비했다거나, 소비 후 불만족했다고 보기 어렵겠죠. 또한, 한 번도 소비하지 않은 경우는 불확실성이 매우 높을 것이고요.
이처럼 ALS 모델은 단순히 관찰된 피드백뿐만 아니라 관찰되지 않은 제로 피드백의 경우에도 학습 과정에 반영 가능합니다. 이 과정에서 계산량이 많아지다 보니, alternating-least-squares optimization 방식을 사용하여 학습을 진행하기 때문에 위와 같은 이름이 붙게 되었습니다.
참고: Implicit Feedback의 특성을 고려하여 Confidence 개념을 도입한 ALS의 Cost 공식
Alternating Least Squares(ALS) : 교대 최소 제곱법. 목적함수를 최적화하는 기법으로, 사용자와 아이템의 Latent Factor를 한 번씩 번갈아가며 학습시킴. 아이템의 행렬을 상수로 놓고 사용자 행렬을 학습시키고, 사용자 행렬을 상수로 놓고 아이템 행렬을 학습시키는 과정을 반복함으로써 최적의 Latent Factor를 학습시키는 방법.
어떤 CF 모델을 선택할 것인가(2): 메트릭(Metrics)
CF 모델을 어떤 기준으로 평가하느냐에 따라서도 모델의 선택이 달라질 수 있습니다. 우리가 추천 모델을 사용하게 되는 구좌의 맥락이 약간씩 다른데, 그때마다 우리가 최적화해야 하는 메트릭도 달라질 수 있습니다.
예를 들어, 광고 추천의 경우에는 광고를 클릭할 예상 확률(predicted click-through rate)이 광고 과금액 선정에 직접적인 영향을 미치기 때문에, 클릭할 확률을 정확하게 맞추는 게 중요합니다. 한편, Top N 개의 후보군을 추출하는 경우에는, 예측값 자체보다는 상위 추천 결과에 유저가 클릭할 만한 아이템이 얼마나 많이 추천되는지가 중요한 경우도 있습니다. 이러한 목적에 맞추어 최적화해야 하는 메트릭을 선택합니다.
하나의 모델을 학습할 때, 여러 가지 메트릭 중에서 어떤 메트릭은 개선이 되어도, 다른 메트릭에서는 개선이 일어나지 않는 경우도 종종 있습니다. 예를 들어, 예측값과 실제 클릭 여부(0, 1) 사이의 차이를 측정하는 지표인 Log Loss가 줄어들어도 랭킹은 그대로일 수 있고, 따라서 랭킹 메트릭은 개선이 되지 않을 수도 있습니다. 이처럼, 여러 메트릭을 측정하더라도, 현재 문제 상황에서 가장 중요한 개선 메트릭이 무엇인지를 파악하는 것이 매우 중요합니다.
예를 들어 보겠습니다. 예측값과 실제 클릭 여부의 차이를 측정하는 메트릭이 아닌, 클릭 확률로 줄을 세웠을 때, 클릭한 아이템이 클릭하지 않은 아이템보다 상위에 랭크될 확률을 계산한 AUC를 최적화하는 것이 중요한 태스크의 경우에는, Bayesian Personalized Ranking(BPR)과 같이 AUC를 직접 최적화하는 모델을 사용하는 것이 적합할 수 있습니다.
많은 추천 모델들이 랭킹 문제를 풀고 있지만, 랭킹 자체를 최적화하기보다는, 아이템 한 개와 관련된 Pointwise Loss7의 최적화를 통해 랭킹 메트릭의 최적화 또한 기대합니다. 즉, 특정 아이템에 대해 예측한 값이 실제 값과 얼마나 다른지를 Loss로 정의하고, 그 Loss를 최소화하는 방식으로 작동합니다.
그러나 BPR의 경우, 단순히 아이템 한 개가 아니라, 선호하는 아이템과 선호하지 않는 아이템 페어8를 활용하여, 선호하는 아이템이 더 상위에 랭크되는지를 측정하는 메트릭인 AUC를 직접 최적화하는 학습 프레임워크를 제공합니다. 즉, 선호하는 아이템과 선호하지 않는 아이템의 예측값 사이의 차이를 최대한 벌리는 방식으로 작동합니다.
참고: BPR Maximization 함수
Bayesian Personalized Ranking(BPR) : 아이템에 대한 사용자의 선호도를 확률 모형화한 모델로, 사용자가 선호하는 아이템을 단계별로 카테고리화(긍정적 아이템, 부정적 아이템) 해서 분석을 진행함. 아이템을 카테고리화할 때 사용자가 내재적 피드백을 제공했는지 안 했는지의 정보만을 이용하기 때문에 정보의 손실이 발생할 수 있지만, 기존의 기법 대비 우수한 성능을 보이는 모델.
Point-wise: 손실 함수(Loss Function)에서 한 번에 하나의 아이템만을 고려하는 방법으로, 하나의 사용자에 대응하는 하나의 아이템만을 자기고 Score를 계산하고 이를 Label Score과 비교해서 최적화함. 아이템 간의 순서 관계를 무시하고 독립적인 개체로써 학습시키고 결과만을 정렬한다는 단점이 있으나, 그만큼 직관적인 모델이기도 함.
Pair-wise: 손실 함수(Loss Function)에서 한 번에 2개의 아이템을 고려하는 방법. 1개의 긍정적 아이템과 1개의 부정적 아이템을 고려하기 때문에, 데이터 셋에 {사용자, 긍정적 아이템, 부정적 아이템}의 3가지 항목이 포함되어야 하고, 이로 인한 데이터 중복을 해결하기 위해 Sampling 기법이 활용됨.
어떤 CF 모델을 선택할 것인가(3): Bias & Feedback Loop
마지막으로 고려할 점은, 추천 시스템에서 학습에 활용하는 피드백 데이터는 본질적으로 실험 데이터가 아닌 관찰 데이터라는 점입니다. 즉, 통제된 환경이 아닌, 여러 가지 요인에 의해 데이터 수집에 영향을 받아 다양한 Bias가 끼어있는 데이터입니다. 대표적으로, 추천 시스템이 노출시키는 특정 아이템에만 노출이 된 아이템에 대한 유저의 피드백만을 관찰할 수 있습니다. 이와 같은 문제는 피드백 루프(Feeback Loop)로 더욱 강화됩니다. 즉, 추천 시스템이 추천한 결과를 다시 추천 시스템이 학습하여, 계속 모델 Bias가 강화되는 문제입니다.
이는 유저에게 더 큰 만족을 줄 수도 있는 아이템의 유입을 어렵게 하여, 장기적으로는 추천 시스템의 온라인 성능이 하락하는 문제로 이어질 수 있습니다. 동시에 Bias가 존재하는 데이터는 오프라인에서 신규 모델 개발에 있어 평가를 어렵게 합니다.
이러한 Bias가 존재하는 데이터 셋을 이용하여 평가가 이루어지면, 기존 모델에 더 유리하게 평가가 되기도 합니다. 특히, nDCG(normalized Discounted Cumulative Gain)9와 같은 메트릭의 경우, 이러한 Bias가 존재하는 데이터로 평가할 경우, 기존 추천 결과를 얼마나 모사하느냐를 평가하게 되기 때문에, 각별한 주의가 필요합니다.
이와 같은 Bias 및 피드백 루프 문제를 방지하는 가장 간단한 방법으로, 랜덤하게 추천된 데이터를 수집해 학습 및 평가에 활용하는 방법이 있지만, 랜덤 데이터 수집은 유저 경험에 상당한 악영향을 끼칠 수 있어 대규모로 수집하는 것은 어렵습니다. 그래서 Bias가 존재하는 데이터로도 최대한 공정한 평가를 하기 위한 Debiasing 방법들이 연구되고 있습니다. 평가뿐만 아니라, 모델 학습에 있어서도 Debiasing 방법론을 활용한 연구들이 진행되고 있습니다(7번 레퍼런스 참조).
nDCG(normalized Discounted Cumulative Gain): 추천 시스템에서 랭킹 추천 분야에서 많이 쓰이는 평가 지표로, 특히 상위의 랭킹 리스트가 하위 랭킹 리스트보다 확연하게 중요한 도메인에서 유용한 평가 기준.
#추천시스템(Recommendation System) 활용사례
아마존
아마존은 전자상거래분야에서 추천시스템의 선구자라고 할수 있다.
아마존은 사업 초기부터 추천시스템의 가치를 알아보고 이를전자상거래에 활용하기 위한 방법을 모색해온 몇 안되는 회사이다.
아마존은 평점(Rating),구매행위(Buying Behavior) 그리고 검색행위(BrowsingBehavior) 정보들을 이용해 추천시스템을 운영하고 있다. 특히 Rating이 추천시스템에 있어서 중요한 역할을 하는데 아마존에서는 이를 명시적인 평점(Explicit Rating)와 암묵적인 평점(Implicit Rating)의 2가지로 구분해 활용하고 있다. 명시적인 평점은 사용자가 직접 주는평점을 의미하는 것이고, 암묵적인 평점은 구매행위와 피드백을 가공해 사용하고 있다.
넷플릭스
비디오 스트리밍회사로 잘 알려져 있는 넷플릭스 역시 아마존과 마찬가지로 추천시스템의 열렬한 신봉자라고 할 수 있다. 넷플릭스 서비스의 핵심적인 기술요소는 추천시스템으로 사용자의 성향을 파악해 좋아할 만한 영화를 추천해주는 단순한 시스템에서 출발했지만 최근에는 사용자가 로그인하는 순간 해당 사용자의 취향에 맞춰 전체 페이지가 구성되는 수준까지 발전했다.
넷플리스는 자사의 추천시스템보다 10%이상 성능을 향상 시킬 수 있는 방법을 제시한 팀에게 상금을 주는 “Netflix Prize Contest“라는 것을 개최해 머신러닝 발전에 혁혁한 공을 세우기도 했다.
Netflix Prize Contest를 통해 SVD(Singular Value Decomposition, 특이값 분해)과 ensemble의 중요성 등이 많이 부각되었고, 우승팀이 사용했던 방법과 수학이론들을 많은 데이터과학자들과 머신러닝 개발자들에게 영감을 주었다.
페이스북
페이스북 역시 추천시스템을 적극적으로 활용중인 회사인데 앞서 언급한 회사들과는 다르게 상품이나 뉴스 추천이 아니라 친구추천을 하는데 활용하고 있다.
친구추천은 전통적인 추천시스템의 대상이었던 상품과는 다른 성격을 가지고 있다.
상품추천의 목적은 매출의 증대와 같은 직접적인 목적을 가지고 있는 반면에 친구추천은 서로의 교류를 증대 시킬 목적을 가지고 있기 때문에 Link Prediction이라는 것에 중점을 두고 있다.