Support more diverse input types for methods working on tabular data

[jklaise]

Current status

Currently tabular data in methods such as AnchorTabular and CounterfactualProto are expected to be in one of a set of restricted formats, e.g.

• np.ndarray of homogeneous number types where numerical columns are float and categorical columns are integer-encoded (to be pedantic, float that can be cast to int without loss of precision, e.g. 0.0 denoting the first category of a categorical feature).
• np.ndarray of homogeneous number types where numerical columns are float and categorical features have been expanded into one-hot-encoded columns (i.e. each categorical feature now occupies n_categories columns which are populated with 0 and 1 entries)

Problem

If a user model is not trained on a data representation that is one of the above then Alibi tabular explainers cannot be used out-of-the-box which is undesirable (as found out by @FarrandTom).

For concreteness, denote by X an input data point that is non-compliant with the Alibi API, e.g. it could be np.ndarray but with unsupported column types, for example array([49.5, 'Male'], dtype=object) representing a numerical feature and a string-encoded categorical variable.

Further, denote by Z an input data point that is compliant with the Alibi API, e.g. array([49.5, 0. ]) representing the same numerical feature and the same but integer-encoded categorical variable.

A client may have a model M that's trained on non-compliant data, i.e. it would be of type Callable[[X], np.ndarray], whereas Alibi expects a model M_hat (prediction function) of type Callable[[Z], np.ndarray]. How can we go from a non-compliant model to a compliant one?

The key is being able to map back and forth between X and Z. Let f: X->Z be such an invertible mapping, for the example above it would be something like:

def f(X: np.ndarray, **kwargs) -> np.ndarray:  # use **kwargs for any other information needed to do the conversion
    Z_num = extract_numeric(X, **kwargs)  # extract columns like 49.5,  Z_num is now a homogenous array of numbers
    Z_cat = extract_cat(X, **kwargs)  # take columns like 'Male' and convert to 0, Z_cat is now a homogenous array of numbers
    Z = combine(Z_num, Z_cat, **kwargs)  # concatenate columns in the right order
    return Z

def f_inverse(Z: np.ndarray, **kwargs) -> np.ndarray:
    ... # do similar operations as above
    return Z

With this extra information we can define an Alibi-compliant model in terms of client model M and inverse mapping f_inv as follows: M_hat = M(f_inv(Z)), in Python

def M_hat(Z: np.ndarray) -> np.ndarray:
    X = f_inv(Z)
    pred = M(X)
    return pred

What we can do

• (Minimum effort) Document the process of manually creating the f, f_inv transformations to make an Alibi non-compliant model into a compliant one, specific examples are needed. This is in spirit the same as the discussion on white-box vs black-box models. This has short term gains demonstrating that in principle it should always be possible do use Alibi explainers if the user is prepared to do a bit more work. It is unclear, however, if this translates well to the deployment setting.
• (Medium effort) Extend the types of data that Alibi can handle natively. This likely requires some design considerations and may require the user to provide more information if they pass heterogenous np.ndarray data. It may be useful to extend this to take in also pd.DataFrame and/or pd.Series objects as necessary. This has longer term gains as the user would no longer need to do extra work in case their model is trained on a different data representation.
• (Medium high effort?) Extend capabilities on the Deployment side. See below for an explanation. This has longer term gains making explainer deployment more flexible wrt to pointing to a component within an inference graph.

What about deployment?

In deployment we may have the following situation where the inference graph consists of a transformer mapping an Alibi-non-compliant data X to a compliant one Z which is then passed into an Alibi-compliant model:

How could we add an explainer to this inference graph?

Point directly to the model component

If we know the model component is Alibi-compliant, we could point the explainer to that instead of the whole inference graph (which is non-compliant):

However, note that in this scenario the explainer expects the compliant data type Z whilst the inference graph operates on the original data type X. To obtain Z from X we would need to leverage the existing transformer so we could extend the inference graph like this (conceptually, implementation details may vary):

The only job of the Explainer-Transformer component is to call an existing transformer that is known (by the user) to transform non-compliant data X into compliant data Z.

Non-compliant models within an inference graph

Not all inference graphs contain a model node that would be Alibi-compliant, so in the general case the above would not work and it would be necessary to either:

• Extend Alibi compliant data types to support a wide variety of use cases / inference graphs
• Have the user add extra nodes to the inference graph, transforming non-compliant data types to Alibi-compliant ones. This is essentially the same as defining the transformation steps f and f_inv but also packaging them as inference graph components:

