2026-09-07

Other changes reviewed today:

• LinkedIn rebuilt candidate generation for follow recommendations as embedding search with a fine-tuned LLM bi-encoder and deployed it on two surfaces.
• Spotify deployed GLIDE, a 1B LLM candidate generator, on the Home podcast surface and added SPDD, multi-objective decoding, to SASRec.
• The X open-source mirror and the Meta and Netflix engineering blogs had no new material.

1Conditional retrieval unified and p90 latency cut by 85% — Pinterest (radar)

Conditional Learned Retrieval (CLR) extends the two-tower setup by conditioning the user tower on an explicit retrieval context. Instead of producing one user embedding, it produces several condition-aware embeddings. These embeddings stay grounded in the user's overall behavior while reflecting multiple intent axes. Pinterest covered this approach in two earlier papers.

• RecSys'24 Bootstrapping Conditional Retrieval for User-to-Item Recommendations first applied it to interest-based notifications.
• KDD'25 Synergizing Implicit and Explicit User Interests: A Multi-Embedding Retrieval Framework at Pinterest extended it to a Home Feed multi-embedding framework that combines explicit and implicit intents.

This blog post describes, along three axes, how CLR evolved from its initial interest conditions into the unified retrieval system of Pinterest Home Feed. The three axes are expanding use cases, expanding the model, and redesigning the serving infrastructure.

A. Condition types grew to three, Interest, Pin and Board, and an agent tunes the number of conditions per request verified

• Interest Conditions: These use the predefined interest taxonomy that Pinterest already maintains as conditions. The initial CLR took a few interests from user-to-interest signals as conditions. Later, new LLM-generated user interest signals were added to the condition sources.
• Pin Conditions: These cluster the Pins a user engaged with recently and pick the medoid (center point) of each cluster as a condition. The condition is represented with pre-training embeddings. With this condition, Pinterest removed the legacy heuristic candidate generator and replaced it with CLR.
• Board Conditions: Pins and Boards form a bipartite graph at Pinterest. Traversing this graph with a random walk makes it possible to recommend Boards to users as well as Pins. Board conditions are represented in the same pretrained embedding space as Pins. Here too, a heuristic was replaced and the serving stack was simplified.
• Agentic Condition Budget Tuning: After the move to GPU serving freed up latency and capacity, Pinterest built a policy that uses Claude Code to automate experiment tuning. It keeps reading experiment feedback and optimizes the number of conditions inferred per request for each of Interest, Pin and Board. Pinterest states that it improved key engagement metrics with a "low cost increase".

"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. The Pin tower uses image signatures and semantic ID embeddings together, and the semantic ID has 2048 codes in each of 5 hierarchy layers verified

The ID embedding of the Pin tower was first trained on image signatures. IDs based on image signatures are distributed randomly, like a hash. Because the ID space is on the order of a billion, Pinterest trained a 20GB pretraining ID embedding table for memorization and tolerable collisions and sharded it across GPUs with TorchRec.

On top of this, it placed the semantic ID alongside the image signature. The semantic ID is a hierarchical code made by quantizing the static content embedding of PinClip fusion with a residual-quantized VAE (RQ-VAE). Pins that are visually and semantically similar share nearby codes. Long-tail Pins suffer from the cold start problem and a lack of training data. With the semantic ID, long-tail Pins share the same ID embedding space as popular Pins and can borrow collaborative signal.

The detailed configuration is as follows:

• Number of layers: 5 layers
• Codes per layer: 2048
• Embedding structure: instead of one large table, five small embedding tables, one per layer, fused sequentially by a 5-layer MLP stack.
• Final combination: the image signature embedding and the semantic ID embedding are fed together into the feature cross layer of the Pin tower.

C. The user tower's sequence encoder moved to a Transformer with condition tokens and then to a Foundation Model verified

The initial CLR user tower relied mostly on static and aggregated features. It was hard to tell which part of the recent history was valid for a given condition (Interest, Board, Pin). Pinterest replaced it with a Conditioned User Sequence Transformer. This Transformer works in the following order:

1. Convert raw condition features into condition tokens.
2. Attach those condition tokens to the user sequence.
3. The Transformer encodes the combined sequence as a whole.

