[RecSys] 한 눈에 보기 정리 - 2

 

 

1. 추천시스템이 필요한 이유

1. 사용자가 정보를 찾는데 소요되는 시간을 효과적으로 감소시키는 것
2. 사용자의 관심사에 해당되는(유사한) 컨텐츠(아이템)을 추천하여, 선택의 폭을 확장시키는 것

Push & Pull

• Push : 사용자가 관심을 가질 만한 정보를 시스템이 Push해줌
• Pull : 사용자의 의도가 명확하여, 사용자가 해당되는 항목을 Pull하는 것 ex) 검색

결정피로 : 방대한 정보 속에서 원하는 정보 찾기 위한 피로도

---->>>> 원하는 정보를 잘 필터링하고 추천해주는 시스템이 필요

 

 

2. 추천시스템 workflow

1) 데이터

: user-item 관련 데이터 / interaction, feedback 등

2) Task 설정

- 단기 목표 : 클릭 수, 특정 기간의 총 수익 등

- 장기 목표 : 사이트 내 소비 시간 증가, 재방문 및 사용자 유지 비율 개선, 구독자 수 증가 등

--->>> 일반적으로 최적화 대상은 한 가지 / but 두 가지 이상을 대상으로 하는 경우도 있음

3) 목적함수(Object function)

: 미래 특정 상황에서 사용자에게 어떤 아이템을 제안했을 때 발생하는 가치를 예측하도록 설계

4) 평가(Ranking)

- 목적함수의 기댓값을 최적화(최대화, 최소화)할 수 있도록 방법론 설정

- 연관성(relevance), 여러 활용성 지표, 비즈니스 규칙 등 많은 요소를 적절히 조합하여 선정

 

 

3. 성능평가 : On-Offline Test

1) Offline Test

: 주로 배포 전에, 모델의 잠재적인 가능성을 평가하기 위해 과거 데이터로 다양한 성능지표를 측정하는 과정

- 데이터 분할 : user, item, timestamp 등 다양한 전략 가능

1. Leave One Last : 마지막 구매를 test로 사용, 마지막에서 두 번째를 validation으로 사용
   • 마지막 구매만으로 평가하므로 전체적인 성능을 반영한다고 보기 어려움
   • 유저마다 타임 라인 상에서 겹쳐지는 부분이 생길 수 있음 -> 모델이 test 데이터를 interaction으로 학습할 가능성
     • Data Leakage 문제
2. Temporal User/Global Split
   • Temporal User : Leave One Last와 유사 -> Data Leakage 문제 / 유저 별로 시간 순서에 따라 일정 비율로 분할
   • Temporal Global : 전체적인 관점에서 시점을 고정 / test 데이터로 많이 분할 될 수 있어서 interaction 데이터가 부족할 수 있음
3. Random Split : 각 사용자 별로 interaction을 시간순서에 관계없이 random하게 분할
   • 사용하기 용이 / 많은 train 데이터 // Data Leakage 문제
4. User Split : 사용자가 겹치지 않게 사용자를 기준으로 분할
   • Cold-start 문제에 대응하는 모델 생성 가능
   • User-free 모델에만 가능 / Data Leakage 문제
5. K-fold Cross Validation : Train을 k개의 fold로 분할 -> validation을 한 fold씩 번갈아가면서 사용
   • 모델 일반화 장점 / fold ensemble -> 성능 향상
   • k개의 fold을 생성해야함으로 많은 resource 필요
6. Time Series Cross Validation : fold 분할시 시간 고려
   • 시계열 데이터의 경우, 미래 데이터를 학습하여 과거 예측하는 문제 있음
   • 그래서 validation은 fold 생성시 마지막 fold로 하여, 매 iteration에서 fold 개수가 증가
   • 혹은 validation을 고정, 매 iteration에서 과거 데이터를 증가시킴

 

2) Online Test

: A/B Test // 모델을 실제 사용자에게 테스트함으로써 새로운 모델과 기존의 모델을 비교하는 방식

• Offline Test에서 좋은 평가를 받았다하더라도 Online Test에서 반드시 좋지는 않음
• 실시간 traffic을 대조군(A)와 실험군(B)로 나누어 성능 비교 실행
  • 이상적인 버킷 리스트
    • 동일 유저에게 A, B를 모두 경험하게 하여 어떤 선택을 하게 되는지를 비교
  • 현실적인 버킷 리스트
    • 유저를 두 그룹으로 분할(유사한 성향을 가진 유저들로 구성) / traffic 반으로 나눠서 사용
    • 각각 A, B를 경험하고 평균을 낸 결과를 비교

 

3) 성능 지표

1) 평점 예측

• RMSE : Root Mean Squared Error
• MAE : Mean Absolute Error

 

2) 랭킹 문제

• Precision@K : 추천된 Top K개 중 실제 관심있는 아이템의 비율
• Recall@K : 관심있는 아이템 전체 중에 Top K개에 포함된 비율
• AP@K (Average Precision@K)
• MAP@K (Mean Average Precision@K)
• Relevance : 유저가 추천된 아이템을 얼마나 선호하는지
  • CG (Cumulative Gain) : rel_i(item i에 대한 선호도)의 합
  • DCG (Dicounted Cumulative Gain)
  • IDCG (Ideal DCG)
  • NDCG (Normalized DCG)
• Hit-rate : 전체 사용자 수 대시 적중한 사용자 수 (적중률)

3) 한계점

정확성 개선과 실제 시스템의 성능향상을 연관 짓기 어려움

서비스의 성능 향상 != 서비스의 만족도 향상

--->>> 특성지표

추천 항목 다각화 -> 다양하게 추천 ::: 만족도 및 성능향상 유도

 

4) 특성지표

: 성공적인 추천시스템 : 정확도 향상 + 흔하지 않으면서 흥미롭고 다양한 아이템 추천 가능

• Coverage 
  • 전체 아이템 중 추천시스템이 추천하는 아이템의 비율
• Novelty
  • 얼마나 새로운 아이템인지
• Personalization
  • 얼마나 개인화되었는지
• Serendipity
  • 얼마나 의외의 아이템을 추천하는지
• Diversity
  • 얼마나 다양한지