Foundations & Concepts

Every large online service faces the same awkward problem: it holds far more things than any one person could ever look at. A Recommendation System is the machinery that resolves this mismatch, choosing — for each individual, at each moment — the small handful of things most worth their attention. It is less a single algorithm than a way of organising a service around the person using it.

The idea that makes this worth doing is Personalisation: the same shelf, arranged differently for different people. Two visitors open the same page a second apart and see different things, because the system has inferred something different about each of them. This is what separates a recommender from a bestseller list, which shows everyone the same ranking and is right only for the average person, who does not exist.

Where and how suggestions appear is the Recommendation Scenario, and it shapes everything downstream. A home feed that must fill a screen from nothing, a strip of alternatives beside something already chosen, and a weekly email digest are three different problems wearing the same name: they differ in how much is known at the moment of asking, how many slots must be filled, and how quickly an answer is needed.

Two actors appear in every scenario. The User (RecSys) is whoever the recommendation is for — a person, an account, sometimes just an anonymous session. The Item is whatever is being recommended: a film, a song, a product, an article, another person to follow. The full inventory available to choose from is the Catalog, and its size is the reason the problem is hard — catalogs of millions are routine, and the screen has room for five.

What links the two sides is the User-Item Interaction: a record that this person did something with that thing. Interactions come in two flavours. Explicit Feedback is a deliberate verdict — a five-star rating, a thumbs-down, a written review. It is precise about opinion, but people rarely bother to give it, so it is scarce and skewed towards strong feelings. Implicit Feedback is everything someone does without meaning to express an opinion: a click, a play, a purchase, time spent on a page. It is abundant and honest about behaviour, but ambiguous — a film watched to the end may still have disappointed, and one never watched may simply never have been noticed. Crucially, the absence of an interaction is not a negative verdict, and treating it as one is a classic beginner's mistake.

Collect every interaction and the result is the User-Item Matrix: rows for people, columns for things, each filled cell a rating or an observed event. This table is the central object of the whole field, and its defining property is emptiness. A typical service observes a tiny fraction of one percent of all possible pairs, so nearly every technique that follows is, at bottom, a disciplined way of reasoning about the cells nobody has filled in.

The quantity all of this chases is Relevance (RecSys) — how well something matches what this particular person wants right now. Relevance is not a property of an item on its own; it depends on who is asking, when, and in which scenario. That is why a universally admired item can still be the wrong recommendation, and why a system cannot be judged by the average quality of what it shows.

The distinction matters most at the edges of the catalog. Attention concentrates on a few blockbusters, while the overwhelming majority of entries each attract very little — the Long Tail. Added together, though, those rarely-touched entries account for an enormous share of what people genuinely enjoy, and they are exactly the things nobody stumbles upon unaided. Surfacing the tail without abandoning the dependable head is one of the standing tensions of the field, and much of what follows is an attempt to manage it.

Problem Formulations

Before choosing a technique, a team has to settle a more basic question: what exactly is the system being asked to compute? The same pile of interaction data can be turned into several quite different problems, and the choice decides what the model optimises, how it is judged, and what it is allowed to cost at serving time. Much confusion in this field comes from comparing systems that were never answering the same question.

The oldest formulation is Rating Prediction: given a person and something they have not yet judged, estimate the score they would give it. It is appealing because it turns recommendation into ordinary supervised regression with an obvious error measure. Its mathematical statement is Matrix Completion — the table of known scores is almost entirely blank, and the task is to reconstruct the blanks from the few entries that exist, on the assumption that the completed table has a simple underlying structure rather than being arbitrary.

In practice, though, nobody consumes a predicted score. People consume a list, and that is the Top-N Recommendation formulation: out of the whole inventory, return the N things this person is most likely to want, in order. The shift is larger than it looks. Accuracy on the millions of entries a person will never see stops mattering, and everything rests on what lands in the handful of visible slots. A model that gets every individual score slightly wrong but orders the top few correctly beats one with the opposite behaviour, so the two formulations can rank the same pair of systems in opposite ways.

Push the idea further and the unit of output stops being a single entry. Slate Recommendation treats the whole set presented together — a row, a page, a playlist — as the thing being chosen. Entries on a slate compete for the same attention and can complement or duplicate one another, so the best slate is usually not the best few picked independently: five near-identical suggestions make a worse page than five good and varied ones, even though each was individually stronger.

When the order of someone's history carries the signal, the problem becomes Next-Item Prediction: given what this person has just done, in sequence, what comes next? Recency dominates here, intent can change within minutes, and a history flattened into an unordered bag of past choices throws away the most informative thing about it.

Two final framings describe not what is predicted but how an answer can be produced at scale. Recommendation as Retrieval poses a search-style question: out of millions, fetch a few hundred plausible candidates, very fast, with completeness as the priority — it is tolerable to let mediocre candidates through, fatal to miss the best one. Recommendation as Ranking then poses the precision question: given a manageable shortlist, order it as carefully as possible, using a model far too expensive to have been run over the entire catalog. Most modern systems are both at once, and holding the two apart is what makes a recommender buildable at all.

Collaborative Filtering

Collaborative filtering rests on one surprisingly powerful observation: you do not need to understand a thing in order to recommend it. If two people have agreed about many things in the past, they will probably agree about the next one; if two things are chosen by the same people, they are probably alike in some way that matters. The only ingredient is the record of who interacted with what — no descriptions, no genres, no editorial knowledge. That is why the approach transfers unchanged from films to groceries to job adverts, and why it was the first family of methods to work convincingly at scale.

The family divides by where the work happens. Memory-Based CF keeps the raw history and computes recommendations directly from it at request time, comparing rows or columns of the table on demand. Nothing is learned in advance, so a new interaction counts immediately and every suggestion can be traced to the specific neighbours that produced it. The price is paid at serving time, and it grows with the data. Model-Based CF instead compresses the history into a trained model — a set of parameters far smaller than the data — and scores from that. Training is an offline cost, predictions are cheap and generalise better where evidence is thin, but fresh behaviour only counts after the next training run.

Almost all memory-based work follows the Neighborhood Method: to guess how someone feels about something, find the most similar rows (or columns) available, then combine their known opinions into a weighted average in which closer neighbours count for more. The idea is intuitive, needs little tuning, and explains itself to a reader in one sentence — a genuine advantage when a product has to justify what it shows.

Its weak point is the quality of the similarity numbers themselves. Two people who have each rated only two things, identically, look like perfect twins; the measurement simply rests on too little evidence. Significance Weighting corrects this by shrinking a similarity score towards zero when it was computed from few shared observations, so that moderate agreement measured over a hundred items outranks perfect agreement measured over two. It is a small adjustment that keeps neighbourhood methods honest on sparse data.

User-Based CF

The original form of the idea works along the rows of the table. User-User CF recommends the things that people resembling you have enjoyed and you have not yet tried — a mechanical version of asking friends whose taste you trust.

Everything then depends on User Similarity, a number measuring how alike two histories are across the entries both people have touched. Raw agreement is a poor measure, because people use scales differently: a generous rater who never drops below four stars and a severe one who reserves five for a dozen favourites may have identical preferences and utterly different numbers. Centered Cosine Similarity removes that distortion by subtracting each person's own average before comparing, so what is compared is the shape of a taste — what someone liked more than their personal normal — rather than the absolute scores. Agreeing deviations become positive similarity, opposing ones negative, and habitual generosity stops masquerading as enthusiasm.

