Blog

May 31, 2018 · newsletter

Rules to Learn By

Longtime readers of this newsletter know that we follow the Fairness, Accountability, and Transparency in Machine Learning conversation closely (see here and here). These conversations address and attempt to mitigate the potential for technical systems to produce unfairness. Much of this unfairness arises from how algorithmic systems might perpetuate historical inequalities or otherwise produce discriminatory effects. This conversation is broader than could be encapsulated in any newsletter, but we want to point to some recommendations that have come out of this conversation to demonstrate how we think through the challenges of building models that don’t learn or perpetuate bias. We embrace these challenges not just because of an overriding ethical commitment to build safely, but also because addressing these challenges helps us build things that work better than they otherwise might.

Joanna Bryson identifies three sources of bias, and offers recommendations for how to fix the the problems they pose. With the intention of generalizing Bryson’s analysis to all machine learning, we’d like to restate her argument slightly by identifying the sources of bias as 1) bias in the training data (with the assumption that historical biases tend to be represented in datasets), 2) bias in the assumptions and intuitions that guide our model, and 3) the bias of unintended consequences. Taking these as three sources of bias leads to three recommendations that are also best practices for machine learning.

Bias in the real world (and therefore in the data available for training an algorithm) can be thought of as a class imbalance, regardless of where it comes from. There are acute disparities in how members of different populations are represented in datasets, due to historical social and economic inequities, but rather than perpetuating this disparate representation in machine learning, data can be balanced at the training step and thereby produce a more balanced representation in the model. This is true of all data as well; we still strive to produce balanced representations in any model we build. For an image classifier, if photographs of, say, “hamburgers with fries” are underrepresented in the training data set, the classifier might not work as well across all food items as it might if trained on balanced classes. While humans and hamburgers are very different things, ethically speaking, any machine learning model should learn robust, balanced representations.

Bias in the assumptions and intuitions that guide our models arises from how we ask and answer questions in machine learning. Bryson refers to this source of bias as “poorly reasoned rules,” but this source of bias can also arise from a lack of robust product testing. Because our own life experience and domain expertise is necessarily partial, we cannot necessarily account for all the ways in which a system might not work as expected. Bryson gives the example of facial recognition not working well for people with dark skin: if we don’t ask whether or not our system works well for all skin tones, it may not work as expected (see Joy Buolamwini’s project on this). One solution to this problem is to develop robust testing pipelines prior to deployment; another solution is to bring in people with diverse sources of expertise and lived experiences to inform the assumptions that guide development and testing; a third solution is to think deeply and broadly about the world in which systems will be deployed. They may work exactly as designed when in ‘the lab,’ but produce unexpected results when deployed. The rules we have in mind about how the world behaves should correspond with the actual world beyond the lab.

The bias of unintended consequences is closely related to the causes of unexpected results, and arises in part from uninterpretable and opaque black box models. When models don’t behave as expected it can be difficult to understand why they misbehaved. Developing (and utilizing) tools that enable interpretability (such as LIME) and auditing algorithms with them can help developers and users understand why a certain result was returned, can identify sources of bias in a model that can then be fixed, and can even result in new and useful insights that have value as products. Bias, in the sense that Joanna Bryson discusses it, perpetuates some of the most harmful tendencies in society. Correcting for that bias is of profound ethical value to society - in machine learning, it also focuses our attention on the things we want to be able to learn (for example, how to create more robust representations of risk factors for disease without overfitting a model to signals that distract from the end goal).

Read more

Newer
Jun 26, 2018 · post
Older
May 31, 2018 · newsletter

Latest posts

Nov 15, 2020 · post

Representation Learning 101 for Software Engineers

by Victor Dibia · Figure 1: Overview of representation learning methods. TLDR; Good representations of data (e.g., text, images) are critical for solving many tasks (e.g., search or recommendations). Deep representation learning yields state of the art results when used to create these representations. In this article, we review methods for representation learning and walk through an example using pretrained models. Introduction Deep Neural Networks (DNNs) have become a particularly useful tool in building intelligent systems that simplify cognitive tasks for users.
...read more
Jun 22, 2020 · post

