검색과 추천을 동시에 최적화하는 Semantic ID 전략

Semantic IDs for Joint Generative Search and Recommendation (2025)

Joint Search&Recommendation 생성 모델에서 어떤 Semantic ID 구성 전략이 두 태스크를 동시에 잘 처리하는지 비교함

Background

Generative Retrieval 모델의 부상: LLM 기반 생성 모델이 검색과 추천을 단일 아키텍처로 처리하는 방향으로 수렴 중
- 아이템을 discrete token 시퀀스로 표현 → LLM이 직접 생성
- SASRec 같은 전통적 방식의 고유 item ID 대신 Semantic ID 사용 추세
Semantic ID란?: 사전 학습된 임베딩을 quantization해 얻은 discrete token 집합
- 비슷한 임베딩의 아이템은 토큰을 공유 → generalization 및 cold-start 대응 가능
- 핵심 설계 변수: 어떤 임베딩 공간을 사용하느냐
기존 한계: 선행 연구들은 태스크별 임베딩 (검색용 bi-encoder, 추천용 collaborative filtering) 으로 Semantic ID를 구성
연구 질문: 단일 Semantic ID 공간으로 검색과 추천 모두를 효과적으로 처리할 수 있는가?

데이터셋: MovieLens 25M 기반 Joint S&R 데이터셋
- 62,138개 영화, 1.24M 유저-아이템 인터랙션
- 아이템당 Gemini-2.0-flash로 생성한 자연어 쿼리 20개 (train 10 / test 10)
- 검색 popularity bias 제거를 위해 uniform 분포 사용 → 실제 서비스에서는 유사 popularity 분포면 더 유리할 것
생성 모델: flan-t5-base, Search & Recommendation 동시 학습 (3 epochs)
평가 지표: Recall@30
ID 토크나이저: RQ-KMeans (FAISS residual quantiser), 코드북 2개 × 크기 256 (총 512 토큰)

Search-based: all-mpnet-base-v2 기반 bi-encoder를 검색 데이터 $D_S$ $D_{S}$ 로 fine-tuning
- In-batch random negatives, MultipleNegativesRankingLoss
- 임베딩 차원: 386
Rec-based: ENMF (Efficient Neural Matrix Factorization) 협업 필터링 모델
- 임베딩 차원: 256

Separate: 검색/추천 ID에 태스크 태그(SEARCH:, REC:)를 prefix로 붙여 분리
- 토큰 vocabulary를 2배(1024개)로 늘림(같은 모델 안에 두 개의 독립적인 vocab이 존재하는 셈)
- 검색 프롬프트는 검색 토큰만, 추천 프롬프트는 추천 토큰만 생성하도록 함
- 두 태스크 간 지식 공유가 불가 → 오히려 Joint 학습의 정규화 효과를 상쇄
Prefix-share: 공유 코드북 256 + 태스크별 코드북 512 = 혼합 구조
- 두 임베딩을 concatenation해서 단일 quantizer에 입력

Fused_concat: $v_i^{search}$ $v_{i}^{se a r c h}$ 와 $v_i^{rec}$ $v_{i}^{r ec}$ 를 $\ell_2$ $ℓ_{2}$ -normalize 후 concatenation
- $v_i^{concat} = [v_i^{search}; v_i^{rec}]$
- 차원 불균형 문제: bi-encoder(386d) > ENMF(256d) → 검색 임베딩이 더 큰 영향력
Fused_SVD: 두 임베딩을 truncated SVD로 차원을 $d$ $d$ 로 맞춘 후 element-wise 합산
- $v_i^{svd} = v_i^{search} + v_i^{rec}$
- Fused_concat 대비 추천 성능 개선, 검색 성능은 소폭 하락
Multi-task: bi-encoder를 검색( $D_S$ $D_{S}$ )과 추천( $D_R$ $D_{R}$ )을 동시에 학습
- 검색: query-item 쌍, 추천: co-occurring item 쌍
- Loss = 두 contrastive loss의 합
- 단일 encoder가 retrieval + collaborative filtering 신호를 모두 담음

![[assets/검색과 추천을 동시에 최적화하는 Semantic ID 전략/result.png|375]]

Task-specific:
- Search-based: Search R@30=0.072 (최고), Rec R@30=0.026
- Rec-based: Search R@30=0.004, Rec R@30=0.062 (최고)
- 검색 fine-tuned IDs는 추천 성능 60% 하락, 반대도 동일한 패턴
Cross-task:
- Separate → 태스크 간 지식 공유 없어 정규화 효과 소실
- Prefix-share → quantization 품질 문제(인 것 같다고 함..)로 최하위
- Fused_concat → 차원 불균형으로 추천 성능 저하
- Fused_SVD: → SVD로 차원 맞추면 추천 회복, 검색 소폭 손실
- **Multi-task → 두 태스크에서 가장 균형 잡힌 성능
Popularity 분석 (Head vs. Torso):
- Rec-based ID는 Head(상위 1% 인기 아이템)에서 R@30=0.170으로 압도적
- Torso에서는 Search-based ID(0.070)가 Rec-based(0.035)보다 우수

💭

RQ-VAE가 k-means보다 나쁜 건 다른 논문에서도 일관적으로 언급
- 이미 fine tuned된 임베딩을 quantize만 하는 거라 그런지 학습 없이 단순하게 k-means로 묶어주는 게 잘 워킹하는 것 같기도
MovieLens에서 검색 쿼리를 LLM으로 자동 생성했는데 실제 서비스 검색 쿼리와 차이가 클 것 같음 (특히 이 점을 고려하면 popularity 분석 결과는 어떻게 보면 당연한 듯)
Fused_concat에서 임베딩 차원 불균형(386 vs 256)이 성능에 크게 영향을 준다는 점은 실제 적용 시 중요한 포인트