Back office ops · Production

Engineering LinkedIn's Next-Generation Feed with LLMs and Transformer Models

The problem

LinkedIn's Feed relied on a heterogeneous retrieval architecture with multiple separate sources—trending content, collaborative filtering, and embedding-based systems—each with its own infrastructure, creating engineering complexity and preventing holistic optimization. The traditional ranking model evaluated each impression independently, missing sequential patterns in how professionals consume content over time.

First attempt

Passing raw numerical engagement counts as unprocessed text tokens resulted in near-zero correlation (-0.004) between item popularity and embedding similarity, degrading retrieval quality. Including all impressed posts—both engaged and scrolled-past—in training histories hurt model performance and inflated GPU compute costs.

Workflow diagram · grounded in source
1
Member opens Feed
trigger
“Every time you open LinkedIn and scroll through your Feed, you're experiencing one of the largest-scale recommendation systems in the industry.”
2
Prompt generation from structured data
ai_action
“We built a "prompt library" that transforms features into templated sequences. For posts, we include format, author information (name, headline, company, industry), engagement counts, article metadata, and post text. For members, we inco…”
3
LLM dual-encoder embedding generation
ai_action
“We distilled and fine-tuned a LLM using millions of member-to-item pairs from Feed engagement data. The dual encoder architecture uses a LLM to process both the member and item prompts, and in return it generates embeddings that are comp…”
4
k-NN retrieval from embedding index
ai_action
“When you open your Feed, we fetch your member embedding and run k-nearest-neighbor search against this index, retrieving the top candidates in sub-50ms despite the index containing millions of posts.”
5
Sequential ranking with Generative Recommender
ai_action
“we built a Generative Recommender (GR) model for LinkedIn's Feed that reimagines ranking by treating your feed interaction history as a sequence - a professional story told through the posts you've engaged with over time. Instead of scor…”
6
Personalized Feed delivered
output
“delivering a smarter, faster, more responsive Feed without you ever noticing the complexity underneath”
Reported outcome

Percentile-bucketed feature encoding improved recall@10 by 15%.
Adding two hard negatives per member improved recall by a further 3.6%. Positives-only training reduced per-sequence memory footprint by 37% and enabled 2.6× faster training iteration. A custom Flash Attention variant delivered an additional 2× serving speedup, with the full system achieving sub-50ms retrieval latency across millions of posts.

Reported metrics
Recall@10 improvement from percentile feature encoding15%
Popularity-embedding correlation jump from percentile encoding30x
Recall improvement from 1 hard negative per member+2.0%
Recall improvement from 2 hard negatives per member+3.6%
Show all 11 reported metrics
recall@10 improvement from percentile feature encoding15%
popularity-embedding correlation jump from percentile encoding30x
recall improvement from 1 hard negative per member+2.0%
recall improvement from 2 hard negatives per member+3.6%
per-sequence memory footprint reduction (positives-only training)37%
training sequences per batch increase (positives-only)40%
training iteration speed improvement (positives-only)2.6×
inference speedup from GRMIS Flash Attention variant2×
Feed retrieval latencysub-50ms
baseline popularity-embedding correlation before fix-0.004
professionals served by Feedmore than 1.3 billion
Reported stack
LLMGPUsH100PyTorchMMoEDCNv2GRMISInfoNCE
Source
https://www.linkedin.com/blog/engineering/feed/engineering-the-next-generation-of-linkedins-feed?utm_source=substack&utm_medium=email
Read source ↗

Frequently asked questions

What did this team achieve with this AI workflow?

Percentile-bucketed feature encoding improved recall@10 by 15%.

What tools did this team use?

LLM, GPUs, H100, PyTorch, MMoE, DCNv2, GRMIS, InfoNCE.

What results were reported?

Recall@10 improvement from percentile feature encoding: 15%; Popularity-embedding correlation jump from percentile encoding: 30x; Recall improvement from 1 hard negative per member: +2.0%; Recall improvement from 2 hard negatives per member: +3.6% (source-reported, not independently verified).

What failed first in this deployment?

Passing raw numerical engagement counts as unprocessed text tokens resulted in near-zero correlation (-0.004) between item popularity and embedding similarity, degrading retrieval quality.

How is this back office ops AI workflow structured?

Member opens Feed → Prompt generation from structured data → LLM dual-encoder embedding generation → k-NN retrieval from embedding index → Sequential ranking with Generative Recommender → Personalized Feed delivered.

Related back office ops cases