요약
네이버 사내 기술 교류 행사인 NAVER Engineering Day 10th 에서 발표되었던 세션을 공개합니다.
크림에서 통합 임베딩(Universal Embedding)은 어떻게 쓰일까?
NAVER D2 | 크림에서 통합 임베딩(Universal Embedding)은 어떻게 쓰일까?
naver.me
발표 내용
여러 엔티티를 한 공간에 담은 통합 임베딩과 범용 리트리벌이 크림 추천 곳곳에 쓰이는 방식, 운영하며 드러난 한계를 v2에서 해결한 과정, 그리고 확장 방향을 공유합니다.
발표 대상
추천 시스템의 후보 생성(Retrieval) 단계에 관심 있으신 분들
여러 서비스·지면에서 함께 쓰는 공용 임베딩을 설계하고 운영하고 싶으신 ML 엔지니어
조건(필터)이 걸린 벡터 검색의 지연과 메모리를 줄이고 싶으신 분들
구좌·서비스마다 늘어나는 추천 모델을 줄이고 싶은 추천·검색 조직의 엔지니어와 기획자
키워드
Recommendation System / Candidate Generation (Retrieval)
Universal Embedding (Bi-encoder · Contrastive Learning)
Matryoshka Representation Learning (MRL)
Filtered Vector Retrieval (Roaring Bitmap · Brute-force vs ANN)
Embedding Serving Optimization
목차
PART 1. 왜 통합 임베딩인가
2025년의 크림: 추천 구좌마다 모델이 따로 있었다
목표: 여러 목적에 쓸 수 있는 범용 임베딩 하나
구좌마다 ‘누구에게 · 무엇을 · 어떻게’가 다르다
통합 임베딩은 후보 생성에 직접, 랭킹에도 입력으로
설계 원칙: 모든 질문이 ‘벡터 + 조건’이 된다
PART 2. v1 모델 — 하나의 공간을 만들다
하나의 인코더가 검색어와 상품을 모두 읽는다
학습: InfoNCE를 받쳐 주는 일곱 가지 장치
학습은 상품 하나, 나머지는 모두 집계로
그림으로 보면: 모두가 상품 공간 위의 점
PART 3. v1 리트리벌 — 하나의 API로 꺼내 쓰다
질문 하나 = 요청 하나
조건별 상품 목록을 미리 만들어 두고 꺼내 쓰기
구좌 전용 모델 없이 붙은 첫 구좌들과 타겟 집단 추천
PART 4. 써 보니 드러난 v1의 한계
모델: 가끔 붕괴하고, 768차원은 무거웠다
리트리벌: 큰 조건을 감당하지 못했다
리트리벌: 조건을 자유롭게 조합할 수 없었다
v1의 한계, 한눈에
PART 5. v2 — 한계를 하나씩 걷어내다
모델 1차: 학습을 안정시키다
모델 2차: 하나의 벡터, 여러 해상도 (MRL)
좌표계: 회전으로 맞추려 했지만, 통하지 않았다
필터: Roaring Bitmap으로 조건을 실행할 때 조합
왜 근사 검색(ANN)이 아니라 후보 전부를 계산하나
점수 계산: 계산량은 그대로, 메모리 낭비만 없앴다
결과: 응답 지연은 약 4배 빠르게, 메모리는 1/6로
API: 조건 칸 하나 → 조건 리스트
v1의 한계 → v2의 처방
PART 6. 지금의 쓰임과 다음 확장
지금: 하나의 API가 채우는 지면과 구좌
비슷한 브랜드: 브랜드 벡터만으로는 부족했다
리트리벌 밖에서도 같은 벡터
다음으로 — 멀티벡터, 지면 확장, 마케팅 타겟팅
|
◎ NAVER Engineering Day란? NAVER에서는 사내 개발 경험과 기술 트렌드를 교류를 할 수 있는 프로그램이 많이 있습니다. 그중 이제는 매회 평균 100개 이상의 발표가 이루어지는 NAVER Engineering Day를 빼놓을 수 없는데요. 2016년부터 시작된 ENGINEERING DAY는 실무에서의 기술 개발 경험과 새로운 기술과 플랫폼 도입 시 유용하게 활용될 수 있는 팁 등을 공유하며 서로 배우고 성장하는 네이버의 대표적인 사내 개발자 행사입니다.(관련 포스팅 보기) 올해 진행된 NAVER Engineering Day의 일부 세션을 공개합니다. |
[동영상 제공 채널 안내]
네이버 TV 서비스 종료로 인해 기존 네이버 TV 채널을 클립(@devrel_d2)으로 이동하였습니다.
앞으로도 많은 관심과 팔로우 부탁드리겠습니다.