Incremental Training
ALS Model
Machine Learning
Recommender Systems
Data Science

Incremental training of ALS model

ML System Design practice on Codemia

Design recommenders, ranking systems and training pipelines the way ML interviews actually ask for them, with worked solutions.

Practice ML system design

Introduction

ALS, or Alternating Least Squares, is usually a batch matrix-factorization algorithm, not a true online learner. That means "incremental training" for ALS usually does not mean calling a simple partial_fit method forever; instead, it means using approximations such as warm-start retraining or updating only selected user or item factors while holding the rest fixed.

Why ALS Is Not Naturally Incremental

Classic ALS alternates between two global optimization steps:

  • solve all user factors while item factors are fixed
  • solve all item factors while user factors are fixed

Those updates are coupled through the full interaction matrix. If new ratings arrive, the mathematically clean answer is to rerun the alternating optimization using the enlarged dataset.

That is why many ALS implementations, including common Spark workflows, are fundamentally retrain-oriented rather than online-update-oriented.

What Incremental ALS Usually Means in Practice

In production recommender systems, people often use one of these strategies:

  • periodic full retraining with warm starts
  • recompute only new or changed user factors while keeping item factors fixed
  • recompute only new or changed item factors while keeping user factors fixed
  • use ALS as a batch backbone and a separate online ranking layer for fresh behavior

The right choice depends on how fast the catalog changes, how fresh recommendations need to be, and whether new users or new items are the main source of drift.

A Practical Approximation: Update One User Against Fixed Item Factors

Suppose item factors are already trained and a user's latest interactions arrive. You can keep the item matrix fixed and solve only that user's vector.

The following NumPy example sketches the idea for an explicit-feedback setting.

python
1import numpy as np
2
3
4def update_user_factor(item_factors, item_indices, ratings, reg=0.1):
5    Y = item_factors[item_indices]
6    A = Y.T @ Y + reg * np.eye(Y.shape[1])
7    b = Y.T @ ratings
8    return np.linalg.solve(A, b)
9
10
11item_factors = np.array([
12    [0.9, 0.1],
13    [0.2, 0.8],
14    [0.7, 0.4],
15], dtype=np.float64)
16
17item_indices = np.array([0, 2])
18ratings = np.array([5.0, 3.0])
19
20user_factor = update_user_factor(item_factors, item_indices, ratings)
21print(user_factor)

This is not a full ALS retraining pass. It is a targeted least-squares update with one side held fixed.

That is often good enough to serve fresher recommendations for an existing user between full retrains.

Warm-Start Retraining

Another practical approach is to keep previous user and item factors as the initialization for the next batch retrain. That does not make ALS online, but it can reduce convergence time because the model starts near a previously good solution.

This is common when you retrain hourly or daily on accumulated interaction data.

The benefit is conceptual simplicity:

  • the model is still trained in a mathematically consistent batch manner
  • the previous factor matrices give the optimizer a head start

Cold Start Still Exists

Incremental updates do not solve the cold-start problem by themselves.

A brand-new user with almost no interactions still has little signal.

A brand-new item still lacks behavioral evidence.

That is why many recommenders combine ALS with metadata-based retrieval, popularity priors, or hybrid ranking. Incremental ALS can improve freshness, but it does not replace cold-start strategy.

When to Stop Forcing ALS

If you truly need per-event online learning with immediate model updates, ALS may be the wrong core model. Algorithms designed for online updates, streaming bandits, or embedding models trained with mini-batch gradient methods may fit that operational requirement better.

This is an important engineering point: not every batch algorithm should be stretched into a pseudo-online system just because the data arrives continuously.

Common Pitfalls

Assuming ALS supports exact online partial_fit semantics is the most common misconception.

Updating only user factors forever while never refreshing item factors eventually creates drift if item behavior changes too.

Calling an approximation "incremental ALS" without stating what is fixed and what is recomputed can also confuse the system design discussion.

Finally, do not mistake warm-start retraining for true online learning. It is a useful optimization, but it is still retraining.

Summary

  • classic ALS is a batch algorithm, not a naturally online one
  • practical incremental behavior usually means warm-start retraining or selective user or item factor updates with the other side fixed
  • targeted least-squares updates can make recommendations fresher between full retrains
  • incremental tactics do not remove cold-start problems
  • if real per-event online learning is the requirement, ALS may not be the best model family to use

Related reading
Free course
Beginner
7 lessons
2 hours
Tackling System Design Interview Problems

A short course that equips you with the skills to approach system design interviews methodically.

Start the free course
Track what you have practised

A free account saves your progress, solutions and study plan across every problem on Codemia.

ML System Design practice on Codemia

Design recommenders, ranking systems and training pipelines the way ML interviews actually ask for them, with worked solutions.

Practice ML system design

All Rights Reserved.