Recommendation systems are often introduced through their most complex forms: graph neural networks, transformers, multi-stage rankers and generative models. That is useful if the goal is to survey the frontier. It is less useful if the goal is to understand what a dependable recommender actually has to do.

A better starting point is ItemKNN: item-based k-nearest-neighbour collaborative filtering.

ItemKNN asks a narrow question:

When people interact with this item, which other items do they also tend to interact with?

That question powers a large class of familiar experiences: related products, similar articles, listeners-also-played rows, next-item suggestions and candidate generation for larger ranking systems. It does not need item descriptions, image embeddings or a language model. It learns from the interaction graph itself.

The method is old by machine-learning standards. The foundational item-based collaborative-filtering work dates to 2001, and Amazon published its item-to-item approach in 2003. ItemKNN remains relevant because it is understandable, deterministic, inexpensive to operate and often difficult to beat on sparse behavioural data.

The basic idea

Assume a catalogue contains items A, B and C.

Many users interact with A and B.
Few users interact with A and C.
A new user interacts with A.

ItemKNN will usually rank B above C because the historical interaction patterns for A and B overlap more strongly.

The model does not need to know what A or B means. It only needs a user-item interaction matrix:

rows represent users;
columns represent items;
values represent interactions or interaction weights.

For implicit-feedback systems, an interaction might be a view, play, click, save, purchase or completion. Different events can be assigned different weights, but the central signal is co-occurrence: items become neighbours when they repeatedly appear in the histories of the same users.

How ItemKNN is built

A practical ItemKNN pipeline has four parts.

1. Construct the interaction matrix

The raw event stream is converted into user-item values. A simple binary matrix records whether an interaction happened. A weighted matrix can distinguish a weak event from a strong one—for example, a view from a purchase or a short play from a completion.

The definition matters. If every impression is treated as preference, the model can learn exposure patterns rather than user intent. If only purchases are included, the signal may be too sparse. The right event policy depends on the product and the recommendation surface.

2. Measure item similarity

Each item is represented by the users who interacted with it. The model compares two item vectors and computes a similarity score.

Cosine similarity is common:

similarity(i, j) = interactions(i) · interactions(j)
                   -----------------------------------
                   ||interactions(i)|| × ||interactions(j)||

The numerator measures overlap. The denominator controls for scale, so two niche items with similar audiences can be close even when a globally popular item has more total activity.

Other implementations use adjusted cosine, Jaccard similarity or BM25-style weighting. The purpose is similar: turn behavioural overlap into an item-to-item neighbourhood.

3. Apply shrinkage and weighting

Raw similarity can overvalue coincidences. Two items used by the same two people may receive a perfect similarity score, but that estimate is much less trustworthy than a slightly lower score supported by thousands of people.

Shrinkage reduces similarity estimates supported by little evidence. One common form is:

adjusted_similarity = raw_similarity × overlap / (overlap + shrinkage)

This leaves well-supported relationships mostly intact while pulling fragile ones toward zero.

Popularity correction can also help. Without it, blockbuster items appear in many histories and can become neighbours of almost everything. Inverse-frequency or BM25 weighting reduces the influence of users and items that contribute little distinguishing information.

4. Score candidates for a user

At request time, the system reads the user's recent or weighted history. It looks up neighbours for those items and aggregates their similarity scores.

A simple score is:

score(candidate) = Σ similarity(candidate, history_item) × history_weight

Items already consumed can be removed. Business rules, availability constraints, freshness controls and diversity reranking can then modify the list before delivery.

The result is personalised even though the stored neighbourhoods are item-to-item. Two people receive different results because their histories activate different parts of the neighbour graph.

What ItemKNN is good at

Related-item recommendations

This is the most natural fit. Start from one product, video, article or track and return behavioural neighbours. The explanation is intuitive: people who engaged with this also engaged with those.

Useful surfaces include:

related products on a product-detail page;
similar videos after playback;
related articles at the end of a story;
substitute content when the current item is unavailable;
"because you watched" or "because you viewed" rows.

Personalised candidate retrieval

Modern recommenders often separate retrieval from ranking. Retrieval finds a few hundred plausible items from a catalogue that may contain millions. A ranker then uses richer context to order them.

ItemKNN is effective as a retriever because neighbour lookups are fast and the candidate set remains connected to observed behaviour. It can feed a gradient-boosted ranker, neural ranker or multi-objective model without forcing the whole system to begin with a neural candidate generator.

Sparse datasets

When the interaction graph is not yet rich enough to support a large model, ItemKNN can be a strong first personalised system. It does not need to estimate a full user representation or learn millions of neural parameters. It stores local relationships that are directly supported by co-occurrence.

That restraint is valuable. A more expressive model can generalise farther, but it can also generalise in the wrong direction when evidence is thin.

Operationally constrained systems

ItemKNN can be trained on CPU, served as compact neighbour lists and updated through a full recomputation or incremental co-occurrence changes. It has no stochastic training process and no random seed, which simplifies reproducibility and debugging.

This makes it useful when teams need a model that can be inspected, compared and rolled back without a large serving stack.

Where it struggles

New items

A new item has no interactions, so it has no behavioural neighbours. This is the item cold-start problem.

Common responses include:

use content embeddings until interaction data arrives;
add the item through editorial or merchandising rules;
place it in an exploration pool;
blend behavioural and content similarity;
use catalogue metadata to create provisional neighbours.

ItemKNN alone cannot infer that two unseen films share a director, genre or visual style. It only knows what the interaction graph contains.

New users

A user with no history activates no neighbours. The usual fallback is contextual popularity, recency-weighted trends, editorial selections or a short onboarding preference flow.

After the first few interactions, ItemKNN can begin personalising quickly because it does not need a separately trained user vector.

