[강연정리] 인공지능 추천 시스템 Airs 개발기

https://tv.naver.com/v/2297146

1. 추천 모델링이란?
2. 추천 모델 종류와 특징
3. 추천 품질 평가 방법
4. 대규모 추천 시스템 구축의 실제
5. 맺음말

 

---

1. 추천 모델링이란?

1.1 추천 모델링 정의

• 특정 시점에 유저가 좋아할 만한 아이템의 리스트를 찾는 것

1.2 추천 모델링 고려사항

• key factor : 유저수, 아이템수, 업데이트 양/주기, 모델 복잡도, 시스템 성능
• 모델 복잡도와 시스템 성능과의 trade off를 고려하여 추천 시스템 생성

1.3 추천 모델링 난제

• Sparsity Problem : 유저와 아이템 개수가 급증할수록 유저가 실제 소비한 아이템 비율은 점점 줄어듦
  → 머신러닝/딥러닝 기술로 극복

1.4 추천 모델링 프로세스

• 로그분석 → 모델선정 → 모델학습 → 품질평가 → A/B테스트 → 서비스 적용
  • A/B테스트(Fail) -> 모델선정
  • 서비스 적용 -> 로그분석

 

---

2. 추천 모델 종류와 특징

• 추천 모델의 종류
  Q. 유저가 좋아할 만한 아이템의 정의가 뭐지?
  A. 추천 모델마다 정의가 다르다.
  
  • Statistics based
  • Collaborative Filtering
  • Deep Learning

2.1 Statistics-based

좋아할만한 = 통계적으로 유의미한 아이템

• Chi-Squared : 예상보다 많이 본(Categorical)
  • 유저가 소비한 아이템의 예측치와 실제로 소비한 관측치의 차이를 이용
  • 예상보다 많이 본 것이므로, 절대값보다는 상대적인 변화량에 주목
• Cross-Entropy(KL-divergence) : 분포가 많이 다른(Continuous)
  • 보통 ML에서 loss function으로 사용 (c.f. 관측 엔트로피를 추가하면 KLD를 쓰는 것과 동일)
  • 분포가 많이 다른 경우 유의미한 추천 아이템으로 활용 가능

2.2 Collaborative Filtering

좋아할 만한 = 나와 비슷한 유저가 좋아한 아이템

• Neighborhood models (유사도 모델)
  • user-based
  • item-based
  • 유사도 계산 방법 (Co-occurrence : 동시에 발생하는 이벤트에 주목)
    • 기존에는 cosine similarity나 jaccard index 같은 것을 이용
    • PMI(pointwise mutual information) : 함께 발생한 빈도와 함께 각 이벤트가 발생할 확률을 함께 고려한 정보량
• Matrix Factoriztion model
  • matrics factorization은 u 이건 i 이건 한쪽으로 압축하게 되면서 압축 손실 발생
  • 아이템과 유저 벡테의 내적으로 구하게 됨
  • wALS (ALS + weighting scheme)
    • 계산량이 많고 학습 속도가 느림 (ASL를 이용해서 보완)
    • sparsity가 심해지므로 weighting scheme 사용
  • missing data를 negative 샘플로 사용

2.3 Deep Learning(Non linear models)

좋아할 만한 = 나의 컨텍스트 벡터와 가까운 아이템

• RNN for News Recommendation : 유저의 문서 소비 패턴을 보고 추천
  • LSTM layer : 많은 시퀀스 데이터 필요
  • 신규 뉴스의 경우 유저 로그가 없는 상태
  • RNN을 통해 학습된 유저 임베딩 정보를 활용
  • 유저-문서간 벡터연산을 통해 뉴스를 추천
• CNN for Deep Topic Tagger : 문서내 단어들의 배열을 보고 주제를 추론
  • convolution layer에 입력하기 위해 단어를 벡터로 변환하는 과정이 필요.
  • 각 문서에 대해 유입되었던 질의를 topic으로 보고 그 topic을 통해 문서의 주제를 판별할 수 있다고 판단
  • depth1 :90%~95%이상, depth3: 80~85% 이며 뎁스별로 활용 용도가 다른것 같음
    • depth3는 tag 추천 모델로 사용
• Deep CF model
  • CF는 나와 유사한 사람들이 본 문서가 나에게 도움이 된다는 가정이 깔려있음
  • Deep learning 스트럭처에만 의존해서 추천해야 하나? CF처럼 다른 사람들이 본 문서를 통해 나에게 좋은 문서를 가져올 순 없을까? (유튜브 검색)
  • rnn이나 cnn을 통해 네트워크에서 학습된 것을 사용자가 소비한 시퀀스의 압축된 형태라고 볼 수 있으므로, 이 아웃풋 layer을 Deep CF Model의 input으로 본다.
    • pre traing된 다양한 모델의 semantic한 정보를 인코딩하여 input feature으로 사용

2.4 추천 모델 특징 비교

• deep learning 모델이 굉장히 좋지만 만병통치약은 아니다.
• cf 모델의 특징 때문에 이를 대체할수 있는 모델은 없는 것 같다.
• 통계적인 기반을 가지고 데이터를 분석하지 않으면 의미가 없다.
• 위 모델들이 하이브리드 해서 들어가는 것이 가장 좋은 성능을 보여주고 있다.

 

---

3. 추천 품질 평가 방법

