3.4 Modeling Techniques for Interpretability Requirements

Google Cloud Professional Machine Learning Engineer Exam

Track your progress as you read

Finished sections get a check mark.

1 Introduction & Exam Overview

0.1 Exam Overview, Blueprint & Certification Logistics 0.2 Study Strategy, Scenario Mechanics & 8-Week Roadmap

2 Section 1: Architecting Low-Code AI Solutions (~13%)

1.1 BigQuery ML: Model Types, SQL Syntax and In-Database Evaluation 1.2 Feature Engineering and Feature Selection in BigQuery ML 1.3 Generating Predictions with BigQuery ML 1.4 AutoML on Agent Platform: Tabular, Image, Text and Video Training 1.5 Fine-Tuning Gemini Models from BigQuery 1.6 Model Garden: Evaluating and Selecting the Right Model 1.7 Industry-Specific AI APIs: Document AI, Vision, Translate and Speech 1.8 Generative Media and Models as a Service: Gemini, Imagen and Veo 1.9 Optimizing Gemini Applications for Cost, Latency and Availability

3 Section 2: Collaborating Within and Across Teams to Manage Data and Models (~16%)

2.1 Organizing and Exploring Tabular, Text, Image and Video Data 2.2 Choosing the Preprocessing Tool: BigQuery, Dataflow, Spark and In-Memory Python 2.3 Creating and Consolidating Features in Agent Platform Feature Store 2.4 Data Privacy, PII Handling and Sensitive Information 2.5 Notebook Environments: Collaboration and Security Best Practices 2.6 Prototyping in Workbench and Colab Enterprise with PyTorch, scikit-learn and JAX 2.7 Prototyping with Model Garden Foundational and Open Models in Notebooks 2.8 Choosing the Development and Experimentation Environment 2.9 Evaluating Generative Solutions: LLM-as-a-Judge and RAG Evaluation 2.10 Experiment Tracking, Artifact Lineage and Model Registry Governance

4 Section 3: Scaling Prototypes into ML Models (~21%)

3.1 Choosing the Model Type: ARIMA, DNN, LLM and Classical Baselines 3.2 Choosing the Product: AutoML, BigQuery ML, Custom Training and Pipelines 3.3 Choosing the Deployment Strategy at Design Time 3.4 Modeling Techniques for Interpretability Requirements 3.5 Organizing Training Data on Cloud Storage and BigQuery 3.6 Ingesting Structured and Unstructured Data into Training Pipelines 3.7 Training SDKs and Services: Custom Training, Kubeflow on GKE, AutoML and Tabular Workflows 3.8 Troubleshooting ML Model Training Failures 3.9 Hyperparameter Tuning, Bayesian Optimization and Vizier 3.10 Model Evaluation Metrics, Transfer Learning and Fine-Tuning 3.11 Evaluating Compute and Accelerator Options: CPU, GPU and TPU 3.12 Distributed Training Strategies, Hardware Acceleration and Performance Optimization

5 Section 4: Serving and Scaling Models (~20%)

4.1 Batch and Online Inference: Agent Platform, Model Garden, Cloud Run and GKE 4.2 Rollout Strategies: Canary, Traffic Splitting, Shadow and Blue-Green 4.3 Tuning Models for Production: Vector Search and Model Compression 4.4 Deploying Models to Public and Private Endpoints 4.5 Choosing Serving Hardware: CPU, GPU, TPU and Edge 4.6 Scaling the Serving Backend for Throughput

6 Section 5: Automating and Orchestrating ML Pipelines (~18%)

5.1 Validating Data and Models Inside Pipelines 5.2 Agent Platform Pipelines: Kubeflow Pipelines (KFP) and TFX Architecture 5.3 Reusable Pipeline Components, Artifacts and ML Metadata Lineage 5.4 Ray on Agent Platform for Distributed Python Workloads 5.5 MLOps CI/CD Automation, Retraining Triggers and Skew Prevention

7 Section 6: Monitoring AI Solutions (~13%)

6.1 Securing AI Systems: Exfiltration, Malicious Prompting and Model Armor 6.2 Responsible AI, Explainable AI, Fairness Metrics and Model Governance 6.3 Model Monitoring: Feature Skew and Drift Detection 6.4 Operational Troubleshooting, Performance Profiling and Cost Optimization 6.5 Monitoring, Testing and Evaluating Generative AI in Production

3.4 Modeling Techniques for Interpretability Requirements

Key Takeaways Explain This Topic AI

Intrinsically interpretable models — linear, logistic, shallow trees, GAMs, rule lists — are the answer when a regulator or reviewer must understand the model itself, not just its outputs.