Comparing against everybody is both wasteful and noisy, so a system keeps only the k-Nearest Users — the k most similar people — and discards the long tail of weak, largely accidental resemblances. That retained set is the User Neighborhood, and the prediction is a similarity-weighted blend of its members' opinions. Choosing k is the familiar trade-off: too small and one eccentric neighbour dominates; too large and the answer drifts back towards the crowd average, which is personalised to nobody.

Item-Based CF

The same arithmetic applied to the columns of the table turns out to work considerably better in practice. Item-Item CF begins from the things a person has already chosen and recommends what is most often chosen alongside them, instead of hunting for people like them.

Item Similarity compares two columns over the people who appear in both: entries chosen by overlapping audiences score highly. The distortion worth removing here is still a per-person one, since the same raters contribute to both columns — Adjusted Cosine Similarity therefore subtracts each individual's mean from their own entries before the columns are compared, correcting for rating style while measuring a relationship between two things rather than between two people.

As before, only the k-Nearest Items are kept for each entry in the catalog, forming an Item Neighborhood: a compact, precomputed table of look-alikes. This is the practical advantage that made the item-based form the production default for years. Taste shifts constantly, so resemblances between people go stale quickly, whereas the relationship between two catalog entries is comparatively stable and can be refreshed on a nightly schedule. Serving then costs little more than a lookup for each thing in a person's recent history, and the explanation almost writes itself — "because you watched this" is a reason readers accept.

Matrix Factorization

Neighbourhood methods compare observed rows and columns directly, which makes them transparent but leaves them helpless exactly where the table is blank — and the table is almost entirely blank. Matrix factorization takes a different route. It assumes the vast, sparse record of interactions is the visible shadow of something much smaller: a few dozen hidden dimensions along which both people and catalog entries can be positioned. Learn those coordinates and any empty cell can be filled by simple arithmetic, whether or not anybody has rated anything nearby. Popularised during the Netflix Prize, the idea remains the backbone of recommendation and the direct ancestor of the neural models that followed.

Latent Factor Models

Each hidden dimension is a Latent Factor: a direction discovered from behaviour rather than specified by anyone. A given direction may loosely correspond to something nameable — how light-hearted a film is, how mainstream a song — but nothing forces that, and most have no tidy verbal label. What matters is that one and the same axis is meaningful for both sides of the table.

A person is then described by a User Factor vector recording how strongly they are drawn to each direction, and a catalog entry by an Item Factor vector recording how strongly it expresses each one. A predicted preference is the dot product of the two: large when appetite and expression point the same way, small when they do not, negative when they oppose. Dozens of numbers per side stand in for millions of raw cells, and taste becomes geometry.

Such a vector is an Embedding (RecSys) — a dense, low-dimensional representation learned so that proximity means similarity. Because both sides are embedded in one shared space, distance is meaningful within a side and across it: neighbouring entries are alike, and the entries nearest a person are the ones to recommend. This single notion carries forward unchanged into the deep and graph-based models that came later, where the embedding stops being the whole model and becomes its first layer.

Factorization Algorithms

The practical question is how to find those vectors. The classical inspiration is SVD for Recommendation, which borrows the singular value decomposition of linear algebra to split a matrix into low-rank parts. Textbook decomposition, however, demands a complete matrix, and this one is mostly holes; filling them with zeros or averages both invents data that was never observed and makes the computation enormous.

The fix that changed the field was Funk SVD, which keeps the low-rank idea and abandons the decomposition. It treats the factors as free parameters, measures error only on cells that actually contain an observation, and walks downhill by gradient descent, nudging one person's vector and one entry's vector slightly on every observed rating. Missing cells never enter the loss at all, which is both far cheaper and more honest about what is known.

A second route exploits a convenient structure in the objective: hold one side fixed and solving for the other is an ordinary least-squares problem. Alternating Least Squares (ALS) alternates those two exact steps until the parameters settle. Each half has a closed-form solution and every person can be solved independently of every other, which makes the method trivially parallel and the natural choice on cluster-scale data.

Plain alternation assumes every cell deserves equal weight, which breaks down when the only signal is behaviour. Weighted ALS attaches a confidence to each cell instead: observed events are trusted in proportion to how often they happened, while the enormous unobserved remainder is kept in the loss as a weak, low-confidence hint of disinterest rather than as either a firm rejection or a blank. The full matrix then participates without the emptiness overwhelming the handful of positives.

A different constraint produces a different flavour of model. Non-Negative Matrix Factorization (RecSys) forbids negative values in the factors, so a predicted preference can only be built by accumulating evidence, never by cancelling it. The resulting dimensions behave like additive parts — tastes a person possesses some amount of — which makes them markedly easier to interpret, at some cost in raw accuracy.

Implicit MF is the name for this whole adaptation: factorizing a table of clicks, plays and purchases rather than stars, where no explicit rejection is ever recorded and the model must learn from the contrast between the little that happened and the overwhelming mass of what did not.

If the end product is an ordered list, it is more direct to optimise order itself. Bayesian Personalized Ranking (BPR) does precisely that, training on triples — a person, something they engaged with, something they did not — and pushing the score of the first above the score of the second. It never attempts an absolute value, only the correct relative order within each pair, which is exactly what a short list needs and nothing more.

Factorization also generalises beyond the two-column world. A Factorization Machine (FM) gives every input feature its own vector — not just the person and the entry, but the day of the week, the device, the genre — and models the effect of any pair of features as the dot product of their two vectors. Because the strength of a combination is assembled from the two sides separately, the model can estimate combinations it has barely witnessed, which a model holding one independent weight per combination can never do. A Field-Aware Factorization Machine (FFM) refines this by letting a feature behave differently according to what kind of feature it is paired with: one vector per feature becomes one vector per field it meets, spending memory to buy accuracy on the wide categorical data typical of advertising.

Bias Terms & Regularization

Factor vectors should not have to explain everything, and a few plain corrections do much of the work before any interaction is modelled at all. The first is the Global Mean (RecSys), the average score across the entire dataset — a baseline that already beats guessing and against which every other component is measured.

On top of it sit two offsets. User Bias is one number per person capturing a habitual tendency to rate above or below that average, and Item Bias is one number per catalog entry capturing broad appeal or quality regardless of who is judging. A prediction becomes the global average plus both offsets plus the factor interaction, and these three scalar pieces typically account for a large share of the explainable variation. Omitting them forces the latent dimensions to squander capacity rediscovering "this person is generous" and "this film is widely admired" instead of learning anything about taste.

The remaining danger is memorisation. With thousands of free parameters and people who have rated five things, a model can fit its training data perfectly and predict nothing. MF Regularization penalises the magnitude of the factors and offsets, pulling thinly-observed people and entries back towards zero — which is to say, back towards the safe baseline — while leaving well-evidenced ones free to move. It is the single setting that most often separates a factorization that works from one that does not.

Content-Based Filtering

