L16 | English F3 Student Learning Log
L16 | English F3 Student Learning Log
Persona: I'm a Form 3 (Grade 9) student and I only read English. I know basic Python (variables, for loops, lists) and school algebra up to quadratics. I learn from the official pages, the videos with captions, and the book. Kaggle notebook steps are written as a practice log that follows the official notebooks.
What I understood (in my own words)
- Callbacks are like sockets left in the training process; plug one in to add a feature.
- Exceptions can end training early when needed.
- Hooks let me peek at the numbers each layer produces.
- Plotting activation distributions shows whether the model is 'broken'.
Where I got stuck, and how I got unstuck
| Where I got stuck | How I solved it |
|---|---|
| The callback flow was confusing | I drew a timeline: before_fit → before_epoch → before_batch → after_batch → after_epoch → after_fit, and marked where each callback runs. |
| I'd only used 'with' to open files | I learned 'with' automatically runs a start step and an end step, which suits wrapping the setup and cleanup around fit. |
My answers to the exercises
Q1. Explain callbacks with an everyday example.
Like setting an alarm: the school day carries on as usual, but at a set time the alarm goes off by itself. A callback is code that runs automatically at a set moment in training.
Q2. Why look at the mean and standard deviation of each layer's activations?
If the mean or standard deviation blows up or shrinks towards 0, the signal is exploding or vanishing through the network and the model can't learn well. Watching them catches problems early instead of after a failed run.
Q3. How could this lesson's tools stop training automatically once validation accuracy hits 95%?
Write a callback that checks validation accuracy in after_epoch; if it's ≥ 95%, raise CancelFitException, and the Learner stops training.
My Zettelkasten card
Card｜A good process leaves sockets so features can be plugged in later
The Learner's key idea is callbacks. The main training flow never changes, but there are sockets before and after every stage. Logging metrics, switching devices or stopping early are all callbacks plugged in. The core stays simple while features keep growing.
Our football training works the same way. Warm-up, passing drills, small-sided games and cool-down happen in the same order every session, but the coach slots in shooting practice before a match, set pieces when we've been conceding corners, and rehab exercises for injured players. The structure stays fixed; the content flexes. Too many sockets can get confusing, though, when you can't tell what runs when, so naming and documentation matter.
My next step: add a callback to my own training loop that prints the loss after every epoch.
🔗 Related notes to grow next: → System design: 'Stable core, plug-ins for extras' → Training: 'A fixed structure with flexible modules' → Debugging: 'Intermediate numbers reveal problems before final results do'
Back to lesson note：L16_Learner框架_202611041526
