Google 공식 원문: Recommendation Systems 과정, Large-scale recommendation systems, Terminology, Recommendation systems overview

추천 시스템은 사용 가능한 전체 콘텐츠 가운데 현재 사용자에게 보여줄 만한 item을 골라 순서를 정하는 시스템이다. YouTube가 다음에 볼 영상을 제안하거나 Google Play가 홈 화면에 앱을 배열하는 과정이 대표적인 예이다.

추천 문제의 핵심은 단순히 사용자가 과거에 본 것과 똑같은 item을 찾는 데 있지 않다. 매우 큰 corpus에서 사용자의 관심을 추정하고, 아직 발견하지 못한 item까지 적절한 시점에 노출해야 한다. 이를 실제 서비스 규모에서 수행하려면 정확도뿐 아니라 latency, 다양성, freshness와 같은 조건도 함께 다뤄야 한다.

이 글에서는 추천 시스템이 해결하려는 문제와 기본 용어를 먼저 정리한 뒤, 대규모 추천 시스템을 구성하는 세 단계인 candidate generation, scoring, re-ranking의 역할을 살펴본다.

과정의 학습 범위와 선수 지식

Google의 Recommendation Systems 과정은 약 4시간 분량으로 구성되어 있으며, 전체 시리즈에서 다음 내용을 학습하는 것을 목표로 한다.

• 추천 시스템이 필요한 이유를 설명한다.
• Candidate generation, scoring, re-ranking으로 이어지는 전체 구조를 이해한다.
• Query와 item을 embedding으로 표현하고 유사도를 계산한다.
• Content-based filtering, collaborative filtering, DNN 등 candidate generation 기법의 동작 원리를 이해한다.

추천 시스템이 필요한 이유

사용자가 원하는 대상을 이미 알고 있다면 검색어를 입력해 찾을 수 있다. 그러나 다음과 같은 상황에서는 검색만으로 충분하지 않다.

• 어떤 콘텐츠가 존재하는지 몰라 검색어를 떠올릴 수 없는 경우
• 전체 item 수가 너무 많아 직접 탐색하기 어려운 경우
• 취향, 최근 행동, 시간대에 따라 관심 대상이 달라지는 경우
• 익숙한 item과 새로운 item을 적절히 섞어 발견하고 싶은 경우

추천 시스템은 사용자가 명시적으로 요청하지 않아도 현재 관심과 관련 있을 가능성이 높은 item을 먼저 제시한다. 따라서 검색이 표현된 의도를 처리하는 수단이라면, 추천은 관찰된 행동과 context로부터 잠재적인 의도를 추정하는 수단으로 볼 수 있다. 실제 서비스에서는 두 기능이 분리되어 있지 않으며, 검색 결과의 개인화나 검색어 추천처럼 서로 결합되기도 한다.

Google의 공식 과정은 대규모 corpus의 예로 수백만 개의 앱을 제공하는 Google Play와 수십억 개의 영상을 제공하는 YouTube를 든다. 이처럼 사용자가 모든 item을 직접 살펴볼 수 없는 환경에서 추천 시스템은 탐색 범위를 줄이고 새로운 콘텐츠의 발견을 돕는다. 공식 과정에 제시된 수치에 따르면 Google Play 앱 설치의 40%, YouTube 시청 시간의 60%가 추천에서 발생한다. 이 수치는 추천이 부가 기능을 넘어 사용자가 콘텐츠를 소비하는 주요 경로가 될 수 있음을 보여준다.

추천이 나타나는 두 가지 형태

추천 결과가 표시되는 맥락은 크게 homepage recommendation과 related-item recommendation으로 구분할 수 있다.

Homepage recommendation

Homepage recommendation은 특정 사용자의 관심을 기준으로 홈 화면을 구성한다. 사용자마다 과거에 본 item, 클릭이나 설치 이력, 현재 context가 다르므로 같은 서비스에 접속하더라도 서로 다른 결과를 보게 된다.