Collaborative methods need a crowd: they work by finding agreement between people, so they say nothing useful about something nobody has touched yet, and nothing useful to somebody who has touched nothing. Content-based filtering sidesteps both gaps by asking a different question — not "who else chose this?" but "what is this thing actually like, and does it resemble what this person has liked before?" Everything it needs lives in the thing itself and in one person's own history, which makes it entirely self-sufficient.

A Content-Based Recommender is therefore built from attributes rather than co-occurrence. It can recommend a book published this morning as confidently as a classic, because its judgement rests on what the book is about rather than on how many people have bought it — and it can serve a brand-new visitor the moment they show interest in anything at all.

It begins with an Item Profile: a structured description assembled from whatever is known — title words, genre, author or brand, price band, the body of a description, the keywords an editor attached. The profile is the system's entire understanding of the thing, so its richness sets a hard ceiling on the quality of every recommendation that follows.

Mirroring it is the User Profile (Content), which is normally not asked for but inferred: the profiles of everything a person has already engaged with, averaged together and weighted by how strongly they engaged. Someone who keeps returning to long historical documentaries accumulates a profile leaning heavily in that direction without ever declaring a preference. Crucially, this profile is expressed in the same vocabulary as the things it will be compared against, which is what makes the comparison possible.

To compute with either side, it is turned into a Content Vector: a list of numbers in which each position stands for one attribute and the value records how strongly that attribute is present. Descriptive text contributes word-frequency weights; numeric fields contribute scaled values. Categorical Features (RecSys) — genre, brand, language, country — are not numbers at all and must be encoded, usually by reserving one position for every possible value and lighting only the one that applies. A handful of such fields can produce a vector thousands of positions wide and almost entirely zero, which is why representation choices matter as much here as the matching rule.

The matching rule itself is Profile Matching: score each candidate by comparing its vector with the person's, conventionally by the angle between them so that overall magnitude — a long description, a heavy user — does not dominate the comparison. Ranking by that score produces the recommendation, and because every score decomposes into the attributes that contributed, the system can state plainly why it chose what it chose.

Attributes need not come from a catalog department. Tag-Based Recommendation draws them from the audience instead, using the free-form labels people attach to things. Community tags capture qualities no official field records — that a game is relaxing, that a textbook is beginner-friendly — and they update as perception shifts. The cost is messiness: synonyms and misspellings fragment the vocabulary, popular things accumulate tags simply by being popular, and tags are open to deliberate manipulation.

The trade-off of the whole approach follows from its premise. Needing no crowd, it handles fresh catalog entries and lone users gracefully, and it explains itself readily. But it can only perceive what the attributes describe — a quality nobody wrote down is invisible to it — and because it rewards resemblance to a person's past, it tends to narrow over time, recommending more of the same and rarely producing the pleasant surprise that comes from other people's unexpected overlaps.

Context-Aware Recommendation

A recommender that knows only who you are and what you enjoyed before is still missing something obvious: the situation you are in right now. The same person wants a quick breakfast recipe on a Tuesday morning and a long film on a Saturday night; a playlist that is perfect for a gym session is wrong for a dinner with friends. Context-Aware Recommendation takes that surrounding situation seriously and treats it as a first-class input rather than as noise. Instead of asking only what this person tends to like, it asks what this person tends to like here and now — at this hour, in this place, on this device, in this company, in this mood.

Technically, the context is recorded as one or more extra labels attached to every logged interaction, so the familiar pair of a person and a thing becomes a triple of person, thing and situation. Once the data has that shape, there are three classic ways to make use of it, and they differ mainly in where the situation enters the pipeline: at the front, at the back, or inside the model.

Contextual Pre-Filtering puts the situation at the front. Before anything is learned or scored, the system keeps only the past interactions that happened in a matching situation, and then runs an ordinary, context-blind recommender on that narrowed slice: to recommend for a weekend evening, learn from weekend evenings. Its great strength is reuse — any existing method works unchanged, because all the context did was choose the training data. Its weakness is arithmetic: every slice is smaller than the whole, so a narrowly defined situation can leave too few examples to learn anything stable from. The usual remedy is to relax the match, generalising "Saturday 9 p.m." to "weekend evening" and, if that is still too thin, to "weekend", trading precision of the situation for weight of evidence.

Contextual Post-Filtering puts the situation at the back. A context-blind model produces its usual ranked list, and only then is the situation used to adjust that list — dropping suggestions that plainly do not fit the moment, or lifting the ones that fit it unusually well. Because the underlying model is never touched, this is the cheapest way to make a running system situation-aware, and the adjustment rules can be rewritten or re-tuned without retraining anything. The limit is equally clear: the model can only re-order what it already proposed, so anything suited to the moment but absent from the original list stays invisible.

Contextual Modeling is the most ambitious of the three, putting the situation inside the model. Context becomes part of what is learned, jointly with everything else, so the model can capture the fact that a certain kind of thing suits a certain kind of moment. Nothing is thrown away as in pre-filtering and nothing is patched afterwards as in post-filtering; one model is trained on all the data and reasons about people, things and situations together.

The natural machinery for that joint view is Tensor Factorization. If the interactions of a plain recommender form a two-dimensional grid — people down one side, things along the other — then adding context adds a third axis, one slab of that grid per situation, so the data becomes a cube instead of a table. Factorization extends to the cube almost unchanged: each person, each thing and each context value is given its own short vector of learned features, and a prediction is produced by combining all three. The real pay-off is sharing. Situations that behave alike end up with similar vectors, so evidence collected in one of them informs predictions in the others, which is precisely what the thin-slice problem of pre-filtering could not do.

By far the most useful context is time, and it is important enough to carry a name of its own. Time-Aware Recommendation treats when something happened as information rather than as an accident of logging. That covers the repeating cycles a pre-filter can exploit — breakfast against dinner, weekday against weekend, December against July — and also drift, the slower fact that tastes move, things age, and a preference expressed three years ago deserves less weight than one expressed last week. Order matters as well: the most recent actions are usually the sharpest clue about what someone wants next, so recency is used both as a decay on old evidence and as a signal in its own right.

Seen together, the three designs are less rivals than a ladder. Post-filtering is the quickest way to make an existing system aware of the moment; pre-filtering suits a small number of coarse situations each with plenty of history; and a jointly trained model with a factorized representation of context earns its extra cost once situations become many, fine-grained and sparsely observed — which, with time included, is almost always what eventually happens.

Hybrid Approaches

Every family of recommenders is strong somewhere and blind somewhere else. One kind learns from the behaviour of similar people and so has nothing to say about something nobody has touched yet; another reads the properties of things and so keeps offering more of the same; a third needs a long history before it will say anything at all. The obvious move is not to pick a winner but to combine, and that is what a Hybrid Recommender does: it runs, blends or chains two or more strategies so that the strengths of one cover the weaknesses of another. In real products hybrids are the norm rather than the exception, and the interesting design question is not whether to build one but where to put the seam between the parts. The seven patterns below are essentially seven answers to that question, ordered from the loosest coupling to the tightest.

The loosest seam is arithmetic. A Weighted Hybrid asks every component to score the same candidates and merges those scores into a single number, typically a weighted sum. It is easy to build and easy to reason about: each component keeps its own implementation, and the weights express how much the system currently trusts each one. Those weights need not be fixed — a sensible system starts out leaning on whichever component works with little evidence and shifts weight towards the behaviour-driven component as a person's history accumulates. The catch is that scores from different methods are not naturally on the same scale, so they have to be made comparable before they can be added at all.

