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 Monitors

As background on the terminology and concepts used below, please read the Monitoring Concepts section of the Model overview documentation.

To add bias monitoring to your business model, you will add an existing “Monitor” to a snapshot (deployable model) of the business model under consideration. Below are the steps to accomplish this. For tutorial purposes, these instructions use all out-of-the-box 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.

Associate a Monitor to a Snapshot of a Business Model

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

2. Navigate to the specific snapshot of the business model. If no snapshots exist, create one.

3. On the Monitoring tab, click on + Add, then click on Monitor

   Open

   

4. Search for (or select) the Bias Monitor: Disparity and Group Metrics from the list of OOTB monitors.

5. Select a snapshot of the monitor. By default, a snapshot is created for each OOTB monitor

   Open

   

6. On the Input Assets page, you’ll notice that the only asset that is required is sample data. This is because a bias monitor computes metrics on 1 dataset only, and thus does not do a comparison to a baseline/reference dataset. For our example, select df_sample_scored.json as the Sample Data Asset. Since the file is already an asset of the business model, we can find it under Select Existing

7. On the Threshold page, click on ADD A THRESHOLD, then select the .dmn file bias_disparity_DMN.dmn. Since the file is already an asset of the business model, we can find it under Select Existing. If the business model does not have a .dmn asset, the user may upload on from a local directory during the monitor association process. Note: threshold files are optional; if absent, a monitoring job will not be considered a Pass or Fail. More on thresholds and decision tables in the next section.

8. The last step in adding a monitor is adding an optional schedule. To do so, click on ADD A SCHEDULE. The Schedule Name field is free-form. The Signal Name field is a dropdown. Choose a signal that corresponds to your ticketing system (Jira, ServiceNow). Lastly, set the frequency of the monitoring job. This can be done either by the wizard or by entering a cron expression. Note: schedules are optional; a monitor may be run on-demand from the business model’s snapshot page, or by a curl command.

9. On the Review page click SAVE

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.

Define Thresholds for your Model

As mentioned in the Monitoring Concepts article, ModelOp Center uses decision tables to define the thresholds within which the model should operate for the given monitor.

• The first step is to define these thresholds. For this tutorial, we will leverage the example bias_disparity_DMN.dmn decision table. Specifically, this decision table ensures that the gender_female_statistical_parity and gender_female_impact_parity metrics of the German Credit Model are within specification.

• 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.

• 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.

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.

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 'http://localhost:8090/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":"23282688-62a6-47ae-8603-16f380efca57"},"ASSOCIATED_MODEL_ID":{"value":"1dc64c1e-3634-4e2e-b37d-71d04a9ee5ef"}}}'

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 “Details” next to the monitoring job of interest

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

Note that the first 4 key:value pairs are what gets shown in the “Summary Metrics” table.

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 22, passed to the monitor instance on line 30, 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 bias monitors, see the GitHub READMEs:

• Bias Monitor: Group Metrics

• Bias Monitor: Disparity Metrics

• Bias Monitor: Disparity and Group Metrics