3.1 추천 품질 평가 요소

• 추천의 만족도
  • Accuracy : 유저가 실제 소비한 아이템이 상위에 추천되는지 ( 추천 모델의 성능 )
  • Diversity : 다양한 주제/유형의 아이템이 잘 추천되는지
  • Novelty : 새로 나온 최신의 아이템이 잘 추천되는지 ( Starvation 문제 해결 )
    • Diversity와 Novelty는 정량적 평가가 어려우며, Ranking을 할 때 사용해준다.

3.2 추천 모델 평가 방법

• 오프라인과 온라인 테스트를 병행하여 장기적인 관점에서 평가
  • 오프라인 정량평가 : 온라인 테스트 모델 선정
    • 비용이 적게 든다 (low cost)
    • 전체 모델간 비교 평가 (general)
    • 유저 관심사 고정 (static)
  • 온라인 A/B 테스트 : 실서비스 적용 여부 결정
    • 비용이 많이 든다 (high cost)
    • 특정 모델간 비교 평가 (specific)
    • 유저 관심사 변화 (dynamic)

3.3 추천 모델 평가 지표

• 추천모델의 기대효과에 따라 지표를 선정하고 시간별 추이를 관찰
  • 추천모델 정돡도 평가지표
    • precision/Recall@N : 추천 후보를 잘 찾는가?
    • F-score/AUROC
    • nDCG/MRR : 상단에 잘 랭킹하는가?
  • 실서비스 만족도 평가지표
    • 유저별 클릭수/CTR : 유저가 얼마나 소비하는가?
    • 유저별 총 체류시간
    • 신규 아이템 회전율 : 아이템이 골고루 소비되는가?

3.4 추천 모델 평가 결과 (Recall@10k)

• Statistics based : global (0.055)
  • 개인화가 아니기 때문에
  • global하게 추천(콜드스타터)
• Neighborhood Model : npmi+global (0.222)
• Matrix Factorization : wALS (0.266)
• Deep Learning : deep_cf (0.310)

*좋은 모델일수록 computational cost가 급격하게 증가

 

---

4.대규모 추천 시스템 구축의 설계

4.1 추천 시스템 구축 요구사항

얼마나 많은 데이터를 얼마나 빠르게 업데이트 할 것인가?

• 네이버 메인 트래픽 10,000TPS 이상
• 네이버 액티브 유저 수천만병 개인화 서빙
• 다양한 추천 서비스에 지속적인 확대 적용

4.2 추천 시스템 아키텍쳐

• 대규모 데이터를 실시간 처리 가능한 클러스터들의 조합
  • Data Warehouse Cluster(Cuve)
  • Processing Cluster(하둡-C3, Brew-K)
  • Serving Cluster(DOT)

4.3 추천 시스템 구축 노하우

• keywords
  • Research+DevOps(Productivity 향상)
  • 유저 데이터를 분석하고 추천모델을 선정 및 학습하는 과정과 실서비스 개발 및 운영하는 과정을 통합
  • Containerization(Scalability 향상)
  • 정제 및 서빙에 필요한 서버들을 컨테이너화 함으로써 확장성과 장애대처에 용이하도록 설계

4.3.1 Agile Development

Language & Tool 통합

• 데이터 분석 및 추천 모델링에 사용하는 언어와 도구를 실서비스 투입이 가능하도록 통합
• Airflow(scheduler), Hive(data warehouse), Spark(big data processing engine), Hadoop YARN(distributed cluster resource manager), Slider(an application to deploy existing distributed applications on Yarn cluster), OpenTSDB/Grafana(a scalable, distributed monitoring system), DOT(distributed incremental search engine), DDK/Cana(event-driven near-realtime serverless compute solution), C3(PaaS, Hadoop cluster), Cuve(Paas, HBase, Kafka), nBase-ARC(paas,..)

4.3.2 Seamless Interface

• Cuve-Hive-DOT (c.f. HBase-Hive-Redis)
• 모델링 코드가 그대로 서빙 시스템에 이식될 수 있도록 시스템간 인터페이스 추상화 구현

4.3.3 Data Catalog&Reusability

• Hive (Meta store)카탈로그 기반 데이터 뷰

4.3.4 효율적인 Task Scheduling

• Airflow DAGs 기반 관리
  • 여러 추천 서비스에서 공유 가능
  • dependency 구조에서 Sensor기능 활용

4.3.5 Batch Job Latency Trade-off

• Spark vs Hive (on MR)
  • Low latency batch job이 필요한 경우 Spark를 이용하자

4.3.6 컨테이너화를 통한 Ops 효율화

• Airflow Scheduler / web 서버는 Slider를 통해 실행
• 서버 장애 등의 상황에 자동 failover 및 급증하는 트래픽에 대한 scailability 확보

 

---

5. 맺음말

• 내 서비스에 딱 맞는 추천을 만들기 위해선, 충분한 데이터 탐색을 통한 유저와 아이템 분석이 필요
• 다양한 추천 모델을 비교하고 제대로 평가하기 위해선, 확률통계 및 머신/딥러닝 기술 적용과 올바른 평가지표 활용
• Throughput, Latency, Scalability라는 3마리 토끼를 잡기 위해선, 대규모 정제/서빙 시스템에 대한 깊은 이해와 협업정신

 

관련 뉴스(https://noelle-world.tistory.com/36)