추천 엔진을 만들기 위해 고려했던 것들

조회수 2604

이전에 API 기반으로 전처리 되지 않은 고객들의 구매 데이터를 입력으로 하여 이탈률, LTV(Life Time Value: 고객 생애 가치 CLV 라고도 합니다.)를 예측하여 데이터를 Delivery해주는 API 서비스를 만들고 있다고 말씀드렸습니다.

참조: 증강분석(Augmented Analytics)에 연계되는 AI 서비스 개발기


내/외부에서 활용해야 할 곳이 많은데 서비스마다 배포 및 운영하기에는 어려운 점이 많다 보니

  1. 인프라 환경을 사용자가 고려할 필요가 없는 Packaged & Managed 서비스
  2. ML, AI에 대한 전문 지식이 필요 없는 AI 서비스
  3. 빅데이터 엔지니어링에 대한 기반이 없어도 쉽게 활용할 수 있는 Datapipe 서비스

를 목표로 AIaaS를 구성하고 있으며 이번 단계에서는 여러 분야에서 많이 활용하는 추천 관련 AI core를 API 서비스에 추가하려는 계획을 잡고 있어 이때 제가 고려하고 있는 부분을 정리해 보려 합니다.


상품 추천을 활용하는 분야가 많다 보니 모두 언급할 수는 없겠지만

  • 상품 연관 분석(Association Rule): '이 물건을 살 때 함께 많이 사는 물건은?' 등을 분석하여 연관상품을 추천
  • 협업필터링(Collaborative Filtering): 고객간 혹은 아이템간의 거리(유사도)를 측정하여 비슷한 유형을 추천
  • 행렬분해(Matrix Factorization): MF는 CF와 별개가 아닌 CF의 한 model based 기법이지만 성능이 뛰어나 많이 사용되다 보니 별도로 언급되곤 합니다. CF에서는 구매하지 않은 아이템과 구매한 경험이 없는 고객에 대한 자료가 없어 희귀행렬(Sprase Matrix)가 만들어지는데 이 데이터는 U x I 행렬로 표현됩니다. MF에서는 이를 U x k, I x k 행렬로 분해하는 과정을 진행하며 이때 빈 곳을 채우는 작업을 수행하게 되며 이때 k(latent factor)라는 블랙박스가 생성됩니다.
  • DNN을 이용한 방법: Item2Vec, User2Vec 등 임베딩으로 벡터화한 후 거리 측정을 하는 방식 정도로 크게 유형을 나눠볼 수 있을 것 같습니다.


저는 이 중에서 설명하기 쉬운 모델인 Association Rule과 Cold Start에 대한 고민도 덜 수 있고 가장 좋은 성능을 낸다는 MF, 두 가지 라인업을 PoC 하여 선정하였습니다. 이들의 구현체인 여러 solution이 있지만 여기에서 설명하기에는 많이 부담스럽기도 하고 또 여러분의 시간은 소중하니까 바로 제가 선정한 것들을 나열해 보겠습니다.


제가 만들어 나가고 있는 API 서비스에서는 2년 이상의 대용량의 웹 transaction 로그를 적재하고 전처리하는 과정이 선행되다 보니 EMR(or 어찌 되었든 HADOOP을 이용한 분산처리)+SPARK는 필수였기에 AR에서는 자연스럽게 spark에 내장된 FPM을 원픽하였고

FPGrowth 샘플코드 (출처: 임지홍 네이버 블로그)


MF도 역시 spark에 내장되어 있는 ALS



 또 여기에서 끝내기가 아쉬워 많이 사용한다는 Surprise 패키지를 추가로 선정하였습니다. 

 

Surprise 샘플코드  (출처: 임지홍 네이버 블로그)


ALS는 spark에 내장되어 있어 EMR을 프로비저닝 시 별도의 패키지 설치가 필요 없이 바로 사용 가능합니다. ETL 및 Feature Engineering 작업과 간극이 없는 스무스한 대용량 추천 개발에 적합한 장점이 있으며 Surprise는 위에 제가 샘플로 만든 코드처럼 CF, MF에 대한 다양한 알고리즘을 쉽게 교체해가면서 활용할 수 있어 hybrid 혹은 앙상블로 모델을 디자인하여 더더욱 robust한 엔진을 만들 수 있다는 장점이 있습니다. 다만, 대용량 처리에 대한 고민은 숙제로 따라오게 되겠지요.

AI, ML에서 시간이 가장 많이 소모되는 부분은 Ingestion ~학습 데이터 Serving까지의 과정입니다. 여기까지는 자체적으로 다해놨는데 AWS Personalize 같은 외부 서비스를 사용하는 것은 뭔가 아쉽기도 하죠. 또 외부 서비스를 사용하는 경우 내부의 여러 요구사항을 반영하기에는 제약이 있기도 하여 이 후보군을 가지고 랩원분들과 논의해본 후 우리가 만드는 시스템에 직접 개발하여 반영할 예정입니다. PoC 과정 중 기본 틀은 거의 만들어져서 남은 작업은 parameter tuning 정도이기도 해서 더더욱 자체적으로 구현하는 것이 더 부담 없기도 하고요.

이 글을 읽는 분들께서 추천 엔진을 선택할 때 저의 고민의 결과가 조금이나마 도움이 되셨으면 합니다. 진행 사항은 상황 봐서 다시 update하겠습니다.  긴 글 읽어주셔서 감사합니다.


참, AR을 사용 중에 한 고객이 구매한 item 리스트의 크기가 큰 경우 연산을 못하더라고요. 데이터 서빙 시 이 부분에 대한 처리도 고려하셔야 합니다. 제 macbook air (M1, 16GB)에서는 60개 이상의 아이템을 가진 고객은 처리가 불가능하여 어쩔 수 없이 제외하고 수행했었습니다.





무료 인사이트 리포트와 최신 마케팅 트렌드 자료를 받아보고 싶다면
다이티 뉴스레터를 구독해보세요!