데이터 아키텍처

데이터 관점의 구조로 각 모듈이 처리하는 데이터는 다음과 같습니다.

데이터 마트 : 상품 정보, 예약 정보, 회원 정보 등 메인 DB로부터 동기화된 데이터와 클라이언트로부터 수집된 로그를 잘 정리된 형태로 저장합니다.
추천 모델-배치 데이터 : 각 모델의 데이터를 표준 포맷으로 저장합니다. 표준 포맷을 준수한다면 어떤 방식으로 생성된 데이터라도 하나의 추천 서비스로서 제공 될 수 있습니다.
실시간 분석-스트리밍 데이터 : 상품 클릭, 구매 등 실시간 유저 액션과 실시간 통계를 저장합니다. 유저별 히스토리 스코어링, 카테고리 선호도, 랜드마크 선호도 등을 구하는데 사용될 수 있습니다.
추천 Provider : 실시간 데이터와 배치 데이터를 결합하여 섹션에 추천 데이터를 제공합니다. 실시간 스코어링, 데이터 병합, 필터링, 중복제거 등의 내부 연산 및 실시간 분석 기능을 수행합니다. MAB와 같이 실시간 AB를 통해 알고리즘을 선택하는 것도 Provider에서 수행할 수 있습니다.
노출 : UI에서 추천을 보여주는 페이지의 영역으로 Provider의 결과를 받아 상품정보를 매핑하여 보여줍니다. 여러 추천이 한 페이지에서 동시에 노출될 수 있습니다.

추천 모델

추천 아키텍처에서 모델은 퀄리티를 결정하는 매우 중요한 구성 요소 중 하나입니다. 모델은 아키텍처의 다른 구성 요소와 매우 밀접하게 연관되어 있습니다. 좋은 모델을 구현하기 위해서는 서비스에 대한 깊은 이해가 필요합니다. 서비스나 다른 구성요소의 고려없이 모델만 따로 고민해서는 실환경에서 좋은 추천 퀄리티를 얻기 어렵습니다. 실환경에서 퀄리티가 안나온다고 모델만 어떤 모델로 변경해서 퀄리티가 잘 나올수는 없는 것이지요.

예를 들어 잘 알려진 CF(Collaborative filtering) 알고리즘을 구현하여 적용한다고 합시다. 이 모델을 그대로 적용하면 실환경에서 좋은 퀄리티를 내기가 어렵습니다. 서비스의 피쳐(Feature)를 얼마나 잘 뽑아내서 적용하느냐는 퀄리티에 매우 큰 부분을 차지합니다. 이런 모델을 그대로 실환경에 적용하는 것은 좋은 방법이 아닙니다. 이런 경우에는 피쳐를 다양하게 반영할 수 있도록 확장해서 구현해야 할 것입니다. 또 경우에 따라 구현한 알고리즘이 서비스하기에는 너무 오랜 시간이 걸릴 수도 있습니다. 이런 경우에는 실시간에 처리될 수 있도록 실시간 스트리밍 및 분석할 수 있게 실시간 모델을 고려해 볼 필요도 있습니다.

추천에는 CTR Prediction 모델이 적용될 수 있습니다. 여기서는 추천에 적용될 수 있는 초창기 모델에 대한 간단한 개요와 히스토리를 설명합니다.

논문 상의 모델과 실 서비스 상의 적용은 큰 차이가 있는 점을 염두에 둘 필요가 있습니다. 데이터, 성능, 비용, 리소스 등 여러 부분에서 고려해야 할 이슈가 많습니다. 특히 데이터가 다르기 때문에 실환경에 적용할 때는 각 서비스에 맞게 어떤 부분은 서로 조합하고, 어떤 부분은 feature를 다르게, 어떤 부분은 실시간으로 처리하는 등의 고려가 필요합니다.

CF(Collaborative filtering) — Low rank matrix factorization

오래전부터 추천에서 잘 알려진 모델이며, 기본 모델은 사용자의 속성을 기준으로 하는 User-CF입니다. 사용자와 비슷한 다른 사용자들이 선호하는 아이템을 추천합니다. 사용자의 속성과 상품의 속성을 매치하는 방식으로 접근하여 인수분해한 매트릭스의 차원으로 속성을 매핑하는 방식입니다. Spark에서 ALS 라이브러리로 제공하고 있습니다.
User CF는 상품을 노출하여 판매를 유도하는 형태의 서비스에서는 거의 적용하지 않는 방식으로, Item-to-Item CF에 비해 퀄리티가 좋지 않습니다. 사용자의 속성을 기준으로 추천을 제공하는 이와 같은 방법은 최종적으로 상품을 추천하는 서비스에서는 퀄리티가 잘 나오지 않습니다.

Item-to-Item Cf

아마존에서 구현하여 실환경에서 크게 효과를 본 모델입니다. 아마존 사이트에 이런 방식으로 “책 추천”이 제공되면서 전세계적으로 크게 조명받기도 했습니다.
유저와 비슷한 유저를 찾는 User-CF와 달리 유저가 함께 구매한 아이템을 찾아 Product-to-product matrix를 만듭니다. 모든 아이템 쌍에 대해 사용자의 액션이 얼마나 겹치는 지를 스코어링 하여 유사도를 구하게 됩니다.
Item-to-item CF의 결과는 아이템 쌍의 테이블이므로 개인화를 위해서는 사용자의 액션을 기반으로 스코어링 한 후, 이 둘을 결합하는 방법을 사용할 수 있습니다.

FM (Factorization Machines)

