[AI논문리뷰-추천알고리즘] Wide & Deep Learning - 추천 시스템에서 암기와 일반화를 함께 쓰는 법

논문  Wide & Deep Learning for Recommender Systems 저자  Heng-Tze Cheng et al. (Google) 학회/연도  DLRS@RecSys 2016 / arXiv 2016 arXiv  1606.07792 Google Research  Publication page

한 문단 요약

Wide & Deep Learning은 추천 랭킹에서 자주 본 feature 조합을 정확히 기억하는 wide linear model과, 처음 보는 조합까지 부드럽게 일반화하는 deep neural network를 함께 학습하는 구조다. Google Play 추천 시스템에 적용했을 때 offline AUC는 Wide 0.726, Deep 0.722, Wide & Deep 0.728로 차이가 작았지만, 3주 온라인 A/B 테스트에서는 앱 설치 전환이 wide-only 대비 +3.9%, deep-only 대비 추가 +1.0% 향상됐다. 이 논문의 진짜 메시지는 “딥러닝만으로 추천을 대체하자”가 아니라, 희소하고 고차원인 추천 데이터에서는 암기와 일반화를 의도적으로 같이 설계해야 한다는 점이다.

이 논문은 무엇을 해결하려고 했나?

추천 시스템의 랭킹 문제는 사용자의 현재 문맥과 후보 아이템을 받아 “이 사용자가 어떤 행동을 할 확률이 높은가”를 점수화하는 문제다. Google Play 같은 대규모 앱 스토어에서는 사용자가 방문할 때마다 retrieval 단계가 수백 개 후보를 뽑고, ranking 단계가 그 후보를 클릭·설치 같은 목표에 맞춰 다시 정렬한다.

이때 추천 모델에는 서로 충돌하는 두 능력이 필요하다. 첫째는 memorization, 즉 과거 로그에서 자주 함께 나타난 feature 조합을 정확히 기억하는 능력이다. 예를 들어 “Netflix를 설치한 사용자가 Pandora를 노출받았다” 같은 조합은 특정 사용자 취향을 강하게 암시할 수 있다. 둘째는 generalization, 즉 과거에 거의 보지 못한 사용자-아이템 조합에도 적당한 점수를 주는 능력이다. 새로운 앱, niche 앱, 긴 꼬리 사용자 행동에서는 이 능력이 중요하다.

논문이 해결하려는 문제는 이 둘 중 하나만 고르면 추천 품질이 흔들린다는 것이다. wide linear model은 cross-product feature로 예외 규칙을 잘 기억하지만, feature engineering 없이는 새로운 조합을 잘 다루지 못한다. deep model은 embedding으로 새로운 조합을 일반화하지만, 희소하고 high-rank인 user-item interaction에서는 관련 없는 조합에도 non-zero 점수를 주며 과도하게 일반화할 수 있다.

배경지식과 핵심 키워드

이 논문은 구조 자체는 단순하지만, 추천 시스템에서 왜 단순한 결합이 강력했는지를 이해하려면 feature engineering, sparse input, ranking serving까지 같이 봐야 한다.