Here the shaded `Compliant-Transformer` and `Compliant-Inverse-Transformer` components correspond exactly to the functions `f` and `f_inv` defined above but explicitly included in an inference graph (implementation details may be different, e.g. these could live inside the `Explainer` as two Python `Callable`s). Effectively we're pointing the explainer to the whole non-compliant inference graph (equivalently, we could also point to the non-compliant model, but there is no point to do that) but we do the conversions to and from compliant data using the new transformer components on the fly (in particular, the inverse transformer intercepts prediction requests and puts them in a format that the non-compliant inference graph can deal with).

Tagging a few people who may be interested in the discussion: @FarrandTom @cliveseldon @axsaucedo @SachinVarghese @arnaudvl .

[ukclivecox]

How could we add an explainer to this inference graph?

Point directly to the model component

This capability to point the explainer to start at a particular node in an inference pipeline is envisioned for SCV2.

Non-compliant models within an inference graph

Not all inference graphs contain a model node that would be Alibi-compliant, so in the general case the above would not work and it would be necessary to either:

* Extend Alibi compliant data types to support a wide variety of use cases / inference graphs

For the various transformation functions of this section and the one of the last I would see these probably being functions in Alibi if possible. So callables passed to the init of the explainer.

• Can we cover the majority of cases with builtin functions for standard categorical string->int use cases?

We could investigate the explainer custom resource in SCV2 being an inference graph of itself to allow images to be used which would run in separate containers. With pre post and explainer sections. Where pre has the compliant transformer. post has the compliant post-transformer, and explainer has the core explainer?

[jklaise]

@cliveseldon if transformation functions for common use cases are built-into alibi then we also have a choice of not having a very general API that accepts custom callables to do custom transformation and inverse transformation (although we may want to support this for genericity). Rather we could dispatch to pre-defined alibi transformations given some information about the data.

This brings me to the data aspect. In order to do this, we will need more information about the data from the user. A good example is actually #487 which is not a tabular use case, but the principle is the same. An "image" may have a channel dimension in different places or it may not have one at all (e.g. grayscale image with no explicit channel axis). These should all be valid inputs to an image predictor that's supported by AnchorImage, but the user has to tell us what the data is (e.g. in this case via image_shape and the proposed channel_axis kwargs).

If we go with the model of "ask user about data and pick an appropriate transformation function" then we will need to carefully design what it is we need to know about the data and in what format (e.g. for the AnchorImage example it's already at least 2 kwargs, for AnchorTabular it may be more - how do you express the concept of "a numpy array with strings in categorical columns"?).

If we go with the other model of "allow custom transformation and inverse transformation functions" (this is similar to alibi-detect preprocessing_fn, we would provide implementations of common ones), then it's a lot more general and we don't tie ourselves into a fixed API, the trade-off is having these extra callables "floating around" (but maybe it's not such a big issue given that we do have a similar design in alibi-detect already).

[sakoush]

I feel in general that we would need to start thinking about how a user can inject predict_fn, pre, post transformation to explainers as opposed to trying to have everything done in alibi. There are a few advantages of this approach in my mind:

• The user would write and it would be possible coupled with the model being trained so the user has the context. I understand that we could ask the user to provide this context and implement it in alibi but I dont see this sustainable and as described above we might need to have a lot of parameters being exposed.
• Less maintenance overhead for alibi code base and focus on its main features.

Can tempo help with enabling the user to supply these transformation boxes?

On the other hand, if in deployment these transformation are separate pods, there is going to be extra overhead because crossing process boundary and for simple transformation this might be a significant overhead.

So we probably need to find the right balance and I personally I think we have to provide some support for both cases.

[jklaise]

@sakoush possibly a versatile option would be to allow alibi explainers to take in custom callables for those transformations. In that way it's still the user responsibility to define and pass these, but then the application layer doesn't have to worry about how to inject them as it would be done by alibi, you also then don't have the issue with these pieces of code ending up having to communicate over the network which I agree would likely cause big slowdowns.

[jklaise]

Wrt to supporting heterogenous numpy arrays, this is actually a bit of an oxymoron since numpy arrays are by definition containers of homogenous data: https://numpy.org/doc/stable/reference/arrays.ndarray.html. This is readily apparent when creating arrays containing both e.g. strings and integers, the dtype defaults to object. Another example is that data consisting of strings would default to a dtype that is roughly "the largest string entry in the array".

Given this it seems that use cases requiring heterogenous numpy arrays may be using the wrong tool for the job and likely shouldn't be seen as good practice becasue you can't do much with a heterogenous array without extra metadata and further transformations into something homogenous. A pandas dataframe would be much better suited for such heterogenous data.

[jklaise]

A fruitful first exploration would be to take some lessons from libraries like sklearn-pandas: https://github.com/scikit-learn-contrib/sklearn-pandas.