Recommendation systems · An interactive essay
Reading tastes,
ranking titles.
How language models became recommenders,
and what Netflix’s GenRec changes.
A reading of GenRec, v2, by Ying Li and colleagues. Independent commentary; no affiliation with Netflix.
It is Friday evening. Last week, you watched a slow detective series. Yesterday, you abandoned an action film. Tonight, you want something short. A good recommendation has to connect those clues, decide which ones still matter, and choose from titles you can actually watch.
This is a prediction problem with a language problem inside it. Viewing history is a sequence of events; descriptions explain what those events were about. Bringing the two together is the promise of language-based recommendation.
Netflix’s GenRec makes that promise concrete: a domain-adapted language backbone, a catalog scoring head, and a single prefill pass. [2] We will unpack the mechanics with small examples, then place the system beside its closest relatives. You can read straight through or open the mathematical details as you go.
01 First, decide what the model should produce.
A recommender usually has two jobs. Retrieval finds a manageable set of plausible items. Ranking orders items for a particular request. The 2016 YouTube system described these as separate neural stages. [3] That separation is useful: searching a huge inventory and making a fine-grained choice need different budgets.
Language can enter either stage. One model might generate an item’s identifier. Another might read a description of the user and return numerical scores. Both can use Transformers. The output contract determines what happens after the input has been read.
One request, two output contracts
Consider a fictional identifier such as [12, 7, 3]. It could describe a path through a learned code space. Generating the next code depends on codes already generated. Scoring six known items, by contrast, can return six numbers together. The computational shape is different even when the starting backbone is similar.
Grounding is a separate responsibility. A score over a fixed item list refers to something in that list. A generated code still needs to resolve to an eligible item, including collision handling and availability checks. Spotify describes those steps explicitly in GLIDE’s serving pipeline. [10] Neither contract, by itself, guarantees that the choice is a good one.
02 A language model can read without writing.
When we use a chatbot, we usually see the decoder’s final act: choosing words. There is another useful output hidden underneath. Each token has a numerical representation. A pooling operation selects or combines token states into one vector for the input.
A small head can turn that vector into scores. This pattern is familiar from text classification and embedding models; vLLM exposes these as pooling tasks. [12] The language model supplies a representation. The head supplies the decision interface.
Let’s remove nearly all the complexity. Our toy user has two preferences, and each fictional title has two coordinates. We will score a title with a dot product. This is an educational construction, not the undisclosed production scoring function.
Move the user. Watch the ranking change.
Illustrative arithmetic · 6 fictional titlesThe interesting behavior is the ordering. A coordinate that matches the user contributes positively; one that points the other way can lower the score. Changing one input can move several titles at once.
The mathematics: a head, a softmax, and a ranking
For a simple dot-product head, sᵢ = h · eᵢ, where h is the user vector and eᵢ is an item vector. With six items, the matrix form is s = E h, with one item per row of E. A nonlinear head is also possible.
π = argsort(s, descending)
Softmax preserves the score ordering. Adding an item changes the denominator and all shares, even if existing scores stay fixed. So a share is relative to this catalog and this model. Calibration against an observed outcome requires a separate evaluation.
In a learned system, the hidden dimensions need not correspond to named genres. We named the toy axes to expose the calculation. These labels would be misleading on arbitrary coordinates of a real language model.
There is a practical limit here. A dense head over N items and d dimensions uses roughly N × d multiply-accumulates for this simplified calculation. Reading once does not make catalog scoring free. Inventory size, candidate selection, model size, and context length remain engineering choices.
03 Learning has two clocks.
A shared model learns relatively durable knowledge. A task model needs to keep up with changing behavior. GenRec separates these: Phase 1 develops a Netflix-aware foundation; the more frequent Phase 2 adapts it for ranking. Training includes ranking and language objectives, with reward weights applied to the ranking loss. [2]
Learn the domain
Catalog + member understanding
Learn the ranking task
Recent examples + task objectives
Why preserve language learning while teaching a ranking task? One way to think about it is as a shared workspace. If all training pressure rewards a single narrow output, useful representations for other tasks may drift. Keeping multiple objectives asks the same backbone to remain useful in more than one way. How much pressure each task receives is an empirical choice.
Where the objective enters
The paper gives a mixture L = αLranking + βLlanguage + γLmiscellaneous, with nonnegative weights summing to one. [1, §4.4] Each coefficient changes a training trade-off. It is not a percentage of requests routed to a different model.
A clean ablation holds data and compute conditions explicit while changing one ingredient. Otherwise, a better score may come from more examples, a different checkpoint, or extra training rather than the ingredient being tested.
Reward changes how loudly an example speaks.
In supervised learning, two examples can ask for the same prediction yet contribute different amounts to the update. A weight multiplies an example’s loss and gradient. That makes it possible to emphasize selected outcomes without turning inference into a deliberation loop.
Turn up one training example
Illustrative weighted cross-entropyThe model’s target probabilities stay fixed. Only the contribution to this batch loss changes.
w × −log(p). The displayed batch loss is their arithmetic mean. This demo changes neither a trained model nor a live recommendation.There is a judgment buried in the weight. “More viewing” is easy to observe; “this person is glad they came back” is harder. A proxy can be useful while still imperfect. Before celebrating a metric, ask which behavior it makes valuable, which people it overlooks, and whether the result persists beyond the evaluation window.
04 The context is part of the bill.
A history can be written many ways. Long prose may repeat facts. A compact record can preserve the same useful distinctions with fewer words. But compression can also erase a crucial clue: an abandonment, a recent change in taste, or the difference between five brief clicks and one completed watch.
On Thursday evening, the member watched Harbour Signal for forty-three minutes out of a total forty-five minutes, and then gave the episode a positive rating.
Thu: Harbour Signal, 43/45 min, liked.
Shorter is useful only when it keeps the relevant information. You would test that with held-out ranking metrics and error slices. A viewer whose preferences changed yesterday may need a different summary from one whose routine has barely changed in a year.
A smaller prompt, a smaller prefill budget
Paper anchor + simplified cost modelThe slider deliberately has no accuracy curve. Interpolating cost under a stated assumption is reasonable. Drawing an attractive quality curve without observations would manufacture evidence. A production evaluation needs both.
05 What the experiment supports.
Results are most useful when the denominator stays attached. Here is a compact ledger of the paper’s main comparison. [1, §5.1]
The online test used about 10% of traffic for four weeks on selected batch-compute surfaces. Phase-1 training is outside the 40× comparison. This does not establish a 40× total compute saving or superiority across every Netflix surface. [1]
A hypothetical baseline index of 100 becomes 100.006 under a +0.006% relative lift. That is different from +0.006 percentage points on an unspecified rate.
What is MRR, and why is an offline gain insufficient?
Mean reciprocal rank asks where a relevant target appears. Rank 1 contributes 1; rank 2 contributes 1/2; rank 10 contributes 1/10. Average across evaluation requests.
MRR rewards placing the target near the top, but it cannot describe every useful property of a recommendation list. It says little about catalog coverage, repetition, eligibility, or whether a person feels satisfied. Offline evaluation also inherits the logging policy that exposed the original items. A controlled online experiment answers a different question: what changes when people experience the new system?
A reproducible replication would need the split protocol, target construction, candidate rules, model checkpoints, uncertainty estimates, and serving conditions. Industrial papers often provide only part of that record. Keep that uncertainty attached to architectural conclusions.
06 Similar systems, different responsibilities.
The useful comparison is architectural. Which information enters the model? What is learned? What comes out? Below, select a system for its closest connection to the ideas in this article. The table remains visible so you can compare all six at once.
Six ways to turn history into a choice
Architecture comparison · not a leaderboard| System | Representation | Backbone | Serving output | Implementation evidence |
|---|---|---|---|---|
| Item-ID history | Task-specific causal attention | Next-item scores | Author code · older TF stack [13] | |
| Learned semantic codes | Sequence-to-sequence Transformer | Autoregressive item codes | External reproduction · disclosed differences [14] | |
| SID-v2 + domain sequences | Adapted pretrained LLM | Generated semantic IDs | Industrial paper [8] | |
| Recent IDs + user soft prompt | Instruction-following LLM | Episode IDs via beam search | Paper + Spotify account [9] [10] | |
| Aligned item tokens + text | Qwen3-based reasoning model | Reasoning + item prediction | Author benchmark code [15] | |
| Verbalized context | Netflix-adapted LLM | Catalog scores; prefill only | Industrial paper + Netflix account [1] [2] |
Three distinctions matter. First, semantic IDs are a representation choice. TIGER learns codes from item content and predicts those codes from a session. [7] PLUM combines enhanced item tokenization, continued pretraining, and task fine-tuning to adapt an existing LLM. [8] Sharing an identifier scheme does not make the backbones equivalent.
Second, personalization need not all be text. GLIDE inserts long-term user embeddings as soft prompts alongside recent history. It makes discovery an explicit objective. [9] That suggests a useful design question: which history should be serialized, and which state is better represented compactly?
Third, reasoning introduces another budget. OneRec-Think trains explicit reasoning with item alignment and recommendation-specific rewards; its industrial deployment uses a Think-Ahead architecture. [11] If you need an explanation, ask whether generating it improves the decision or merely adds a plausible account after the fact.
Where to start if you want to implement these ideas
For a sequence baseline: the SASRec authors provide code and preprocessed data. Their original environment is TensorFlow 1.12 and Python 2, so expect modernization work or inspect a linked port. [13]
For semantic-ID retrieval: the linked TIGER reproduction exposes RQ-VAE codes and training scripts. Its README reports a smaller parameter count and a different content-embedding model from the paper. Treat it as an external implementation, not a verified exact reproduction. [14]
For explicit reasoning: OneRec-Think’s repository includes model setup, vocabulary expansion, data, training, and test directories, using Qwen3-1.7B for its public path. This is evidence for a buildable benchmark workflow, not a copy of Kuaishou’s full serving stack. [15]
For a reading-and-scoring prototype: use an open backbone, a chosen pooling rule, and a small catalog head. vLLM’s pooling interfaces are a relevant serving primitive. A custom head still needs compatible model registration and validation; a generic scoring API is not a GenRec implementation. [12]
Whichever path you choose, begin with chronological data splits and a strong baseline. Report ranking quality, coverage, freshness, eligibility failures, and cost under a declared workload. The browser models above demonstrate mechanics; they do not constitute a reproduction or benchmark.
07 The field grew branches.
It is tempting to draw recommender history as a straight upgrade path. The research is more interesting than that. One branch learns sequences of discrete items. Another changes the item representation. A third brings language pretraining and explicit intent into personalization. Today’s systems combine these choices in different ways.
From latent tastes to language interfaces
Selected milestones · 2009–2026SASRec made self-attention useful for sequential recommendation; BERT4Rec trained bidirectional sequence representations by masking items. [4] [5] Their lesson is about learning from behavior order. A Transformer is already useful here without becoming a general-purpose language model.
P5 framed several recommendation tasks through personalized prompts and text-to-text learning. [6] TIGER then made the identity of an item into something a model could generate. More recent industrial work adds domain adaptation, discovery objectives, preference alignment, or reasoning. There is no single mandatory combination.
My reading of this lineage is that three questions have become increasingly separable: How do we represent behavior? What knowledge does the backbone bring? What output can we afford to serve? Treating those as independent decisions makes the field easier to navigate. It also gives you a better way to evaluate the next paper than simply asking whether it uses an LLM.
08 What I would test next.
For a practical experiment, I would begin with a small, observable task: rank a fixed eligible catalog from a recent history. Keep the dataset and evaluation protocol identical across an item-sequence baseline, a text encoder with a scoring head, and a semantic-ID generator. Measure both training and serving cost.
Then remove information deliberately. Drop titles but keep IDs. Drop IDs but keep descriptions. Shorten history. Change the freshness window. Those interventions reveal where a language representation helps and where behavior alone already carries the signal.
The most revealing failures may be ordinary ones: a stale preference, a new title with little exposure, a household with mixed tastes, or an excellent item that never appeared in the logs. Those cases tell us whether the model has learned a useful representation of a person’s needs, or a convincing account of the data it was shown.
GenRec gives us a concrete reason to investigate a reading-and-scoring design. The larger research opportunity is to learn when each output contract earns its cost, and to make that evidence visible.
Sources & implementation notes
Primary papers, author repositories, and official engineering accounts. Checked 2 October 2026. Numbers from GenRec use the requested v2; all browser examples use invented data.
- Li et al. GenRec: An LLM-Backed Recommendation Ranker at Netflix. v2, 21 August 2026. Main paper; §§4–5 for architecture and evidence.
- Netflix. GenRec: Towards LLM-Native Recommendation at Netflix. 30 July 2026. Engineering account.
- Covington, Adams & Sargin. Deep Neural Networks for YouTube Recommendations. RecSys 2016.
- Kang & McAuley. Self-Attentive Sequential Recommendation. 2018.
- Sun et al. BERT4Rec. 2019.
- Geng et al. Recommendation as Language Processing (P5). 2022. Author repository.
- Rajput et al. Recommender Systems with Generative Retrieval (TIGER). 2023.
- He et al. PLUM. October 2025 preprint; WWW 2026 publication.
- D’Amico et al. Deploying Semantic ID-based Generative Retrieval for Large-Scale Podcast Discovery at Spotify (GLIDE). March 2026.
- Spotify Research. From Models to Products: LLMs for Recommendation at Spotify Scale. August 2026.
- Liu et al. OneRec-Think: In-Text Reasoning for Generative Recommendation. October 2025.
- vLLM. Pooling models. Serving primitive; not a released GenRec model.
- SASRec author implementation. Original TensorFlow environment; linked ports are separate implementations.
- TIGER external PyTorch reproduction. README documents implementation differences.
- OneRec-Think author repository. Public benchmark model setup, training, and evaluation.
- Koren, Bell & Volinsky. Matrix Factorization Techniques for Recommender Systems. Computer, 2009. Historical overview, not the invention date.
- Deng et al. OneRec: Unifying Retrieve and Rank with Generative Recommender and Iterative Preference Alignment. February 2025.