YouTube Recommendation system 트릴로지 리뷰 - [1]
본 포스팅은 2010, 2016, 2019에 발표한 유튜브의 추천시스템 자료를 리뷰한 것이다. 3부작이 끝이 아님에도 트릴로지라는 이름을 붙인 것은, 필자에게는 이 자료들이 매트릭스 3부작이나 반지의제왕 3부작 만큼이나 재미있었기 때문(..)
오늘 리뷰할 자료는<The YouTube Video Recommendation System (2010)> 으로, 2010년에 발표된 것이다. 유튜브 붐이 일어나던 초창기에 사용된 추천시스템을 살펴볼 수 있다. 하지만 그 철학과 기본 틀은 현재까지도 유효하며, 이제 막 추천시스템을 구축하려는 작은 서비스에서는 여전히 현대적인 추천시스템이라고 할 수 있다.
1. Intro
유튜브 추천시스템을 요약하면, 유저가 유튜브에서 행동한 데이터를 바탕으로 개인화된 비디오를 추천해준다는 것이라고 할 수 있다. 그리고 이 논문은 그 과정에서 직면한 문제점들과 이를 어떻게 기술로 해결했는지를 다룬다.
유튜브 유저의 사용 패턴은 크게 3가지로 나뉠 수 있다. 첫 번째로, 다른 곳에서 유입된 경우(ex. 구글 검색 혹은 페이지 내 html 삽입). 두 번째는 특정한 비디오를 찾고자 하는 경우(ex. 유튜브 내 검색). 그리고 마지막으로 흥미 위주로 돌아다니는 경우(유튜브 앱을 켜놓고 슬라이딩 하여 마음대로 돌아다니는 경우)이다. 개인화 추천의 필수 사항은, 이러한 모든 유저들의 흥미를 빠르게 업데이트하여 추천시스템의 결과로 반영하는 것이라고 할 수 있다. 후술하겠지만 이 케이스들의 balance를 맞추는 것도 중요하다고 한다. 헤비유저로 인해 모델의 bias가 커지는 것을 막기 위해 필요한 과정이기 때문.
유튜브 추천시스템에서 가장 먼저 직면한 문제점은 메타데이터의 부재였다고 한다. 아무래도 유튜브는 이용자들이 영상을 올리는 플랫폼이다 보니, 당연하게도 추천에 필요한 메타데이터가 부족할 것이고(현재는 업로드 제한, ML 기반 메타데이터 추론 등으로 해결하고 있다) 콘텐츠에 대한 feedback도 명확하지가 않다. (아마존이나 넷플릭스는 구매와 결제라는 explicit score가 존재한다고 언급한다. 단, 이는 넷플릭스가 구독형이 아닌 영화당 결제 시스템이었을 때의 이야기이다. 그리고 아마존을 비롯한 커머스 추천시스템에서는 오히려 Youtube처럼 명확한 feedback이 없다고 불평한다..)
어찌되었든 이에 대한 논지는, 휘발성이 매우 강하며 메타데이터가 부족하고, 게다가 life cycle이 매우 짧은 콘텐츠인 유튜브에서 추천을 잘 하려면 'constant freshness'를 파악하는게 중요하다는 것이다.
2. System design
추천시스템을 구성하는 큰 축은 두 가지로, Candidates와 Ranked Results이다. Candidates를 생성할 때는 유저의 활동(시청, 좋아요, 구독 등)이력을 seed로 하여 co-visitation이 일어난 비디오를 추려낸다(association rule, co-visitation count 등의 방법을 사용했다고 한다). 그리고 이 결과의 랭킹을 매기고, 몇 가지 제약을 추가하여 relevance와 diversity를 조절한다.
Input 데이터로 사용된 것은 크게 두 가지로, 메타데이터(제목, 영상 자체, 영상 설명 등..)와 같은 content 데이터이다. 두 번째는 유저의 행동 데이터로 implicit과 explicit을 모두 포함한다.
2-1) Candidates
다시 Candidates로 돌아가서 조금 더 자세히 살펴보면, association rule과 같은 r(vi, vj) 스코어를 생성해내는 알고리즘을 적용할 때 count는 하나의 세션 안에서 일어난 것으로 하되, 이를 global popularity로 normalize 하여 relatedness score를 계산한다고 한다. 스코어를 뽑아내는 것은 복잡하지 않고, 나눗셈 같은 간단한 normalize를 사용해도 좋다고 한다. 그리고 논문에는 자세히 기술하지 않았지만, candidates pool을 만들기 위해 time stamp, 메타데이터 등을 사용했다고 한다. 아무래도 cadidate generation은 알고리즘보다는 분석가의 직관이나 재량, 피처 엔지니어링이 더 중요한 영역이다 보니 자세히 기술하지는 않은 것으로 보인다.
한 가지 문제점은, 제한된 시드에서 association, graph를 기반으로 candidates를 추려내면 커버리지가 낮아지는 약점을 해결해야 한다는 것이다. 그래서 추천의 풀을 더 늘리기 위해, 연관 절(혹은 branch)이 chaining 되는 횟수 제한을 늘렸고, 이에 따라 coverage 자체를 늘리는 효과를 가져왔다고 한다.
지금 읽어보면 굉장히 노멀한 candidates 생성 방법과, coverage 보충 방법에 대해 이야기하는 것 같지만 이게 10년도 더 전에 나온 논문이라는 것을 생각해보면 참으로 대단하다(지금 필자가 근무하는 회사에서 추천하는 방식과 거의 유사하거나 오히려 더 낫기 때문..).
2-2) Ranking
랭킹이 매겨지는 기준은 3가지(video quality, user specific, diversification)이다. 비디오 퀄리티는 조회수, 좋아요 갯수, 댓글 분석 등등으로 이루어지며, user specific은 유저의 선호도를 고려하는 피처로 구성되어 있다. 그리고 이러한 피처들을 linear combination으로 랭킹을 매긴다. 아마 point-wise ranking 모델을 의미하는 듯 하다. (참고 링크)
하지만 유저에게 최종적으로 보여져야 하는 컨텐츠의 갯수는 매우 작으며, 동시에 유저는 하나의 관심사만 갖고 있는 것이 아니기 때문에 카테고리별로 추천 리스트를 제한하는 balancing이 필요하다. 이에 대한 내용이 위에서 언급한 3가지 기준 중 하나인 diversification이며, 같은 채널의 동영상 갯수를 제한한다던가 하는 식으로 적용된다. 혹은 클러스터링 분석을 통해 이를 제한하기도 한다.
2-3) System Implementation
2010년 당시 유튜브의 추천 계산 결과는 on-demand 보다는 배치 방식으로 구현되었다고 한다. 유튜브의 자료가 워낙 어마어마하다보니, latency를 보장하기 위해 이런 방식을 선택했다고 하는데, 이게 추후에 어떻게 변하는 지 눈여겨 보아야겠다.
유튜브의 로그는 수집되자 마자 전처리 과정을 거쳐 Bigtable에 저장된다고 한다(Bigtable은 구글의 분산 스토리지 시스템이다). 그리고 이 데이터에서 MapReduce로 user-video를 쌍으로 하는 candidate를 만들어낸 뒤(위의 내용과 동일) Read-only Bigtable에서 이를 서비스한다.
3. Evaluation & Result
추천시스템의 전반적인 평가는 온라인 A/B 테스트와 CTR에 의존하였고, 이뿐만 아니라 다양한 요소를 테스트했다고 한다. 단순 인기도를 기반으로 한 알고리즘과 비교하면 거의 2배가 넘는 효율을 보인다.
2016년도 리뷰에서 계속