reclist 0.2.3

Overview

RecList is an open source library providing behavioral, “black-box” testing for recommender systems. Inspired by the pioneering work of Ribeiro et al. 2020 in NLP, we introduce a general plug-and-play procedure to scale up behavioral testing, with an easy-to-extend interface for custom use cases.

While quantitative metrics over held-out data points are important, a lot more tests are needed for recommenders to properly function in the wild and not erode our confidence in them: for example, a model may boast an accuracy improvement over the entire dataset, but actually be significantly worse than another on rare items or new users; or again, a model that correctly recommends HDMI cables as add-on for shoppers buying a TV, may also wrongly recommend TVs to shoppers just buying a cable.

RecList goal is to operationalize these important intuitions into a practical package for testing research and production models in a more nuanced way, without requiring unnecessary custom code and ad hoc procedures. To streamline comparisons among existing models, RecList ships with popular datasets and ready-made behavioral tests: read the TDS blog post as a gentle introduction to the main use cases, check the paper for more details on the relevant literature.

If you are not familiar with the library, we suggest first taking our small tour to get acquainted with the main abstractions through ready-made models and public datasets.

Quick Start

If you want to see RecList in action, clone the repository, create and activate a virtual env, and install the required packages from pip (you can install from root of course). If you prefer to experiment in an interactive, no-installation-required fashion, try out our colab notebook.

Sample scripts are divided by use-cases: similar items, complementary items or session-based recommendations. When executing one, a suitable public dataset will be downloaded, and a baseline model trained: finally, the script will run a pre-made suite of behavioral tests to show typical results.

git clone https://github.com/jacopotagliabue/reclist
cd reclist
python3 -m venv venv
source venv/bin/activate
pip install reclist
python examples/coveo_complementary_rec.py

Running your model on one of the supported dataset, leveraging the pre-made tests, is as easy as implementing a simple interface, RecModel.

Once you’ve run successfully the sample script, take the guided tour below to learn more about the abstractions and the out-of-the-box capabilities of RecList.

A Guided Tour

An instance of RecList represents a suite of tests for recommender systems: given a dataset (more appropriately, an instance of RecDataset) and a model (an instance of RecModel), it will run the specified tests on the target dataset, using the supplied model.

For example, the following code instantiates a pre-made suite of tests that contains sensible defaults for a cart recommendation use case:

rec_list = CoveoCartRecList(
    model=model,
    dataset=coveo_dataset
)
# invoke rec_list to run tests
rec_list(verbose=True)

Our library pre-packages standard recSys KPIs and important behavioral tests, divided by use cases, but it is built with extensibility in mind: you can re-use tests in new suites, or you can write new domain-specific suites and tests.

Any suite must inherit the RecList interface, and then declare with Pytonic decorators its tests. In this case, the test re-uses a standard function:

class MyRecList(RecList):

    @rec_test(test_type='stats')
    def basic_stats(self):
        """
        Basic statistics on training, test and prediction data
        """
        from reclist.metrics.standard_metrics import statistics
        return statistics(self._x_train,
            self._y_train,
            self._x_test,
            self._y_test,
            self._y_preds)

Any model can be tested, as long as its predictions are wrapped in a RecModel. This allows for pure “black-box” testings, a SaaS provider can be tested just by wrapping the proper API call in the method:

class MyCartModel(RecModel):

    def __init__(self, **kwargs):
        super().__init__(**kwargs)

    def predict(self, prediction_input: list, *args, **kwargs):
        """
        Implement the abstract method, accepting a list of lists, each list being
        the content of a cart: the predictions returned by the model are the top K
        items suggested to complete the cart.
        """

        return

More generally, the logical workflow of a typical RecList implementation is as follows (see our blog post for a longer explanation):

While many standard KPIs are available in the package, the philosophy behind RecList is that metrics like Hit Rate provide only a partial picture of the expected behavior of recommenders in the wild: two models with very similar accuracy can have very different behavior on, say, the long-tail, or model A can be better than model B overall, but at the expense of providing disastrous performance on a set of inputs that are particularly important in production.

