Recommenders and Embeddings — Same Math as RAG, Different Goal

What sits behind "recommended for you" is very nearly the same math as RAG's vector search. A from-zero tour: matrix factorization, two-tower models, and how the ANN stack is reused — plus why the evaluation and the failure modes end up completely different.

BPR: Bayesian Personalized Ranking from Implicit Feedback

Who actually picks your recommendations

Picture the secondhand bookshop you keep going back to. The owner pulls something off the shelf and says, "You'll probably like this." They haven't read the book. What they've read is not the contents but what other customers with shelves like yours went home with.

That is exactly the idea behind collaborative filtering. You can infer taste from overlapping behaviour alone, without understanding any content at all. "Customers who bought this item also bought" is that sentence written out in plain English.

The opposite approach is content-based filtering, which actually reads the blurb and the genre to find similar things. RAG's document retrieval sits squarely on that side. Modern recommenders blend both inside the same equation, and what comes out is exactly the kind of meaning-bearing array of numbers covered in Embeddings from Scratch. If you've built a RAG system, you already know half of how a recommender works.

Intuition: filling in an enormous sparse table

Put users on the rows and items on the columns. The cells can hold ratings or just a clicked/not-clicked flag. A real service has millions of rows by millions of columns, and since any one person touches a tiny slice of the catalogue, almost every cell is empty. Predicting those empty cells is what recommendation means.

Why is prediction possible at all? If the table were random numbers, it wouldn't be. It works because a few dozen tendencies — "people who like sci-fi buy sci-fi" — already explain most of the cells. In mathematical terms, the table is low rank: it can be approximated by a tall matrix times a wide one.

Here $\hat{r}_{ui}$ is the predicted affinity of user $u$ for item $i$, $\mathbf{p}_u$ is a list of $d$ numbers describing that user's taste, and $\mathbf{q}_i$ is a list of $d$ numbers describing that item's character. The whole formula says: for each of $d$ hidden axes, multiply "how much this person wants it" by "how much this work has it," and add everything up. Said in words: $\hat{r}_{ui}$ is a single running total — walk down the person's taste list and the item's trait list side by side, and add a point wherever the two agree.

The crucial part is that nobody decides what the axes mean. No one defines a "sci-fi score." Run training so the fill-in error shrinks and the axes appear on their own — the same story as Singular value decomposition and low-rank approximation. And as a by-product, users and items become points in the same $d$-dimensional space. People and things land on one map. That is what an embedding is in a recommender.

Where plain matrix factorization loses to reality

This form was the star of the Netflix Prize era, but it will not carry a modern service as-is. There are three holes.

Cold start. A user who just signed up has an entirely empty row, so there is no material to learn $\mathbf{p}_u$ from. A title released yesterday has an empty column. And new titles are precisely the ones you most want to surface.

No door for features. The formula sees IDs and nothing else. Age, device, time of day, the item's own title text — none of them have anywhere to enter.

There are no five-star ratings. Very few people diligently leave stars; what actually accumulates is clicks, plays and purchases, i.e. implicit feedback. And it contains positives only. Whether a non-click meant "dislike" or "never appeared on screen" is something the logs simply do not distinguish.

How you handle that third one is where recommender systems break most often.

Implicit feedback, and how to manufacture negatives

You cannot learn like-versus-dislike from data that contains only positives. Negatives have to be manufactured, and how you do it drives the outcome. The standard trick is in-batch negatives: reuse the positive items of the other users in the same mini-batch as your negatives. Nothing extra needs loading, which makes it the default once the catalogue is large.

The other direction is to stop trying to predict absolute scores. BPR (Bayesian Personalized Ranking) learns only the pairwise ordering "what you saw ranks above what you didn't."