[강연정리] 쿠팡 추천 시스템 2년간의 변천사(1)

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

I. 쿠팡 추천 플랫폼의 변화

1. 쿠팡 추천 팀이 하는 일
2. 과거, 추천 모델 중심의 플랫폼
3. 현재, 서비스와 모델을 분리하는 플랫폼

II. 더 나은 추천을 위해

1. Learning to Rank
2. 실시간 개인화

III. 요약&팁

 

 

I. 쿠팡 추천 플랫폼의 변화

---

1. 쿠팡 추천 팀이 하는 일

• 과거 상품 추천
  • Item을 input으로 받아 item을 output으로 출력 (item-item)
  • e-commerce는 대표적으로 함께 본 상품과(대체재) 함께 산 상품(보완재)이 있다.
• 하고 싶었던 것 :
  • 특정 상품을 컨텍스트로 하지 않는 유저, 카테고리, 시간을 컨텍스트 또는 복합적 컨텍스트로 하는 추천
    • example
      • 나를 위한 개인화 추천 (user - item)
      • 오늘의 쇼핑 제안 (time - item)
      • 요즘 인기있는 상품들
      • 나를 위한 할인 상품들
      • 특정 카테고리에서 내가 자주 산 상품 (category - item)
      • 특정 카테고리에서 요즘 인기있는 상품
    • 복합적 컨텍스트의 경우 다양한 Weight를 통해 서비스를 다양화
    • 실제 서비스를 운영할 때 좋지 않은 퀄리티의 상품이나 좋은 방향을 위해 필터를 걸도록
  • 아이템 뿐만 아니라 고객별로 추천영역이나 UI도 개인화 추천 할 수 있다고 생각
    • 할인 제품을 좋아하는 고객에게는 할인 추천 영역을 제공
    • 트렌디한 패션 상품을 좋아하는 고객에게는 최신 인기 패션 추천 영역 제공
    • 빨간색을 좋아하는 유저에게는 빨간색을 입힌 UI를 제공
  • Cart에서는 유저들이 더 빠른 결정을 돕기 위한 추천
    • 함께 구매하면 좋을 상품, 무료배송 추천 상품

 

---

2. 과거, 추천 모델 중심의 플랫폼

• 상품 추천을 위주로 할때는 추천 모델 중심의 플랫폼이었다.
  • item-item의 관계를 찾는게 중요했었고, 이 관계는 그대로 서비스로 나가게 되었다.
  • 그렇기 때문에 모델과 서비스는 강한 연결관계를 가지고 있었고, 모델은 꽤나 복잡하게 만들어지게 된다.

2.1 아키텍처

• 데이터
  • 상품정보, 유저정보, 유저로그를 이용해 복잡한 테이블들(후보 상품들, 필터 적용, 임베딩)이 나오게 되고, 이 테이블들을 이용해 모델링을 하여 결과(item-item의 score)가 출력된다. 해당 결과가 그대로 서비스로 나가게 됨.
• 서버
  • 서버쪽 아키텍처는 단순
  • 모델 파이프라인의 결과가 추천 서비스 전체를 결정했기 때문에, 서버는 어떤 product id에 대해 다른 product id를 점수 순서대로 key-value storage를 lookup하는 것으로 충분했다.
  • 컨텍스트는 item밖에 없었기 때문에 key는 선형적으로 증가하였고 별 무리 없이 낮은 latency를 유지할 수 있었다.
  • 서버 api를 이용해 필터 및 세부조정을 할 수 있었지만, 추천 랭킹 측면에서 할 수 있는 기능은 별로 없었다.

2.2 단점/한계

• 모델 변경에 따라 길어지는 파이프라인 (필터, 부스팅, ..)
• 추가 요청사항을 처리하기 어려움
• 완성 전가지 결과를 알 수 없음
• 개발에 시간이 오래 걸림
• 점진적인 개선이 힘들다. 새로운 컨텍스트나 weight를 시도할때마다 전체적인 파이프 라인을 새롭게 만들어야해. 기존의 모델은 재사용할 필요없이 버려져