RecList recognizes that outside of academic benchmarks, some mistakes are worse than others, and not all inputs are created equal: when possible, it tries to operationalize through scalable code behavioral insights for debugging and error analysis; it also provides extensible abstractions when domain knowledge and custom logic are needed.

Once you run a suite of tests, results are dumped automatically and versioned in a local folder, structured as follows (name of the suite, name of the model, run timestamp):

.reclist/
  myList/
    myModel/
      1637357392/
      1637357404/

If you start using RecList as part of your standard testings - either for research or production purposes - you can use the JSON report for machine-to-machine communication with downstream system (e.g. you may want to automatically fail the model pipeline if certain behavioral tests are not passed).

Note: our app is deprecated, as RecList Beta will have connectors with existing apps (experiment trackers, model cards, etc.).

Capabilities

RecList provides a dataset and model agnostic framework to scale up behavioral tests. As long as the proper abstractions are implemented, all the out-of-the-box components can be re-used. For example:

• you can use a public dataset provided by RecList to train your new cart recommender model, and then use the RecTests we provide for that use case;

• you can use some baseline model on your custom dataset, to establish a baseline for your project;

• you can use a custom model, on a private dataset and define from scratch a new suite of tests, mixing existing methods and domain-specific tests.

We list below what we currently support out-of-the-box, with particular focus on datasets and tests, as the models we provide are convenient baselines, but they are not meant to be SOTA research models.

Behavioral Tests

RecList helps report standard quantitative metrics over popular (or custom) datasets, such as the ones collected in standard_metrics.py: hit rate, mrr, coverage, popularity bias, etc. However, RecList raison d’etre is providing plug-and-play behavioral tests, as agnostic as possible to the underlying models and datasets, while leaving open the possibility of writing personalized tests when domain knowledge and custom logic are necessary.

Tests descriptions are available in our (WIP) docs, but we share here some examples from our paper.

First, RecList allows to compare the performance of models which may have similar aggregate KPIs (e.g. hit rate on the entire test set) in different slices. When plotting HR by product popularity, it is easy to spot that prod2vec works much better with rarer items than the alternatives:

When slicing by important meta-data (in this simulated example, brands), RecList uncovers significant differences in performance for different groups; since the features we care about vary across datasets, the package allows for a generic way to partition the test set and compute per-slice metrics:

Finally, RecList can take advantage of the latent item space to compute the cosine distances <query item, ground truth> and <query item, prediction> for missed predictions in the test set. In a cart recommender use case, we expect items to reflect the complementary nature of the suggestions: if a TV is in the cart, a model should recommend a HDMI cable, not another TV. As we see in the comparison below, Google’s predictions better match the label distribution, suggesting that the model better capture the nature of the task:

Roadmap

To do:

• the app is just a stub: improve the report “contract” and extend the app capabilities, possibly including it in the library itself;

• continue adding default RecTests by use cases, and test them on public datasets;

• improving our test suites and refactor some abstractions;

• adding Colab tutorials and extensive documentation to explain the basic usage (a first blog post is out!).

We maintain a small Trello board on the project which we plan on sharing with the community: more details coming soon!

Acknowledgments

The main contributors are:

• Patrick John Chia - LinkedIn, GitHub

• Jacopo Tagliabue - LinkedIn, GitHub

• Federico Bianchi - LinkedIn, GitHub

• Chloe He - LinkedIn, GitHub

• Brian Ko - LinkedIn, GitHub

If you have questions or feedback, please reach out to: jacopo dot tagliabue at tooso dot ai.

License and Citation

All the code is released under an open MIT license. If you found RecList useful, please cite our pre-print: RecList is a WWW, so the citation below will be updated soon.

@inproceedings{Chia2021BeyondNB,
  title={Beyond NDCG: behavioral testing of recommender systems with RecList},
  author={Patrick John Chia and Jacopo Tagliabue and Federico Bianchi and Chloe He and Brian Ko},
  year={2021}
}

Credits

This package was created with Cookiecutter and the audreyr/cookiecutter-pypackage project template.