홈 화면에는 기준이 되는 단일 item이 없다. 따라서 사용자의 여러 관심사를 하나의 query로 표현하고, 서로 다른 주제의 후보를 적절히 섞는 과정이 중요하다. 예를 들어 게임을 자주 설치한 사용자라도 홈 화면 전체를 한 종류의 게임으로 채우기보다는 생산성 앱, 새로 출시된 앱, 이전 관심사와 연결되는 앱을 함께 보여줄 수 있다.

Related-item recommendation

Related-item recommendation은 사용자가 현재 보고 있는 item과 관련된 다른 item을 제시한다. 수학 학습 앱의 상세 페이지에서 다른 수학·과학 앱을 보여주거나, 한 영상을 시청한 뒤 비슷한 주제의 영상을 제안하는 경우이다.

이때 query에는 현재 item 자체가 강한 신호로 들어간다. 사용자 정보가 거의 없는 익명 사용자에게도 item의 내용이나 item 간 상호작용 패턴을 이용해 추천할 수 있다는 장점이 있다.

두 형태의 차이는 추천 알고리즘의 이름보다 무엇을 query로 주는가에 가깝다. 같은 모델이라도 사용자 history를 query로 주면 homepage recommendation에, 현재 item을 query로 주면 related-item recommendation에 사용할 수 있다.

기본 용어

추천 시스템의 입력과 출력을 이해하려면 item, query, embedding의 관계를 먼저 정리해야 한다.

Corpus와 item

Corpus는 추천 대상으로 고려할 수 있는 전체 item 집합이다. 이를 $\mathcal{I}$로 나타내면 다음과 같다.

$$\mathcal{I}=\{i_1,i_2,\ldots,i_{|\mathcal{I}|}\}$$

Item은 시스템이 추천하는 개별 대상이며 문서에서는 document라고 부르기도 한다. 서비스에 따라 item의 의미는 달라진다.

서비스	item의 예
Google Play	설치할 앱
YouTube	시청할 영상
전자상거래	구매할 상품
음악 서비스	곡, 앨범, playlist
뉴스 서비스	기사

Item은 추천 결과로 노출되는 단위이다. 하나의 서비스에서도 화면 목적에 따라 영상, channel, playlist처럼 서로 다른 단위를 item으로 정의할 수 있다.

Query 또는 context

Query는 추천을 만들 때 시스템이 이용하는 정보의 묶음이다. 검색 시스템의 query가 보통 사용자가 입력한 문자열인 것과 달리, 추천 시스템의 query는 사용자와 현재 상황을 표현하는 여러 feature의 조합일 수 있다. 이런 의미에서 context라고도 부른다.

대표적인 query 정보는 다음과 같다.

• 사용자 ID
• 사용자가 이전에 클릭·시청·구매한 item
• 각 상호작용의 순서와 시점
• 현재 보고 있는 item
• 시간대, 요일, 위치와 같은 상황 정보
• 사용 중인 device와 화면 종류

예를 들어 같은 사용자라도 출근 시간의 mobile device와 저녁의 TV에서는 선호하는 영상 길이나 주제가 달라질 수 있다. 따라서 query는 고정된 사용자 ID 하나가 아니라 현재 추천 요청을 설명하는 상태라고 이해하는 편이 정확하다.

Embedding

ID나 category처럼 이산적인 대상을 그대로 비교하기는 어렵다. Embedding은 query나 item을 연속적인 vector 공간으로 옮긴 표현이다. Query 집합을 $\mathcal{Q}$, $d$차원 embedding 공간을 $E=\mathbb{R}^d$라고 하면 다음과 같은 두 mapping을 생각할 수 있다.

$$f_Q:\mathcal{Q}\rightarrow\mathbb{R}^d$$ $$f_I:\mathcal{I}\rightarrow\mathbb{R}^d$$