Memorization 추천에서 memorization은 과거 로그에 자주 등장한 feature co-occurrence를 직접 활용하는 능력이다. 논문에서는 wide component가 cross-product transformation으로 이 역할을 맡는다. 예를 들어 AND(user_installed_app=Netflix, impression_app=Pandora)가 1이면 그 조합 자체가 target label과 연결되어, 적은 파라미터로도 특정 예외 규칙을 강하게 잡을 수 있다.	Generalization Generalization은 학습 데이터에서 드물거나 없었던 feature 조합에도 의미 있는 점수를 주는 능력이다. deep component는 sparse categorical feature를 O(10)~O(100) 차원의 dense embedding으로 바꾸고, 여러 hidden layer를 통과시켜 비선형 조합을 학습한다. 다만 embedding은 모든 쌍에 어느 정도 non-zero interaction을 만들기 때문에, 희소하고 high-rank인 추천 행렬에서는 관련 없는 아이템까지 과하게 추천하는 문제가 생길 수 있다.
Wide Component Wide component는 일반화 선형 모델이며 예측식은 y = wᵀx + b 형태다. 입력 x에는 원본 sparse feature와 cross-product feature가 함께 들어간다. 이 구조는 해석 가능하고 빠르며, 논문 실험의 기존 production control도 rich cross-product feature를 가진 wide-only logistic regression이었다.	Cross-Product Transformation Cross-product transformation은 여러 binary feature가 동시에 켜질 때만 1이 되는 AND feature다. 논문은 φₖ(x)=∏ᵢ xᵢ^cₖᵢ 로 표현하며, cₖᵢ는 i번째 feature가 k번째 조합에 포함되는지 나타내는 0/1 변수다. 이 변환이 없으면 wide model은 raw feature의 선형 효과만 보게 되고, “특정 사용자 속성×특정 아이템 속성” 같은 추천 핵심 상호작용을 직접 표현하기 어렵다.
Sparse Categorical Feature 추천 로그에는 country, language, installed app, impression app처럼 값의 종류가 매우 많은 categorical feature가 많다. one-hot으로 펼치면 대부분의 값이 0인 고차원 sparse vector가 된다. 논문은 이 sparse feature를 wide 쪽에서는 그대로 조합 규칙으로 쓰고, deep 쪽에서는 embedding lookup을 통해 dense vector로 바꿔 두 경로가 서로 다른 정보를 보게 한다.	Embedding Embedding은 sparse categorical id를 낮은 차원의 실수 벡터로 바꾸는 테이블이다. 논문에서는 embedding 차원이 보통 O(10)~O(100) 수준이라고 설명한다. embedding은 unseen combination을 다루는 핵심 장치지만, dense representation의 특성상 user-item 쌍 대부분에 약한 상호작용을 만들 수 있어 deep-only 모델의 over-generalization 원인이 된다.
Joint Training Wide & Deep은 wide model과 deep model을 따로 학습한 뒤 앙상블하는 방식이 아니다. 두 component의 logit을 마지막 output unit에서 함께 더하고, 동일한 logistic loss로 end-to-end joint training한다. 이 덕분에 wide 쪽은 자주 관측된 규칙을 잡고, deep 쪽은 embedding 기반 비선형 일반화를 맡도록 하나의 목적함수 안에서 균형을 찾는다.	Online Acquisition Gain 논문에서 가장 중요한 지표는 offline AUC보다 online acquisition gain이다. Table 1에서 Wide & Deep의 AUC는 0.728로 Wide 0.726보다 0.002 높을 뿐이지만, 온라인에서는 앱 설치가 +3.9% 증가했다. 추천 시스템에서는 offline holdout이 고정된 impression과 label만 반영하므로, 실제 트래픽에서 새로운 추천을 탐색하고 사용자 반응을 받는 효과를 완전히 설명하지 못한다.

핵심 인사이트

Wide & Deep의 핵심 연결고리는 “wide는 관측된 조합을 기억하고, deep은 관측되지 않은 조합을 일반화한다”는 역할 분담이다. 추천 데이터가 희소할수록 두 능력 중 하나만으로는 online behavior를 안정적으로 끌어올리기 어렵다.

기존 방법의 한계

기존 production 추천 시스템에서 많이 쓰인 generalized linear model은 대규모 serving에 적합하다. sparse feature를 one-hot으로 두고 logistic regression을 학습하면 빠르고 해석 가능하며, feature weight를 직접 들여다볼 수 있다. 문제는 성능을 올리려면 cross-product feature를 사람이 계속 설계해야 한다는 점이다. user_installed_category=video와 impression_category=music 같은 덜 세분화된 feature를 만들면 어느 정도 일반화가 가능하지만, 그 일반화의 방향 자체가 feature engineer의 가정에 묶인다.