The condition token acts like a query over recent user actions, so the model focuses on the sequence signals most relevant to the retrieval context. The Transformer output splits into three streams and goes to the DHEN (Deep Hierarchical Ensemble Network) layer of the User Tower:

• the encoded condition tokens
• the encoded recent user sequence tokens
• the raw condition features passed through a residual path

This sequence encoder was later replaced with the PinFM Foundation Model. PinFM is a large Transformer pretrained on global user action sequences from several Pinterest surfaces, and it is fine-tuned inside the Unified CLR framework. PinFM uses a large ID embedding table together with OmniSage embeddings to memorize engagement-oriented representations of Pins. The same ID embedding table is reused when the Pin tower encodes candidate Pins. The authors intend that a consistent representation of the Pin on both towers makes alignment easier.

There are three detailed design choices:

• The next-token loss is kept during fine-tuning to adapt the model to the CLR dataset. Positive actions are saves, repins, sends and downloads.
• In addition to sequence pooling and condition pooling, attention pooling of the user sequence Transformer output is added to give feature cross a view of the whole sequence.
• A contrastive alignment loss between the condition token representation and the candidate Pin representation encourages the condition token to align closely with the Pin embedding space. This alignment is presented as a practical basis for making the Query-key similarity of cross-attention interpretable.

D. Interest CLR and Board CLR were merged into one Unified CLR, and routing was changed to a Slot Architecture verified

Maintaining a separate model for each condition type duplicates the training pipeline, feature upgrades, experiments, serving configuration, and indexing every time a new condition is introduced. Pinterest solved this in two steps.

• Unified CLR: Interest CLR and Board CLR were unified into one model. The model accepts several condition types and imputes defaults for missing condition features. In training, conditional filtering focuses on examples that have a valid condition.
• Router Simplification: Per-condition routing was a bottleneck because every new condition type (Board, Interest, Pin) required dedicated features and zero-padding. Pinterest replaced it with a Slot Architecture.
  • condition_os slot: holds OmniSage-compatible embeddings (Pin OS, Board OS, interest text embedding, etc.).
  • condition_id slot: holds specific identifier embeddings (Interest ID, Semantic ID, etc.).
  • condition_type_id slot: encodes the condition type as a 32-dimensional learned embedding to preserve the identity of the candidate generator.

E. Request-level Training and M-Falcon increased training throughput 2× verified

Integrating the Foundation Model into the user tower greatly increased training compute. Pinterest doubled training throughput with two lossless infrastructure optimizations.

• Request-level training: Within the same training batch, user features are often repeated across different candidate conditions. Deduplicating user features by the unique combination of (user_id, condition identifiers) greatly reduces the actual batch size passing through the user tower. After the forward pass, the generated embeddings are re-duplicated to the original batch size for the contrastive loss computation.
• M-Falcon: Because causal attention is used, the user sequence representation is always independent of the condition tokens. So all conditions of one user in a batch are appended after a single user sequence, and the same user sequence is not computed repeatedly in the batch.
  • A custom block attention mask blocks condition tokens from attending to each other and lets each condition token fully attend to the underlying user sequence.
  • It greatly reduces the effective batch passing through the Transformer layers, lowering the GPU memory footprint of both ID embeddings and activations.

F. Serving merged model requests into one and moved to GPU serving and NVEmbed verified

The initial CLR treated each condition like a user-level feature and sent a separate model request per condition. As the number of conditions grew, compute cluster cost surged. Pinterest redesigned serving in two steps.

• Single Model Request: Multiple CLR model requests inside one backend request were deduplicated at the request level and merged into a single model request. To do this, it modified the model's TorchScript to batch features internally and parallelized the forward pass with Torch JIT. The bottleneck moved from the network to the CPU, and latency stayed neutral.
• GPU Serving and NVEmbed: CLR was redefined as a ranker of conditions, treating conditions like items and broadcasting user-level features across the conditions. This unifies CLR inference into the "1 query — N doc" paradigm that matches the L2 ranker structure.
  • A CUDA-compatible model was exported and deployed on g6e.4xlarge, model-side batch formation logic was removed, and output parsing was improved.
  • NVEmbed was adopted to serve and experiment with the large ID embedding tables that grew after the Foundation Model. NVEmbed is a framework that unifies the embedding tables and the dense model into one servable TorchScript artifact.

