Permutation Feature Importance
A model-agnostic way to measure how much a trained model actually relies on a given feature, by scrambling that feature's values and checking how much worse the model's predictions get.
Prerequisites: Random Forests and Out-of-Bag Error
You've trained a gradient-boosted model on 40 features to predict next-day returns, and it works. A natural next question is: which of those 40 features is the model actually leaning on? Some models expose an internal notion of "importance" (like how often a tree splits on a feature), but those internal measures are tied to the specific algorithm and can be biased toward certain feature types. Permutation importance sidesteps all of that by testing a much more direct question empirically: if you break a feature's real relationship with the outcome, how much does the model's performance suffer?
An analogy: pulling one musician out of an orchestra
Imagine judging how important the second violin section is to an orchestra's performance, without knowing anything about music theory. One way to test it: replace the second violins' actual sheet music with random notes, played at the same times and volumes, and listen to how much worse the overall performance sounds. If the performance falls apart, the second violins were carrying real, load-bearing structure. If it sounds almost the same, that section wasn't contributing much that the rest of the orchestra wasn't already covering. Permutation importance does exactly this to a trained model: it randomly shuffles one feature's column of values — destroying its real relationship with the target while keeping its overall distribution intact — and measures how much the model's accuracy degrades.
The procedure, step by step
- Measure the model's baseline error on a held-out validation set, call it .
- Pick one feature and randomly shuffle its values across all the rows in that validation set, leaving every other feature untouched.
- Re-run the (already-trained) model's predictions on this shuffled data and measure the new error, .
- The feature's importance is the degradation: .
- Repeat for every feature, and repeat the shuffle several times per feature to average out random shuffling luck.
In plain English: a feature the model genuinely depends on will hurt performance badly when scrambled, because the model is fed garbage in place of a real signal it was using; a feature the model barely uses will barely move the error when scrambled, because there was little real signal there to lose.
Worked example: three features, one dominant
A model trained to predict next-day return direction has a baseline validation error (1 − accuracy) of . Shuffling "5-day momentum" raises the error to ; shuffling "sector dummy" raises it to ; shuffling "random noise column" (deliberately included as a sanity check) raises it to . Importances are:
Momentum is clearly doing the heavy lifting. Sector contributes a little. The noise column — which by construction carries zero real information — comes out near zero, which is exactly the sanity check it's there for: if a genuine feature scored anywhere near the noise column's importance, that would be a signal the model isn't really using it either, whatever its algorithm-internal importance score might claim.
What this means in practice
Because permutation importance only requires the ability to predict and score, it works on any model — linear, tree ensemble, or neural network — unlike importance measures baked into a specific algorithm. It's the standard first check when a stakeholder asks "what is this model actually using," and adding a deliberately random noise column as a control (as in the example above) is a cheap way to calibrate what "importance near zero" should look like for your specific data and model. It measures predictive reliance, not causal importance — a feature can score high because it's a good proxy for something else the model can't directly see, not because it causes the outcome.
Permutation feature importance measures how much a model's error rises when one feature's values are randomly shuffled, breaking its real relationship with the target while leaving everything else intact — a model-agnostic way to see what the model actually relies on, not just what an internal algorithm score claims.
When two features are highly correlated (say, two similar momentum lookback windows), shuffling just one of them barely hurts performance, because the model can lean on the other correlated feature instead — making both look unimportant even though the pair together carries real signal. Check correlated feature groups jointly, not one at a time.
Related concepts
Practice in interviews
Further reading
- Breiman, Random Forests, Machine Learning 45