A relational, explainable recommendation engine, built on Relational Deep Learning (the approach Kumo.ai and NVIDIA build on: predicting directly over a multi-table relational database, treated as a graph, instead of hand-built features).
What makes this different from a typical recommender demo:
- Explainable by construction — because the data is relational, a recommendation can be traced back to the real graph path that produced it ("recommended because you bought X, and X is frequently bought with Y by sellers in your region"), not just a similarity score from a black-box embedding.
- One trained graph, multiple predictions — the same relational representation feeds more than one task (e.g. product recommendation and churn/ad-targeting signals) instead of hand-engineering separate features per task — the actual value proposition of relational deep learning, which most public recommender tutorials only demonstrate for a single task.
- Compared head-to-head against a classic baseline (hand-engineered features + Logistic Regression — not TF-IDF, since this dataset has no product description text) to show, with real numbers, what the relational approach actually buys you.
An evolving project — real public datasets, cleaned and documented myself, with new ideas added here over time rather than spinning up a new repo each time.
- ERD for the first dataset —
docs/ERD.md - Data cleaning —
notebooks/01-explore-and-clean.ipynb,data/clean/ - Baseline model (classic ML, hand-engineered features) —
notebooks/02-baseline-model.ipynb, 27.4% top-1 / 52.3% top-3 vs. 1.6% random - RelBench data prep (BYOD format, reindexed keys, task labels) —
relbench_data/,notebooks/03-relbench-prep.ipynb,notebooks/04-relbench-task-labels.ipynb, 0 validation errors - Relational Deep Learning model (RelBench GNN training) —
notebooks/06-relbench-model.ipynb, 27.2% top-1 / 57.0% top-3, zero hand-built features - Business case write-up
Task: given one product category already in an order, predict which other category is likely to also be in that same order.
| Top-1 | Top-3 | |
|---|---|---|
| Classic baseline (hand-engineered features, Logistic Regression) | 27.4% | 52.3% |
| RelBench (raw relational graph, zero hand-built features) | 27.2% | 57.0% |
| Random guess (63 categories) | 1.6% | — |
Both models clear random by a wide margin. The relational model matches the baseline on top-1 and beats it by ~5 points on top-3 — without any manually engineered input features, just the raw tables and automatic column-type inference. Full write-up: notes/04-relbench-model.md.
Source: Brazilian E-Commerce Public Dataset by Olist, via Kaggle.
License: CC BY-NC-SA 4.0 (non-commercial, attribution required, share-alike). Raw files are not committed to this repo (see data/raw/); download them yourself from the Kaggle link above.
Nine tables, linked by real foreign keys — customers → orders → order_items → products/sellers, plus payments and reviews per order. Full schema notes in docs/.
graphcart/
├── data/
│ ├── raw/ # downloaded Kaggle CSVs (gitignored — see Source above)
│ └── clean/ # my cleaned, documented CSV output
├── relbench_data/ # RelBench BYOD format: manifest.yaml + db/*.parquet + tasks/
├── notebooks/ # 01 clean → 02 baseline → 03/04 RelBench prep → 05/06 graph + model
├── docs/ # ERD, heterogeneous graph diagram, business case
├── notes/ # written explanations of concepts and decisions as I build
├── requirements.txt
└── .gitignore
(to write once the ERD is done — why would a company actually want this, what's the real metric they'd track)