It's been a minute since I last posted here — most of that gap was spent heads-down on a project I just wrapped up, so let's catch up.
![]() |
| Where a heartbeat becomes a data point — teaching a neural network to see risk before it happens. |
If you've followed along before, you know this space usually lives in supervised learning — regression, classification, the more "classical" side of the toolkit. This post is a deliberate left turn into neural networks, the first one I've built and documented fully end-to-end. I expect this thread to keep rotating: NLP is probably next, and I'll likely circle back to supervised or unsupervised learning again after that. Think of it as this notebook's current chapter, not a permanent pivot.
The setup
The project: predict whether a patient will be readmitted to hospital within 30 days of discharge, using a 5,000-row dataset of vitals, prior admission history, chronic conditions, and a handful of administrative fields. It's a binary classification problem, and I built it as an Artificial Neural Network in TensorFlow/Keras — but the actual modeling code was the smaller half of the work.
What I made myself do differently this time
Two things, going in:
First, before letting Keras build anything, I hand-coded a single forward pass in
NumPy — random weights, a hidden layer, ReLU, a sigmoid output — on one real patient row.
The output number is meaningless with random weights, but watching every multiplication
happen by hand is what turns "I know forward propagation exists" into "I know what it's
actually doing." If you've only ever called .fit(), I'd genuinely recommend doing this
once.
Second, I refused to take "use Binary Cross-Entropy for classification" on faith. I trained the same architecture twice — once with MSE, once with BCE — and compared them directly. The MSE version came back with an R² near zero, basically explaining nothing. BCE punishes confident wrong answers much harder, which is exactly the property you want in a clinical setting, where a model confidently telling you "this patient is fine" when they're not is the costliest mistake on the table.
Where the project actually got hard
The baseline model overfit almost immediately — training accuracy climbing well past validation, the usual story. What came next is the part I think is worth writing about.
I ran four trials in a row on the same architecture, just dialing regularization up each time — more dropout, a stronger L2 penalty. It's the obvious first move, and I made it four times before stopping to actually look at what was happening. The train-test gap was shrinking, technically, but mostly because training accuracy was dropping, not because test accuracy was improving. I was quieting the symptom without touching the cause, and test accuracy stayed stuck in roughly the same narrow band the whole time.
So on trial five, I stopped turning the same dial and changed the shape of the network instead — narrower layers, less raw capacity to memorize, combined L1+L2 regularization instead of just stacking more dropout. That one trial beat all four of the previous ones: the best test accuracy of the project, and one of the smallest gaps between training and test performance.
What that pattern actually means
Across three different optimizers and five regularization trials, test accuracy never broke out of a roughly 7-point band. That's not what a hyperparameter problem looks like — it's what a ceiling in the features themselves looks like. No amount of further architecture tuning was going to push much past it. The honest next step is feature engineering — interaction terms, smarter binning of continuous variables, maybe richer data sources — not another round of dropout values.
The part I'd actually tell someone starting out
The useful learning here didn't come from the model that worked. It came from the four trials that didn't, and from forcing myself to actually ask why "more regularization" had stopped helping instead of assuming a fifth trial would finally do it. That habit of diagnosing instead of guessing is the thing I'm taking forward more than any specific architecture choice.
Full notebook, all five trials, and the final write-up (the kind I'd actually hand to a hospital analytics team) are public on GitHub: github.com/dshah-ds.
If you want to talk through any of it — or you've hit the same "added dropout, nothing changed" wall — find me on LinkedIn.
Next up on this notebook: probably NLP. Possibly back to supervised or unsupervised learning after that. One notebook at a time, like always.

Comments
Post a Comment