A Switching Hybrid avoids that problem by choosing instead of blending. A decision rule inspects the case at hand and hands it to exactly one component: if there is enough history to be confident, use the method that exploits history; if there is not, fall back to one that does not need it. Only one set of scores is ever produced, so nothing needs rescaling, and each component is used only where it is known to be reliable. The cost moves into the rule itself, which must be designed and tuned, and the switch can be felt by the reader as an abrupt change in the character of what is suggested.

A Mixed Hybrid declines to reconcile the components at all and instead shows them side by side, each owning its own slot on the page: a row of things similar to what you just finished, next to a row of what is popular around you, next to a row of new arrivals. Nothing has to be made comparable, every component keeps its own voice, and the variety is visible rather than averaged away. The price is screen space and the risk of overlap, since two components may well propose the same thing in different rows.

The remaining patterns tighten the seam by merging inside the machinery rather than at the output. A Feature Combination Hybrid stops treating the second strategy as a separate recommender and reduces it to extra input: signals that one approach would have used on its own — properties of a thing, attributes of a person — are simply handed to a single model as additional features alongside the interaction data. There is then only one model to train, serve and debug, and it can learn for itself how much each kind of signal is worth instead of being told by a weight.

A Cascade Hybrid arranges the components in strict precedence. The first produces a coarse ordering, and the next is allowed only to refine it — to break ties and separate candidates the first could not distinguish — without ever overturning its ranking. This suits the common situation where one signal is clearly more trustworthy than another: the weaker signal is given a job small enough that it can help without doing harm. It also saves work, since each later stage sees fewer candidates than the one before it.

A Meta-Level Hybrid is the tightest coupling of all: one component's learned model, not its output, becomes the input of the next. The first technique digests the raw evidence into a compact representation — profiles, clusters, learned vectors — and the second treats that representation as its data, never seeing the original interactions. Because the hand-off is a model rather than a list of scores, the second component inherits whatever structure the first discovered, which can help considerably when the raw data is thin; the dependency is also total, since the second component is only as good as the representation it was given.

One component appears in hybrids far more often than it ever appears alone: Demographic Filtering, which groups people by attributes such as age bracket, language, country or stated interests and recommends what the group as a whole tends to like. On its own it is crude, offering everyone in a bracket much the same thing and ignoring how people differ inside it. Its virtue is availability — those attributes exist from the first moment someone arrives, before they have clicked on anything — which makes it the ideal partner in a hybrid: the component a switching design falls back on, or that a weighted design leans on heavily at first and then quietly retires as genuine behaviour accumulates.

Choosing among the seven is mostly a question of how much freedom the parts should keep. Weighted, switching and mixed designs leave the components intact and combine their verdicts, which makes them quick to assemble from systems that already exist and easy to take apart again. Feature combination, cascade and meta-level designs fuse the parts into one pipeline, which usually gains accuracy and loses modularity. Demographic signals, being cheap and always present, tend to show up somewhere in all of them.

Deep Learning for RecSys

Classical recommenders score a person against a thing in a deliberately simple way: learn a short vector for each, multiply them together, and read off the result. That simplicity is a feature — it is fast and it generalises well — but it fixes in advance how the two sides may interact, and it has no room for anything beyond the identity of a person and a thing. Deep learning loosens all three limits at once. The scoring function can be learned instead of assumed; the inputs can be heterogeneous, mixing identities with properties, history and context; and the structure of the data — the order of a sequence, the shape of a graph — can be modelled directly. The five families below correspond to the five places this has mattered most: generalising the scoring function, predicting clicks from richly interacting features, retrieving candidates from a huge pool, reading behaviour as a sequence, and exploiting the graph of interactions.

Neural Collaborative Filtering

The first and most direct application asks what happens if the multiplication at the heart of a classical model is replaced by something learned. Neural Collaborative Filtering (NCF) keeps the familiar idea that every person and every thing is represented by a learned vector, but hands those vectors to a small neural network and lets it decide how they should be combined into a score. The gain is expressiveness: interactions that a fixed product cannot express — thresholds, saturations, combinations that matter only together — are now learnable from the data, and the network is trained on observed interactions in the usual way.

Within this family it helps to see two complementary halves. Generalized Matrix Factorization (GMF) is the conservative half: it keeps the element-wise product of the two vectors, which is exactly what a classical model computes, but instead of summing the resulting numbers with equal weight it lets the network learn a weight for each dimension. Classical factorization is then simply the special case where all those weights are one — hence the word generalized. The MLP Recommender is the liberal half: it concatenates the two vectors rather than multiplying them and pushes the result through several fully connected layers, imposing no multiplicative structure at all and relying on depth to discover whatever relationship exists. Each half has a characteristic failure — the first is still constrained to a product, the second can struggle to learn the simple multiplicative pattern that the first gets for free.

Neural Matrix Factorization is the standard resolution: run both halves in parallel, each with its own vectors, and join them only at the very end, where a final layer learns how much to listen to each. The result keeps the sharp, well-understood multiplicative signal and adds the flexible learned one on top, and it is the arrangement most often meant when this family is referred to as a whole.

CTR Prediction & Feature Interaction

Where the previous family starts from identities, this one starts from a flood of attributes: who, what, where, which device, which slot on the page, what was seen recently. The task is to predict the probability that a particular suggestion will actually be clicked, and the difficulty is that almost all the signal lives in combinations of attributes rather than in any single one. The models in this group are a sequence of answers to one question: how should those combinations be built?

Wide & Deep gives the classic framing by refusing to choose. It trains two parts jointly: a wide linear part fed with explicit combinations of attributes, which memorises specific co-occurrences seen often in the data, and a deep part over learned vectors, which generalises to combinations never seen. Memorisation keeps the model accurate on frequent cases, generalisation keeps it sensible on rare ones.

The wide part, however, has to be hand-built, which is the weakness DeepFM removes: it replaces the hand-written combinations with a factorization component that forms every pairwise interaction automatically, and lets that component share its vectors with the deep part so that both are learned from the same representation. Nothing has to be specified by hand, and every pair is covered.

Pairs are not always enough, and enumerating triples and quadruples explicitly is hopeless. Deep & Cross Network (DCN) addresses this with a dedicated cross component that is applied repeatedly, each application raising the degree of the interactions it represents by one, so a few layers reach higher-order combinations with very few parameters and without any enumeration. Alongside it, as in the earlier designs, sits an ordinary deep part.

Deep Learning Recommendation Model (DLRM) is less a new idea about interactions than a careful statement of the production-scale shape: a very large learned table per categorical attribute, a small network for the continuous ones, explicit pairwise interaction between the resulting vectors, and a network on top. Its significance is practical — the embedding tables dominate memory while the networks dominate computation, and that split is what makes serving at scale an engineering problem as much as a modelling one.

Deep Interest Network (DIN) adds the observation the others miss: a person's history should not be compressed into one fixed summary, because which parts of it are relevant depends on what is being scored. It therefore weights the items in the history by their relevance to the current candidate, building a different picture of the same person for each thing considered — the same reader looks like a runner when a running shoe is scored and like a novelist when a notebook is.

