AutoSlicer: Scalable Automated Data Slicing for ML Model Analysis

In production settings, machine learning (ML) practitioners have to consider whether the input data have errors, whether a new version is good enough to replace the model currently used by the downstream stack, how to debug and improve model performance etc. Those require reliable model evaluation that can aid with validating, debugging and improving model performance.

Example 1: Consider a continuous ML pipeline that trains on new data arriving in batches every day, to obtain a fresh model that needs to be pushed to the serving infrastructure. The ML engineer needs to validate that the new model does not perform worse than the previous one.

Model metrics computed on the whole evaluation dataset can mask interesting or significant deviations of the same metrics computed on data slices that correspond to meaningful sub-populations. Thus, it is often desired to identify slices of data where the model performs poorly.

Example 2: Consider the same pipeline in Example 1. To ensure fairness and model quality, we want to avoid pushing the new model to serving if it performs poorly on sensitive data slices.

Example 3: Consider an ML engineer who is building the first model for a task. The engineer tries to iteratively debug and improve the model. Knowing on which data slices the current model is performing poorly would aid the engineer to take actions towards improving the accuracy on them.

To this end, we focus on the problem of automated slicing, aiming at identifying problematic data slices automatically. As part of an ML platform in production, the automated slicing system should satisfy the following requirements: (Scalability) The system should be able to operate on distributed clusters and the search method should be efficient, since modern ML datasets are often too large to fit in memory, and enumerating the number all possible slices is infeasible. (Reliability) The system should provide uncertainty measures that tell the user how reliable the results are, since some slices may appear problematic by chance due to sampling errors. (Generality) The system should be general and flexible to support common types of models and metrics.

SliceFinder [11] identifies problematic slices by lattice search and hypothesis testing. However, SliceFinder focuses on the single-machine setting, failing to scale on large datasets. SliceLine [21] addresses the scalability issues by formulating automated slicing as linear-algebra problems, and solving them through distributed matrix computing. However, SliceLine does not provide uncertainty measures for the computed metric. In addition, SliceFinder and SliceLine only support metrics that are mean values over individual examples (e.g., average loss, accuracy), while we want a general framework that supports all common metrics in ML evaluation (e.g., AUC, F1 score).

In this paper we describe AutoSlicer, a scalable and reliable solution to the automatic slicing problem. Our technical contributions include: 1. A distributed computing framework that performs sliced evaluation efficiently for a general family of ML metrics (e.g., those provided by TensorFlow). 2. Uncertainty estimation for the results of metric comparison by distributed hypothesis testing. 3. A search strategy that identifies most of the problematic slices without exhausting the search space.

We assume a dataset $D=\{(x^{(1)}_{F},y^{(1)}),(x^{(2)}_{F},y^{(2)}),\dots,(x^{(N)}_{F},y^{(N)})\}$ with $N$ examples, where $x^{(n)}_{F}$ is the $n^{\text{th}}$ example and $y^{(n)}$ is the corresponding ground truth label. $F=\{F_{1},F_{2},\dots,F_{M}\}$ is the set of features in each example. We also assume a model $h$ to be tested, and a metric $\psi(S,h)$ measuring how well the model makes predictions about the ground truth labels on a subset $S\subseteq D$.

A slice $S_{P}$ is a subset of $D$ that satisfies a conjunctive predicate $P=\bigwedge_{i}F_{m_{i}}\in V_{i}$, where $V_{i}$ is a set of values from the domain of feature $F_{m_{i}}$. For categorical features, each $V_{i}$ contains one value from the feature domain. If the domain of a feature is too large (it contains more than $J$ values), we put each of the $J$ most frequent values into one singleton set, and all the rest into one set. For numerical values, each $V_{i}$ corresponds to a bin. We call each $F_{m_{i}}\in V_{i}$ a singleton predicate, and use $|P|$ to denote the number of singleton predicates in $P$ (cross size of $P$). We use $O$ to denote the predicate that is always true, and thereby $S_{O}$ is the overall slice that contains all examples.

Automated slicing aims to find slices with significantly higher or lower metric values, compared to the overall slice or the same slice under a baseline model. Formally, we seek $S_{P}$ such that $\Delta\psi_{S_{P}}$ is significantly greater or less than $0$, where $\Delta\psi_{S_{P}}=\psi(S_{P},h)-\psi(S_{O},h)$ in the former scenario, and $\Delta\psi_{S_{P}}=\psi(S_{P},h)-\psi(S_{P},h^{\prime})$ ($h^{\prime}$ is a baseline model) in the latter. We quantify significance by $p$-values from hypothesis testing. Any slice with $p$-value less than $\alpha$ is considered significant where $\alpha$ is a user-specified threshold.

