Introduction

Organizations need visibility into how models are forming predictions, in particular, if the model is generating unfair and partial results to certain protected classes. Bias monitors should be run routinely against batches of labeled and scored data to ensure that the model is performing within specifications. If the production bias metrics deviate beyond/below pre-set thresholds, then the appropriate alerts are raised for the data scientist or ModelOps engineer to investigate.

ModelOp Center provides bias monitors out-of-the-box (OOTB) but also allows you to write your own custom bias/fairness/group metrics to monitor your model. The subsequent sections describe how to add a bias monitor - assuming an OOTB monitor - and the detailed makeup of a bias monitor.

Adding Bias Monitor to a Business Model

As background on the terminology and concepts used below, please read the Monitoring Concepts section of the Model overview documentation. For this tutorial purposes, the instructions below use an out-of-the-box monitor and publicly available content provided by ModelOp, focusing on the German Credit Model and its related assets.

The "German Credit Data" dataset classifies people described by a set of attributes as good or bad credit risks. Among the twenty attributes is gender (reported as a hybrid status_sex attribute), which is considered a protected attribute in most financial risk models. It is therefore of the utmost importance that any machine learning model aiming to assign risk levels to lessees is not biased against a particular gender.

It is important to note that simply excluding gender from the training step does not guarantee an unbiased model, as gender could be highly correlated to other unprotected attributes, such as annual income.

Open-source Python libraries developed to address the problem of Bias and Fairness in AI are available. Among these, Aequitas can be easily leveraged to calculate Bias and Fairness metrics of a particular ML model, given a labeled and scored data set, as well as a set of protected attributes. In the case of German Credit Data, ground truths are provided and predictions can be generated by, say, a logistic regression model. Scores (predictions), label values (ground truths), and protected attributes (e.g. gender) can then be given as inputs to the Aequitas library. Aequitas's Group() class calculates commonly used metrics such as false-positive rate (FPR) and false omission rate (FOR), as well as counts by group and group prevalence among the sample population. It returns group counts and group value bias metrics in a data frame.

For instance, one could discover that under the trained logistic regression model, females have an FPR=0.32, whereas males have an FPR=0.16. This means that women are twice as likely to be falsely labeled as high-risk as men. The Aequitas Bias() class calculates disparities between groups, where a disparity is a ratio of a metric for a group of interest compared to a reference group. For example, the FPR-disparity for the example above between males and females, where males are the reference group, is equal to 32/16 = 2. Disparities are computed for each bias metric and are returned by Aequitas in a data frame.

Steps to follow:

1. In MOC, navigate to the business model to be monitored. In our case, as described above, that’s the German Credit Model.

2. Following the steps in Add a Monitor, search for (or select) the Bias Monitor: Disparity and Group Metrics from the list of OOTB monitors. For this example, select df_sample_scored.json as the Assets. Since the file is already an asset of the business model, we can find it under Select Existing.Similarly, the file bias_disparity_DMN.dmn is selected for threshold setup and a schedule is selected in the last step. The screenshot below shows the details of this monitor. To run a monitor on demand, click on COPY CURL TO RUN JOB EXTERNALLY. The CURL command can then be run from the application of your choosing.

Open

3. On the Review page click SAVE.

4. Before proceeding to executing the monitor, we will go through the details of the decision table selected for this example.

   1. This decision table ensures that the gender_female_statistical_parity and gender_female_impact_parity metrics of the German Credit Model are within specification. Please note that .dmn files can be opened/edited using Camunda Modeler.

      Open

      

   2. The gender_female_statistical_parity and gender_female_impact_parity values can be accessed directly from the Monitoring Test Result by design. More metrics are produced OOTB by the bias monitor. We will discuss this in more detail later.

   3. In our example, the .dmn file is already an asset of the business model and versioned/managed along with the source code in the same Github repo. This is considered best practice, as the decision tables are closely tied to the specific business model under consideration. However, it is not a requirement that the .dmn files are available as model assets ahead of time.

Run a Monitor On-demand (UI)

To run a monitor on-demand from the UI, navigate to the business model’s snapshot page and click the play button next to the monitor of interest. A monitoring job will be initiated, and you will be redirected to the corresponding job page once the job is created. The model test results created from this execution are described in the Monitoring Results and Notifications section below.

Schedule a Monitor DIY (CURL)

Monitors can be scheduled to run using your preferred enterprise scheduling capability (Control-M, Airflow, Autosys, etc.) While the details will depend on the specific scheduling software, at the highest level, the user simply needs to create a REST call to the ModelOp Center API. Here are the steps:

1. Obtain the Business Model snapshot’s UUID. This can be found, for instance, in the URL of the snapshot page, as shown in this example:

2. Similarly, obtain the Monitoring Model snapshot’s UUID by navigating to Inventory from the main menu and selecting Monitors from the drop down menu and searching for the name of the monitor attached to the given business model.

