Machine learning, deep learning and neural networks
Tuesday, 9:30: Hotel Ribeira in Porto loses 6% of its room nights to guests who never arrive, and asks StayHub to predict them. Maya's first idea is to ask the concierge's LLM.
How a program can learn a rule from examples instead of being told it, and why your API calls never teach the model anything.
- Problem
A hotel wants to know which bookings will be no-shows, so it can overbook safely and stop losing 6% of room nights.
- Why the simple system fails
Hand-written rules ("non-refundable rate = will show up") catch the obvious cases, then drown in exceptions nobody can maintain.
- Engineering concept
Let the program find the rule: give it labelled examples, measure how wrong it is (loss), and nudge its numbers (weights) to be less wrong, millions of times.
- Technology
Neural networks trained with gradient descent on GPUs, then served as frozen weights for fast, cheap inference.
- Trade-offs
Learned rules need data, compute and evaluation, can't easily explain themselves, and can memorise the training set instead of learning the pattern.
The problem
2 min- Maya · Product managerRibeira loses 6% of room nights to no-shows. Can't we just ask the concierge's LLM about each booking?
- You · Engineer at StayHubOur rule today is "non-refundable means they'll show". It finds about 35% of no-shows.
- Lina · Senior engineer, your mentorBefore we pick a tool, make a guess.
The big idea
4 minMachine learning: give the program data and answers, and it finds the rule; judge it only on data it has never seen.
A new receptionist gets no rulebook for spotting no-shows. After months of watching bookings and who turned up, she just knows, because she adjusted her hunches every time she was wrong. That adjusting is training.
How it works
5 min- 1Predict
Run a past booking through the model with its current , the adjustable numbers inside it. It says "30% no-show risk".
- 2Measure
The guest didn't come. A turns "how wrong was 30%?" into one number.
- 3Nudge
moves every weight a tiny step in the direction that lowers the loss. Repeat over millions of bookings.
- 4Stack it
A stacks many such units in layers; many layers is what means.
- 5Training vs inference
Training changes the weights. uses frozen weights to answer. Our concierge calls are all inference: the LLM learns nothing from our chats.
- 6Overfitting
: the model memorises its training examples instead of the pattern. Only a held-out month it never saw reveals it.
Three kinds of learning: (examples with answers, like no-shows), (find groups without answers), (act, get a reward, improve).
Watch a decision being made
4 minLina sets up the no-show model (you do the split)
Build a no-show model for Hotel Ribeira and prove it beats today's rule (35% of no-shows found) before the hotel overbooks on it.
- 1Frame the question
Input: fields known at booking time (lead time, rate type, deposit, channel, past stays). Output: probability of no-show. Label: did the guest arrive?
Why: A field like "checked in" would leak the answer and make the model look perfect.
- 2Hold out a month
Train on bookings up to August; keep September aside, untouched while tuning. Lina checks the split is by date, not random.
Why: In real use the model predicts the future from the past. A later month is the honest rehearsal.
- 3Train small, compare with the rule
A small model first. On September, flagging the riskiest 5%: the rule finds 35% of no-shows, the model 62%, in under 10 ms.
pythonmodel.fit(X_train, y_train) # training: weights change p = model.predict_proba(X_september) # inference: weights frozenWhy: A model must beat the simple thing on unseen data, or it isn't worth its pipeline.
- 4Serve and watch it
The booking service calls it at checkout. Each month, compare predictions with who actually came, and retrain.
Why: The world changes; accuracy decays silently unless you measure it.
In real life
3 minNetflix: trains its own models
- Recommendations are famously learned from members' viewing history (it ran the public Netflix Prize on it)
- Needs data teams, training pipelines and constant evaluation
Fits a defined prediction with lots of your own history.
Expedia: plugged in a pretrained LLM
- Announced in 2023 a ChatGPT-powered conversational trip planner
- No training data needed; pays per call, depends on someone else's model
Fits open-ended language tasks with no labelled data.
What goes wrong
3 minA big network can memorise and still fail on new data.
Report results only on held-out data, next to the simple baseline.
With a few hundred examples, a model is noisy and hard to test.
Rules and logging first; a model when it clearly beats the rules.
New channels or policies decay accuracy silently.
Compare with real outcomes monthly and retrain on a schedule.
Trade-offs
3 min| Option | Fits when | You pay |
|---|---|---|
| Hand-written rules | Little data, strict explainability | Misses combinations nobody thought of |
| Classic ML on your data | Structured data, lots of labelled history | A pipeline, retraining, monitoring |
| Pretrained LLM via prompting | Free text, many small tasks, no labels | Slower, costlier per call, less predictable |
- Karim · CTOWe already pay for an LLM. Send it each booking and ask "no-show risk?". No pipeline to build.
- Lina · Senior engineer, your mentorA second per booking at checkout, and it's never seen our 20 million bookings.
- Karim · CTOA training pipeline is an engineer for a month.
Your job as tech lead
4 minClaude Code can write the code for this. You still own the decisions, and you have to know what good looks like to accept or reject its work.
- Whether the problem needs ML, and which kind: no-shows from booking fields is a small model, not an LLM call.
- The bar to beat: the rule's 35%, on a month the model never saw.
- What the score may trigger: a deposit request, an overbooking suggestion, or nothing automatic.
Hotel Ribeira wants no-show predictions. Plan first, then build a baseline in notebooks/no-show. Train on bookings with check-in before 2026-09-01, evaluate on September 2026 only. Features: lead time, rate type, channel, deposit, length of stay; no names, emails or free text. Start with a simple model, not a neural network. Report the share of no-shows found at the same false-alarm rate as our current rule (35%), and the training and September scores side by side.
- Training and September scores side by side; 97% vs 41% is .
- The split is by date: ask Claude to print the date ranges.
- No feature is known only after the stay, and no personal data is used.
- It reports only accuracy: with 6% no-shows, "everyone shows up" is 94% accurate and useless.
- It splits randomly and reports a great score.
- It claims the concierge "will learn" from guests' corrections.
Check yourself
2 minNext episode: the old support-ticket classifier sends a long, angry message about a suite to the "anniversary gifts" team, and Lina explains why transformers read differently.
Mark it complete to update your skill map.
Go deeper (optional)You don't need this to understand the lesson. Open it when a project needs the details: Technical deep dive, Visual diagram, Analogy, Check your understanding, Practice ladder, Explain it yourself.
Technical deep dive
Lina sets up the no-show model (you do the split)
Build a no-show model for Hotel Ribeira from StayHub's past bookings, and prove it beats today's rule (35% of no-shows found) before the hotel overbooks on it.
- 1Frame the question
Input: booking fields known at booking time (lead time, rate type, deposit, channel, past stays). Output: probability of no-show. Label: did the guest arrive?
Why: Only use what you know at booking time. A field like "checked in" would leak the answer and make the model look perfect.
- 2Hold out a month
Train on bookings up to August; keep September aside and never look at it while tuning. You do this split; Lina checks it's by date, not random.
Why: Guest behaviour drifts with seasons. Testing on a later month mimics real use: predicting the future from the past.
- 3Train with the loop
Start with a small model. Run predict → loss → nudge until the loss on the training data stops improving.
pythonmodel.fit(X_train, y_train) # training: weights change p = model.predict_proba(X_september) # inference: weights frozen print(share_of_no_shows_found(p, y_september, flag_top=0.05))Why: A small model is fast to train, cheap to run and easier to debug than a giant one.
- 4Compare with the rule
On September, flagging the riskiest 5% of bookings: the rule finds 35% of no-shows, the model 62%.
Why: A model must beat the simple thing on unseen data, or it isn't worth its pipeline.
- 5Serve and watch it
Save the weights; the booking service calls the model at checkout (< 10 ms). Each month, compare predictions with who actually came, and retrain.
Why: Inference uses frozen weights, but the world keeps changing. Accuracy decays silently unless you measure it.
| Training | Inference | |
|---|---|---|
| What happens | Predict + loss + adjust the weights | Predict only, weights frozen |
| How often | Once, or on a schedule (nightly to yearly) | Every request, all day |
| Compute | Huge for LLMs; small for our no-show model | Milliseconds for ours; a GPU slice per LLM call |
| Changes the model? | Yes, that's the point | No. Our prompts never teach the model |
| What to watch | Overfitting, bad data, leaked answers | Latency, cost, drift from the training data |
Visual diagram
Two loops with different owners, costs and speeds: the training loop (left) produces weights; the inference path (right) uses them.
Analogy
- A sound engineer's mixing deskA million knobs on the deskMachine learningThe model's weights
- A sound engineer's mixing deskA judge scoring how far off it soundsMachine learningThe loss function
- A sound engineer's mixing deskTurning every knob a little in the better directionMachine learningGradient descent
- A sound engineer's mixing deskPractising only on the same 20 songsMachine learningOverfitting
- A sound engineer's mixing deskTaping the knobs and touring with itMachine learningInference with frozen weights
Where the analogy breaks: a sound engineer understands music. The training process understands nothing. It just follows the numbers downhill, which is why it can learn odd shortcuts from your data.
Check your understanding
Practice ladder
Score two bookings by hand
Estimation Warm-upThe trained one-neuron model computes score = 1.0 × lead_months − 6.7 × non_refundable − 3.5, then turns the score into a probability with the sigmoid:
| score | −10 | −4 | −2 | 0 | 1.5 | 3 |
|---|---|---|---|---|---|---|
| no-show probability | 0.00005 | 0.02 | 0.12 | 0.50 | 0.82 | 0.95 |
Trace both bookings: - A: booked 5 months ahead, refundable (non_refundable = 0) - B: booked 0.5 months ahead, non-refundable (non_refundable = 1)
Compute each score, read the probability, and say which one a careful hotel might overbook against.
Finish the training plan
Design PracticeLina's plan for a no-show model for all Lisbon hotels has two gaps. Fill in steps 2 and 4.
- Frame: input = booking fields known at booking time; output = no-show probability; label = arrived or not.
- Split the data: ___
- Train a small model on the training part.
- Decide if it's good enough: ___
- Serve at checkout, compare predictions with real outcomes monthly, retrain.
Flag urgent reviews
Decision PracticeStayHub receives 40,000 guest reviews a month in 9 languages. Hotel managers want urgent ones (hygiene, safety, billing errors) flagged within an hour. Nobody has ever labelled reviews as urgent or not.
Choose between hand-written rules, training your own model, and prompting a pretrained LLM. Say what data you'd need, how you'd know it works, and what you'd do first.
Fine-tune the concierge on our policies?
Decision StretchKarim: "Instead of sending hotel facts in every concierge call, let's fine-tune the LLM on all our hotel policies. Then it just knows them, and the prompts are shorter."
Facts: StayHub has 9,000 hotels. Policies change daily (prices, breakfast hours, renovations). A fine-tuning run takes a day and costs a few thousand euros. Today, facts for one hotel add about 1,500 tokens per call.
Write a short decision: "We chose X over Y because…, accepting the risk of…".
Explain it yourself
Explain to a product manager how a neural network 'learns' to predict no-shows, and why the chatbot doesn't learn from guests' messages.