Embedding-Based Retrieval

The models above are too slow to apply to a whole catalogue, because each score requires running a network on a pair. Retrieval solves the complementary problem: narrowing millions of candidates to a few hundred plausible ones in a few milliseconds. The architecture that makes this possible is the Two-Tower Model, which deliberately forbids the two sides from interacting until the very last step. A User Tower turns everything known about a person — identity, attributes, recent behaviour — into a single vector, an Item Tower does the same for a thing from its identity and properties, and the score is just the product of the two vectors. Because the towers never see each other's input, every item vector can be computed in advance and only the person's vector has to be produced live.

A simpler ancestor of the item side is Item2Vec, which learns vectors for things directly from co-occurrence: treat each person's interaction history as a sentence, and train so that things appearing in the same history land close together. It needs no attributes at all and still produces a serviceable space in which nearness means consumed by the same kinds of people.

Training a retrieval model raises its own difficulty. The correct behaviour is to rank the one true item above the entire catalogue, but evaluating that comparison over millions of candidates at every step is impossible, so Sampled Softmax is used instead: compare the true item against a manageable random subset standing in for the rest, with a correction so the result still approximates the full comparison. Cheaper still is In-Batch Negative Sampling, which takes those stand-ins from the training batch itself — the other people's items are already encoded, so they are free. The subtlety is that batches are drawn from real traffic, so popular things appear as stand-ins far more often than rare ones, and the resulting bias against popularity has to be corrected explicitly.

Having vectors is only half of serving them. All item vectors are gathered into an Embedding Index, a structure built for one operation: given a query vector, return the nearest item vectors. Scanning it exhaustively would defeat the purpose, so lookups use Approximate Nearest Neighbour Retrieval, which organises the vectors — into clusters, trees or navigable graphs — so that only a small fraction need be examined. It accepts a small chance of missing a true nearest neighbour in exchange for an enormous speed-up, a trade that is almost always worth making here because the result is a candidate list that a slower, more accurate model will re-score anyway.

Sequential & Session-Based Models

All of the above still treat a person's history as a set. But behaviour has order, and order carries meaning: someone who has just looked at three cameras in a row is telling you something that the same three items scattered over a year would not. Session-Based Recommendation pushes this to its limit by assuming there is no long-term profile at all — only the current visit, perhaps from someone not signed in — so every prediction must be made from the handful of actions observed so far. The matching objective is Next-Click Prediction: given the ordered actions up to now, predict the immediate next one. It is attractive to train on because it needs no ratings and no labelling — every logged action is simultaneously a target for the actions before it and context for the actions after.

The architectures in this family are essentially four ways of reading a short ordered list. GRU4Rec reads it recurrently, consuming one action at a time while maintaining a hidden state that summarises the visit so far, which fits the streaming nature of a session naturally. Caser instead lays the vectors of the recent items out as a grid and slides filters across it, treating the recent window like a small image so that short local patterns — two or three actions that typically go together, in order — are picked up directly. SASRec replaces both with attention: when predicting the next action it lets the model weigh every earlier action by how relevant it is right now, so a decisive event ten steps back is not diluted by the noise that followed it, while still only ever looking backwards. BERT4Rec relaxes even that, training by hiding actions in the middle of a history and reconstructing them from both sides at once; the richer bidirectional view produces stronger representations, at the cost of a training objective that no longer matches prediction-time use exactly.

Graph Neural Networks

The final family changes the data structure rather than the architecture. Interactions can be read as a graph: people and things are nodes, an interaction is an edge, and the whole dataset becomes one large network connecting the two kinds of node. A GNN-Based Recommender exploits that view by passing messages along the edges — each node repeatedly updates its own vector from the vectors of its neighbours, so after one round a person is described by the things they interacted with, after two rounds by the people who interacted with those things, and so on. Relationships that a pairwise model can only infer indirectly are thus built into the representation, which is especially valuable for nodes with few edges of their own.

Neural Graph CF (NGCF) was the design that made this explicit, propagating vectors through several rounds of neighbourhood aggregation and keeping the learned transformations and nonlinearities at every layer. LightGCN then asked which of those parts actually earn their keep and found that most do not: strip out the transformations and nonlinearities, keep only the neighbourhood averaging and a combination of the vectors from each round, and the model becomes smaller, faster, easier to train and typically more accurate — a useful reminder that borrowed machinery is not always needed in full. PinSage attacks the remaining obstacle, which is size: on a graph with billions of edges, no round of message passing can touch every neighbour, so it samples a small, importance-weighted neighbourhood per node and trains on batches of these local structures, making graph methods practicable at web scale.

Ranking, Retrieval & Serving

A model that predicts preferences accurately is not yet a recommender. What a reader actually meets is an ordered list, assembled from an enormous catalogue, within the fraction of a second it takes a page to load, and then shown in a way that teaches the system something for next time. That turns recommendation into a systems problem with three parts: deciding what good order means and learning to produce it, arranging the computation so it can run at scale and in time, and ensuring the traffic the system generates keeps feeding it the evidence it needs.

Ranking & Re-ranking

The first shift is in the objective. Predicting a score for each candidate as accurately as possible is not the same as putting the right things at the top, and only the second matters to a reader who looks at a handful of slots. Learning to Rank takes the order itself as the thing to be learned: the model is trained and judged on the arrangement it produces, so an error that reverses the top two candidates counts for far more than an error deep down the list where nobody looks.

How that objective is expressed defines three approaches of increasing ambition. Pointwise Ranking looks at one candidate at a time, predicting an absolute score or label and sorting by the result; it is the simplest to implement and reuses any ordinary prediction model, but it never actually compares candidates and so optimises something other than the order it produces. Pairwise Ranking looks at two candidates at once and learns which of them should come first, an objective much closer to what a reader experiences and one that conveniently needs only relative judgements — which are far easier to obtain from behaviour than absolute ones. Listwise Ranking goes further still and treats the entire list as a single training example, so the quality of the whole arrangement — not of a point or a pair — is what the model is pushed to improve.

Four models mark the path these ideas actually took. RankNet made the pairwise objective practical by turning the score difference between two candidates into a probability that one outranks the other, giving a smooth, differentiable target where the raw order is a step function and cannot be optimised directly. LambdaRank then noticed that not all pairs matter equally: it scales each pair's training signal by how much swapping those two candidates would change the list's measured quality, so effort concentrates where a swap near the top is worth many swaps further down. LambdaMART carries that signal over to boosted decision trees, which handle the heterogeneous, tabular features of ranking well, and the combination remained the method to beat for years. XGBoost Ranker is how most practitioners meet this family today — a widely used gradient-boosting implementation with ranking objectives built in, turning the approach into a few lines of configuration.

All of this learns from logged behaviour, and logged behaviour is systematically distorted: a candidate shown in the top slot is clicked more than an equally good one shown far below, so training naively on clicks teaches the model to repeat its own earlier placements. Unbiased Learning to Rank corrects for that by modelling how likely each position was to be examined at all and weighting the observations accordingly, so a click on a rarely examined slot counts for more than a click on an unavoidable one.

