Block 1 · Data & the Pipeline¶
A model is the easy part.
You will hardly train a model in these four weeks, and that is on purpose. By the time you call .fit(), most of what can ruin a project has already happened, and none of it raises an error. Split the data carelessly, or let one column leak, and the code runs perfectly. You get a great score. Then the model meets real data and falls over.
So we start at the other end, with the pipeline that decides whether a score can be trusted at all. One stage a week.
The running example¶
Will this order arrive late?¶
Predicted at the moment the customer clicks buy.
Olist connects small Brazilian shops to the big online marketplaces. In 2018 the company published an anonymised record of about a hundred thousand real orders, and that is what every lecture, figure and lab in this block runs on.
Few things lose a customer faster than a parcel that turns up late. Spot it at the moment of purchase and there is still time to do something: send a warning, move the shipment up the queue, pick a different carrier. Somebody would pay for that answer, which is what makes it worth practising on.
The data is the Brazilian E-Commerce Public Dataset by Olist, published under CC BY-NC-SA 4.0. You do not download it by hand: the labs repository fetches it with python data/download.py, from the course data release. Everything provenance-related is listed on the reference page.
How the nine tables connect
You will only need two of these in Week 1. Week 2 joins all nine, and one of the relationships below hides a trap you will meet there.
erDiagram
CUSTOMERS ||--|| ORDERS : "places"
ORDERS ||--|{ ORDER_ITEMS : "contains"
ORDERS ||--|{ PAYMENTS : "paid by"
ORDERS ||--o{ REVIEWS : "receives"
PRODUCTS ||--o{ ORDER_ITEMS : "appears in"
SELLERS ||--o{ ORDER_ITEMS : "ships"
CATEGORY_NAMES ||--o{ PRODUCTS : "translates"
GEOLOCATION }o--o{ CUSTOMERS : "zip prefix"
GEOLOCATION }o--o{ SELLERS : "zip prefix"
ORDERS {
string order_id PK
string customer_id FK
string order_status
datetime order_purchase_timestamp
datetime order_delivered_customer_date
datetime order_estimated_delivery_date
}
CUSTOMERS {
string customer_id PK
string customer_unique_id
string customer_state
}
ORDER_ITEMS {
string order_id FK
string product_id FK
string seller_id FK
float price
float freight_value
}Four ways a score can lie¶
Each week shuts one of them down, so that by the end of the block any score you report has survived all four.
-
Week 01 · Problem framing & baselines
The lie: "it beats nothing." A 95% score means nothing until you know what always guessing the most common answer would have scored.
The defence: a precisely defined target, and a ladder of baselines before any real model.
-
Week 02 · Data quality & splitting
The lie: "the test set was unseen." Rows from the same customer, or from the future, sitting on both sides of the split.
The defence: cleaning you can repeat, and a split that matches how the model will actually be used.
-
Week 03 · Feature engineering
The lie: "the features are fair." A column recorded after the prediction was made, or a scaler that quietly saw the test set.
The defence: features built only from what is known at prediction time, inside a pipeline that cannot leak.
-
Week 04 · Evaluation & error analysis
The lie: "the average is fine." A respectable overall score that is poor for exactly the customers who matter most.
The defence: a metric chosen for the cost of being wrong, and error analysis slice by slice.
What you build¶
Every week leaves something real in your repository. Put together, they are most of Project 1 already.
| Week | By the end of the week, your repo has |
|---|---|
| 01 | A problem card stating exactly what you predict, when, and why, plus a baseline ladder |
| 02 | A cleaning step anyone can rerun, and a split with its reasoning written down |
| 03 | A preprocessing pipeline that cannot leak, whatever you put through it |
| 04 | An error analysis broken down by slice, and a short model card |
Skills you leave with¶
How the labs work¶
The labs repository holds every notebook and the script that fetches the Olist data.
Run git pull to get that week's notebook. It arrives with gaps for you to fill in class.
The complete, narrated solution appears the same evening. Compare it with what you wrote.
Missed a week? You are not locked out
Each lab starts from a checkpoint produced by the previous week's solution, so you can join at any week without having finished the one before.
Where it leads¶
Project 1: the same four stages, on a different dataset.
We work through Olist together in class. Your team then runs the same four stages on data you have never seen, which is where you find out whether you understood the idea or were following along.
Before you start: make sure the toolkit readiness checklist is done. Then go to Week 01.