2.3 목표

• 추천 모델은 서비스의 흥망과 상관없이 계속해서 발전 할 수 있다.
  • 추천 모델과 서비스를 분리시킬 것
• 서비스는 모델작업과 별개로 이슈에 대응
  • 상품 정보나 유저 정보를 서빙 중에 접근 가능할 것
  • 필터, 부스팅 등의 변경이 쉽고 빠를것

 

---

3. 현재, 서비스와 모델을 분리하는 플랫폼

3.1 검색과 추천

• 플랫폼에 검색엔진을 사용검색 자연어 키워드 매칭 관련도

  검색	자연어	키워드 매칭	관련도
  추천	상품/유저	모델 결과	모델 스코어

• 자연어를 쿼리로 받아 키워드 매칭을 통해 관련 문서를 찾고 관련도에 따라 랭킹을 구하는 것처럼, 추천은 상품이나 유저를 쿼리로 받아 추천모델이 알려주는 관계를 토대로 관련된 상품을 찾고 모델과 기타 정보들을 이용해 랭킹을 구한다.

3.2 중앙화 된 상품 정보

• 검색과 추천 데이터 중앙화
• 상품을 잘 표현할 수 있는 피쳐를 생성(Spark, Hive, TF 사용) ⇒ HBase에 저장
• 검색과 추천팀은 protocol과 buffer로 각자 관리하는 데이터를 저장 (서로 다른 인덱싱)

3.3 Feature

연관성 피처	상품 자체 피처
- 추천 모델 결과 - 이미지 유사도 - 카테고리 관련성 …	- 카테고리 - 상품평 - 가격 ...

3.4 인덱싱

• 어떤 상품에 검색 되어야 하는지? 페이로드로 리버스 인덱싱
• 필터나 부스팅에 따라 인덱싱 (category, is_adult, is_rocket)
• 서빙 중 상품에 대한 정보를 필요로 할때가 있다. key-value 형태로 protocol buffer로 꺼내올수 있는 인메모리 형태의 작은 스토리지도 있음

3.5 Search Cluster

• 컨텍스트와 관련된 상품을 찾고 (Query Handler Cluster에서 컨텍스트를 정렬 해서 넘겨줌)
• 조건에 따라 필터 한 다음
• 점수에 따라 정렬

3.6 Query Handler Cluster

• 서비스를 정의
  • ex) 냄비와 함께 살 할인 식품
    • Query: bought_together 냄비
    • Filter: category 식품
    • Boost: discount_rage
    • 추가 정렬 : 고기, 생선, 야채를 번갈아 보여주자
• 빠른 서비스 개발 가능
  • 피처 조합과 가중치에 따라 새로운 서비스
  • 필터로 새로운 추천 서비스를 만들수 있음 ( ex. 요즘 인기있는 xxx)
  • 검색 결과를 필요에 따라 새롭게 정렬할 수 있음. ( ex. Round Robin)

3.7 모델과 서비스의 분리

• 모델 개발, 피처생성 : 모델은 좋은 피처를 만들기 위해 노력
  • 카테고리 모델 개발
  • 함께 구매 할 만한 가격대 분포 계산
  • 이전 AB테스트 반영하여 새 피처 개발
  • 만들어진 피처는 다른 서비스에도 사용
• 서비스 정의 : 서비스는 있는 피처들을 어떻게 쓸지 고민
  • 함께 산 상품 데이터 사용
  • 매뉴얼 카테고리 맵(주방용품 → 식자재)
  → AB테스트 시작
  • 지속적인 쿼리 튜닝

3.8 변화

• 추천 영역 수 7배 증가
  • 추천 노출/클릭/구매 굉장한 증가
• 빠른 서비스 개발
• 비지니스 상황에 대한 빠른 대처
• 피처의 다양한 방면으로의 활용