A ranked list can still be a poor list, which is why a final pass exists. Re-ranking takes the top candidates and rearranges them with considerations that cannot be expressed as a per-candidate score: business rules, freshness, how often something has already been shown, or the composition of the list as a whole. The most common of those considerations has its own name — Diversification (Ranking), which penalises a candidate for resembling what is already placed above it. Without it, a model that is confident about one interest will fill every slot with near-duplicates; with it, the list spreads across several plausible interests and the chance that at least one slot is useful goes up, even though every individual slot is slightly less likely to be the single best choice.

Production Patterns

The expensive models above cannot be run against a whole catalogue, and the cheap ones are not accurate enough to produce the final order. The standard resolution is the Multi-Stage Recommender: a funnel in which each stage considers fewer candidates than the last and spends correspondingly more computation on each one. Cost is then spent where it changes what the reader sees, instead of being spread evenly over millions of candidates that were never in contention.

The funnel's first stage is Candidate Generation, which reduces the catalogue to a few hundred plausible candidates using methods fast enough to touch everything — often several such sources in parallel, each with its own notion of plausibility, their outputs pooled. Its only duty is recall: anything it drops here can never be recommended, however good the later stages are. The Ranking Stage then applies the expensive model to that short list, with the full feature set, to produce the order the reader actually sees. The division of labour is what makes the whole thing possible — a cheap method that need not be precise, followed by a precise method that need not be cheap.

Where in time this work happens is a second axis. Offline Recommendation computes results in advance — in a nightly or hourly batch — and stores them to be looked up when needed, which is simple, cheap per request and robust, but blind to anything that has happened since the batch ran. Online Recommendation computes on request, so the actions of the last few seconds can shape the list, at the price of a far more demanding service. Most real systems split the difference, precomputing the heavy parts and assembling the rest live.

Either way, the features the model expects must exist by the time they are needed, and that is the job of the Feature Pipeline (RecSys): the plumbing that collects raw events, computes the aggregates and vectors the model consumes, and makes them available for both training and serving. Its central requirement is consistency — a feature must be computed the same way in both places, since a quantity defined slightly differently at serving time than during training will degrade a model in ways that are extremely hard to diagnose.

Finally, every one of these choices is constrained by an Inference Latency Budget: the few tens of milliseconds the whole pipeline may consume before the delay becomes visible and the reader's experience suffers. The budget is a hard allowance to be divided between candidate generation, feature lookup and ranking, and it explains most of the architecture above. Depth of model, number of candidates and richness of features are all traded against it, which is why the accurate model is reserved for the few hundred candidates that survive the funnel.

Exploration & Online Learning

A recommender creates the data it learns from. If it only ever shows what it currently believes to be best, it never finds out about anything else, and its confident mistakes are never corrected — a self-confirming loop in which untried items stay untried because they were never shown. This is the Exploration-Exploitation (RecSys) trade-off: every slot can either exploit, by showing the current best guess, or explore, by showing something uncertain in order to learn from the outcome. Pure exploitation stagnates; pure exploration wastes the reader's attention; the art is in the balance, and in spending only a small part of the traffic on learning.

Bandit-Based Recommendation gives that balance a principled form. Each candidate is treated as an option of unknown payoff, and the system chooses in a way that accounts for its own uncertainty — an option that might be good but has rarely been tried is worth showing, while one that has been shown many times with poor results can be set aside. Because it updates from outcomes as they arrive rather than from a nightly retraining, it adapts in minutes to things a batch-trained model would notice much later.

Plain bandits ignore who is asking, which for recommendation is a severe loss. A Contextual Bandit (RecSys) restores it: the choice is conditioned on the situation — the person, their recent behaviour, the surface, the time — so the system learns not which option is best overall but which is best in which circumstances, and uncertainty is tracked per circumstance too. Thompson Sampling (RecSys) is the most widely used way of actually making the choice: instead of a fixed exploration rate, maintain a belief about each option's payoff, draw one plausible value at random from each belief, and show whichever option wins that draw. Exploration then emerges naturally and in exactly the right proportion — an option whose belief is wide is often drawn high and so gets tried, while one that is confidently poor almost never wins — and as evidence accumulates the beliefs narrow and the behaviour settles towards exploitation on its own.

Bandits still treat each slot as a one-off decision with an immediate payoff, and some decisions are not like that: introducing someone to a new interest may cost a click today and earn many tomorrow. Reinforcement Learning for Recommendation frames the problem as a sequence of decisions whose value accumulates over a whole session or lifetime, so the system can learn to accept a small immediate loss for a larger later gain. It is the most general framing of all, and the hardest to use in practice — the long-term reward must be defined, the consequences of a choice are observed only much later, and learning by trial on live traffic is costly — which is why it is normally reserved for decisions where long-run engagement is plainly at stake.

Cold Start & Sparsity

Every method that learns from behaviour shares one structural weakness: it needs behaviour to exist. When there is none, or far too little, even an excellent model has nothing to work with — not because it is badly built, but because the evidence it was designed to consume has not been collected yet. This is the Cold Start Problem, and it is not an edge case to be handled later. A live service meets it constantly: new arrivals sign up every hour, new things are added to the catalogue every day, and both must be dealt with immediately, long before enough evidence accumulates for the main model to say anything sensible.

The problem appears in two mirror-image forms, and they call for different remedies. New-User Cold Start is the case of someone who has just arrived: nothing is known about their taste, so there is nothing to compare against other people, and the system must decide what to show on the strength of no personal evidence at all. The usual responses are to fall back on what is broadly popular, to use whatever was stated at sign-up, or to ask directly — a short list of choices on first use buys enough signal to begin. New-Item Cold Start is the opposite: a thing just added that nobody has touched, and so a thing that behaviour-driven methods are structurally incapable of ever suggesting. It is the more insidious of the two, because it is invisible from the reader's side and silently starves the newest part of the catalogue: unseen means unused, and unused means unseen. The remedy has to be deliberate — reserve some exposure for the untried, or describe the new thing well enough that it can be matched without any history.

That second route is the general escape from both forms, and it rests on Side Information: everything known about a person or a thing that is not an interaction. Attributes, descriptions, categories, tags, text, images, declared preferences, the context of a visit — all of it is available on day one, which is precisely when interactions are not. Side information lets a newcomer be positioned among existing ones by resemblance rather than by overlap of behaviour, and it is what makes a hybrid system genuinely robust: the behaviour-driven part takes over once evidence arrives, while the attribute-driven part carries the load until then. In practice this is why most production recommenders are hybrids, since the cold-start case is far too common to treat as an exception.

Cold start is the extreme of a condition that never really goes away. Sparsity (RecSys) is the fact that the overwhelming majority of possible person-and-thing pairs have never occurred: with a large catalogue, any individual interacts with a vanishing fraction of it, so the evidence is a scattering of points in a vast empty space. Sparsity is what makes two people's histories likely to have almost no overlap even when their tastes are close, and it is the reason methods that compress behaviour into a few learned dimensions work so much better than methods that compare raw histories directly — compression lets evidence about one thing inform predictions about a similar one. Seen this way, cold start is simply sparsity taken to its limit, with a count of zero instead of a small number.

