Why GNN recommendations are more accurate on sparse data
Sparsity is the main reason recommendations degenerate into “showing what will be bought anyway.” In a typical catalog, most users have a history of two or three actions: a view, an add to cart, a rare purchase.
The interaction matrix is filled by fractions of a percent, and the wider the catalog, the faster the density of known connections falls.
Classic methods — collaborative filtering and matrix factorization — rely on co-occurrences of items in histories. When histories are almost empty, common pairs are few: user and item vectors remain undertrained, and the model honestly drifts to the popular.
Bestsellers settle at the top, the long tail of the catalog is not shown at all, and new items do not accumulate statistics — the loop closes.
Graph neural networks change the problem formulation: users and items are vertices of a single bipartite graph, actions are edges, and item features (category, brand, attributes) add connections between similar items.
Neighbor aggregation over two or three hops collects signal where there are no direct interactions: a user is connected to an item through a category or through behaviorally similar people.
This is exactly why recommendation quality holds up on sparse data and in cold start: a new user needs one or two actions, and a new item needs several impressions to get a meaningful vector. Below is how this effect is measured and transferred into production recommendations.
Measurable effect of graph models: speed, coverage, robustness
The first measurement after switching to a graph approach is the hit rate in the top. Collaborative recommendations rely on the frequency of joint purchases, so rare items do not break into the upper rows and the long tail of the catalog sits idle without impressions.
We measure recommendation metrics layer by layer: separately for active users, separately for rare segments. An average otherwise masks a failure in the niche, and it is this failure that determines whether a buyer will see anything besides bestsellers. The graph adds edges by attributes, categories, and co-views to user–item pairs.
Coverage grows on the tail, while accuracy in the head of the catalog does not fall. This is most noticeable on new catalog items: in LightGCN and hybrid schemes, a cold item gets a vector from connections rather than from accumulated sales statistics.
The time between publishing a card and its first impression shrinks from days to hours — a collection launch does not wait for purchase history to accumulate.
We separately test model robustness. The graph is assembled from several types of connections, so a break in one signal source does not zero out recommendations. We test deliberately: we disable a stream, look at the drop in top hit rate and the time to return to previous values.
Approaches to building graph models: comparison
Data representation sets the quality ceiling for GNN recommendations more strongly than the architecture itself.
If the system has only events, an interaction graph is used; if the catalog is labeled with connections between items, a knowledge graph is added; a hybrid model uses both sources, while item features remain a baseline layer that does not require edge construction.
The choice is not by “modernity” but by data density and maintenance cost: each additional source increases return and at the same time complicates preparation and error analysis. Below is a comparison of approaches with applicability conditions.
| Option | When it fits | Limitations |
|---|---|---|
| Interaction graph only | dense traffic, many repeated touches of the same items | cold start: new users and items without history receive no connections |
| Knowledge graph only | catalog with pronounced connections, few events | does not reflect the tastes of a specific audience, requires a validated ontology |
| Hybrid model: interactions plus product knowledge | both sources are filled, there is a long tail of items | more expensive in data preparation, harder to explain the reason for a recommendation |
| Item features without a graph | sparse data, need to quickly launch a baseline | hits a ceiling, does not capture joint purchases |
In practice, almost always start with item features and an interaction graph — this layer provides production recommendations and is measured consistently.
Knowledge edges are added when a long tail and new items without clicks appear: connections between items compensate for the lack of history.
Migration proceeds gradually, not by rewriting. An additional source is connected alongside, metrics are compared on the same sample, and only after sustained improvement is the old branch disabled — with rollback preserved if quality drops on live traffic.
How we build GNN recommendations: implementation stages
Implementation of a graph model starts not with choosing an architecture but with data. Until the connections between users, items, and context are described, any model learns from noise.
Therefore, the development stages go from logs to product, and each has an artifact that can be checked before moving further.
- Log and event parsing. We consolidate views, add-to-cart events, and rejections into a single timeline, clean bots and duplicates. The output is an understanding of which connections are missing in the data for the graph.
- Connection schema. We fix node and edge types, their weights and direction, and mark sparse areas separately. The schema is agreed before training — otherwise there is nothing to compare recommendation quality against.
- Dataset assembly. We prepare training and validation sets by time: the past for training, a later slice for control. This excludes leakage of future events into features.
- Model training. We train node representations, watch for overfitting on rare items, and tune the propagation depth over edges. Cold items are backed up with content features.
- Quality validation. We calculate top hit rate, recommendation diversity, and catalog coverage. The main criterion is the holdout period: quality on events the model did not see during training.
- Handover to product. We deliver the recommendation service with model versioning, logging, and rollback to the previous build. After release, we monitor data drift and retrain on a schedule.
The order of stages is sequential but not linear: if quality validation fails, we return to the connection schema or datasets rather than retraining the model blindly.
Project artifacts: graph schemas, feature stores, policies
A graph model does not live on its own: its behavior is determined by how connections and features are described.
Therefore, the project is closed not with a metric demonstration but with the handover of a working loop — the client’s team must be able to rebuild the graph, retrain the model, and investigate an incident without our help.
- Graph schema. Node and edge types, connection direction, weights, duplicate merging rules. The schema is versioned: adding a new edge type does not break already trained models.
- Connection assembly description. Which events form an edge, what observation window is used, how random and artificial interactions are filtered out.
- Feature store. Node and edge features with the source of each, rebuild schedule, checks for distribution shift between stores.
- Retraining policy. Launch triggers — accumulation of new interactions or a drop in ranking metrics; validation procedure, acceptance criterion, and rollback to the previous version.
- Access rules. Roles, anonymization levels, separation of stores by sensitivity, audit log of access to user behavior data.
- Quality control. Sets of input data checks, graph integrity tests, recommendation quality metrics, and incident investigation procedure with responsible owners.
- Documentation and handover. Instructions for launch and training, environment configurations, deployment diagram, architecture walkthrough with your team.
Each artifact is accepted by a formal criterion: it can be opened, run, and changed without us. If an item does not pass this check, it remains in progress, not in the report.
Case study: how a graph model increased hits in the top of recommendations
The catalog is a long tail: most items receive single interactions, while the top 1% of items collect the main share of views.
Classic collaborative filtering barely trains on such items — the vector for an item with two or three events is built from noise, and only promoted items break into recommendations.
What we changed in the model
We restructured the data into a graph: nodes are users, items, categories, and attributes; edges are interactions and connections between attributes.
We took the graph neural network LightGCN as the foundation — it propagates signal over edges and pulls up sparse items through neighbors — and on top added edges from the knowledge base: compatibility, brand, series. Training used sampled negatives; otherwise the model learns “popular = relevant.”
Metrics before and after
The top-10 hit rate grew by about 1.8 times, and items outside the top 1% by popularity began to receive noticeably more impressions — 26% versus 7%.
Three classes of errors disappeared: recommendations looping on one category, duplicates of variants of the same model within one screen, and recommendations of items unavailable for order.
We tested not only offline on the holdout period but also on part of the traffic — the effect held throughout the observation week without a drop in conversion in key categories.
Model versions and weights are saved, so returning to the previous recommendations takes minutes if the experiment needs to be rolled back.
How does a knowledge graph differ from an interaction graph?
An interaction graph is assembled from logs: nodes are users and items, edges are a view, click, add to cart, purchase; each edge has a weight and timestamp.
Such a structure is dense and quickly becomes outdated, but it answers the question “what is similar by behavior” with accuracy unattainable for attributes. The weak point is cold start: a new item and a new user simply have no edges.
A knowledge graph describes the subject domain, not behavior: an item, its properties, category, brand, compatibility, constraints.
Edges here are typed — “belongs to,” “analog,” “requires,” “replaces” — and define connections between items by meaning rather than by frequency of joint actions.
It is sparse and changes slowly, but it provides explainability: you can see through which chain of connections an item entered the selection.
The difference between the approaches is in the source of truth and the horizon. Interactions are accurate on a warm audience but blind outside it; knowledge covers rare categories and the first visit but does not know current demand. Neither graph alone covers both selection and explanation at once.
Therefore, in practice both are more often assembled and linked: shared entities — user, item, category — become bridges between the graphs.
Node representations from both sources are brought into one space, and an attention layer decides which graph to weight more heavily for a specific request.
We design the linkage so that disabling one source degrades recommendations gradually rather than collapsing them: this makes it easier to compare options and roll back.
Technical concerns: data, quality, explainability
Before starting, a technical lead asks the same questions: will there be enough history, how does the model keep up with catalog changes, how do you prove superiority over current recommendations, and how do you explain the result. Below are short answers.
Is history volume enough?
We look not at the length of the log but at connectivity: how many interactions fall on an active item and what share of items are cold.
If half the catalog has fewer than ten events, we start with a hybrid — content features and rules supplement graph embeddings; otherwise the model recommends only hits.
How does it survive daily catalog edits?
New and removed items do not break recommendations: graph nodes are updated incrementally, and connections are recalculated from incoming events.
For items without history, content embeddings are mixed in — the item gets meaningful recommendations from day one, not after a month of accumulating clicks.
How do you prove the graph is better than current recommendations?
Offline measurement on a holdout period: we compare recall and NDCG on an equal number of items, and separately calculate the share of cold items in the top.
The final word belongs to an online test on part of the traffic — offline does not show how users react to the new recommendations.
How often do you retrain the model?
Embeddings are updated on a schedule and on the stream of new interactions; heavy retraining happens less often, when enough data has accumulated. Each version is recorded together with metrics, so rolling back to the previous one takes minutes.
What will you show in the explanation of a recommendation?
Not one reason, but a path in the graph: interaction neighbors, bridge items between interests, the contribution of content features.
We return this as a separate field in the response — support and category managers see what the recommendations are built on and can challenge them substantively.
Let’s discuss the task: what to send for evaluation
The more accurate the input data, the fewer assumptions in the work plan. At the task discussion stage, we do not need access to the production environment — a sample of logs, a catalog description, and the current recommendation logic are enough.
Below is a list of what to send so that the project estimate is based on your facts, not on market averages.
- Product and scenario: what and where we recommend — home page, item page, mailings; what the recommendation object is and how large the catalog is.
- Current recommendations: rules, “popular,” collaborative filtering — what works now, what metrics you already collect, and why the result is unsatisfactory.
- Interaction logs: an event export for a period with action type, timestamp, user and item identifiers; the share of anonymous traffic and history depth.
- Item connections: categories, attributes, brands, suppliers, joint purchases — everything from which graph edges are built, and in what form it is stored.
- Target metrics: coverage in the first K positions, click-through rate, conversion; how you measure changes and whether there is a control group.
- Constraints: recommendation service response time, retraining frequency, explainability requirements for recommendations, rules for handling personal data.
- Infrastructure and roles: where models are computed, who is responsible for data and access, how updates are released — whether recommendations can be changed without an app release.
Based on this set, we will break the work plan into stages: data and graph preparation, a baseline graph model, a hybrid scheme with subject-domain connections, and measurement in the production environment. We will come back with a timeline estimate and a list of what will be needed from your team.
