H&M real-time recommender course: a four stage pipeline you can run

What the five modules actually build

The course is called the Hands-on H&M Real-Time Personalized Recommender and it is described as a five module course backed up by code, notebooks and lessons. The stated list of what you will do runs to eight numbered items. You architect a scalable and modular ML system using the Feature, Training and Inference architecture. You do feature engineering on the H&M data for collaborative and content based filtering. You use the two-tower network to create user and item embeddings in the same vector space. You implement the recommender using the four stage design and a vector database. You apply MLOps practices such as a feature store and a model registry. You deploy the online inference pipeline to Kubernetes using KServe, the offline ML pipelines to GitHub Actions, and a web interface with Streamlit. And finally you improve the recommender using LLMs. The order matters, because the last item is an addition to a working system rather than a replacement for one.

The four stage design and the two-tower model

The two architectural ideas the course is built around are the four stage recommender and the two-tower network. The four stage design splits recommendation into distinct stages, with a retrieval stage that narrows the catalogue and ranking stages that order what is left, which is what makes the thing scale. The two-tower network is the retrieval model, and the key property is that it creates user and item embeddings in the same vector space, so that candidate generation becomes a nearest neighbour search rather than a scoring pass over every product. Both ideas have dedicated diagrams in the repository assets, named for the four stage architecture and for the two-tower embedding model. The first module is the theory module, and the course table marks it as no code, with the article covering how to architect the system using the four stage architecture and the two-tower network. The articles are on the Decoding AI site, and the code, notebooks and lessons are in this repository.

How to work through the five modules

The course gives a three step recommendation for each module. Read the article, run the notebook to replicate the results locally or on Colab, and then go deeper into the code by reading the `recsys` Python module. That last step is the important one, because the notebook shows you what happened and the module shows you how the system is put together. The repository layout supports that structure. There is a `notebooks/` directory holding the numbered notebooks, a `recsys/` directory for the Python package the notebooks import, a `streamlit_app.py` for the interface, a `tools/` directory, an `assets/` directory for the diagrams, an `INSTALL_AND_USAGE.md` document for a step by step installation guide, a `Makefile`, a `uv.lock`, a `packages.txt`, a `.env.example` and a `.devcontainer/`. The `recsys` package is also the hint that the notebooks are thin drivers over a real package, which is a better shape for a course than a pile of disconnected cells.

The notebooks are the interface to the pipeline

The Makefile turns each pipeline stage into a named target, and the targets are the clearest description of the pipeline order. Feature engineering runs the first notebook, training the retrieval model runs the second, training the ranking model the third, computing item embeddings the fourth, and creating deployments the fifth:

feature-engineering:
	uv run ipython notebooks/1_fp_computing_features.ipynb

train-retrieval:
	uv run ipython notebooks/2_tp_training_retrieval_model.ipynb

train-ranking:
	uv run ipython notebooks/3_tp_training_ranking_model.ipynb

create-embeddings:
	uv run ipython notebooks/4_ip_computing_item_embeddings.ipynb

create-deployments:
	uv run ipython notebooks/5_ip_creating_deployments.ipynb

There is a sixth notebook for scheduling materialization jobs and a seventh for creating deployments with the LLM ranking variant, and an aggregate `all` target that chains feature engineering, train-retrieval, train-ranking, create-embeddings, create-deployments and schedule-materialization-jobs in order. The naming convention is worth noticing, since the notebook numbers carry a prefix, `fp` for feature pipelines, `tp` for training pipelines and `ip` for inference pipelines, which maps the files onto the three stages of the FTI architecture the course teaches.

The interface runs in two modes

The Streamlit front end is launched with an environment variable that selects the ranking model, so the same interface can show the learned ranker or the LLM enhanced one. The plain ranking mode sets the variable to `ranking`, and the LLM variant sets it to `llmranking`:

start-ui:
	RANKING_MODEL_TYPE=ranking uv run python -m streamlit run streamlit_app.py