One last case is a problem of a different kind, since it survives any amount of data. The Gray Sheep Problem describes people whose tastes do not line up with any identifiable group: their preferences are consistent but idiosyncratic, matching no cluster of similar people closely enough for others' behaviour to be a useful guide. Because methods built on similarity have no reliable neighbours to borrow from, their predictions stay poor however long the person stays. Here too the escape is to stop relying on comparison with others — lean on the person's own history and on the attributes of what they have liked — which is why these edge cases keep pointing to the same architectural conclusion: a system that can only reason from the crowd will fail quietly for anyone the crowd does not describe.

Evaluation

A recommender is never finished; it is only measured. Two systems can look equally sensible on paper and differ enormously in what they actually put in front of a person, and the only way to tell them apart is to agree in advance on what counts as a good recommendation. That agreement is what evaluation provides, and it is built in layers. The first layer decides how past interactions are divided into a part the model learns from and a part it is tested on. The second scores how closely the predictions match what people really did. The third asks what that score quietly ignores — whether a list is varied, surprising, or drawn from more than a handful of obvious items. The fourth leaves the archive behind and watches real users respond. The last layer is the hardest: estimating how a system would have performed on recommendations it never actually made.

Evaluation Protocol

Before any number can be trusted, the data has to be split honestly, and that is the job of the protocol. The most widely used arrangement is Leave-One-Out Evaluation: for each person a single interaction is held back, and the model is asked to recover it from everything else. It is appealing because every user contributes a test case, even users with very little history. It is also easy to abuse — if the held-back interaction is picked at random, the model is usually allowed to learn from behaviour that happened after it, and it then answers the test using information it could not possibly have had in production.

A Temporal Split fixes exactly that. Instead of cutting the data per user, it cuts along the clock: everything before a chosen moment trains the model, everything after it tests the model. This mirrors the real task of predicting the future from the past, and it normally produces lower, more sober scores than a random split — which is a sign of a better experiment rather than a worse model. It also reproduces difficulties the live system genuinely faces, such as items that simply did not exist during training.

Even with a clean split, one practical problem remains: the test asks the model to rank the held-out item against everything else, and in a large catalogue that is an enormous amount of scoring for a single answer. Negative Sampling for Evaluation is the usual shortcut — the true item is hidden among a small handful of items the person never touched, and the model only has to rank that short list. The results this produces are Sampled Metrics, and they deserve a warning label. Because the comparison set is small and drawn by chance, the scores come out far more flattering than a full-catalogue evaluation, and the size of the flattery differs from model to model — so two systems can swap places purely as an artefact of how the negatives were drawn. Sampled numbers are useful for fast iteration; a conclusion meant to last is better taken against the whole catalogue.

Accuracy Metrics

Once the protocol is settled the question becomes what to measure, and the answer depends on what the model was asked to produce. If it predicts a score for an item — how much a person would like it — the natural measures compare predicted numbers against observed ones. RMSE (RecSys) squares each error before averaging, which makes it react sharply to a few badly wrong predictions, while MAE (RecSys) simply averages the sizes of the errors and so treats a single large miss much more gently. Reporting both is informative: when the squared measure is much the larger of the two, the model is usually reasonable in general but occasionally dramatically off.

The trouble is that a person never sees a predicted number. They see a short list, and only its first few entries get any attention at all. Rank-aware metrics judge that list instead. Precision@k asks what fraction of the k items shown turned out to be worth showing, and Recall@k asks what fraction of the items the person actually wanted managed to appear in those k slots. The two pull in opposite directions as k grows — a longer list can only recover more of what was wanted, while diluting the proportion that was useful — which is why both are quoted at a k that reflects how many items the interface really displays. Hit Rate is the blunt version of the same idea: it records only whether anything worthwhile made the list at all, which is exactly the right question when the test has hidden a single item.

None of those three cares where in the list a good item landed, yet a correct answer in the top slot is worth far more than the same answer in the tenth. The remaining metrics build position into the score. Mean Reciprocal Rank (MRR) takes one divided by the rank of the first good item and averages that over test cases, so first place scores one, second place a half, tenth place a tenth. MAP (RecSys) extends the idea to several wanted items by averaging precision at each position where one of them is found, rewarding lists that front-load everything useful. The most widely reported of all is NDCG, which gives each position a discount that falls off smoothly with depth, adds up the discounted value of the good items found, and divides by the best total the ideal ordering could have achieved. That final division is what makes the metric comparable across people who have very different numbers of wanted items, and it also allows graded judgements to count — an item someone loved can contribute more than one they merely tolerated.

Beyond-Accuracy Metrics

A system can score beautifully on every metric above and still be a poor product. The reliable way to win at accuracy is to recommend what is already widely consumed, because widely consumed items are what most test sets mostly contain — and a list of the obvious is of little use to anybody. Beyond-accuracy metrics exist to make that failure visible. Coverage measures how much of the catalogue the system is ever willing to recommend at all; a model that confines itself to a few hundred items out of a million can be accurate while leaving most of the inventory permanently invisible. Diversity Metric turns instead to a single list and asks how different its entries are from one another, which is what separates a genuinely useful set of options from five near-identical ones.

The last two qualities concern how being recommended to actually feels. Novelty asks whether the items shown are ones the person was unlikely to have come across already; naming the single most famous item in the catalogue may well be accurate and tells the reader nothing they did not know. Serendipity is the more demanding of the pair, because it asks a recommendation to be apt, unfamiliar and genuinely unexpected at once — the pleasant surprise rather than the safe guess. It resists clean measurement for that very reason and is often assessed by asking people directly. None of these quantities should be maximised on its own: a perfectly diverse, perfectly novel list is a random one. They are read alongside accuracy, as the price of a score that was obtained too cheaply.

Online Metrics & Experimentation

Every measure so far is computed against a record of things that already happened. The decisive test is what people do when the system is live. Click-Through Rate (CTR) — the share of shown items that get clicked — is the most immediate signal and the most easily gamed, since a striking thumbnail attracts clicks that the recommendation behind it does not deserve. Conversion Rate looks past the click to the action that actually mattered, whether that is a purchase, a subscription or a finished article, and is much harder to inflate. Dwell Time records how long the person stayed with what they chose, which is often the clearest evidence that a click was not a mistake. Rolled up over longer windows these feed a User Engagement Metric — return visits, sessions per week, total time spent — the kind of number an organisation will genuinely optimise, and the slowest of all to move.

Comparing two systems live usually means showing each to a separate slice of traffic, which is simple and slow: the difference between two decent recommenders is small, the variation between people is huge, and a trustworthy verdict can take weeks. Interleaving is a sharper instrument. Rather than splitting the users, it splits the list — the two systems' outputs are merged into one list shown to the same person, and the system whose contributions attract more interaction wins. Because every single user compares both candidates directly, the noise of differing tastes largely cancels out, and far less traffic is needed to detect a small improvement. The price is that it measures preference between two rankings rather than the effect on behaviour overall, so it works best as a fast filter in front of the slower comparison.

Counterfactual & Off-Policy Evaluation

A gap remains between the archive and the live test, and it is the most subtle problem in evaluation. The logs were never collected neutrally: every interaction in them is feedback on an item that some earlier system chose to display. Items it never displayed have no feedback at all, so a new model that would have recommended them looks unaccountably bad — the data cannot distinguish an item nobody wanted from an item nobody was offered. Counterfactual Evaluation is the attempt to answer the question the log does not directly contain: what would have happened if a different system had been in charge?