3. Within the scheduler, configure the REST call to ModelOp Center’s automation engine to trigger the monitor for your model:

   1. Obtain a valid auth token

   2. Make a call (POST) to the ModelOp Center API to initiate the monitor. The endpoint is

      <MOC_INSTANCE_URL>/mlc-service/rest/signal

   3. The body should contain references to the Model Life Cycle (MLC) being triggered, as well as the business model and monitor snapshots, as shown below:

      { "name": "com.modelop.mlc.definitions.Signals_Run_Associated_Model_Jira", "variables": { "DEPLOYABLE_MODEL_ID" : { "value": <UUID_of_business_model_snapshot_as_a_string> }, "ASSOCIATED_MODEL_ID": { "value": <UUID_of_monitoring_model_snapshot_as_a_string> } } }

This process is made easier by copying the CURL command provided at the last step of the monitoring wizard

The copied command will look something like this:

curl 'https://mocaasin.modelop.center/mlc-service/rest/signalResponsive' -H 'Accept: application/json, text/plain, /' -H 'Content-Type: application/json' -X POST -H 'Authorization: Bearer <token>' --data-raw '{"name":"com.modelop.mlc.definitions.Signals_Run_Associated_Model_Jira","variables":{"DEPLOYABLE_MODEL_ID":{"value":"d440a597-4cfb-4541-874f-356cca742446"},"ASSOCIATED_MODEL_ID":{"value":"cb328e3a-7fcb-4853-9833-44c0b26b0b13"}}}'

Monitoring Execution

Once the scheduler triggers the signal, the corresponding MLC (listening to that signal) will be initiated. The sequence of events include:

1. Preparing the monitoring job with all artifacts necessary to run the job

2. Creating the monitoring job

3. Parsing the results into viewable test results

4. Comparing the results against the thresholds in the decision table

5. Taking action, which could include creating a notification and/or opening up an incident in JIRA/ServiceNow/etc.

These steps can be summarized in the following Model Life Cycle (MLC)

Monitoring Results and Notifications

Sample Standard Output of Bias Monitors

Monitoring Test Results are listed under the Test Results table:

Upon clicking on the View icon, you’ll have two options for looking at test results: graphical (under Test Results), and raw (under Raw Results).

Visual elements

1. Summary Metrics: These are a subset of all metrics computed by the monitor, returned as key:value pairs for ease-of-reference:

2. Bias/Disparity Metrics

3. Group Metrics

Raw Results

The “Raw Results” tab shows a clickable (expandable and collapsable) JSON representation of the test results

To get a JSON file of the test results:

1. Navigate to the Jobs tab of the snapshot and click on the row below to the get details of the job of interest

2. Click on “Download File” under “Outputs”

Sample Monitoring Notification

Notifications arising from monitoring jobs can be found under the corresponding model test result

If a ticketing system is configured in ModelOp Center, such as Jira, a ticket will be written when an ERROR occurs (as in above), and a link to the ticket will be available next to the notification. In the example above, a metric fell out of a preset threshold, and thus the monitoring job failed.

Bias Monitors Details

Model Assumptions

Business Models considered for bias monitoring have a few requirements:

1. An extended schema asset for the input data.

2. Model type is binary classification.

3. Protected classes under consideration are categorical features.

4. Input data contains columns for label (ground truth), score (model output), and at least 1 protected class.

Protected Classes with Numerical Values

While not supported out of the box, a bias monitor can be easily edited to allow protected protected classes with numerical values, such as a continuous age column. Consider the following example:

In this example, the cutoff list on line 27 tells the BiasMonitor to split the age values on 40. This produces an artificial age_bucketed column, with two categorical values: (-inf, 40) and [40, +inf). The Bias metrics are then computed on the engineered categorical feature:

To split on more than one value, simply add all interval endpoints to the numerical_cutoffs list. For example,

Model Execution

During execution, bias monitors execute the following steps:

1. init function extracts extended input schema (corresponding to the BUSINESS_MODEL being monitored) from job JSON.

2. Monitoring parameters are set based on the schema above. protected_classes, label_column, and score_column are determined accordingly.

3. metrics function runs an Aequitas Bias test and/or an Aequitas Group test for each protected class in the list of protected classes. A reference group for each protected class is chosen by default (first occurrence).

   • The combination of bias and group metrics to be computed depends on the specific flavor of the bias monitor:

     • Bias Monitor: Group Metrics computes group metrics only for each protected class: tpr, tnr, for, fdr, fpr, fnr, npv, precision, ppr, pprev, prev

     • Bias Monitor: Disparity Metrics computes disparity metrics only for each protected class: ppr_disparity, pprev_disparity, precision_disparity, fdr_disparity, for_disparity, fpr_disparity, fnr_disparity, tpr_disparity, tnr_disparity, npv_disparity

     • Bias Monitor: Disparity and Group Metrics computes both group and disparity metrics for each protected class

4. Test results are appended to the list of bias tests to be returned by the model.

For a deeper look at OOTB monitors, see https://modelopdocs.atlassian.net/wiki/spaces/py140 (subscribed customers only).