추천 요청 $u\in\mathcal{Q}$와 item $i\in\mathcal{I}$는 각각 query embedding $q=f_Q(u)$와 item embedding $x_i=f_I(i)$로 표현된다. 학습이 잘 이루어지면 관련 있는 query와 item, 또는 성격이 비슷한 item들이 embedding 공간에서 가까운 위치에 놓인다.

Embedding은 사람이 각 dimension의 의미를 직접 지정한 규칙표가 아니다. 사용자와 item의 상호작용이나 item feature로부터 추천 목적에 유용한 latent structure를 모델이 학습한 결과이다. 다음 글에서는 이 공간에서 가까움을 어떻게 계산하는지 자세히 다룬다.

대규모 추천 시스템의 세 단계

Corpus가 매우 크면 모든 item에 복잡한 모델을 적용해 순위를 매기기 어렵다. 그래서 일반적인 대규모 추천 시스템은 candidate generation, scoring, re-ranking을 차례로 수행하는 funnel 구조를 사용한다.

전체 corpus의 크기를 $N_0$, 생성한 후보 수를 $N_1$, scoring 뒤 남긴 수를 $N_2$, 최종 노출 수를 $N_3$라고 하면 일반적인 크기 관계는 다음과 같다.

$$N_0 \gg N_1 \gg N_2 \geq N_3$$

YouTube를 예로 들면 candidate generation은 수십억 개의 영상에서 수백∼수천 개를 고르고, 뒤의 단계는 그중 실제 화면에 표시할 수십 개 안팎을 선택한다. 앞 단계일수록 속도와 recall이 중요하고, 뒤 단계일수록 적은 후보에 더 많은 feature와 계산을 사용할 수 있다.

1단계: Candidate generation

Candidate generation은 전체 corpus에서 query와 관련 있을 가능성이 있는 작은 후보 집합을 빠르게 찾는다. 이 단계의 목적은 최종 순서를 완벽하게 정하는 것이 아니라, 좋은 item을 뒤 단계가 검토할 수 있도록 후보 안에 포함하는 것이다.

하나의 서비스는 여러 candidate generator를 동시에 사용할 수 있다. 예를 들어 다음과 같은 source가 각각 후보를 낼 수 있다.

• 사용자가 최근 본 item과 내용이 비슷한 후보
• 비슷한 사용자들이 함께 소비한 후보
• 사용자가 구독한 channel의 새 콘텐츠
• 현재 지역이나 시간대에 인기 있는 후보

각 generator가 만든 후보를 합치고 중복을 제거한 뒤 scoring 단계로 넘긴다. 특정 generator 하나가 사용자의 모든 관심사를 담당하도록 하기보다, 서로 다른 신호로 후보를 넓게 모으는 구조이다.

2단계: Scoring

Scoring은 candidate generation이 만든 비교적 작은 후보 집합에 relevance score를 계산하고 순위를 정한다. Candidate generation보다 후보 수가 적기 때문에 더 많은 feature와 복잡한 모델을 사용할 수 있다.

Score는 단순한 클릭 확률 하나일 수도 있지만, 실제 시스템에서는 시청 시간, 구매 가능성, 만족도처럼 서비스 목표에 맞는 여러 신호를 결합할 수 있다. 중요한 점은 score가 모델이 최적화한 목적의 추정값이라는 것이다. 높은 score가 항상 사용자에게 장기적으로 가장 좋은 item이라는 뜻은 아니므로 마지막 re-ranking 단계가 필요하다.

3단계: Re-ranking

Re-ranking은 scoring 결과에 정책과 사용자 경험에 관한 추가 조건을 반영해 최종 순서를 만든다. 공식 과정은 사용자가 명시적으로 싫다고 표시한 item을 제거하거나 더 새로운 콘텐츠의 순위를 높이는 예를 든다.

이 단계에서는 다음과 같은 조건을 다룰 수 있다.

• Diversity: 거의 같은 item만 연속으로 나오지 않도록 주제나 creator를 분산한다.
• Freshness: 새로 올라온 item이 발견될 기회를 준다.
• Fairness: 특정 집단이나 공급자에게 노출이 과도하게 집중되는지 고려한다.
• Policy와 eligibility: 연령, 지역, 재고, 안전 정책에 맞지 않는 item을 제외한다.
• 사용자 feedback: 이미 소비했거나 명시적으로 싫다고 한 item을 내린다.