How to Explain HuggingFace BERT for Question Answering NLP Models with TF 2.0

by Victor · Given a question and a passage, the task of Question Answering (QA) focuses on identifying the exact span within the passage that answers the question. Figure 1: In this sample, a BERTbase model gets the answer correct (Achaemenid Persia). Model gradients show that the token “subordinate ..” is impactful in the selection of an answer to the question “Macedonia was under the rule of which country?". This makes sense .. good for BERTbase.
...read more
Jun 16, 2020 · notebook

Evaluating QA: Metrics, Predictions, and the Null Response →

by Melanie · A deep dive into computing QA predictions and when to tell BERT to zip it! In our last post, Building a QA System with BERT on Wikipedia, we used the HuggingFace framework to train BERT on the SQuAD2.0 dataset and built a simple QA system on top of the Wikipedia search engine. This time, we’ll look at how to assess the quality of a BERT-like model for Question Answering.
qa.fastforwardlabs.com
May 19, 2020 · notebook

Building a QA System with BERT on Wikipedia →

by Melanie · So you’ve decided to build a QA system. You want to start with something simple and general so you plan to make it open domain using Wikipedia as a corpus for answering questions. You want to use the best NLP that your compute resources allow (you’re lucky enough to have access to a GPU) so you’re going to focus on the big, flashy Transformer models that are all the rage these days.
qa.fastforwardlabs.com
Apr 28, 2020 · notebook

Intro to Automated Question Answering →

by Melanie · Welcome to the first edition of the Cloudera Fast Forward blog on Natural Language Processing for Question Answering! Throughout this series, we’ll build a Question Answering (QA) system with off-the-shelf algorithms and libraries and blog about our process and what we find along the way. We hope to wind up with a beginning-to-end documentary that provides:
qa.fastforwardlabs.com
Apr 1, 2020 · newsletter

Enterprise Grade ML

by Shioulin · At Cloudera Fast Forward, one of the mechanisms we use to tightly couple machine learning research with application is through application development projects for both internal and external clients. The problems we tackle in these projects are wide ranging and cut across various industries; the end goal is a production system that translates data into business impact. What is Enterprise Grade Machine Learning? Enterprise grade ML, a term mentioned in a paper put forth by Microsoft, refers to ML applications where there is a high level of scrutiny for data handling, model fairness, user privacy, and debuggability.
...read more

Popular posts

Oct 30, 2019 · newsletter
Exciting Applications of Graph Neural Networks
Nov 14, 2018 · post
Federated learning: distributed machine learning with data locality and privacy
Apr 10, 2018 · post
PyTorch for Recommenders 101
Oct 4, 2017 · post
First Look: Using Three.js for 2D Data Visualization
Aug 22, 2016 · whitepaper
Under the Hood of the Variational Autoencoder (in Prose and Code)
Feb 24, 2016 · post
"Hello world" in Keras (or, Scikit-learn versus Keras)

Reports

In-depth guides to specific machine learning capabilities

Prototypes

Machine learning prototypes and interactive notebooks
Library

NeuralQA

A usable library for question answering on large datasets.
https://neuralqa.fastforwardlabs.com
Notebook

Explain BERT for Question Answering Models

Tensorflow 2.0 notebook to explain and visualize a HuggingFace BERT for Question Answering model.
https://colab.research.google.com/drive/1tTiOgJ7xvy3sjfiFC9OozbjAX1ho8WN9?usp=sharing
Notebooks

NLP for Question Answering

Ongoing posts and code documenting the process of building a question answering model.
https://qa.fastforwardlabs.com
Notebook

Interpretability Revisited: SHAP and LIME

Explore how to use LIME and SHAP for interpretability.
https://colab.research.google.com/drive/1pjPzsw_uZew-Zcz646JTkRDhF2GkPk0N

About

Cloudera Fast Forward is an applied machine learning reseach group.
Cloudera   Blog   Twitter