start-ui-llm-ranking:
	RANKING_MODEL_TYPE=llmranking uv run python -m streamlit run streamlit_app.py

That single switch is a good summary of the fifth module, since the LLM is an alternative ranker rather than a separate application. There is also a `clean-hopsworks-resources` target that runs a script in the `tools/` directory to remove the resources the course created, which is the operation you will want most at the end, because everything else in the course leaves state behind in a hosted platform.

The dependency set tells you what the stack is

The pyproject.toml for the project named hands-on-recommender-system requires Python 3.11 and pins its dependencies tightly. The ML side is `tensorflow==2.14` with `tensorflow-recommenders==0.7.2`, which is the reference implementation of the two-tower retrieval model, plus `catboost==1.2` for the ranking stage. The data side is `polars==1.9.0` for feature engineering, and the platform side is `hopsworks[python]>=4.1.2` for the feature store and model registry, which is the piece that makes the offline and online paths meet. The model side includes `sentence-transformers==2.2.2` for content based features and the item embeddings, and `huggingface-hub==0.24.7` to fetch models. The LLM module is `langchain==0.2.6` with `langchain-openai==0.1.14`, and the interface is `streamlit==1.28.2`. The rest is tooling, with `pydantic-settings` for configuration, `loguru` for logging, `altair` for the charts, and `ipykernel` and `nbformat` for the notebooks themselves, with ruff as the only dev dependency.

Credentials, cost and the free tier claim

Two environment variables are needed, and the `.env.example` file in the repository lists both. The Hopsworks API key is required, and the OpenAI API key is marked optional and required only for the last LLM lesson. The cost structure is stated plainly in the README. All the tools used throughout the course stay on their free tier, except OpenAI's API, with modules 1 to 4 completely free and module 5, which is optional, costing roughly one to two dollars of OpenAI API usage when building LLM enhanced recommenders. The hardware requirement is deliberately low, since any modern laptop or workstation will do and no GPU or powerful computing is required, and Google Colab or GitHub Actions are supported for compute. The level is described as intermediate, with a basic understanding of Python and machine learning as the stated skill requirement, and the target audience is ML and AI engineers who want production ready recommender systems plus data engineers, data scientists and software engineers who want to understand the engineering behind recommenders.

Where this course is the wrong choice

Two limits are stated by the project itself. The first is scope of research. The README says plainly that the course focuses on engineering practices and end to end system implementation rather than theoretical model optimisation or research, so if your goal is a new ranking objective or a new retrieval architecture, this is not where the answer is. The second is the vendor dependency. Hopsworks is not a detail here, it is the feature store, the model registry and the serving layer across the modules, so the course teaches a Hopsworks shaped system, and the KServe deployment and the GitHub Actions offline pipeline are tied to that world too. The third is the depth of the code. The README frames the `recsys` module as something to read after the notebooks, and the primary language of the repository is recorded as a Jupyter Notebook, so the code is organised as instructional notebooks with a supporting package rather than as a library with tests and releases. The fourth is the state it leaves behind. Everything runs against a hosted platform, which is why the clean up target exists, and a learner who abandons the course midway leaves feature groups, models and deployments in someone else's account.

Editorial conclusion

The course suits an ML engineer who wants to see a complete production-shaped recommender rather than a paper, because the four stage design, the feature store and the deployment steps are all in one place and every stage is a runnable notebook. It is the wrong choice if you are looking for a new model architecture, since the stated focus is engineering practice and end-to-end implementation rather than theoretical model optimisation, and the wrong choice if you want to avoid a vendor dependency, since Hopsworks is load bearing across the modules. Before you start, read INSTALL_AND_USAGE.md, and note that module 5 is the only one that costs anything, an estimated one to two dollars of OpenAI API usage. The last push was on 2026-04-06, the repository publishes no GitHub releases, and the code is MIT licensed.

Frequently asked questions

Official sources

1. decodingai-magazine/personalized-recommender-course on GitHub
2. Issues
3. License: MIT
4. README