Description
Many alibi
implementations rely heavily on user callbacks, allowing to customize the behaviour of explainers. On the other hand, for application developers it is sometimes necessary to be able to refer to specific instances of callbacks from outside of Python (e.g. using a string key in a config file). This issue is for tracking discussions on how this feature should be supported by alibi
. An initial discussion can be found in #523.
For a concrete example using #523, consider being able to customize the behaviour of IntegratedGradients
by passing a target_fn
callback. First, we can integrate common callbacks in alibi
ourselves so users can import them and use them, however this does not solve the issue of being able to refer to these callbacks via string keys from outside of Python, e.g.:
from alibi.utils.callbacks import argmax_target_fn
ig = IntegratedGradients(model=model, target_fn=argmax_target_fn)
A solution would be to provide function registries via catalogue which allows the following:
alibi
can register it's own callbacks so they can be referred to by string keys- users can import the registry and register their custom callbacks so they can also be referred to by string keys
The next question is, given the ability to refer to callbacks via string keys, should our public interfaces change to accept both custom callabacks (i.e. Callable
types) and a fixed set of string keys validated against some registry content, e.g.:
class IntegratedGradients:
def __init__(self,
model: SomeModelTypes,
target_fn: Union[Callable, Literal['argmax_target_fn']]): ... # strings map to registry functions
However, I would argue that this is not the best approach as it pollutes the public API of alibi
implementations (i.e. extending allowable types from Callable
to some bigger set) and doesn't solve the issue of hinting that user registered string keys are also allowed (unless we type it as Union[Callable, str]
but this is too broad to be useful).
I would instead propose that the "resolution" of strings to the functions that they refer to should happen earlier and the public API of alibi
should not change and only accommodate taking in Callable
types. Concretely, because the main use case appears to be using config files, I would constrain being able to specify custom callables via string keys to cases where explainers are initialized from a config file. This is very similar to the work in alibi-detect
being carried out by @ascillitoe.
As always, note that there are already some exceptions to this in the existing implementations, e.g. for AnchorImage
the segmentation_fn
can be either a user callable or a fixed set of string keys which internally map to existing scikit-image
functions:
alibi/alibi/explainers/anchor_image.py
Lines 324 to 327 in ee356b1