Sampling-bias-corrected Two-Tower Recommendation @Youtube

• 두 개의 입력을 각각 독립된(또는 파라미터를 공유하는) 인코더에 넣어 임베딩을 만든 뒤 임베딩 사이의 유사도 함수를 적용하는 구조를 뜻함 (NLP쪽에서 처음에 주로 사용)
  • = Siamese network
  • 유사도 계산은 일반적으로 dot product, cosine similarity 등
  • inference 시에는 유사도 계산해서 top-k를 리턴
• 사용자/context -> User Tower
• 아이템 -> Item Tower

추천 시스템 Retrieval 단계에서의 역할

YouTube DNN (Covington et al., 2016)에서 산업 표준이 된 두 단계 아키텍처:

• Retrieval: 수십억 아이템에서 수백~수천 개 후보 빠르게 선택 (Recall@k 최대화)
• Ranking: 소수 최종 후보를 예측 보상 확률로 정렬

Two-Tower는 Retrieval 단계의 표준 구조다. 각 탑은 연속 은닉층에서 유닛 수가 절반씩 감소하는 구조이며, 정식 정의는:

• 쿼리 인코더: $u : \mathcal{X} \times \mathbb{R}^d \rightarrow \mathbb{R}^k$
• 아이템 인코더: $v : \mathcal{Y} \times \mathbb{R}^d \rightarrow \mathbb{R}^k$
• 점수 함수: $s(x, y) = \langle u(x, \theta),\, v(y, \theta) \rangle$

학습 목표는 positive $(x_i, y_i)$ 쌍을 임베딩 공간에서 가깝게, negative 쌍을 멀리 배치하는 것 → Negative Sampling 참고.

변형 및 확장

• 다중 임베딩 헤드: 쿼리 탑이 복수의 임베딩을 출력해 다의어 쿼리를 처리 (JD.com의 DPSR)

• 개인화 검색: 소셜 그래프 임베딩 등 사회적 특성 추가 (Facebook 인물 검색)

• DNN Recommendation @Youtube에서 제시된 retrieval 방식과 거의 유사함 (dot product + negative sampling + softmax)

• item (video id, channel id) -> embedding, hashing, average

• user (최근 본 비디오 id) -> embedding average

• 각 row는 하나의 쿼리(혹은 user), 각 column은 item을 의미
• desired items(초록색): 이번 mini-batch에 포함된 positive item들
• sampled negative items(파란색): 해당 쿼리와 상호작용하지 않은 다른 아이템들 중 샘플링된 negative item들
  • 위 그림에서는 다른 쿼리의 positive만 negative로 샘플링하고 있음 -> hard negatives

선택 편향 (Selection Bias)

BNS의 핵심 문제: 인기 아이템이 미니배치에 더 자주 등장 → 아이템 선택 확률이 Unigram 분포를 따름

• 인기 아이템이 negative로 과도하게 처리됨 → 롱테일 아이템과의 구분 능력 약화
• NLP 유비: Zipf 법칙처럼 인기 아이템의 빈도가 순위에 반비례해 집중됨

logQ 보정 (Yi et al., 2019)

점수에서 샘플링 확률의 로그를 빼 편향을 보정:

$s^c(x_i, y_j) = s(x_i, y_j) - \log Q(j)$

여기서 $Q(j) = \frac{\text{count}(j)}{\sum_k \text{count}(k)}$ (아이템 $j$의 Unigram 확률)

인기 아이템일수록 $\log Q(j)$ 값이 커서 점수가 낮아지고, 롱테일 아이템은 상대적으로 점수가 올라가 편향이 완화된다.

요청 정렬 데이터에서의 거짓 음성 (False Negative)

학습 데이터를 Request-level Deduplication 목적으로 요청(request) 단위로 정렬하면 IID 가정이 깨지면서 거짓 음성이 급증한다.

• IID 배치: 거짓 음성 ~0% (서로 다른 사용자의 아이템이 섞임)
• 요청 정렬 배치: 같은 배치 안에 동일 사용자의 다른 아이템들이 집중 → 실제로는 positive일 가능성이 높은 항목이 negative로 취급됨 → 거짓 음성 ~30%

해결책: user-level masking — 동일 사용자(요청)에서 온 아이템은 negative 후보에서 제외하고, 다른 사용자의 아이템만 negative로 사용. logQ 보정(logQ 보정)은 별도로 유지.

• 여기서도 positive item들만 사용
  • 조금 시청하면 0, 다 봤으면 1
  • 아예 시청하지 않은 아이템들은 사용하지 않음
• Stream Frequency Estimation
  • ⚠️ 이 논문의 핵심 변경점
  • 문제: 매우 인기 있는 아이템이 negative에 너무 많이 포함될 수 있음 (popularity bias) -> 즉 인기 아이템이 페널티를 받음
  • 해결: 각 아이템의in-batch softmax의 로짓에서 popularity(=배치의 등장황률) 를 빼주는 correction
    • $s_c(x_i,y_{j)}= s(x_{i},y_{j}) - log{p_j}$
  • $p_j$를 어떻게 추정하나
    • 그냥 전체 corpus counting은 안 됨
      • 유튜브의 아이템 개수를 고려하면 매번 배치마다 카운팅하는 게 사실상 불가능하고, 미리 계산해두면 실시간 변동하는 trend를 반영할 수 없음
    • 스트리밍으로 각 아이템의 배치 간 도달 간격의 EWMA(지수 가중 이동 평균)을 사용함
      • $A[h(y)]$ : 아이템 $y$가 마지막으로 관찰된 gloabl step
      • $t$ : 현재 step, $\alpha$ : 학습률 파라미터 (커질수록 변화를 크게 반영)
      • $B[h(y)] \leftarrow (1-\alpha)B[h(y)] +\alpha(t-A[h(y)])$
      • 즉 $B$는 스트리밍으로 업데이트 되는 평균적인 해당 아이템의 등장 간격 -> 이 값의 역수를 $p$로 사용 (등장 간격이 넓을수록 인기도가 낮은 아이템)
      • 왜 $h(y)$로 표기하나? -> hash sketch : 메모리가 터지지 않게 하기 위해 모든 아이템을 키로 저장하지 않고 고정된 크기의 배열을 만들어서 각 아이템을 해당 배열 내 인덱스로 맵핑 (해시 충돌, 즉 다른 아이템이 같은 위치로 맵핑될 경우 max를 써서 해결함. 등장 간격을 너무 적게 잡을 때의 위험이 더 크다고 보기 때문)

• ⬆️ 최종 구조
• training
  • sequential training - 새 학습 데이터는 하루에 한번씩 일단위로 생성, 이어서 학습, shuffle하지 않음(최근의 distribution shift)
  • 빠른 inference를 위한 index training (학습된 item embedding을 기반으로 ANN 검색 구조를 빌드하는 과정)