Explainability in JupyterLab and Beyond: Interactive XAI Systems for Integrated and Collaborative Workflows

TL;DR

The paper addresses the mismatch between Python-centric model development and interactive XAI tools by proposing three embedding design patterns for front-end explanations in Jupyter notebooks. It introduces bonXAI, an open-source toolkit with DataExplorer, DataSelector, and InferenceExplorer to realize one-way, two-way, and bi-directional approaches in a PyTorch text classification workflow. The authors discuss best practices, workflow alignment, and data-type considerations to enable more collaborative, human-centered AI within computational notebooks. They also raise open questions about data-size limits, alternative patterns, and extensions beyond Jupyter to guide future research.

Abstract

Explainable AI (XAI) tools represent a turn to more human-centered and human-in-the-loop AI approaches that emphasize user needs and perspectives in machine learning model development workflows. However, while the majority of ML resources available today are developed for Python computational environments such as JupyterLab and Jupyter Notebook, the same has not been true of interactive XAI systems, which are often still implemented as standalone interfaces. In this paper, we address this mismatch by identifying three design patterns for embedding front-end XAI interfaces into Jupyter, namely: 1) One-way communication from Python to JavaScript, 2) Two-way data synchronization, and 3) Bi-directional callbacks. We also provide an open-source toolkit, bonXAI, that demonstrates how each design pattern might be used to build interactive XAI tools for a Pytorch text classification workflow. Finally, we conclude with a discussion of best practices and open questions. Our aims for this paper are to discuss how interactive XAI tools might be developed for computational notebooks, and how they can better integrate into existing model development workflows to support more collaborative, human-centered AI.

Figures (4)

• Figure 1: The DataExplorer widget is an example of design pattern 1. This type of XAI system provides a display based on a given a model and/or dataset as input. ① The DataExplorer widget is instantiated with some data that is converted to JSON and sent to the front-end. ② While users can interact with the display, their interactions do not change data attributes on the back-end Python kernel.
• Figure 2: The DataSelector widget is an example of design pattern 2, which synchronizes the data/states between the front-end and back-end, allowing user inputs to be propagated back to the notebook. ① As before, the DataSelector widget is instantiated with some data that is converted to JSON and sent to the front-end. ② Users can interactively explore the data set by searching or applying filters. ③ The filtered data set from user interactions can be accessed in subsequent notebook cells/code blocks.
• Figure 3: The InferenceExplorer module demonstrates how Design Pattern 3 might be applied. ① Like in previous examples, data is converted to JSON and sent to the front-end. In this widget, we also provide a pre-trained model. Since a model cannot be converted to JSON format, the model is simply registered as a widget attribute in the Python back-end. The widget computes and visualizes the UMAP embedding of all text in the data set. ② Users can interactively input some new text for inference. Its label, predicted by the pre-trained model on the Python back-end, is displayed in the table below. ③ The position of this new text is also computed and added to the UMAP embedding visualization as a red dot. ④ To explain why their input was given a particular label, users can brush and select its nearest neighbors in the visualization. ⑤ These selected neighbors are listed in a separate table. We can see that tonally, they resemble the user input text, and have the same label.
• Figure 4: The InferenceExplorer module applies the third design pattern to provide bi-directional callbacks. When users interact with input components, their interactions update the data/state on the Python kernel back-end. These changes automatically trigger callback functions for data processing, model inferencing, and updating the front-end display.