Detector Configuration Files

For advanced use cases, Alibi Detect features powerful configuration file based functionality. As shown below, Drift detectors can be specified with a configuration file named config.toml (adversarial and outlier detectors coming soon!), which can then be passed to load_detector():

Standard instantiation

import numpy as np
from alibi_detect.cd import MMDDrift

x_ref = np.load('detector_directory/x_ref.npy')
detector = MMDDrift(x_ref, p_val=0.05)

Config-driven instantiation

config.toml

name = "MMDDrift"
x_ref = "x_ref.npy"
p_val = 0.05

from alibi_detect.saving import load_detector
filepath = 'detector_directory/'
detector = load_detector(filepath)

Compared to standard instantiation, config-driven instantiation has a number of advantages:

Human readable: The config.toml files are human-readable (and editable!), providing a readily accessible record of previously created detectors.
Flexible artefact specification: Artefacts such as datasets and models can be specified as locally serialized objects, or as runtime registered objects (see Specifying complex fields). Multiple detectors can share the same artefacts, and they can be easily swapped.
Inbuilt validation: The load_detector() function uses pydantic to validate detector configurations.

To get a general idea of the expected layout of a config file, see the Example config files. Alternatively, to obtain a fully populated config file for reference, users can run one of the example notebooks and generate a config file by passing an instantiated detector to save_detector().

Configuration file layout

All detector configuration files follow a consistent layout, simplifying the process of writing simple config files by hand. For example, a KSDrift detector with a dill serialized function to preprocess reference and test data can be specified as:

Config-driven instantiation

config.toml

name = "KSDrift"
x_ref = "x_ref.npy"
p_val = 0.05
preprocess_fn = "function.dill"

from alibi_detect.saving import load_detector
detector = load_detector('detector_directory/')

Standard instantiation

import numpy as np
from alibi_detect.cd import KSDrift

x_ref = np.load('detector_directory/x_ref.npy')
preprocess_fn = dill.load('detector_directory/function.dill')
detector = MMDDrift(x_ref, p_val=0.05, preprocess_fn=preprocess_fn)

The name field should always be the name of the detector, for example KSDrift or SpotTheDiffDrift. The remaining fields are the args/kwargs to pass to the detector (see the alibi_detect.cd docs for a full list of permissible args/kwargs for each detector). All config fields follow this convention, however as discussed in Specifying artefacts, some fields can be more complex than others.

Note

In the above example config.toml, x_ref and preprocess_fn are stored in detector_directory/, but this directory isn’t included in the config file. This is because in the config file, relative directories are relative to the location of the config.toml file. Filepaths may be absolute, or include nested directories, but must be POSIX paths i.e. use / path separators instead of \.

Note

Sometimes, fields representing kwargs need to be set to None. However, unspecified fields are set to a detector’s default kwargs (or for Artefact dictionaries, the defaults shown in the tables). To set fields as None, specify them as the string "None".

Specifying artefacts

When specifying a detector via a config.toml file, the locally stored reference data x_ref must be specified. In addition, many detectors also require (or allow) additional artefacts, such as kernels, functions and models. Depending on their type, artefacts can be specified in config.toml in a number of ways:

Local files: Simple functions and/or models can be specified as locally stored dill files, whilst data arrays are specified as locally stored numpy npy files.
Function/object registry: As discussed in Registering artefacts, functions and other objects defined at runtime can be registered using alibi_detect.saving.registry(), allowing them to be specified in the config file without having to serialise them. For convenience a number of Alibi Detect functions such as preprocess_drift() are also pre-registered.
Dictionaries: More complex artefacts are specified via nested dictionaries, usually containing a src field and additional option/setting fields. Sometimes these fields may be nested artefact dictionaries themselves. See Artefact dictionaries for further details.

The following table shows the allowable formats for all possible config file artefacts.

Allowable artefact formats
Field	.npy file	.dill file	Registry	Artefact Dictionary
`x_ref`	✔
`c_ref`	✔
`reg_loss_fn`		✔	✔
`dataset`		✔	✔
`initial_diffs`	✔
`model`/`proj`			✔	`ModelConfig`
`preprocess_fn`		✔	✔	`PreprocessConfig`
`preprocess_batch_fn`		✔	✔
`embedding`			✔	`EmbeddingConfig`
`tokenizer`			✔	`TokenizerConfig`
`kernel`			✔	`KernelConfig` or `DeepKernelConfig`
`kernel_a`/`kernel_b`			✔	`KernelConfig`
`optimizer`		✔	✔	`OptimizerConfig`

Artefact dictionaries

Simple artefacts, for example a simple preprocessing function serialized in a dill file, can be specified directly: preprocess_fn = "function.dill". However, if more complex, they can be specified as an artefact dictionary:

config.toml (excerpt)

[preprocess_fn]
src = "function.dill"
kwargs = {'kwarg1'=42, 'kwarg2'=false}

Here, the preprocess_fn field is a PreprocessConfig artefact dictionary. In this example, specifying the preprocess_fn function as a dictionary allows us to specify additional kwarg’s to be passed to the function upon loading. This example also demonstrates the flexibility of the TOML format, with dictionaries able to be specified with {} brackets or by sections demarcated with [] brackets (see the TOML documentation for more details on the TOML format).

Other config fields in the Allowable artefact formats table can be specified via artefact dictionaries in a similar way. For example, the model and proj fields can be set as TensorFlow or PyTorch models via the ModelConfig dictionary. Often an artefact dictionary may itself contain nested artefact dictionaries, as is the case in in the following example, where a preprocess_fn is specified with a TensorFlow model.

config.toml (excerpt)

[preprocess_fn]
src = "@cd.tensorflow.preprocess.preprocess_drift"
batch_size = 32

