- 읽은 자료 4건
- 정본 반영 0개 파일
- 레이더 4건
오늘 함께 본 다른 변화는 다음과 같다.
- LinkedIn은 팔로우 추천의 후보 생성을 fine-tuned LLM bi-encoder의 임베딩 검색으로 다시 만들어 두 지면에 배포했다.
- Spotify는 Home 팟캐스트 지면에 1B LLM 후보 생성기 GLIDE를 배포했고, SASRec에 다중 목표 디코딩 SPDD를 붙였다.
- X 오픈소스 미러와 Meta·Netflix 엔지니어링 블로그에는 새 자료가 없었다.
1조건부 임베딩 retrieval을 통합 구조로 넓히고 p90 지연을 85% 줄였다 — Pinterest (레이더)
자료 Scaling Conditional Learned Retrieval for Pinterest Home Feed — Pinterest Engineering Blog, 2026-08-26, 블로그. 저자 6인(Devin Kreuzer·Yichi Wang·Sujan Reddy Ale·Zelun Wang·Hongtao Lin·Piyush Maheshwari).
배경 Pinterest Home Feed의 후보 생성(candidate generation)은 대규모 User-to-Pin retrieval 문제다. 흔한 접근은 two-tower 모델이다. user tower가 유저를 벡터로 인코딩하고 item tower가 후보 Pin을 인코딩한 뒤, approximate nearest neighbor 검색으로 유저 임베딩과 가까운 Pin을 뽑는다. 그런데 Pinterest 유저는 여러 의도를 동시에 가진다. 리노베이션 계획, 레시피 저장, 패션 탐색, 여행 아이디어 정리를 한꺼번에 진행하는 식이다. 유저 임베딩 하나로는 이 다양성을 담기 어렵다.
Conditional Learned Retrieval(CLR)은 two-tower 구성을 확장해, user tower를 명시적인 retrieval 컨텍스트로 조건화(condition)한다. 유저 임베딩을 하나만 뽑지 않고 조건을 인식하는 임베딩을 여러 개 만든다. 이 임베딩들은 유저의 전반적인 행동에 근거를 두면서도 여러 의도 축을 반영한다. Pinterest는 이 접근을 사전 논문 두 편에서 다뤘다.
- RecSys'24 Bootstrapping Conditional Retrieval for User-to-Item Recommendations에서 관심 기반 알림에 처음 적용했다.
- KDD'25 Synergizing Implicit and Explicit User Interests: A Multi-Embedding Retrieval Framework at Pinterest에서 명시 의도와 암묵 의도를 결합하는 Home Feed 다중 임베딩 프레임워크로 넓혔다.
이번 블로그는 초기 관심 조건에서 시작한 CLR이 어떻게 Pinterest Home Feed의 통합 retrieval 시스템으로 진화했는지를 세 축으로 정리한다. 세 축은 사용 사례 확장, 모델 확장, 서빙 인프라 재설계다.
새로 알게 된 것
A. 조건 유형이 Interest·Pin·Board 세 가지로 늘었고, 요청당 조건 개수는 에이전트가 튜닝한다 확인
- Interest Conditions: Pinterest가 이미 유지하는 사전 정의 관심 taxonomy를 조건으로 쓴다. 초기 CLR은 user-to-interest 신호에서 관심 몇 개를 뽑아 조건으로 삼았다. 이후에는 LLM이 생성한 새 유저 관심 신호를 조건 소스에 넣었다.
- Pin Conditions: 유저가 최근 engage한 Pin을 클러스터링하고, 각 클러스터의 medoid(중심점)를 골라 조건으로 쓴다. 이 조건은 pre-training 임베딩으로 표현한다. Pinterest는 이 조건으로 레거시 heuristic candidate generator를 없애고 CLR로 대체했다.
- Board Conditions: Pin과 Board는 Pinterest에서 이분 그래프를 이룬다. random walk로 이 그래프를 순회하면 Pin뿐 아니라 Board도 유저에게 추천할 수 있다. Board 조건은 Pin과 같은 사전학습 임베딩 공간으로 표현한다. 이때에도 heuristic 대체와 서빙 스택 단순화가 함께 이뤄졌다.
- Agentic Condition Budget Tuning: GPU 서빙으로 바꿔 지연과 용량에 여유가 생긴 뒤, Pinterest는 Claude Code를 활용해 실험 튜닝을 자동화하는 정책을 만들었다. 그리고 실험 피드백을 계속 읽어서, 요청마다 추론할 조건 개수를 Interest·Pin·Board 각각에 대해 최적화했다. Pinterest는 "low cost increase"로 주요 engagement 지표를 개선했다고 진술한다.
"Following the migration to GPU-based serving, which significantly reduced latency and freed capacity, the team leveraged Claude Code to automate experimentation by continually reading experiment feedback to optimize the number of conditions inferred per request for CLR across Interest, Pin and Board conditions." — Scaling Conditional Learned Retrieval for Pinterest Home Feed, 2026-08-26
B. Pin tower는 이미지 서명과 semantic ID 임베딩을 함께 쓰고, semantic ID는 5단계 계층마다 2048개 코드를 둔다 확인
Pin tower의 ID 임베딩은 처음에 이미지 서명(image signature)을 기반으로 학습됐다. 이미지 서명 기반 ID는 hash처럼 무작위로 분포한다. ID 공간이 십억 규모여서, memorization과 tolerable collision을 위해 20GB 크기의 pretraining ID 임베딩 테이블을 학습했고 TorchRec으로 여러 GPU에 샤딩했다.
여기에 semantic ID를 이미지 서명과 나란히 두었다. semantic ID는 PinClip fusion의 정적 콘텐츠 임베딩을 residual-quantized VAE(RQ-VAE)로 양자화해서 만든 계층 코드다. 시각적·의미적으로 비슷한 Pin은 가까운 코드를 공유한다. Long-tail Pin은 콜드스타트 문제와 학습 데이터 부족을 겪는다. semantic ID 덕분에 long-tail Pin은 인기 Pin과 같은 ID 임베딩 공간을 공유해서 collaborative signal을 빌려 쓸 수 있다.
세부 구성은 다음과 같다.
- 계층 수: 5 layers
- 각 계층 코드 수: 2048
- 임베딩 구조: 대형 테이블 대신 계층별로 작은 임베딩 테이블 5개를 두고, MLP 5층 스택으로 순차 융합한다.
- 최종 결합: 이미지 서명 임베딩과 semantic ID 임베딩을 Pin tower의 feature cross layer에 함께 입력한다.
C. User tower의 시퀀스 인코더는 조건 토큰을 쓰는 Transformer를 거쳐 Foundation Model로 바뀌었다 확인
초기 CLR의 user tower는 정적·집계 피처 위주였다. 최근 이력의 어느 부분이 특정 조건(Interest·Board·Pin)에 유효한지 판단하기 어려웠다. Pinterest는 이를 Conditioned User Sequence Transformer로 바꿨다. 이 Transformer는 아래 순서로 동작한다.
- raw 조건 피처를 condition token으로 변환한다.
- 그 condition token을 user sequence에 붙인다.
- Transformer가 결합된 시퀀스 전체를 인코딩한다.
Condition token은 최근 유저 액션에 대한 query처럼 작동해서, 모델이 retrieval 컨텍스트에 가장 유의미한 시퀀스 신호에 집중하게 한다. Transformer 출력은 세 흐름으로 나뉘어 User Tower의 DHEN(Deep Hierarchical Ensemble Network) layer로 전달된다.
- 인코딩된 condition token
- 인코딩된 최근 유저 시퀀스 token
- residual path로 통과한 raw 조건 피처
이 시퀀스 인코더는 다시 PinFM Foundation Model로 교체됐다. PinFM은 여러 Pinterest 지면의 글로벌 유저 액션 시퀀스로 사전 학습한 대형 Transformer이고, Unified CLR 프레임워크 안에서 fine-tune된다. PinFM은 OmniSage 임베딩에 더해 대형 ID 임베딩 테이블을 함께 써서 Pin의 engagement 지향 표현을 memorization한다. 같은 ID 임베딩 테이블은 Pin tower가 후보 Pin을 인코딩할 때에도 재사용된다. 저자들의 의도는 tower 양쪽에 Pin의 일관된 표현을 두면 정렬이 쉬워진다는 것이다.
세부 설계는 세 가지다.
- fine-tuning에도 다음 토큰 loss를 유지해서 CLR 데이터셋에 적응시킨다. positive action은 saves·repins·sends·downloads다.
- 시퀀스 pooling과 조건 pooling 외에 유저 시퀀스 Transformer 출력의 attention pooling을 추가해, feature cross에 시퀀스 전체 관점을 제공한다.
- condition token 표현과 후보 Pin 표현 사이에 contrastive alignment loss를 걸어, condition token이 Pin 임베딩 공간과 가깝게 정렬되도록 유도한다. 이 alignment는 cross-attention의 Query-key 유사도를 이해할 수 있게 만드는 실용적 근거로 제시된다.
D. Interest CLR과 Board CLR을 Unified CLR 하나로 합치고, 라우팅을 Slot Architecture로 바꿨다 확인
조건 유형마다 별도 모델을 유지하면, 새 조건을 도입할 때마다 학습 파이프라인, 피처 업그레이드, 실험, 서빙 설정, 인덱싱이 중복된다. Pinterest는 두 단계로 이 문제를 해결했다.
- Unified CLR: Interest CLR과 Board CLR을 하나의 모델로 통합했다. 이 모델은 여러 조건 유형을 받고, 없는 조건 피처는 기본값으로 imputation한다. 학습에서는 conditional filtering으로 유효한 조건이 있는 예시에만 집중한다.
- Router Simplification: 조건별 라우팅은 새 조건 유형(Board·Interest·Pin)을 도입할 때마다 전용 피처와 zero-padding을 요구하는 병목이었다. Pinterest는 이를 Slot Architecture로 바꿨다.
condition_os slot: OmniSage 호환 임베딩(Pin OS, Board OS, interest text embedding 등)을 담는다.condition_id slot: 특정 식별자 임베딩(Interest ID, Semantic ID 등)을 담는다.condition_type_id slot: 조건 유형을 32차원 학습 임베딩으로 인코딩해 candidate generator의 정체성을 보존한다.
E. Request-level Training과 M-Falcon으로 학습 처리량을 2배로 늘렸다 확인
Foundation Model을 user tower에 통합하면서 학습 계산량이 크게 늘었다. Pinterest는 손실 없는(lossless) 인프라 최적화 두 가지로 학습 처리량을 2배로 끌어올렸다.
- Request-level training: 같은 학습 batch 안에서 유저 피처는 서로 다른 후보 조건에 걸쳐 반복되는 경우가 잦다.
(user_id, condition identifiers)의 unique 조합으로 유저 피처를 중복 제거해, user tower를 통과하는 실제 배치 크기를 크게 줄인다. forward pass 뒤에는 contrastive loss 계산을 위해, 생성된 임베딩을 원래 batch 크기로 다시 복제(re-duplicate)한다. - M-Falcon: causal attention을 쓰는 덕분에 user sequence 표현은 항상 조건 token과 독립적이다. 따라서 batch 안에서 한 유저의 모든 조건을 user sequence 하나 뒤에 이어 붙이고, 같은 user sequence가 batch 안에서 중복 계산되지 않게 한다.
- 커스텀 block attention mask는 조건 token끼리 서로 attend하는 것은 막고, 조건 token이 바탕이 되는 user sequence에는 완전히 attend하도록 허용한다.
- Transformer layer를 통과하는 유효 배치를 크게 줄여, ID 임베딩과 activation 양쪽의 GPU 메모리 footprint를 낮췄다.
F. 서빙은 모델 요청을 하나로 합친 뒤 GPU 서빙과 NVEmbed로 옮겼다 확인
초기 CLR은 각 조건을 유저 레벨 피처처럼 다뤄서, 조건마다 별도 모델 요청을 보냈다. 조건 수가 늘면서 컴퓨트 클러스터 비용이 급증했다. Pinterest는 서빙을 두 단계로 재설계했다.
- Single Model Request: 백엔드 요청 하나에 담긴 여러 CLR 모델 요청을 request 수준에서 중복 제거하고 모델 요청 하나로 통합했다. 이를 위해 모델의 TorchScript를 고쳐 내부에서 피처를 배치하고, Torch JIT으로 forward pass를 병렬화했다. 병목은 네트워크에서 CPU로 옮겨 갔고, 지연은 중립을 유지했다.
- GPU Serving과 NVEmbed: CLR을 조건의 랭커로 다시 정의해서, 조건을 아이템처럼 다루고 유저 레벨 피처를 조건들에 broadcast했다. 이렇게 하면 CLR 추론이 L2 랭커 구조와 맞는 "1 query — N doc" 패러다임으로 통합된다.
- CUDA 호환 모델을 export해 g6e.4xlarge에 배포했고, 모델 쪽 배치 형성 로직을 없애고 출력 파싱을 개선했다.
- Foundation Model 이후 늘어난 대형 ID 임베딩 테이블을 함께 서빙하고 실험하기 위해 NVEmbed를 채택했다. NVEmbed는 임베딩 테이블과 dense 모델을 서빙 가능한 TorchScript artifact 하나로 통합하는 프레임워크다.
G. 프로덕션에서 7-figure 비용을 절감하고 p90 모델 지연을 85% 줄였다 확인
- 재무·성능: 7-figure 비용을 절감했고, p90 모델 지연을 80ms → 12ms로 85% 줄였다.
- 확장성: CLR FM(Foundation Model), Search CLR 같은 후속 이니셔티브를 가능하게 했다. 유저당 더 많은 조건을 지원할 수 있게 됐다.
- 개발 속도: 인프라 단순화로 기술 부채가 줄었고, 새 조건으로 확장하는 진입 장벽이 낮아졌다.
"Financial & Performance: 7 figure cost savings and reduced p90 model latency by 85% (80ms to 12ms) Scalability: Unblocked major initiatives, including CLR FM and Search CLR, while enabling more conditions per user." — Scaling Conditional Learned Retrieval for Pinterest Home Feed, 2026-08-26
정본 반영 radar.md의 이번 달 신규 절에 항목을 추가했다. Pinterest는 현재 정본으로 추적하는 서비스가 아니어서 services/ 정본은 만들지 않는다.
의미 Pinterest CLR은 조건부 임베딩 검색을 두 축으로 확장한 프로덕션 사례다.
- 첫째 축은 조건의 종류다. Interest에서 Pin, Board로 넓혔고, LLM이 생성한 새 관심 신호를 조건 소스에 넣었다.
- 둘째 축은 조건 아키텍처의 통합이다. Unified CLR과 Slot Architecture가 여기에 해당한다.
Netflix Foundation Model이 채점 함수 위로 통합했다면, Pinterest CLR은 retrieval의 조건화 축으로 통합했다. 두 방향은 다른 층에서 같은 결론에 도달한다. 하나의 프레임워크로 여러 지면과 조건을 지탱한다는 결론이다.
또 하나 볼 점은 에이전트 기반 하이퍼파라미터 튜닝을 프로덕션에서 썼다는 진술이다. Pinterest는 Claude Code로 실험 피드백을 읽어 요청당 조건 예산을 자동 튜닝했다고 밝혔다. 이는 AI 에이전트를 recsys 프로덕션 파이프라인의 튜닝 루프에 붙인 사례다. Meta AMBER나 X의 랭킹 모델 Phoenix에는 아직 비슷한 진술이 없어서, 다른 회사도 비슷한 흐름을 낼지가 앞으로 지켜볼 지점이다.
2LLM bi-encoder 임베딩 검색을 팔로우 추천의 후보 생성기로 배포했다 — LinkedIn (레이더)
자료 Rebuilding LinkedIn's Follows Recommendations with LLM-Based Semantic Retrieval and Ranking — LinkedIn Engineering Blog, 2026-08-24, 블로그. 저자 Haohua Wan.
배경 LinkedIn의 Follows Recommendations는 유저가 팔로우할 만한 크리에이터를 추천하는 지면이다. MyNetwork tab의 왼쪽 사이드바와 Home Feed의 오른쪽, 두 곳에 나타난다. 기존 시스템은 그래프 기반과 인기 기반 후보 생성기에 의존해 왔다. 특히 새 멤버는 첫 세션에서 sparse·popularity-based fallback만 얻는 문제가 있었다. LinkedIn은 이를 LLM 기반 semantic retrieval과 dense L2 랭킹을 갖춘 3단 파이프라인으로 재작성했다.
새로 알게 된 것
A. fine-tuned LLM bi-encoder가 기존 후보 생성기와 병렬로 도는 새 후보 생성 채널을 맡는다 확인
파이프라인의 첫 단계는 Embedding-Based Retrieval(EBR)이다. fine-tuned bi-encoder가 멤버와 크리에이터의 프로필을 각각 임베딩으로 인코딩한다. 프로필 필드는 narrative prompting 방식으로 인코더에 넣는다. narrative prompting은 프로필 필드를 자연어 문장으로 재구성해 LLM 입력으로 주는 방식이다. 이 EBR 채널은 기존 graph 기반, popularity 기반 candidate generator와 병렬로 돈다.
- 백본: 중간 규모 instruction-tuned 오픈소스 모델이다. 구체적인 이름은 공개하지 않았다.
- 임베딩 차원: 1024–4096이다. 서빙할 때 supervised projection layer로 64–128차원으로 압축한다.
- 크리에이터 후보 풀: 1000만 명 미만의 eligible creator다.
- 멤버 규모: "billions of LinkedIn members".
B. 크리에이터 임베딩은 오프라인에서 미리 계산해 FAISS에 적재하고, 뷰어 임베딩은 온라인에서 Proxima로 추론한다 확인
LLM은 크리에이터 쪽은 오프라인 batch, 뷰어 쪽은 온라인 실시간 추론이라는 이중 배치 구조로 서빙 경로에 들어간다.
- 오프라인: 크리에이터 임베딩은 Ray 분산 GPU 클러스터에서 야간 batch 추론으로 미리 계산하고, FAISS IndexFlatIP exact K-NN 인덱스에 적재한다(~10M).
- 온라인: 멤버가 온보딩하는 순간 Proxima(LinkedIn의 모델 호스팅 인프라)에서 viewer 임베딩을 실시간으로 추론한다. 그 임베딩으로 hosted vector search service에 질의한다.
C. L2 랭킹 층에서는 dense 신경망이 후보 점수를 매긴다 확인
FC, ReLU, batch norm, dropout으로 이뤄진 dense NN이 후보 점수를 매긴다. 피처는 behavioral, categorical, collaborative-filtering 피처와 task-aware projected embeddings다. task-aware projected embeddings는 supervised projection layer로 1024–4096차원을 64–128차원으로 줄인 것이다.
D. A/B에서 세그먼트별 follow rate가 유의하게 올랐고, 새 멤버에서 가장 크게 올랐다 확인
LinkedIn은 세그먼트별로 통계적으로 유의미한 follow rate lift가 있었고, 새 멤버 세그먼트가 가장 크다는 점만 밝혔다. 구체적인 uplift 백분율, 지연 수치, 절대 engagement 숫자는 블로그에 공개하지 않았다.
"After the redesign shipped, in production A/B tests, the new pipeline delivered statistically significant lifts in follow rate across member segments, with the strongest gains for new members, who now get relevant matches from their first session instead of the sparse, popularity-based suggestions the old system fell back on." — Rebuilding LinkedIn's Follows Recommendations, 2026-08-24
정본 반영 radar.md의 이번 달 신규 절에 항목을 추가했다. LLM-native ranking의 확산 스레드에는 LinkedIn을 추가 근거로 넣었다.
의미 LinkedIn Follows는 radar.md의 "LLM-native ranking의 확산" 스레드에 새 항목으로 붙는다. LinkedIn이 차지하는 자리는 "Bi-encoder embedding retrieval을 LLM으로 fine-tune해서 후보 생성기 채널로 추가"이고, 지금까지 이 스레드에 있던 항목 어디에도 정확히 대응하지 않는다. 지금까지 있던 항목은 다음과 같다.
- Netflix GenRec(채점 함수)
- Yandex Gryphon-v2/Sona(생성 retrieval과 rank)
- Alibaba MetaStrategy(오프라인 정책 컴파일러)
- Meta ConnectionMind(그래프 경로 추론기)
- Meta AMBER(입력 tokenization)
이 자리는 Pinterest CLR이 조건화된 EBR로 진화한 방향과 상보적이다. Pinterest는 조건을 붙였고, LinkedIn은 자연어 profile prompting을 붙였다.
LinkedIn 진술의 약점은 구체적 수치가 부족하다는 것이다. 콜드스타트 세그먼트에서 개선이 가장 크다는 정성적 표현은, EBR이 popularity fallback을 대체할 때 신규 유저 지표가 좋아진다는 관찰과 정합적이다. 같은 흐름을 X Phoenix의 cold-start author boost와 대비할 수 있다. 세그먼트별 lift 숫자가 다음 자료에 공개되는지가 관전 포인트다.
3Home 팟캐스트에 1B LLM 후보 생성기를 배포하고, SASRec에 다중 목표 디코딩을 붙였다 — Spotify (레이더)
자료 (1) From Models to Products: LLMs for Recommendation at Spotify Scale — Spotify Research, 2026-08-03, 블로그.
자료 (2) Balancing Multiple Objectives in Generative Recommendations with Adaptive Decoding — Spotify Research, 2026-08-07, 블로그.
배경 Spotify Research는 LLM과 generative recommender를 프로덕션에 어떻게 통합했는지 블로그 두 편으로 정리했다. 첫 편은 GLIDE를 Home의 팟캐스트 발견 지면에 배포한 사례다. 두 번째 편은 SPDD(Stochastic Primal-Dual Decoding)를 SASRec 기반 플레이리스트 랭킹의 디코딩 층에 붙인 사례다.
새로 알게 된 것
A. GLIDE는 1B LLM과 Semantic ID로 만든 후보 생성기이고, Home 팟캐스트 지면에 배포됐다 확인
- 지면: Spotify Home의 팟캐스트 발견 카드.
- 작동 방식: 추가 candidate generator로 작동하며, 뒤쪽 랭킹 파이프라인에 후보를 공급한다.
- 모델 크기: 1B parameter LLM.
- 아이템 표현: Semantic ID. 카탈로그 아이템을 짧은 token 시퀀스로 표현해서, LLM이 실제 카탈로그 참조를 생성하게 만든다. 텍스트 hallucination을 막는 장치다.
- A/B: 21일 테스트, 약 2000만 impression 규모.
- 결과: non-habitual podcast listening +5.4%, new-show discovery +14.3%. 지연과 engagement 요구사항은 유지했다.
이 블로그는 NEO 프레임워크도 언급한다. NEO는 검색·추천·추론을 하나의 모델로 통합하는 "language-steerable" 아키텍처다. 1000만 개 이상의 아이템과 1500만 유저 규모로 테스트했지만, 프로덕션 배포는 언급하지 않았다. 연구 단계다.
B. SPDD는 SASRec의 디코딩 시점에만 개입해, 재학습 없이 여러 목표의 가중을 조정한다 확인
- 위치: 사전 학습된 generative recommender의 디코딩(생성/추론) 시점에만 개입하는 lightweight layer다.
- 대상 모델: 프로덕션 A/B는 SASRec(autoregressive sequential recommender)으로 플레이리스트 랭킹에 적용했다. 논문에서는 TransAct(Home shelf 랭킹)에서도 평가했지만, 라이브 배포는 SASRec 쪽이다.
- 작동 방식: 생성 단계에서 auxiliary objective(예: relevance와 diversity, 또는 relevance와 novelty)에 대한 가중치를 동적으로 튜닝하고, 재학습 없이 목표를 조정한다.
- A/B: ~100만 유저 × 60만 플레이리스트 규모의 대규모 실험이다.
- 결과: auxiliary stream-share 지표에서 SPDD는 +5.44%(control 대비), fixed-weight는 +3.60%로 약 1.8pp 차이가 났다. 유저 소비 감소 없이 달성했고, skip rate 증가폭도 더 낮았다.
Spotify는 "generative recommender"를 autoregressive 시스템으로 정의한다. 한 번에 아이템 하나를 고르고, 그 선택이 이후 위치의 점수에 영향을 주면서 sequential dependency를 잡는 시스템이다.
정본 반영 radar.md의 이번 달 신규 절에 두 항목을 추가했다. LLM-native ranking 스레드에는 Spotify GLIDE를 추가 근거로 넣었다. 생성형 retrieval / semantic ID 스레드에는 GLIDE(Semantic ID 기반 LLM 후보 생성기)와 SPDD(multi-objective adaptive decoding)를 함께 넣었다.
의미 Spotify GLIDE는 LLM을 랭킹 파이프라인에 붙인 프로덕션 진술로 이 스레드에 더해진다. 콘텐츠 도메인은 다르지만, 서빙 경로에서 LLM을 후보 생성기로 두는 자리가 새롭다. 이 스레드는 그동안 Netflix와 Yandex, Alibaba, Meta가 채웠고, 같은 날 LinkedIn(§2)도 붙었다.
SPDD는 decoding time에만 개입하는 multi-objective 컨트롤러라는 자리를 새로 만든다. 지금까지 SID(semantic ID)와 LLM 계열의 논쟁은 두 가지에 집중돼 있었다.
- architecture: HSTU(Meta organic 쪽 시퀀스 모델 계보) 대 Transformer 대 SID와 CoT의 결합
- training objective: next-token 대 contrastive 대 distillation
SPDD는 여기에 serving-side 디코딩 정책이 계산을 늘리지 않고 auxiliary objective를 조정한다는 방향의 실증을 더한다. Kuaishou의 PushDualGen이 서빙 비용을 피하려고 SID와 skippable copy를 쓰는 구조로 갔다면, SPDD는 서빙 모델을 그대로 두고 디코딩 정책만 바꾸는 대안 각도다.
검증에서 뒤집힌 것
없다. 세 자료 모두 기존 radar 스레드와 정합하고, 그 스레드를 확장한다.
레이더
이번 4건은 오늘 월요일 산업 블로그 스캔에서 발견했고, 지난 배치들이 놓친 항목이다. 모두 radar.md의 이번 달 신규 절에 추가한다.
- Pinterest CLR (Scaling Conditional Learned Retrieval for Pinterest Home Feed, 2026-08-26): Home Feed retrieval의 조건화 프레임워크를 통합했다. 프로덕션에서 p90 지연이 80ms에서 12ms로 줄었다.
- LinkedIn Follows LLM (Rebuilding LinkedIn's Follows Recommendations, 2026-08-24): bi-encoder LLM EBR을 MyNetwork·Home Feed 두 지면에 배포했다.
- Spotify GLIDE (From Models to Products: LLMs for Recommendation at Spotify Scale, 2026-08-03): 1B LLM과 Semantic ID 기반 후보 생성기를 Spotify Home 팟캐스트에 배포했다. 21일 동안 20M impression 규모로 A/B를 했고, non-habitual listening은 +5.4%였다.
- Spotify SPDD (Balancing Multiple Objectives in Generative Recommendations with Adaptive Decoding, 2026-08-07): SASRec 위에서 inference-time multi-objective 디코딩을 한다. 100만 유저 A/B에서 aux stream-share는 +5.44%, fixed-weight는 +3.60%였다.
arXiv cs.IR triage에서는 30건을 파싱했고, 통과한 것은 0건이다. 프로덕션 배포나 A/B 진술이 있는 후보는 없었다. 대부분은 아래 두 부류에 속한다.
- 학술 기관 저자의 offline 벤치마크 연구: CORE MLLM reranker distill, EPIC SID diffusion, HypRQ-VAE hyperbolic long-tail, SelfDR LLM reasoning distill, DoPR LLM reranker prefix, UniCon CTR, Recommender as Slow/Fast Thinkers, Training seeds stability 등
- 도메인 제한 연구: POI·법률·의료·야구·music·finance QA·essay grading·RAG·private retrieval
다음에 볼 것
- Pinterest CLR의 조건 예산 튜닝에 쓴 Claude Code 파이프라인의 세부 — 어떤 metric을 목적 함수로 삼았는지, feedback loop 주기가 어떤지가 후속 블로그나 발표에서 공개될지 지켜본다. AI 에이전트를 recsys 튜닝 루프에 붙인 프로덕션 사례로서 다른 회사가 비슷한 진술을 낼지가 두 번째 관전 포인트다.
- LinkedIn Follows의 구체적 uplift 수치 — 블로그는 세그먼트별 lift만 정성적으로 진술했다. LinkedIn이 후속 논문(RecSys/CIKM 등)이나 발표에서 세그먼트별 절대 수치를 공개하는지 확인한다. 특히 new-member 세그먼트의 개선폭은 콜드스타트 논쟁에서 유의미한 데이터 포인트다.
- Spotify NEO 프레임워크의 프로덕션 진술 — GLIDE는 candidate generator로 배포됐지만, NEO(검색·추천·추론을 통합한 모델)는 아직 연구 단계다. Spotify가 NEO를 어느 지면에 언제 배포하는지가 다음 관전 포인트다.
- PinFM Foundation Model의 상세 아키텍처와 크기 — Pinterest CLR 블로그는 PinFM을 참조(ref)로만 표기하고 상세를 공개하지 않았다. Meta의 GEM/HSTU와 Netflix Foundation Model에 대응하는 Pinterest 진술이 별도 자료로 나오는지 확인한다.
조회 실패는 두 곳이다.
- ai.meta.com/blog/rss/: curl exit 56이 났고, RSS에는 접근하지 못했다. 브라우저 UA로 blog 페이지를 가져오는 것은 성공했다.
- linkedin.com/blog/engineering/rss.xml: HTTP 404를 받았다. RSS URL 자체가 없다. blog 페이지에서 직접 확인했다.