반대로 embedding 기반 deep model은 feature engineering 부담을 줄인다. 사용자와 아이템 feature를 dense vector로 바꾸면, 학습 데이터에 그대로 등장하지 않은 조합도 비슷한 embedding 위치를 통해 예측할 수 있다. 하지만 논문이 지적하는 중요한 함정은 추천 행렬이 sparse하면서 high-rank일 때다. niche 취향이나 narrow appeal 아이템처럼 “대부분의 user-item 쌍은 상호작용이 없어야 하는” 상황에서 deep model은 모든 쌍에 약한 non-zero prediction을 만들 수 있다. 이게 deep-only 추천의 over-generalization이다.

즉 wide-only는 너무 딱딱하고, deep-only는 때로 너무 부드럽다. Wide & Deep은 이 둘을 하나의 모델로 묶어, 딱딱해야 할 곳은 딱딱하게 기억하고 부드러워야 할 곳은 embedding으로 일반화하도록 만든다.

제안 방법의 핵심 아이디어

제안 방법은 이름 그대로 두 부분이다. wide component는 raw feature와 manually designed cross-product feature를 입력으로 받는 선형 모델이다. deep component는 categorical feature를 embedding으로 바꾼 뒤 concatenation하고, feed-forward neural network를 통과시킨다. 마지막 output unit은 두 component의 출력을 함께 사용해 사용자 action label y의 확률 P(y|x)를 예측한다.

중요한 점은 “모델 두 개를 붙였다”보다 “둘을 동시에 학습한다”에 있다. 논문은 wide component에 FTRL with L1 regularization을, deep component에 AdaGrad를 사용한다. 이 선택도 실용적이다. wide 쪽은 sparse cross-product feature가 많으므로 L1로 불필요한 feature weight를 줄이는 것이 중요하고, deep 쪽은 embedding과 hidden layer 파라미터를 안정적으로 업데이트해야 한다.

또 하나의 실용적 설계는 training-serving pipeline이다. Google Play 환경에서는 training data generation, vocabulary generation, model training, model verification, model serving이 하나의 production 흐름으로 연결된다. 모델 구조가 좋아도 serving latency가 맞지 않으면 실제 추천 시스템에는 들어갈 수 없다. 이 논문이 유명해진 이유도 단순히 AUC가 오른 논문이 아니라, billion-user scale app store에 productionized된 추천 랭킹 모델을 공개적으로 설명했기 때문이다.

모델 구조/알고리즘 흐름

학습 데이터는 user data와 app impression data에서 만들어진다. 사용자가 앱 스토어에 들어오면 query가 생성되고, retrieval system이 전체 앱 데이터베이스에서 대략 O(100)개 후보를 뽑는다. ranking model은 이 후보 각각에 대해 사용자 feature, 문맥 feature, impression feature를 입력으로 받아 action probability를 계산하고, 상위 O(10)개 앱을 사용자에게 보여준다.

모델 내부 흐름은 다음과 같다.

첫째, wide path는 sparse input x와 cross-product feature φ(x)를 그대로 선형 모델에 넣는다. 이 경로는 “이미 로그에서 검증된 조합”을 빠르게 재사용한다.

둘째, deep path는 categorical feature string을 embedding vector로 바꾼다. 논문 Figure 4의 Google Play 모델에서는 Age, #App Installs, #Engagement Sessions 같은 continuous feature와 User Demographics, Device Class, User Installed App, Impression App 같은 embedding feature가 concatenated embeddings 약 1200 dimensions로 합쳐진다. 그 위에 ReLU hidden layer 1024, 512, 256이 쌓이고 output layer로 이어진다.

셋째, 두 경로의 출력을 같은 objective로 joint training한다. 이 구조는 deep neural network가 embedding 사이의 nonlinear interaction을 학습하게 하면서도, sparse feature에서 바로 output unit으로 가는 direct connection을 유지한다. 그래서 Factorization Machine처럼 두 변수의 dot product만 보는 모델보다 더 높은 capacity를 갖고, 동시에 wide feature가 추천 특유의 예외 규칙을 보존한다.

논문 그림/표로 이해하기

