The Book of Why (Part 1)

I stumbled on this book about 2 years ago. The topic has been a lifelong interest of mine. The dream of every data person is to be able to say “By doing X, we can increase our chance of solving Y by Z%.” Not describe, not predict, but actually cause the change. So the subject was familiar, even if the author wasn’t. I had never heard of Judea Pearl.

The first thing that came up when I browsed about him was his Ladder of Causation, and his claim that current LLM tools can’t deal with causal thinking because they’re stuck on the first rung. I thought to myself: this is interesting, but I’m not sure the book will be useful.

Turns out it is.

When I explain causality to peers and non-data people, I lean on the catchphrase everyone has already heard: correlation doesn’t always mean causation. The usual example is the rooster and the sun. We often see a rooster crow as the sun rises.

The rooster is an easy case. Nobody needs a diagram to reject “the sun rises because the rooster crows.” Say it and you get a laugh. Say “the rooster crows because the sun rises” and you might start a real debate with your local poultry farmer. The problem is that this ease is misleading. Most real problems don’t arrive pre-labeled as absurd. Take “marriage causes a person to be happy.” You can’t refute it just by flipping it into “a happy person is more likely to be married.” Both statements sound reasonable, and swapping one for the other settles nothing. That is exactly where the slogan runs out and you need real machinery.

Pearl’s machinery, as I understand it, comes down to two moves.

First, you draw the causal model. A diagram that lays out which variables influence the outcome and how they relate. The direction of the arrow is the whole game. “The sun rises because the rooster crows” and “the rooster crows because the sun rises” use the same two variables and mean completely different things.

Second, you eliminate the confounder. A confounder is a variable that influences both the thing you observe and the outcome. Pearl describes several kinds of them, and there are two methods to remove them, the back-door and the front-door. I’ll leave it at that for now.

What made the book genuinely exciting for me is that it answered a question I didn’t come in with: what’s next for data teams in a world of LLMs? Pearl’s DAG-based approach fits a clean division of labor. We still need a human to come up with the causal model. If we want to solve churn, a person first lists the variables that influence it and how each one relates to the outcome. Once that model exists, we can hand the rest to an LLM. They can write the code to run the independence checks on the model, examine each variable, and establish a causality score. They can read charts and diagrams, and they can read and write code. The business understanding stays with the human, the execution goes to the machine.

This is also where I part ways with the usual anxiety about Pearl’s LLM claim. I agree with his assessment that LLMs are stuck on the first rung. It doesn’t matter to me. The workflow above doesn’t need them to reason causally. Humans still own the “why,” and the LLM does the work around it. His limit isn’t a problem for the plan, it’s the reason the plan is split that way.

I want to close honestly, because there is a lot I don’t have yet. I don’t remember the full taxonomy of confounders Pearl lays out, and knowing which type you’re facing is what tells you whether to use the back-door or the front-door. I also don’t yet understand d-separation, which is what tells you whether the causal model you drew is any good in the first place. Those are the pieces I want to work through next.

That’s Part 2. For now, if this review does one thing, I hope it makes you slower to accept a correlation as an answer.