Follow the transformation
Start with the audience and decision.
Choose an explanation method that matches model type and question (global vs local).
Use held-out data when measuring importance that depends on predictive performance.
Interpretation & Production Thinking · Lesson 81
PDP and ICE
PDP and ICE is part of model interpretation and communication.
What PDP and ICE actually means
PDP and ICE is part of model interpretation and communication. Explanations describe model behaviour under specific assumptions; they are not automatically causal statements about the real world.
PDP and ICE matters because a trained model becomes a system only when it can be explained, persisted, served, monitored and governed consistently with its validated preprocessing and intended use.
Deeper walkthrough
Read PDP and ICE as a mechanism, not a recipe
Treat this as a sequence of observable decisions rather than one opaque command. Stage 1: Start with the audience and decision. Stage 2: Choose an explanation method that matches model type and question (global vs local). Stage 3: Use held-out data when measuring importance that depends on predictive performance. Final checkpoint: State uncertainty, limitations and what the explanation does not establish.
Know what would convince you
- Reload the packaged pipeline in a fresh process/environment and reproduce known predictions.
- Validate the inference schema and feature order on both valid and deliberately invalid requests/batches.
Useful distinctionCoefficients: Direct model parameters; interpretation depends on scaling/encoding and model form.
Click a stage to inspect what happens, what changes, and what should be checked before moving on.
Stage 1
Start with the audience and decision
Start with the audience and decision. For PDP and ICE, identify the exact state before this stage, the operation or rule applied here, and the observable state afterwards so the mechanism remains inspectable.
State focus: identify exactly what changed at this stage and what observable evidence confirms that change.
Trace the mechanism step by step
- Start with the audience and decision.
- Choose an explanation method that matches model type and question (global vs local).
- Use held-out data when measuring importance that depends on predictive performance.
- Check correlated features because importance can be shared or displaced.
- State uncertainty, limitations and what the explanation does not establish.
Make the concept concrete
Demonstration
Text example
PDP: average the model prediction after setting a feature to each grid value across all rows.
ICE: draw the same prediction-vs-feature curve separately for individual rows.Expected / illustrative result
If ICE curves differ strongly, a single average PDP can hide heterogeneous effects or interactions.
Interpret the result.
For PDP and ICE, connect the reported result to the exact training/validation/prediction step that produced it and check one prediction, fold or metric component independently.
Know what this is — and what it is not
CoefficientsDirect model parameters; interpretation depends on scaling/encoding and model form.Permutation importancePerformance loss after shuffling a feature.PDPAverage predicted response as a feature is varied, marginalising over data.ICEIndividual prediction curves rather than the average.SHAPAdditive feature-attribution framework tied to a background/reference distribution.When it is appropriate
Use PDP and ICE when a trained model must be interpreted, persisted, served or monitored as part of a repeatable prediction system rather than a one-off notebook.
When to stop or reconsider
Do not deploy or automate when feature definitions, software/model versions, input contracts, monitoring signals or ownership for retraining are unspecified.
Failure modes to recognise
- Saving only model weights while losing preprocessing, feature order, thresholds or software-version assumptions.
- Assuming offline validation guarantees behaviour after deployment despite drift and changing data contracts.
- Monitoring aggregate accuracy alone without input, subgroup, calibration or business-outcome signals.
How to check the result
- Reload the packaged pipeline in a fresh process/environment and reproduce known predictions.
- Validate the inference schema and feature order on both valid and deliberately invalid requests/batches.
- Define and test monitoring/retraining triggers against simulated drift or changed input distributions.
Demonstrate understanding
Try this:
Build a tiny, inspectable example of PDP and ICE. First start with the audience and decision. Then choose an explanation method that matches model type and question (global vs local). Write the expected result before running it, and explain one condition that would make the result misleading or invalid.
Treat the model as one component in a versioned system. Reproduce a prediction from raw input after reload, then deliberately violate one input contract and inspect the response.
Check reasoning, not memorisation
Before trusting a result from PDP and ICE, which check provides the strongest evidence that you understand and applied it correctly?
Keep the important distinctions visible
Step 1Start with the audience and decision.Step 2Choose an explanation method that matches model type and question (global vs local).Step 3Use held-out data when measuring importance that depends on predictive performance.Step 4Check correlated features because importance can be shared or displaced.What to remember
- PDP and ICE is part of model interpretation and communication. Explanations describe model behaviour under specific assumptions; they are not automatically causal statements about the real world.
- Start with the audience and decision.
- Saving only model weights while losing preprocessing, feature order, thresholds or software-version assumptions.
- Reload the packaged pipeline in a fresh process/environment and reproduce known predictions.