Skip to main content

The Network That Learns Who Comes Back


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

Popular posts from this blog

The First Notebook

Somewhere between where I was and where I am going! Welcome to One Notebook at a Time. Every data project starts the same way. A blank notebook. A first cell. No idea yet what the data is going to say, or whether the model is going to work, or whether the whole approach is wrong and you'll scrap it by Tuesday. You just start. This blog is that first cell. Why "One Notebook at a Time" I picked this name because it's literally true on two levels. If you're a data person, you already know what a notebook is — Jupyter, Colab, whatever your tool of choice. It's where the real thinking happens. Not the polished dashboard, not the final slide deck — the notebook. Messy cells, half-finished thoughts, a graph that didn't work followed by one that finally did. But it's also true in the older sense of the word. A notebook is just where you write things down before you know what they're going to become. That's what this space is for. One notebook — one pos...

The Line of Best Fit Isn't "Best" — It's a Decision What I wish someone had told me before I ran my first regression model.

  Same data. Different definition of "best." Different line." Here's something that took me longer than I'd like to admit to figure out about linear regression. That line through your scatter plot — the one everyone calls the "line of best fit" — isn't objectively the best anything. It's the best fit for one very specific definition of the word "best." Swap that definition, and you get a completely different line. Equally valid mathematically. Just built on a different set of assumptions. Once I understood that, I started looking at every machine learning model differently. What Everyone Gets Taught (And What Gets Left Out) The standard introduction to linear regression goes something like this: draw a line through your data that minimises the total error between your predictions and the actual values. Square those errors, add them up, minimise the sum. Done. This is Ordinary Least Squares (OLS) — the engine behind most introductory r...