The machinery begins by recording how likely the logging system was to show each item in the first place. That probability is the Propensity Score, and it is available only when the system that produced the log had some randomness in it — a strictly deterministic ranker leaves no room to ask what else might have been shown. Given propensities, Inverse Propensity Scoring (IPS) reweights each logged outcome by one divided by its propensity, so an interaction that was unlikely to be observed stands in for many, and the reweighted average estimates what the new system would have earned. The estimate is unbiased in principle and unstable in practice: a single rare event with a tiny propensity can dominate the whole total, which is why the weights are normally capped.

Doubly Robust Estimation is the standard remedy. It pairs the reweighting with a model that predicts the outcome for any item, uses that prediction as a baseline, and applies the propensity weights only to the baseline's errors. The name is a promise about failure: the estimate stays close to correct if either the outcome model is good or the propensities are accurate, so only both being wrong together is fatal — and because the weights now act on small residuals rather than raw outcomes, the instability drops sharply. Taken together, these techniques make up Off-Policy Evaluation (RecSys), the practice of grading a candidate system on traffic it never served. It does not replace a live test, but it decides which handful of candidates deserve one, and that makes it the bridge between an offline score and online truth.

Bias, Fairness & Privacy

A recommender does not simply observe behaviour; it causes much of the behaviour it later learns from. What a person clicks depends on what they were shown, and what they were shown was decided by yesterday's model. That loop is what makes this section necessary: a distortion in the data does not merely produce one wrong answer, it returns as training signal and is amplified. The concerns gathered here fall into three families — distortions that creep in through the data, questions about whom the system ends up serving well, and the problem of making useful recommendations without hoarding everything there is to know about a person.

The most familiar distortion is Popularity Bias. Heavily consumed items accumulate interactions simply because they are everywhere; the model learns that they are safe recommendations; recommending them produces still more interactions. Over time the system's attention narrows onto a small head of the catalogue, and the many items with modest but real audiences are never surfaced to the people who would have wanted them. Behind it sits a more general problem. Selection Bias (RecSys) is the observation that logged data is not a representative sample of what people think: they judge what they chose to consume, and they chose it because something put it in front of them, or because they already expected to like it. The opinions that would be most informative — about items a person never encountered — are precisely the ones missing.

Two forms of this are specific enough to correct for directly. Position Bias is the finding that an item placed at the top of a list is clicked far more often than the identical item placed further down, so click counts partly measure placement rather than merit, and a model trained on them will happily conclude that whatever it ranked first was right. Implicit Feedback Bias is the trouble with reading a click, a view or a purchase as approval: such signals are abundant but ambiguous, a click can be followed by immediate disappointment, and the absence of a signal is more treacherous still, since not interacting with an item may mean dislike or may mean never having seen it.

Left to compound, these effects change what a person is able to discover at all. A Filter Bubble forms when a system, fitting someone's revealed preferences ever more tightly, gradually stops offering anything outside them; each recommendation is defensible and the world on offer has quietly shrunk. An Echo Chamber is the social version of the same narrowing, in which the surviving material keeps restating one position and the repetition is itself read as confirmation. Both are nearly invisible to an accuracy score, because by construction they recommend things the person does indeed engage with.

Algorithmic Fairness (RecSys) asks who the system actually serves well, and here the question has two sides. People may be served unequally: a group whose tastes are thinly represented in the data receives visibly weaker recommendations than the majority, and because weaker recommendations generate less usable signal, the gap maintains itself. The providers whose items are being ranked have a stake too — exposure is their livelihood, and a system that routes almost all attention to a small set of them is making an allocation decision, not merely a prediction. One concrete and widely used remedy is Ranking Calibration, which asks that the mix of a person's recommendations reflect the mix of their demonstrated interests in proportion: someone who spends most of their time on one subject but reliably returns to two others should see that proportion back, rather than watching the dominant interest crowd the others out entirely, as a purely score-maximising ranking tends to let it.

The remaining tension is structural. Tailoring recommendations to an individual is valuable in proportion to how much the system knows about them, and what it knows — what someone reads, watches, buys, and when — is exactly the sort of record they would not volunteer. Privacy-Preserving Recommendation is the umbrella for approaches that try to keep the usefulness while reducing the exposure, whether by collecting less, by keeping identifying detail away from the party doing the computation, or by making the stored signal less revealing. Federated Recommendation pursues this by moving the computation rather than the data: each person's history stays on their own device, the update to a shared model is computed locally, and only those updates travel back to be combined, so the central service never assembles anyone's complete record. That alone is not a guarantee, because an update still carries traces of the data that produced it, which is where Differential Privacy in RecSys enters: carefully calibrated noise is added so that the published result is almost identical whether or not any single person was included, making an individual's history formally hard to infer from the output. The trade is explicit and adjustable — more noise, stronger protection, less precise personal fit — and stating where that dial is set is part of describing the system.

Attacks & Robustness

A recommender is unusual among learning systems in that the public supplies its training data. Anyone who can open an account can add ratings, clicks and reviews, and that material is what the model learns from. The openness is what lets recommendation work at scale, and it is also an invitation: if the system's output influences what people buy, read or watch, then influencing the system's input is worth money. This section is about deliberate manipulation of that input — how it is carried out, how it is spotted, and what it means for a system to hold up under it.

The classic form is the Shilling Attack, named for the shill who praises a product on the seller's behalf. An attacker creates a population of accounts whose behaviour is designed to move one item: pushing it, so that it is recommended far more often than it merits, or nuking a rival's item so that it drops out of lists altogether. What makes the attack worth understanding is that it never touches the model or the code. It only adds ordinary-looking data, and the system — built on the assumption that its users' behaviour can be taken at face value — does the rest of the work itself.

Mechanically this is delivered as a Profile Injection Attack: each fake account is given a complete, plausible history rather than one suspicious rating. The target item receives the extreme judgement, and around it sit filler items judged in unremarkable ways, chosen so the account resembles a real person and lands close to the genuine users whose recommendations the attacker wants to influence. Nearly all the sophistication of an attack lives in that camouflage and in how much the attacker knows about the catalogue; well-chosen filler makes a profile both more convincing and more effective, so that fewer accounts are needed to shift the outcome.

Attack Detection (RecSys) exploits the fact that manufactured histories are rarely statistically ordinary. Injected profiles tend to leave traces — an odd distribution of judgements, improbably high agreement with one another, a sharp concentration on a single item, batches of accounts created in the same window and active only briefly. Detection either scores individual profiles against features built from such signals, or looks for clusters that behave too alike to be independent people. It is an arms race rather than a solved problem, since every published detector also tells an attacker precisely which behaviour to avoid.

The broader aim is Robustness (RecSys): a system whose recommendations bend rather than swing when a few hundred fabricated accounts arrive. Much of it comes from design rather than policing — capping how much influence any one account can exert on a result, discounting accounts that are new or thinly evidenced, preferring models in which a small tight cluster cannot dominate a conclusion, and treating a sudden narrowly-focused change in one item's standing as something to verify before acting on. Robustness is measured the way the attacks are built: simulate an attack of a given size, and report how far the target item actually moved.