이 방식은 CF와 비슷하지만 많은 피쳐를 반영할 수 있도록 확장한 모델입니다. 매트릭스를 각 아이템의 피쳐 벡터와 정답셋으로 구성하고, 회소(sparse)한 벡터는 원-핫 인코딩하여 처리하는 방식을 제안했습니다.
추천을 딥러닝으로 구현하는 모델은 이 모델을 기반으로 확장하는 방식으로 생각할 수 있습니다.

FFM (Field-aware Factorization Machines)

FM과 비슷하지만 field의 조합을 반영하는 식으로 발전된 형태입니다.

Wide and Deep Learning

구글에서 추천에 딥러닝을 적용한 모델로 와이드 모델과 딥 모델(회소 벡터)을 나누어 처리합니다. 그리고 일부 관련된 피쳐를 서로 교차시킨 피쳐를 모델에 반영합니다.
상품 카테고리와 같은 Categorial Feature를 임베딩하여 이를 클릭율 같은 수치 데이터를 함께 모델에 넣을 수 있도록 설계되었습니다.
검색 랭킹에 사용하는 모델로 보이며, 실제 적용해보면, 상품 마다 추천이 변경되어야 CTR이 높아지는 커머스 상품 페이지의 추천에서는 상품이 자주 변하지 않고 고정되기 때문에 적용하기 쉽지 않은 단점도 있습니다.

DNN For Youtube

이 모델은 유튜브 검색에 적용된 딥러닝 검색 랭킹 모델인데, 실환경에 적용할 수 있는 아주 실전적인 모델입니다. 개인화를 위한 좋은 출발점이 될 수 있습니다. 먼저 비디오를 후보군(Candidate)으로 추리고, 이를 영상 피쳐를 적용해서 랭킹을 구합니다. 영상 감상 히스토리(watch history), 검색 히스토리(search history), 본 시간 등의 피쳐와 사용자, 비디오, 언어 등을 임베딩한 피쳐를 결합하여 학습합니다.
개인화 추천을 위해 사용자의 액션 히스토리와 문맥을 사용합니다. 사용자의 속성, 성향은 유튜브에서 파악할 수 없는 외부의 요소가 너무나 많기 때문에, 사용자의 액션(implicit feedback)을 개인화 추천을 위해 사용합니다.

DeepFM(Deep Factorization Machines)

FM에 딥러닝을 적용한 모델이라고 할 수 있습니다. 광고서비스에서 CTR 예측의 퀄리티를 높이려는 모델이며 추천에 딥러닝 고려 시 거의 동일하게 적용해 볼 수 있습니다.

LTR(Learning to rank)

검색쪽에서 검색 결과의 랭킹 퀄리티를 올리기 위한 모델로 추천에서도 상품의 랭킹을 적용할 때 고려해볼 수 있습니다. 검색은 (쿼리,결과 리스트)로 구성된다면 추천은 (소스 아이템, 추천 아이템)으로 구성된다는데 있어 상당히 유사합니다. 대부분을 추천에 그대로 적용할 수 있습니다. 정답셋을 구성하는 것도 상당히 닯아 있습니다.
그중에서 LTR Pairwise 접근은 Item CF와 구조가 상당히 유사합니다. 하지만 결과를 뽑고 평가하는 방식은 추천에 맞게 변경이 필요합니다. 실환경에 퀄리티 개선에 효과를 볼 수 있는 접근입니다.

유저 액션 로그 수집 (User feedback)

앱, 웹 클라이언트로부터의 데이터의 수집은 추천 퀄리티의 근간이 되는 부분으로 매우 중요합니다. 특히 impression 로그의 수집이 중요한데 추천 모델에 딥러닝을 적용하려면 사용자의 액션(implicit feedback)으로 부터 정답셋을 구성하는 것이 굉장히 중요하기 때문입니다.

Impression 로그란 사용자가 어떤 상품을 본 순간 남는 로그를 말합니다. 사용자가 페이지에 진입하더라도 상품은 사용자에게 아직 보이지 않을 수 있습니다. “페이지 view”에 대한 로그만 가지고 있다면 사용자가 상품을 좋아하지 않아서 클릭하지 않았는지, 상품을 아예 못보았기 때문에 클릭하지 않았는지 구분할 수 없습니다. Impression 로그를 처리하려면, 많은 양의 로그를 처리할 수 있도록 견고한 로그 수집 플랫폼이 필요합니다.

추천의 퀄리티는 다음과 같은 로그 수집 이슈에 큰 영향을 받습니다.

Impression 로그의 수집
사용자의 트래픽(로그)이 많아야 함
앱, 웹의 모든 액션의 위치에 로그가 있어야 하고, 이를 유실없이 수집해야 함
주요 로그(클릭, 구매 등)는 실시간 스트리밍 처리되어야 함

마지막으로

이 글에서는 추천 서비스와 아키텍쳐에 대한 전반적인 내용을 설명하였습니다. 추천 서비스는 고정되어 있는 것이 아니라 추천 개발자의 좋은 아이디어에 의해 서비스가 시작됩니다. 이렇게 시작된 추천 서비스를 퀄리티 있게 구현하려면 아키텍쳐 상의 모든 구성 요소가 확장성 있고 구현되고 서로 잘 연결되어야 합니다. 또한 지속적으로 지표를 관찰하고 업그레이드 하여 품질을 계속 개선하는 것이 중요합니다.

다음글: 추천 모델 개발 (1) — Data Processing 개발로 이어집니다.

이글은 기존 작성된 문서 추천 서비스와 아키텍처[2]-추천 서비스란 무엇인가 를 업데이트하여 작성한 문서입니다.

추천 시스템 아키텍처

추천 서비스의 중요 구성 요소

추천 아키텍쳐 (Recommendation System Architecture)