G. In production it saved 7 figures in cost and cut p90 model latency by 85% verified

• Financial and performance: It saved 7 figures in cost and cut p90 model latency by 85%, from 80ms to 12ms.
• Scalability: It unblocked follow-on initiatives such as CLR FM (Foundation Model) and Search CLR. It made it possible to support more conditions per user.
• Development velocity: Simplified infrastructure reduced technical debt and lowered the barrier to expanding to new conditions.

"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

• The first axis is the kind of condition. It widened from Interest to Pin and Board, and added new LLM-generated interest signals to the condition sources.
• The second axis is the unification of the condition architecture. Unified CLR and the Slot Architecture count as this.

If the Netflix Foundation Model unified above the scoring function, Pinterest CLR unified along the conditioning axis of retrieval. The two directions reach the same conclusion at different layers: one framework supports multiple surfaces and conditions.

Another point to note is the statement that agent-based hyperparameter tuning was used in production. Pinterest said it used Claude Code to read experiment feedback and automatically tune the per-request condition budget. This is a case of attaching an AI agent to the tuning loop of a recsys production pipeline. Meta AMBER and X's ranking model Phoenix have no similar statement yet, so whether other companies show a similar trend is a point to watch.

↑ Contents

2LLM bi-encoder embedding retrieval deployed as follow-recommendation candidate generator — LinkedIn (radar)

A. A fine-tuned LLM bi-encoder runs a new candidate generation channel in parallel with the existing candidate generators verified

The first stage of the pipeline is Embedding-Based Retrieval (EBR). A fine-tuned bi-encoder encodes the profiles of members and creators into embeddings. Profile fields are fed to the encoder with narrative prompting. Narrative prompting reconstructs profile fields into natural-language sentences and gives them as LLM input. This EBR channel runs in parallel with the existing graph-based and popularity-based candidate generators.

• Backbone: a mid-size instruction-tuned open-source model. The specific name is not disclosed.
• Embedding dimension: 1024–4096. At serving time, a supervised projection layer compresses it to 64–128 dimensions.
• Creator candidate pool: fewer than 10 million eligible creators.
• Member scale: "billions of LinkedIn members".

B. Creator embeddings are precomputed offline and loaded into FAISS, and viewer embeddings are inferred online on Proxima verified

The LLM enters the serving path in a dual deployment structure: offline batch on the creator side and online real-time inference on the viewer side.