[preprocess_fn.model]
src = "model/"

Each artefact dictionary has an associated pydantic model which is used for validation of config files. The documentation for these pydantic models provides a description of the permissible fields for each artefact dictionary. For examples of how the artefact dictionaries can be used in practice, see Example config files.

Registering artefacts

Custom artefacts defined in Python code may be specified in the config file without the need to serialise them, by first adding them to the Alibi Detect artefact registry using the alibi_detect.saving.registry submodule. This submodule harnesses the catalogue library to allow functions to be registered with a decorator syntax:

Registering a function

import numpy as np
from alibi_detect.saving import registry, load_detector

# Register a simple function
@registry.register('my_function.v1')
def my_function(x: np.ndarray) -> np.ndarray:
    "A custom function to normalise input data."
    return (x - x.mean()) / x.std()

# Load detector with config.toml file referencing "@my_function.v1"    
detector = load_detector(filepath)

Specifying in a config.toml

config.toml

name = "MMDDrift"
x_ref = "x_ref.npy"
preprocess_fn = "@my_function.v1"

Once the custom function has been registered, it can be specified in config.toml files via its reference string (with @ prepended), for example "@my_function.v1" in this case. Other objects, such as custom tensorflow or pytorch models, can also be registered by using the register function directly. For example, to register a tensorflow encoder model:

import tensorflow as tf
from tensorflow.keras.layers import Conv2D, Dense, Flatten, InputLayer
from alibi_detect.saving import registry

encoder_net = tf.keras.Sequential(
  [
      InputLayer(input_shape=(32, 32, 3)),
      Conv2D(64, 4, strides=2, padding='same', activation=tf.nn.relu),
      Conv2D(128, 4, strides=2, padding='same', activation=tf.nn.relu),
      Flatten(),
      Dense(32,)
  ]
)
registry.register("my_encoder.v1", func=encoder_net)

Examining registered artefacts

A registered object’s metadata can be obtained with registry.find(), and all currently registered objects can be listed with registry.get_all(). For example, registry.find("my_function.v1") returns the following:

{'module': '__main__', 'file': 'test.py', 'line_no': 3, 'docstring': 'A custom function to normalise input data.'}

Pre-registered utility functions/objects

For convenience, Alibi Detect also pre-registers a number of commonly used utility functions and objects.

Function/Class	Registry reference*	Tensorflow	Pytorch
`preprocess_drift()`	`'@cd.[backend].preprocess.preprocess_drift'`	✔	✔
`GaussianRBF`	`'@utils.[backend].kernels.GaussianRBF'`	✔	✔
`TFDataset`	`'@utils.tensorflow.data.TFDataset'`	✔

*For backend-specific functions/classes, [backend] should be replaced the desired backend e.g. tensorflow or pytorch.

These can be used in config.toml files. Of particular importance are the preprocess_drift utility functions, which allows models, tokenizers and embeddings to be easily specified for preprocessing, as demonstrated in the IMDB example.

Example config files

Drift detection on text data

This example presents a configuration for the MMDDrift detector used in Text drift detection on IMDB movie reviews. The detector will pass the input text data through a preprocess_fn step consisting of a tokenizer, embedding and model. An Untrained AutoEncoder (UAE) model is included in order to reduce the dimensionality of the embedding space, which consists of a 768-dimensional vector for each instance.

config.toml

x_ref = "x_ref.npy"
name = "MMDDrift"

[preprocess_fn]
src = "@cd.tensorflow.preprocess.preprocess_drift"
batch_size = 32
max_len = 100
tokenizer.src = "tokenizer/"

[preprocess_fn.model]
src = "model/"

[preprocess_fn.embedding]
src = "embedding/"
type = "hidden_state"
layers = [-1, -2, -3, -4, -5, -6, -7, -8]

Validating config files

When load_detector() is called, the validate_config() utility function is used internally to validate the given detector configuration. This allows any problems with the configuration to be detected prior to sometimes time-consuming operations of loading artefacts and instantiating the detector. validate_config() can also be used by devs working with Alibi Detect config dictionaries.

Under-the-hood, load_detector() parses the config.toml file into a unresolved config dictionary. It then passes this dict through validate_config(), to check for errors such as incorrectly named fields, and incorrect types. If working directly with config dictionaries, the same process can be done explicitly, for example:

from alibi_detect.saving import validate_config

# Define a simple config dict
cfg = {
    'name': 'MMDDrift',
    'x_ref': 'x_ref.npy',
    'p_val': [0.05],
    'bad_field': 'oops!'
}

# Validate the config
validate_config(cfg)

This will return a ValidationError because p_val is expected to be float not a list, and bad_field isn’t a recognised field for the MMDDrift detector:

ValidationError: 2 validation errors for MMDDriftConfig
p_val
  value is not a valid float (type=type_error.float)
bad_field
  extra fields not permitted (type=value_error.extra)

Validating at this stage is useful as errors can be caught before the sometimes time-consuming operation of resolving the config dictionary, which involves loading each artefact in the dictionary (read_config() and resolve_config() can be used to manually read and resolve a config for debugging). The resolved config dictionary is then also passed through validate_config(), and this second validation can also be done explicitly:

import numpy as np
from alibi_detect.saving import validate_config

# Create some reference data
x_ref = np.random.normal(size=(100,5))

# Define a simple config dict
cfg = {
    'name': 'MMDDrift',
    'x_ref': x_ref,
    'p_val': 0.05
}

# Validate the config
validate_config(cfg, resolved=True)

Note that since resolved=True, validate_config() is now expecting x_ref to be a Numpy ndarray instead of a string. This second level of validation can be useful as it helps detect problems with loaded artefacts before attempting the sometimes time-consuming operation of instantiating the detector.