원문 Figure 1. Wide, Wide & Deep, Deep 모델의 스펙트럼. 출처: Cheng et al., "Wide & Deep Learning for Recommender Systems", DLRS@RecSys 2016. arXiv:1606.07792 — arXiv 라이선스 하에 인용.

Figure 1은 논문 전체를 한 장으로 요약한다. 왼쪽 wide model은 sparse feature가 output으로 직접 연결된다. 오른쪽 deep model은 sparse feature를 embedding과 hidden layer로 보낸다. 가운데 Wide & Deep model은 두 경로를 동시에 둔다. 추천 랭킹에서 자주 보이는 패턴을 기억하는 shortcut과, embedding을 통한 일반화 경로를 같이 유지하는 그림이다.

원문 Figure 2. Google Play 추천 시스템의 retrieval-ranking 흐름. 출처: Cheng et al., "Wide & Deep Learning for Recommender Systems", DLRS@RecSys 2016. arXiv:1606.07792 — arXiv 라이선스 하에 인용.

원문 Figure 4. Google Play 앱 추천용 Wide & Deep model structure. 출처: Cheng et al., "Wide & Deep Learning for Recommender Systems", DLRS@RecSys 2016. arXiv:1606.07792 — arXiv 라이선스 하에 인용.

Offline & Online 결과 비교

모델	Offline AUC	Online Acquisition Gain
Wide (control)	0.726	0%
Deep	0.722	+2.9%
Wide & Deep	0.728	+3.9%

논문 Table 1 재구성. Online Acquisition Gain은 control 대비 상대 개선이다.

실험 설정과 결과 해석

실험은 Google Play의 실제 추천 시스템에서 3주간 A/B 테스트로 진행됐다. control group은 기존 production wide-only logistic regression이며, 사용자 1%가 이 추천을 받았다. experiment group도 사용자 1%를 무작위로 뽑아 Wide & Deep 모델이 만든 추천을 받았다. 논문은 같은 feature set을 사용했다고 밝히기 때문에, 개선은 단순히 feature 추가가 아니라 모델 구조 차이에서 온 것으로 보는 편이 맞다.

결과를 보면 offline AUC만으로는 논문의 임팩트가 잘 보이지 않는다. Wide & Deep은 0.728, Wide는 0.726, Deep은 0.722다. 숫자만 보면 “AUC 0.002 차이인데 왜 중요하지?”라고 느낄 수 있다. 하지만 온라인 앱 설치 전환에서는 Wide & Deep이 control 대비 +3.9%를 만들었고, deep-only보다도 +1.0% 높았다. 대규모 앱 스토어에서 acquisition +3.9%는 매우 큰 운영 지표다.

논문은 이 차이를 offline dataset의 고정성으로 설명한다. offline holdout에는 이미 노출된 impression과 label만 들어 있다. 반면 online system은 ranking 결과가 실제 노출을 바꾸고, 그 노출이 새로운 사용자 반응을 만든다. deep component가 더 다양한 exploratory recommendation을 만들고, wide component가 관련 없는 과잉 일반화를 막을 때 online metric에서 더 큰 차이가 날 수 있다.

Serving 성능도 실험의 일부다. peak traffic에서 추천 서버는 초당 1천만 개가 넘는 app score를 계산해야 했다. 단일 스레드로 후보 전체를 한 batch에서 scoring하면 31ms가 걸렸고, batch size 50과 thread 4개로 나누자 serving overhead 포함 14ms까지 줄었다. 추천 모델은 accuracy만 보는 논문이 많지만, 이 논문은 production latency가 설계 제약이라는 점을 분명히 보여준다.

핵심 인사이트

추천 시스템에서는 offline AUC의 작은 차이가 online business metric의 큰 차이로 이어질 수 있다. 모델이 어떤 후보를 실제로 노출시키느냐가 다음 데이터 분포를 바꾸기 때문이다.

한계와 비판적 관점

첫 번째 한계는 manual cross-product feature가 여전히 필요하다는 점이다. Wide & Deep은 feature engineering을 없앤 논문이 아니다. 오히려 wide component가 좋은 memorization을 하려면 어떤 feature pair를 cross-product로 만들지 사람이 잘 골라야 한다. 이후 DCN, DeepFM, xDeepFM 같은 모델들이 cross feature를 자동으로 학습하려 한 이유가 여기에 있다.