• Offline: Creator embeddings are precomputed by nightly batch inference on a Ray distributed GPU cluster and loaded into a FAISS IndexFlatIP exact K-NN index (~10M).
• Online: At the moment a member onboards, the viewer embedding is inferred in real time on Proxima (LinkedIn's model hosting infrastructure). That embedding is used to query the hosted vector search service.

C. In the L2 ranking layer, a dense neural network scores candidates verified

A dense NN made of FC, ReLU, batch norm and dropout scores the candidates. The features are behavioral, categorical and collaborative-filtering features plus task-aware projected embeddings. Task-aware projected embeddings are 1024–4096 dimensions reduced to 64–128 dimensions by a supervised projection layer.

D. In the A/B test, follow rate rose significantly by segment, most for new members verified

LinkedIn said only that there were statistically significant follow rate lifts by segment and that the new member segment is the largest. It did not publish specific uplift percentages, latency figures, or absolute engagement numbers in the blog post.

"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

• Netflix GenRec (scoring function)
• Yandex Gryphon-v2/Sona (generative retrieval and rank)
• Alibaba MetaStrategy (offline policy compiler)
• Meta ConnectionMind (graph path reasoner)
• Meta AMBER (input tokenization)

This role is complementary to the direction in which Pinterest CLR evolved into conditioned EBR. Pinterest added conditions, and LinkedIn added natural-language profile prompting.

The weakness of LinkedIn's statement is the lack of concrete figures. The qualitative claim that improvement is largest in the cold start segment is consistent with the observation that new-user metrics improve when EBR replaces the popularity fallback. The same trend can be contrasted with the cold-start author boost in X Phoenix. Whether segment-level lift figures are published in a later source is the point to watch.

↑ Contents

31B LLM candidate generator deployed on Home podcasts, multi-objective decoding on SASRec — Spotify (radar)

A. GLIDE is a candidate generator built from a 1B LLM and Semantic IDs, deployed on the Home podcast surface verified

• Surface: the podcast discovery card on Spotify Home.
• How it works: it runs as an additional candidate generator and supplies candidates to the downstream ranking pipeline.
• Model size: 1B parameter LLM.
• Item representation: Semantic ID. Catalog items are represented as short token sequences so that the LLM generates real catalog references. This is a mechanism to prevent text hallucination.
• A/B: 21-day test, about 20 million impressions.
• Result: non-habitual podcast listening +5.4%, new-show discovery +14.3%. It kept the latency and engagement requirements.

The blog post also mentions the NEO framework. NEO is a "language-steerable" architecture that unifies search, recommendation and reasoning in one model. It was tested at the scale of more than 10 million items and 15 million users, but the post does not mention production deployment. It is at the research stage.

B. SPDD adjusts the weights of multiple objectives without retraining by intervening only at SASRec's decoding time verified

• Position: a lightweight layer that intervenes only at decoding (generation/inference) time of a pretrained generative recommender.
• Target model: the production A/B applied it to playlist ranking on SASRec (an autoregressive sequential recommender). The paper also evaluated it on TransAct (Home shelf ranking), but the live deployment is on the SASRec side.
• How it works: at the generation stage it dynamically tunes the weights for auxiliary objectives (for example relevance and diversity, or relevance and novelty) and adjusts the objectives without retraining.
• A/B: a large-scale experiment at the scale of ~1 million users × 600,000 playlists.
• Result: on the auxiliary stream-share metric, SPDD reached +5.44% (vs. control) and fixed-weight reached +3.60%, a gap of about 1.8 pp. It achieved this without reducing user consumption, and the increase in skip rate was also smaller.

Spotify defines a "generative recommender" as an autoregressive system. It picks one item at a time, and that choice affects the scores of later positions, which captures sequential dependency.

SPDD creates a new role: a multi-objective controller that intervenes only at decoding time. So far the debate over SID (semantic ID) and the LLM family has centered on two things:

• architecture: HSTU (the lineage of Meta's organic-side sequence model) vs. Transformer vs. combining SID with CoT
• training objective: next-token vs. contrastive vs. distillation

SPDD adds empirical support in a further direction: a serving-side decoding policy can adjust auxiliary objectives without increasing computation. Kuaishou's PushDualGen went toward a structure using SID and a skippable copy to avoid serving cost, whereas SPDD is an alternative angle that leaves the serving model as it is and changes only the decoding policy.

↑ Contents

Corrections

None. All three sources are consistent with the existing radar threads and extend them.

↑ Contents

Radar

Today's Monday industry blog scan found these four, which earlier batches missed. All are added to the new this month section of radar.md.

• Pinterest CLR (Scaling Conditional Learned Retrieval for Pinterest Home Feed, 2026-08-26): Unified the conditioning framework for Home Feed retrieval. In production, p90 latency fell from 80ms to 12ms.
• LinkedIn Follows LLM (Rebuilding LinkedIn's Follows Recommendations, 2026-08-24): Deployed a bi-encoder LLM EBR on two surfaces, MyNetwork and Home Feed.
• Spotify GLIDE (From Models to Products: LLMs for Recommendation at Spotify Scale, 2026-08-03): Deployed a candidate generator based on a 1B LLM and Semantic ID to the Spotify Home podcast surface. The A/B ran for 21 days at a scale of 20M impressions, and non-habitual listening was +5.4%.
• Spotify SPDD (Balancing Multiple Objectives in Generative Recommendations with Adaptive Decoding, 2026-08-07): Inference-time multi-objective decoding on top of SASRec. In the 1 million-user A/B, aux stream-share was +5.44% and fixed-weight was +3.60%.

The arXiv cs.IR triage parsed 30 papers, and 0 passed. None had a production deployment or A/B claim. Most fall into the two groups below.

• Offline benchmark studies by authors at academic institutions: 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, and others
• Domain-restricted studies: POI, legal, medical, baseball, music, finance QA, essay grading, RAG, private retrieval

↑ Contents

What to check next

↑ Contents