Rapidly changing intent

A lifetime history can mix unrelated interests. A user researching a holiday today may not want recommendations driven by purchases made two years ago.

Recency weighting, session boundaries and short-term history windows help. For strongly sequential products—short-form video, music sessions or episodic viewing—a session model such as VS-KNN or a transformer such as SASRec may represent changing intent more directly.

Popularity concentration

Co-occurrence data reflects exposure. Popular items accumulate more interactions, create more neighbours and can dominate recommendations. Similarity normalisation helps, but it does not remove the feedback loop.

Coverage, novelty, long-tail exposure and provider concentration should therefore be measured alongside relevance. Diversity or business-aware reranking may be needed after retrieval.

No understanding beyond behaviour

ItemKNN cannot reason about text, images, price, creator, category or editorial meaning unless those signals are added elsewhere. Two items can be semantically close but behaviourally disconnected. Conversely, two items can be behaviourally close because they were promoted together rather than because users see them as substitutes.

ItemKNN is not the same as content similarity

The distinction is important.

Content similarity says:

These items look alike according to their metadata or embeddings.

ItemKNN says:

These items attract overlapping behaviour.

A documentary and a drama may be behaviourally close because the same audience watches both, even if their descriptions are dissimilar. Two near-identical products may be content-similar but never co-occur because users choose one or the other.

Strong systems often use both. Content similarity provides coverage for new and long-tail items. ItemKNN captures relationships revealed by real use. A ranker can combine their scores with freshness, context and business constraints.

Public examples and implementations

Item-to-item collaborative filtering is not merely an academic baseline.

Amazon described an item-to-item collaborative-filtering system in its 2003 IEEE Internet Computing paper, "Amazon.com Recommendations: Item-to-Item Collaborative Filtering". The paper explains why precomputed item relationships were more practical for a very large catalogue than finding similar customers at request time. It is a historical publication, not evidence about Amazon's current production architecture, but it remains one of the clearest large-scale examples of the approach.

The foundational research paper, "Item-Based Collaborative Filtering Recommendation Algorithms" by Sarwar and colleagues, compares item-based methods and similarity choices on the MovieLens data set.

For a working implementation, the open-source implicit library includes cosine, TF-IDF and BM25 item-item nearest-neighbour models for implicit-feedback data. These are useful references for understanding how weighting choices alter neighbourhood quality.

Many consumer products expose experiences that look like item-to-item recommendation—"customers also bought", "similar titles", "listeners also like"—but the interface alone does not reveal the model underneath. Those rows may be powered by co-occurrence, embeddings, a learned ranker or a blend. Publicly documented examples should be separated from visual resemblance.

How ItemKNN fits in NeuronSearchLab

NeuronSearchLab's recommender catalogue treats ItemKNN as a neighbourhood model and a reference system for comparison. It is suited to related-item, search and homepage candidate surfaces. Training uses interaction data; serving can use precomputed neighbours without GPU inference.

The important point is not that ItemKNN should win every comparison. It should not. Its role is to establish a serious, reproducible behavioural baseline and, when appropriate, provide candidates for a more expressive ranker.

A model that cannot improve on a carefully configured ItemKNN for the target data and objective has not yet justified its added complexity.

Within the platform, the main controls are the number of neighbours retained and similarity shrinkage. More neighbours improve recall but increase memory and can introduce weak relationships. More shrinkage demands stronger co-occurrence evidence but can suppress useful links in a sparse catalogue. These parameters should be selected against time-aware validation data, not tuned on random interaction splits.

What to measure

Offline evaluation should reflect the actual surface. Useful measures include:

recall and NDCG for whether relevant items are retrieved and well ordered;
catalogue coverage for how much inventory can appear;
long-tail share for whether recommendations extend beyond head items;
novelty and diversity for list composition;
cold-user and cold-item cohorts;
provider or creator concentration;
latency, index size and refresh cost.

A time-based split is essential. Training on interactions that occurred after the test event leaks future information into the neighbourhood graph and makes the model look stronger than it will be in production.

Online, the outcome depends on the surface. A related-item module might optimise qualified detail-page visits or downstream conversion. A video row might care about starts, completion and session depth. Negative signals—quick exits, hides or repeated skips—should be monitored rather than hidden inside a single click-through rate.

When to move beyond it

Move beyond standalone ItemKNN when the problem requires capabilities it cannot provide:

use content or multimodal retrieval when new-item coverage matters;
use matrix factorisation when broader latent taste patterns are important;
use VS-KNN when the current session matters more than long-term history;
use SASRec or another sequential model when order and transitions carry substantial signal;
use LightGCN when higher-order graph connectivity is useful and the interaction graph is dense enough;
use a multi-stage system when retrieval must be followed by context-aware or multi-objective ranking.

The usual progression is not replacement for its own sake. It is composition. ItemKNN can remain a candidate source, fallback, diagnostic baseline or explanation path inside a more advanced system.

The practical standard

ItemKNN is simple, but it is not naive. A production-quality version still requires deliberate event definitions, weighting, shrinkage, temporal evaluation, cold-start handling, filtering and reranking.

That is exactly why it is a useful foundation. It exposes the core mechanics of recommendation without hiding them behind model complexity:

infer relationships from behaviour;
retrieve plausible candidates;
score them for the current user;
enforce product and catalogue constraints;
evaluate more than clicks.

The next models in the series build on those ideas rather than replacing them. EASE learns a global linear item-to-item model. Matrix factorisation introduces latent user and item representations. Session methods prioritise immediate intent. Graph and transformer models capture higher-order or sequential structure. Multi-stage rankers combine several candidate sources and objectives.

Understanding ItemKNN first makes the trade-offs in every later architecture easier to see.