Post-hoc explanations such as Shapley values, integrated gradients, and LIME describe a black box approximately and do not make it inherently interpretable.

Integrated gradients requires a differentiable model and a baseline input; sampled Shapley works on non-differentiable models such as tree ensembles.

Global interpretability answers "what drives this model", local interpretability answers "why this decision" — regulatory adverse-action notices need the local kind.

Monotonic constraints let a boosted tree encode required directional relationships, giving auditable behaviour without dropping to a linear model.

Last updated: September 2026

• 3.4 Modeling Techniques for Interpretability Requirements
• Blueprint reference: Section 3.1, "Modeling techniques given interpretability requirements."

Interpretability appears in Section 3 as a modeling consideration, not only as an explainability tool bolted on afterwards. The exam distinction that matters most: some requirements can be met with post-hoc explanations, and some can only be met by choosing a different model.

Intrinsic Interpretability Versus Post-Hoc Explanation

• Intrinsically interpretable Post-hoc explained
• What it means The model's structure is directly readable A separate method approximates the model's behaviour

Examples Linear/logistic regression, shallow decision trees, GAMs, rule lists, scorecards Shapley values, integrated gradients, LIME, partial dependence

• Fidelity Exact — the explanation is the model Approximate — a faithful-but-not-identical account
• Regulator asks "how does the model decide?" Answerable exactly Answerable only approximately
• Typical accuracy Lower on complex problems Whatever the underlying model achieves

The decisive scenario: a regulator or model-risk committee requires that the model itself be reviewable and its decision logic reproducible by hand. Post-hoc attributions do not satisfy that, because they are an approximation produced by a second algorithm. Choose a linear model, a scorecard, or a shallow tree.

When the requirement is instead "explain individual decisions to affected customers," a black-box model with reliable local attributions is usually acceptable, and the accuracy is worth keeping.

Global Versus Local

Global — which features drive the model overall. Feature importances, aggregate attributions, partial dependence plots. Used for model review, debugging, and documentation.

Local — why this input received this output. Per-row attributions. Used for adverse-action notices, dispute handling, and clinician-facing justification.

Regulatory scenarios almost always need local explanations. "We publish a ranked list of the model's top features" is not an adverse-action notice, and it is a common wrong option.

The One Applicability Rule to Carry Into Design

The mechanics of Explainable AI on the Agent Platform — sampled Shapley, integrated gradients, XRAI, and baseline selection — are covered in Section 6.2, Responsible AI, Explainable AI, Fairness Metrics and Model Governance . Only one of those facts constrains the modeling decision and therefore belongs here:

A non-differentiable model cannot be explained with gradient-based methods. Integrated gradients and XRAI need gradients, which a tree ensemble does not have, so choosing gradient boosting commits you to model-agnostic sampled Shapley for attributions. Choosing a neural network keeps both options open. If a project has already standardized on integrated gradients for consistency across its model portfolio, that decision silently rules out tree ensembles — which is exactly the kind of constraint that should be surfaced at design time rather than discovered at explanation time.

Monotonic Constraints: The Middle Path

Often the requirement is not full interpretability but guaranteed directional behaviour : risk must not decrease as debt rises; price must not decrease as square footage rises. Gradient boosting implementations support monotonic constraints that enforce this per feature during training.

This gives an auditable, defensible property — "the model provably never rewards higher debt" — while keeping most of the accuracy of a boosted ensemble. When a scenario asks for a guarantee about direction rather than a full account of the logic, monotonic constraints beat both a linear model (accuracy loss) and unconstrained boosting (no guarantee).

Other Techniques That Buy Interpretability

Feature reduction. A model with 12 well-chosen features is reviewable; one with 900 is not, whatever the attribution method.

Binned / scorecard models. Widely used in credit because the resulting model is a small table a human can read and audit.

Generalized additive models (GAMs). Each feature contributes an independently plottable shape function, giving non-linearity with per-feature readability.

Distillation to a simpler surrogate. Train a complex model, then fit an interpretable one to its predictions. Useful for understanding, but the surrogate is not the deployed model — do not offer it as an audit substitute for the deployed system.

Documenting the Decision

Whatever technique is chosen, the artifacts a review expects are the model card (intended use, data, evaluation, limitations), the explanation method and its configuration (including baseline), and evidence that explanations were validated — for example, that attributions align with domain expectations on known cases.

Exam Traps

Offering post-hoc attributions when the requirement is that the model itself be reviewable.

Integrated gradients on a boosted tree. Not differentiable; use sampled Shapley.

Forgetting the baseline for integrated gradients, or choosing a meaningless one.

Global importances presented as per-customer explanations.

A distilled surrogate offered as the auditable artifact when a different model is deployed.