두 번째는 논문의 실험 환경이 매우 강한 production setting이라는 점이다. Google Play는 10억 이상 활성 사용자와 100만 개 이상 앱을 가진 거대한 시스템이다. 이런 규모에서는 +3.9% acquisition gain이 설득력 있지만, 데이터가 작거나 candidate generation 품질이 낮은 서비스에서는 같은 구조가 그대로 먹힌다고 보장하기 어렵다.

세 번째는 fairness, diversity, long-term satisfaction 같은 현대 추천 시스템의 중요한 문제를 깊게 다루지 않는다는 점이다. 논문은 acquisition 중심의 랭킹 목적을 최적화한다. 그러나 앱 설치가 늘었다고 해서 장기 retention이나 사용자 만족이 항상 같이 오른다고 말할 수는 없다.

마지막으로, 이 논문은 2016년 기준의 딥러닝 추천 모델이다. 지금 보면 architecture 자체는 단순하고, attention-based sequential recommendation이나 graph-based recommendation, two-tower retrieval model 같은 흐름과는 거리가 있다. 그래도 “wide memorization + deep generalization”이라는 문제 정의는 여전히 추천 모델 설계의 기본 문법으로 남아 있다.

구현하거나 응용한다면 무엇을 봐야 하나?

실무에 적용한다면 먼저 wide feature와 deep feature의 역할을 분리해서 설계해야 한다. wide에는 “반드시 기억해야 하는 규칙”을 넣는다. 예를 들어 특정 카테고리 선호, 최근 설치 앱과 후보 앱의 조합, 국가·언어·디바이스와 아이템 속성의 조합처럼 로그에서 명확한 신호가 있는 feature가 적합하다. deep에는 long-tail 일반화가 필요한 categorical feature를 embedding으로 넣는다.

둘째, offline AUC 하나만 보고 판단하면 안 된다. 이 논문처럼 online metric과 serving latency를 같이 봐야 한다. 추천 랭킹 모델은 후보를 정렬하는 순간 사용자에게 노출되는 데이터 분포를 바꾼다. 그래서 click, acquisition, retention, uninstall, dwell time 같은 서비스 목표 지표를 함께 설계해야 한다.

셋째, feature pipeline 재현성이 중요하다. Wide & Deep은 training-serving skew가 생기기 쉬운 모델이다. training data generation에서 만든 cross-product feature와 serving에서 계산하는 feature가 조금만 달라도 wide component의 장점이 사라진다. vocabulary generation, feature hashing, missing value 처리, embedding OOV 정책을 명확히 고정해야 한다.

넷째, 지금 구현한다면 TensorFlow의 legacy Wide & Deep API를 그대로 쓰기보다, PyTorch나 TensorFlow/Keras에서 wide logit과 deep logit을 명시적으로 더하는 형태로 구현하는 것이 이해와 디버깅에 좋다. 추천 시스템 프레임워크를 쓴다면 Wide & Deep을 baseline으로 두고, DeepFM이나 DCN 계열과 비교하는 구성이 자연스럽다.

한 줄 결론과 다음에 읽을 논문

한 줄로 말하면, Wide & Deep은 추천 시스템에서 “기억해야 할 조합은 선형 shortcut으로 남기고, 일반화해야 할 조합은 embedding network에 맡기자”는 매우 실용적인 production 논문이다.

다음에 읽을 논문으로는 DeepFM: A Factorization-Machine based Neural Network for CTR Prediction을 추천한다. Wide & Deep이 manual cross-product feature에 기대는 부분을 Factorization Machine으로 자동화하려는 흐름이라, 이 논문과 비교해 읽으면 추천 알고리즘의 feature interaction 설계가 훨씬 선명해진다.

출처:

• arXiv: Wide & Deep Learning for Recommender Systems
• Google Research publication page
• ar5iv HTML version and paper figures