The search space forms a lattice structure, where the $l^{\text{th}}$ layer contains all possible slices with cross size $l$. An example of the search space is shown in Figure 1. To limit the number of candidate slices, we introduce the maximum cross size $L$ as a user-specified parameter. Another reason for setting the maximum cross size is that as the cross size increases, the results become less interpretable.

In some cases, the user may not want slices that are too small since they do not have a large impact on the overall performance of the model. Therefore, we also introduce the minimum slice size $N_{\text{min}}$ as another user-specified parameter.

In summary, we seek $S_{P}$’s such that the difference of a given metric $\Delta\psi_{S_{P}}$ is significantly greater (or less) than $0$, with $|P|\leq L$ and $|S_{P}|\geq N_{\text{min}}$, where $|S_{P}|$ is the number of examples in the slice.

AutoSlicer uses the Beam programming model [1] to express distributed programs that can be executed in a variety of environments.

AutoSlicer relies on a candidate slice generator that automatically proposes candidate slices from the search space. The candidate slice generator supports several search strategies. We describe them as follows. The complete algorithms for the last two are provided in Appendix A.1.

In the first iteration, all the candidates with cross size one are proposed. Afterwards, the nonsignificant slices are pushed into the priority queue. In each subsequent iteration, we pop base slices from the priority queue, and subdivide them by adding one more singleton predicate until the estimated number of nonempty candidates slices reaches the limit $K$. Then we compute the metrics and perform hypothesis testing for the candidates and push the new nonsignificant slices into the priority queue. In this strategy, we follow the same criterion as in the iterative strategy to prune the search space.

Note that we use an estimated number of nonempty candidate slices to decide if enough base slices have been popped from the queue. This is because some candidates are empty, introducing no computation cost. With this estimation, we have a better control over the computation cost per iteration. We keep track of the nonempty rate for each cross size $l$, i.e., the ratio between the actual number of nonempty slices and the number of slice candidates with cross size $l$ that we have seen so far. When we count the number of nonempty slices, each candidate is discounted based on the nonempty rate corresponding to its cross size. For example, a candidate with cross size $3$ will be counted as $0.5$ slices if the nonempty rate of cross size $3$ is $0.5$. If we have not seen any slice with cross size $l$, the empty rate of cross size $l$ will be predicted as that of cross size $l-1$.

We compare the search strategies on a variety of real-world datasets. In the Appendix, we provide micro-benchmarks over several design choices and a scalability evaluation (Appendix A.2.3,  A.2.4).

We describe the datasets, ML models, and parameters of AutoSlicer in Appendix A.2.1. We run all the experiments on an internal cluster. Due to the resource allocation mechanism that we do not have control over, the wall time of the same run may vary a lot. Therefore, we report the total CPU time across workers for fair comparison of computation cost.

The comparison between the strategies is shown in Table 1. We run the priority strategy for 5 iterations, and set the target number of candidates per iteration ($K$) to be 12% of the size of batch strategy search space. When the batch strategy cannot finish, we set $K$ to 2500. Results under other configurations can be found in Appendix A.2.2. The significant slices in this experiment are those the model performs poorly on compared to the overall dataset. We report the number of significant slices found by each strategy (significant slices that are subsets of other significant ones are pruned), the actual number of candidate slices computed, the total CPU usage across workers and the amount of shuffle bytes. Note that due to the randomness of bootstrapping, the number of significant slices is slightly different across runs, which is the reason why the number of significant slices found by the priority strategy is larger than that by the exhaustive batch strategy in some cases.

The results show the effectiveness of our search space pruning and the priority strategy. On OpenML Electricity and UCI Census, the iterative strategy takes at least 45% less CPU seconds and 90% less shuffle bytes than the batch strategy due to the pruning. The priority strategy further reduces those costs. Compared to the iterative strategy, the priority strategy takes 40% less CPU seconds on OpenML Electricity and 76% less on UCI Census to find a comparable number of significant slices. The shuffle bytes are also reduced by at least 38% on both datasets. For Safe Driving and Traffic Stop, the priority strategy is able to finish while the other two strategies run out of time.