Re-ranking은 score를 단순히 다시 정렬하는 작업을 넘어, 모델의 목적함수에 모두 넣기 어려운 제약을 최종 결과에 적용하는 단계이다.

왜 하나의 모델로 처리하지 않는가

세 단계를 나누는 가장 큰 이유는 정확도와 계산 비용 사이의 trade-off이다. Corpus의 모든 item에 정교한 scoring model을 적용하면 한 요청을 처리하는 비용과 latency가 지나치게 커질 수 있다. 반대로 매우 단순한 모델 하나로 끝내면 다양한 context와 정책을 충분히 반영하기 어렵다.

단계	입력 규모	우선 목표	허용 가능한 계산량
Candidate generation	전체 corpus	관련 후보를 놓치지 않는 것	item당 매우 작음
Scoring	수백∼수천 개 후보	후보 사이의 정밀한 relevance 비교	중간
Re-ranking	상위 수십 개	다양성·freshness·정책 반영	후보별 추가 규칙 적용 가능

이 구조에서는 빠른 모델이 넓게 탐색하고, 정교한 모델이 좁게 비교하며, 마지막 단계가 실제 서비스 제약을 적용한다. 각 단계의 목표가 다르므로 평가 지표도 달라질 수 있다. Candidate generation에서는 정답 item이 후보 집합에 포함되는지를 나타내는 recall이 중요하고, 뒤 단계에서는 최종 순서의 품질과 사용자 경험이 더 중요하다.

확인 문제

추천 시스템은 검색으로 찾을 수 없는 무엇을 제공하는가?

사용자가 존재를 몰라 직접 검색하지 못한 item을 과거 행동과 context를 바탕으로 발견하게 한다. 검색과 추천은 서로 대체하는 기능이라기보다 서로 다른 형태의 사용자 의도를 처리한다.

추천 시스템의 세 가지 주요 단계는 무엇인가?

Candidate generation, scoring, re-ranking이다. Embedding과 similarity measure는 candidate generation 등에 쓰이는 표현과 계산 방법이며, matrix factorization과 DNN은 단계를 구현할 수 있는 model 계열이다.

Query가 사용자 ID와 같은 의미인가?

아니다. 사용자 ID는 query를 구성할 수 있는 하나의 feature이다. Query에는 interaction history, 현재 item, 시간대, device 등 현재 추천 요청을 설명하는 context가 함께 들어갈 수 있다.

정리

• 추천 시스템은 큰 corpus에서 사용자가 관심을 가질 item을 발견하고 순서를 정한다.
• Homepage recommendation은 사용자 중심, related-item recommendation은 현재 item 중심의 query를 사용하는 경우가 많다.
• Item은 추천 대상이고, query는 추천 요청의 context이며, embedding은 이산적인 query와 item을 vector로 나타낸 표현이다.
• 대규모 시스템은 candidate generation, scoring, re-ranking을 거치며 후보 수를 단계적으로 줄인다.
• 단계별 분리는 제한된 latency 안에서 넓은 탐색, 정밀한 비교, 서비스 제약 반영을 함께 수행하기 위한 구조이다.

다음 글: 02. Candidate generation과 embedding

출처

• Google for Developers, Recommendation Systems
• Google for Developers, Large-scale recommendation systems
• Google for Developers, Terminology
• Google for Developers, Recommendation systems overview
• Paul Covington, Jay Adams, Emre Sargin, Deep Neural Networks for YouTube Recommendations, RecSys 2016

이 글은 Google for Developers의 Recommendation Systems 과정 내용을 바탕으로 재구성하고 설명을 보강한 학습 노트이다. 원문 콘텐츠와 그림은 Creative Commons Attribution 4.0 License에 따라 이용하였다.