Design an Explainable AI Dashboard

Problem Statement

Design a web-based dashboard that displays predictions from an ML model alongside explanations of the features that influenced each result. The system must integrate SHAP (SHapley Additive exPlanations) or LIME (Local Interpretable Model-agnostic Explanations) calls with model inference, handle both real-time and batch explanation modes, store partial analysis results, and let data scientists or business decision-makers browse individual predictions or explore global feature importance and partial dependence plots.

This is not a simple CRUD dashboard. The central engineering challenge is that explanation computation is 10 to 100 times more expensive than raw model inference. A gradient-boosted tree model might return a prediction in 2 milliseconds, but computing SHAP values for that same instance can take 50 to 500 milliseconds. For deep learning models, a single LIME explanation can require 2 to 10 seconds because it generates hundreds of perturbed samples and runs each through the model. When dozens of data scientists simultaneously explore explanations across thousands of predictions, the system must manage a compute-intensive workload that behaves nothing like a typical read-heavy web application.

Why This Problem Is Distinctive

A standard analytics dashboard reads precomputed aggregates from a warehouse. An XAI dashboard must compute explanations on demand because SHAP values depend on the specific model version, the background dataset used for expected values, and the exact feature values of the instance being explained. A model retrain invalidates every cached explanation. A change in the background reference dataset shifts every SHAP value. The system therefore sits at the intersection of a model-serving platform, an async compute pipeline, and an interactive visualization layer.

The brief specifies four functional requirements: an inference endpoint integrated with SHAP or LIME, a UI for local single-instance explanations, global feature importance and partial dependence plots, and logging of user queries and feedback. The non-functional requirements demand scalability under concurrent load, moderate latency acknowledging that explanations are heavier than inference, graceful degradation when SHAP computation partially fails, and compliance readiness for regulated decisions.

The Bridging Gap

Most preparation resources treat explainability as a Python library call. The gap this design fills is the production architecture that bridges SHAP or LIME computation with model predictions at scale, handling concurrency for large user query volumes. A data scientist at a lending company does not want to run a Jupyter notebook to understand why a loan application was denied. They want a dashboard that shows the prediction, the top contributing features with directional impact, a waterfall or force plot, and the ability to drill into counterfactual scenarios. The system must deliver that experience with sub-second interactivity for cached results and bounded wait times for fresh computations.

The Four Architectural Planes

1. Inference Plane: Receives feature vectors, runs the registered model, returns predictions with version and timestamp metadata.
2. Explanation Plane: Computes SHAP or LIME values asynchronously or synchronously, stores partial results, and manages background dataset references.
3. Aggregation Plane: Computes global feature importance rankings, partial dependence curves, and interaction effects across batches of instances.
4. Presentation Plane: Renders local explanations as waterfall, force, and dependence plots; renders global views as bar charts, PDP grids, and SHAP summary plots; logs user interactions and feedback.

A strong interview answer keeps these planes separate. The inference plane must never block on explanation computation. The explanation plane must degrade gracefully when a SHAP kernel times out. The aggregation plane must handle incremental updates as new predictions arrive. The presentation plane must render partial results while full computations are still in flight.