Reliability Assurance for Deep Neural Network Architectures Against
  Numerical Defects
With the widespread deployment of deep neural networks (DNNs), ensuring the
reliability of DNN-based systems is of great importance. Serious reliability
issues such as system failures can be caused by numerical defects, one of the
most frequent defects in DNNs. To assure high reliability against numerical
defects, in this paper, we propose the RANUM approach including novel
techniques for three reliability assurance tasks: detection of potential
numerical defects, confirmation of potential-defect feasibility, and suggestion
of defect fixes. To the best of our knowledge, RANUM is the first approach that
confirms potential-defect feasibility with failure-exhibiting tests and
suggests fixes automatically. Extensive experiments on the benchmarks of 63
real-world DNN architectures show that RANUM outperforms state-of-the-art
approaches across the three reliability assurance tasks. In addition, when the
RANUM-generated fixes are compared with developers' fixes on open-source
projects, in 37 out of 40 cases, RANUM-generated fixes are equivalent to or
even better than human fixes.
Linyi Li, Yuhao Zhang, Luyao Ren, Yingfei Xiong, Tao Xie
# Reliability Assurance for Deep Neural Network Architectures Against Numerical Defects

###### Abstract

With the widespread deployment of deep neural networks (DNNs), ensuring the reliability of DNN-based systems is of great importance. Serious reliability issues such as system failures can be caused by numerical defects, one of the most frequent defects in DNNs. To assure high reliability against numerical defects, in this paper, we propose the RANUM approach including novel techniques for three reliability assurance tasks: detection of potential numerical defects, confirmation of potential-defect feasibility, and suggestion of defect fixes. To the best of our knowledge, RANUM is the first approach that confirms potential-defect feasibility with failure-exhibiting tests and suggests fixes automatically. Extensive experiments on the benchmarks of 63 real-world DNN architectures show that RANUM outperforms state-of-the-art approaches across the three reliability assurance tasks. In addition, when the RANUM-generated fixes are compared with developers' fixes on open-source projects, in 37 out of 40 cases, RANUM-generated fixes are equivalent to or even better than human fixes.

 neural network, numerical defect, testing, fix

## I Introduction

Deep Neural Networks (DNNs) are successfully deployed and show remarkable performance in many challenging applications, including facial recognition [21, 56], game playing [38], and code completion [20, 4]. To develop and deploy DNNs, one needs to attain a DNN architecture, which is usually encoded by program code as the example shown in Figure 2. First, for training, the user executes the program with the architecture on the given training/validation data, attains the model weights, and stores them in a weight file. The architecture along with the weights is named a model. Then, for inference, the user loads the weight file to CPU/GPU memory or AI chips, executes the same program with the given inference sample and weights as arguments, and gets the model prediction result as the program output. With the wide deployment of DNN models (resulted from training DNN architectures), reliability issues of DNN-based systems have become a serious concern, where malfunctioning DNN-based systems have led to serious consequences such as fatal traffic accidents [24].

To assure the reliability of DNN-based systems, it is highly critical to detect and fix numerical defects for two main reasons. First, numerical defects widely exist in DNN-based systems. For example, in the DeepStability database [14], over 250 defects are identified in deep learning (DL) algorithms where over 60% of them are numerical defects. Moreover, since numerical defects exist at the architecture level, any model using the architecture naturally inherits these defects. Second, numerical defects can result in serious consequences. Once numerical defects (such as divide-by-zero) are exposed, the faulty DNN model will output NaN or INF instead of producing any meaningful prediction, resulting in numerical failures and system crashes [60, 58]. Thus, numerical defects hinder the application of DNNs in scenarios with high reliability and availability requirements such as threat monitoring in cybersecurity [33] and cloud system controlling [36, 13].

To address numerical defects in DNN architectures in an actionable manner [53], in this paper, we propose a workflow of reliability assurance (as shown in Figure 1), consisting of three tasks: potential-defect detection, feasibility confirmation, and fix suggestion, along with our proposed approach to support all these three tasks.

_Potential-Defect Detection._ In this task, we detect all potential numerical defects in a DNN architecture, with a focus on operators with numerical defects (in short as defective operators) that potentially exhibit inference-phase numerical failures for two main reasons, following the literature [61, 54]. First, these defective operators can be exposed after the model is deployed and thus are more devastating than those that potentially exhibit training-phase numerical failures [27, 61]. Second, a defective operator that potentially exhibits training-phase numerical failures can usually be triggered to exhibit inference-phase numerical failures, thus also being detected by

Fig. 1: Workflow for reliability assurance against numerical defects in DNN architectures. The left-hand side shows three tasks and the right-hand side shows corresponding examples. RANUM supports all the three tasks, and is the first automatic approach for system test generation and fix suggestion.
our task. For example, the type of training-phase NaN gradient failures is caused by an operator's input that leads to invalid derivatives, and this input also triggers failures in the inference phase [54].

_Feasibility Confirmation_. In this task, we confirm the feasibility of these potential numerical defects by generating failure-exhibiting system tests. As shown in Figure 1, a system test is a tuple of training example1\(\mathbf{x}_{\text{train}}\) and inference example \(\mathbf{x}\) such that after the training example is used to train the architecture under consideration, applying the resulting model on the inference example exhibits a numerical failure.

Footnote 1: In real settings, multiple training examples are used to train an architecture, but generating a single training example to exhibit failures (targeted by our work) is desirable for ease of debugging while being more challenging than generating multiple training examples to exhibit failures.

_Fix Suggestion_. In this task, we fix a feasible numerical defect. To determine the fix form, we have inspected the developers' fixes of the numerical defects collected by Zhang et al. [60] by looking at follow-up Stack Overflow posts or GitHub commits. Among the 13 numerical defects whose fixes can be located, 12 fixes can be viewed as explicitly or implicitly imposing interval preconditions on different locations, such as after inputs or weights are loaded and before defective operators are invoked. Thus, imposing an interval precondition, e.g., by clipping (i.e., chopping off the input parts that exceed the specified input range) the input for defective operator(s), is an effective and common strategy for fixing a numerical defect. Given a location (i.e., one related to an operator, input, or weight where users prefer to impose a fix), we suggest a fix for the numerical defect under consideration.

To support all the three tasks of the reliability assurance process against DNN numerical defects, we propose the **RANUM** approach in this paper.

_For task 1 and task 2a, which are already supported by two existing tools (DEBAR [61] and GRIST [54]), RANUM introduces novel extensions and optimizations that substantially improve the effectiveness and efficiency_. (1) DEBAR [61] is the state-of-the-art tool for potential-defect detection; however, DEBAR can handle only static computational graphs and does not support widely used dynamic graphs in PyTorch programs [28]. RANUM supports dynamic graphs thanks to our novel technique of _backward fine-grained node labeling_. (2) GRIST [54] is the state-of-the-art tool for generating failure-exhibiting unit tests to confirm potential-defect feasibility; however, GRIST conducts gradient back-propagation by using the original inference input and weights as the starting point. Recent studies [23, 8] on DNN adversarial attacks suggest that using a randomized input as the starting point leads to stronger attacks than using the original input. Taking this observation, we combine gradient back-propagation with random initialization in RANUM.

_For task 2 and task 3, which are not supported by any existing tool, RANUM is the first automatic approach for them_.

For **feasibility confirmation**, RANUM is the **first** approach that generates failure-exhibiting **system** tests that contain training examples. Doing so is a major step further from the existing GRIST tool, which generates failure-exhibiting unit tests ignoring the practicality of generated model weights. Given that in practice model weights are determined by training examples, we propose the technique of _two-step generation_ for this task. First, we generate a failure-exhibiting unit test. Second, we generate a training example that leads to the model weights in the unit test when used for training. For the second step, we extend the deep-leakage-from-gradient (DLG) attack [63] by incorporating the straight-through gradient estimator [3].

For **fix suggestion**, RANUM is the **first** automatic approach. RANUM is based on the novel technique of _abstraction optimization_. We observe that a defect fix in practice is typically imposing interval clipping on some operators such that each later-executed operator (including those defective ones) can never exhibit numerical failures. Therefore, we propose the novel technique of abstraction optimization to "deviate away" the input range of a defective operator from the invalid range, falling in which can cause numerical failures.

For RANUM, we implement a tool2 and evaluate it on the benchmarks [54] of 63 real-world DNN architectures containing 79 real numerical defects; these benchmarks are the largest benchmarks of DNN numerical defects to the best of our knowledge. The evaluation results show that RANUM is both effective and efficient in all the three tasks for DNN reliability assurance. (1) For potential-defect detection, RANUM detects \(>\)60% more true defects than the state-of-the-art DEBAR approach. (2) For feasibility confirmation, RANUM generates failure-exhibiting unit tests to confirm potential numerical defects in the benchmarks with 100% success rate; in contrast, with the much higher time cost (17.32X), the state-of-the-art GRIST approach generates unit tests to confirm defects with 96.96% success rate. More importantly, for the first time, RANUM generates failure-exhibiting system tests that confirm defects (with 92.78% success rate). (3) For fix suggestion, RANUM proposes fix suggestions for numerical defects with 100% success rate. In addition, when the RANUM-generated fixes are compared with developers' fixes on open-source projects, in 37 out of 40 cases, RANUM-generated fixes are equivalent to or even better than human fixes.

Footnote 2: Open source at [https://github.com/llyly/RANUM](https://github.com/llyly/RANUM).

This paper makes the following main contributions:

* We formulate the reliability assurance problem for DNN architectures against numerical defects and elaborate on three important tasks for this problem.
* We propose RANUM--the first automatic approach that solves all these three tasks. RANUM includes three novel techniques (backward fine-grained node labeling, two-step test generation, and abstraction optimization) and solves system test generation and fix suggestion for the first time.
* We implement RANUM and apply it on 63 real-world DNN architectures, showing the high effectiveness and efficiency of RANUM compared to both the state-of-the-art approaches and developers' fixes.
## II Background and Approach Overview

In this section, we introduce the background of DNN numerical defects and failures, and then give an overview of the RANUM approach with a running example.

### _Background_

DL developers define the DNN architecture with code using modern DL libraries such as PyTorch [28] and TensorFlow [1]. The DNN architecture can be expressed by a computational graph. Figures 2 and 3 depict a real-world example. Specifically, the DNN architecture in a DL program can be automatically converted to an ONNX-format computational graph [43].

The computational graph can be viewed as a Directed Acyclic Graph (DAG): \(\mathcal{G}=\langle\mathcal{V},\mathcal{E}\rangle\), where \(\mathcal{V}\) and \(\mathcal{E}\) are sets of nodes and edges, respectively. We call nodes with zero in-degree as _initial nodes_, which correspond to input, weight, or constant nodes. Initial nodes provide concrete data for the DNN models resulted from training the DNN architecture. The data from each node is formatted as a tensor, i.e., a multidimensional array, with a specified data type and array shape annotated alongside the node definition. We call nodes with positive in-degree as _internal nodes_, which correspond to concrete operators, such as matrix multiplication (MatMul) and addition (Add). During model training, the model weights, i.e., data from weight nodes, are generated by the training algorithm. Then, in the deployment phase (i.e., model inference), with these trained weights and a user-specified input named inference example, the output of each operator is computed in the topological order. The output of some specific node is used as the prediction result.

We let \(\mathbf{x}\) and \(\mathbf{w}\) denote the concatenation of data from all input nodes and data from all weight nodes, respectively.3 For example, in Figure 3, \(\mathbf{x}\) concatenates data from nodes 1 and 11; and \(\mathbf{w}\) concatenates data from nodes 2 and 4. Given specific \(\mathbf{x}\) and \(\mathbf{w}\), the input and output for each node are deterministic.4 We use \(f^{\text{in}}_{n}(\mathbf{x};\mathbf{w})\) and \(f^{\text{out}}_{n}(\mathbf{x};\mathbf{w})\) to express input and output data of node \(n\), respectively, given \(\mathbf{x}\) and \(\mathbf{w}\).

Footnote 3: A bolded alphabet stands for a vector or tensor throughout the paper.

Footnote 4: An architecture may contain stochastic nodes. We view these nodes as nodes with randomly sampled data, so the architecture itself is deterministic.

**Numerical Defects in DNN Architecture.** We focus on inference-phase numerical defects. These defects lead to numerical failures when specific operators receive inputs within invalid ranges so that the operators output NaN or INF.

**Definition 1**.: For the given computational graph \(\mathcal{G}=\langle\mathcal{V},\mathcal{E}\rangle\), if there is a node \(n_{0}\in\mathcal{V}\), such that there exists a valid input and valid weights that can let the input of node \(n_{0}\) fall within the invalid range, we say there is a _numerical defect_ at node \(n_{0}\).

Formally, \(\exists\mathbf{x}_{0}\in\mathcal{X}_{\text{valid}},\mathbf{w}_{0}\in\mathcal{W}_{ \text{valid}},f^{\text{in}}_{n_{0}}(\mathbf{x}_{0};\mathbf{w}_{0})\in\mathcal{I}_{n_{0 },\text{invalid}}\)

\(\Longrightarrow\exists\) numerical defect at node \(n_{0}\).

In the definition, \(\mathcal{X}_{\text{valid}}\) and \(\mathcal{W}_{\text{valid}}\) are valid input range and weight range, respectively, which are clear given the deployed scenario. For example, ImageNet Resnet50 models have valid input range \(\mathcal{X}_{\text{valid}}=[0,1]^{3\times 224\times 224}\) since image pixel intensities are within \([0,1]\), and valid weight range \(\mathcal{W}_{\text{valid}}=[-1,1]^{p}\) where \(p\) is the number of parameters since weights of well-trained Resnet50 models are typically within \([-1,1]\). The invalid range \(\mathcal{I}_{n_{0},\text{invalid}}\) is determined by \(n_{0}\)'s operator type with detailed definitions in Suppl. B. For example, for the Log operator, the invalid range \(\mathcal{I}_{n_{0},\text{invalid}}=(-\infty,U_{\min})\) where \(U_{\min}\) is the smallest positive number of a tensor's data type.

### _Approach Overview_

In Figure 4, we show the overview structure of the RANUM approach. RANUM takes a DNN architecture as the input. Note that although RANUM is mainly designed and illustrated for a DNN architecture, the RANUM approach can also be directly applied to general neural network architectures since they can also be expressed by computational graphs. First, the DNN static analysis framework (task 1 in Figure 1) in

Fig. 4: Overview of the RANUM approach. The output of RANUM indicates confirmation and manifestation of numerical defects (that can be feasibly exposed at the system level) for a given DNN architecture and effective fixes for the architecture’s confirmed defects.

Fig. 3: Computational graph encoded by the snippet in Figure 2.
RANUM detects all potential numerical defects in the architecture. Second, the two-step test generation component (task 2) in Figure 1), including unit test generation and training example generation, confirms the feasibility of these potential numerical defects. Third, the abstraction optimization component (task 3 in Figure 1) takes the input/output abstractions produced by the DNN static analysis framework along with the user-specified fix locations, and produces preconditions to fix the confirmed defects.

We next go through the whole process in detail taking the DNN architecture shown in Figure 3 as a running example.

**Task 1: Potential-Defect Detection via Static Analysis**. The DNN static analysis framework within RANUM first computes the numerical intervals of possible inputs and outputs for all nodes within the given DNN architecture, and then flags any nodes whose input intervals overlap with their invalid ranges as nodes with potential numerical defects.

In Figure 3, suppose that the user-specified input x-input (node 1) is within (elementwise, same below) range \([(-10,-10)^{\mathrm{ T}},(10,10)^{\mathrm{ T}}]\); weights (node 2) are within range \([-10\ \
method is clipping before the defective operator, \(\mathcal{V}_{\text{fix}}\) are nodes with numerical defects (e.g., nodes 9, 10 in Figure 3).

According to the empirical study of developers' fixes in Section I, 12 out of 13 defects are fixed by imposing interval preconditions for clipping the inputs of \(\mathcal{V}_{\text{fix}}\). Hence, we suggest interval precondition, which is interval constraint \(\mathbf{l}_{n}\leq f_{n}^{\text{in}}(\mathbf{x};\mathbf{w})\leq\mathbf{u}_{n}\) for nodes \(n\in\mathcal{V}_{\text{fix}}\), as the defect fix in this paper. A fix should satisfy that, when these constraints \(\bigwedge_{n\in\mathcal{V}_{\text{fix}}}(\mathbf{l}_{n}\leq f_{n}^{\text{in}}(\mathbf{x };\mathbf{w})\leq\mathbf{u}_{n})\) are imposed, the input of any node in the computational graph should always be valid, i.e., \(f_{n_{0}}^{\text{in}}(\mathbf{x};\mathbf{w})\notin\mathcal{I}_{n_{0},\text{invalid}}, \forall n_{0}\in\mathcal{V}\).

In RANUM, we formulate the fix suggestion task as a constrained optimization problem, taking the endpoints of interval abstractions for nodes in \(\mathcal{V}_{\text{fix}}\) as optimizable variables. We then propose the novel technique of abstraction optimization to solve this constrained optimization problem. Back to the Figure 3 example, if users plan to impose a fix on inference input, RANUM can suggest the fix \(-1\leq\) x-input \(\leq\) 1; if users plan to impose a fix on nodes with numerical defects, RANUM can suggest the fix \(10^{-38}\leq\) node 9 & node 10.input \(\leq+\infty\).

## III The RANUM Approach

In this section, we introduce the three novel techniques in RANUM: backward fine-grained node labeling in Section III-A; two-step test generation in Section III-B; and abstraction optimization in Section III-C.

_DNN Static Analysis Framework with Backward Fine-Grained Node Labeling for Potential-Defect Detection_

RANUM contains a static analysis framework to enable potential-defect detection and support downstream tasks as shown in Figure 4. Given a DNN architecture and valid ranges for input and weight nodes, the static analysis framework computes interval abstractions for possible inputs and outputs of each node. As a result, we can check whether an overlap exists between the interval abstraction and invalid input ranges for all nodes in the graph to detect potential numerical defects. Then, the defective nodes are fed into the two-step test generation component to confirm the feasibility of potential defects; and the differentiable abstractions are fed into the abstract optimization component to produce fixes.

Formally, for given valid ranges of inference input and model weights, namely \(\mathcal{X}\) and \(\mathcal{W}\), for each node \(n\in\mathcal{V}\), our framework computes _sound_ input interval abstraction \([\mathbf{l}_{n},\mathbf{u}_{n}]:=\{\mathbf{x}:\mathbf{l}_{n}\leq\mathbf{x}\leq\mathbf{u}_{n}\}\) such that \([\mathbf{l}_{n},\mathbf{u}_{n}]\) always captures all possible inputs of the node: \([\mathbf{l}_{n},\mathbf{u}_{n}]\supseteq\{f_{n}^{\text{in}}(\mathbf{x},\mathbf{w}):\mathbf{x}\in \mathcal{X},\mathbf{w}\in\mathcal{W}\}\). We also compute output interval abstractions similarly.

Compared with traditional analysis tools for numerical software [10, 39], RANUM's static analysis framework designs abstractions for DNN primitives operating on multi-dimensional tensors that are not supported by traditional tools. Compared with the state-of-the-art DEBAR tool [61], RANUM uses the same abstraction domain (interval domain with tensor partitioning), but incorporates a novel technique (backward fine-grained node labeling) to improve abstraction precision and support a wider range of DNN architectures.

**Abstract Domain: Interval with Tensor Partitioning.** Following DEBAR's design, we use the interval with tensor partitioning [61] as the abstraction domain. This abstraction domain partitions a tensor into multiple subblocks and shares the interval abstractions at the block level instead of imposing abstractions at the element level. Therefore, we can compute the abstraction of a smaller size than the original tensor to improve efficiency.

**Our Technique: Backward Fine-Grained Node Labeling.** The interval domain with tensor partitioning provides a degree of freedom in terms of the partition granularity, i.e., we can choose the subblock size for each node's abstraction. When the finest granularity, i.e., elementwise abstraction, is chosen, the abstraction interval is the most concrete. When the coarsest granularity (i.e., one scalar to summarize the node tensor) is chosen, the abstraction saves the most space and computational cost but loses much precision.

_Example._ Suppose that the possible input range of a node is \(([-1,0],[0,1],[1,2],[-1,0])\), where each interval \([l,u]\) specifies the range of corresponding elements in the four-dimensional vector. If we choose the finest granularity, we use \([\mathbf{l}_{n},\mathbf{u}_{n}]=[(-1,0,1,-1),(0,1,2,0)]\) as the input range abstraction. If we choose the coarsest granularity, we use \([\mathbf{l}_{n},\mathbf{u}_{n}]=[-1,2]\) as the abstraction where the same interval is shared for all elements. As we can see, finer granularity provides tighter abstraction at the expense of larger computational and space costs.

In DEBAR, the coarsest granularity is used by default for most operators. However, we find that using the finest instead of the coarsest granularity for some nodes is more beneficial for overall abstraction preciseness. For example, the control-flow operators (e.g., Loop) benefit from concrete execution to determine the exact control flow in the dynamic graph, and the indexing operators (e.g., Slice) and shaping operators (e.g., Reshape) benefit from explicit indexers and shapes to precisely infer the output range. Hence, we propose to use the finest granularity for some nodes (namely fine-grained requiring operators) while the coarsest granularity for other nodes during static analysis.

To benefit from the finest granularity abstraction for required nodes, typically, all of their preceding nodes also need the finest granularity. Otherwise, the over-approximated intervals from preceding nodes will be propagated to the required nodes, making the finest abstraction for the required nodes useless. To solve this problem, in RANUM, we back-propagate "fine-grained" labels from these fine-grained requiring nodes to initial nodes by topologically sorting the graph with _inverted_ edges, and then apply the finest granularity abstractions on all labeled nodes. In practice, we find that this strategy eliminates the control-flow ambiguity and indexing ambiguity with little
loss of efficiency6. As a result, RANUM supports all dynamic graphs (which are not supported by DEBAR) that comprise 39.2% of the benchmarks proposed by Yan et al. [54].

Footnote 6: Theoretically, using the finest granularity for tensor partitioning cannot fully eliminate the ambiguity, since interval abstraction is intrinsically an over-approximation. Nevertheless, in our evaluation (Section IV), we find that this technique eliminates control-flow and indexing ambiguities on all 63 programs in the benchmarks.

Furthermore, when preceding nodes use finer-grain abstraction granularity, the subsequent nodes should preserve such fine granularity to preserve the analysis preciseness. Principally, the choice of abstraction granularity should satisfy both tightness (bearing no precision loss compared to elementwise interval abstraction) and minimality (using the minimum number of partitions for high efficiency). To realize these principles, we dynamically determine a node's abstraction granularity based on the granularity of preceding nodes. The abstraction design for some operators is non-trivial. Omitted details (formulation, illustration, and proofs) about the static analysis framework are in Suppl. C.

In summary, the whole static analysis process consists of three steps. (1) Determine the tensor partition granularity of all initial nodes by our technique of backward fine-grained node labeling. (2) Sort all nodes in the graph in the topological order. (3) Apply corresponding abstraction computation algorithms for each node based on the preceding node's abstractions. The key insight behind the design of our static analysis framework is the strategic granularity selection for tensor abstraction, maintaining both high efficiency (by selecting the coarse granularity for data-intensive nodes) and high precision (by selecting the fine granularity for some critical nodes, such as nodes with control-flow, indexing, and shaping operators).

### _Two-Step Test Generation for Feasibility Confirmation_

RANUM generates failure-exhibiting system tests for the given DNN to confirm the feasibility of potential numerical defects. Here, we take the DNN architecture as the input. From the static analysis framework, we obtain a list of nodes that have potential numerical defects. For each node \(n_{0}\) within the list, we apply our technique of two-step test generation to produce a failure-exhibiting system test \(\mathbf{t}_{\text{sys}}=\langle\mathbf{x}_{\text{train}},\mathbf{x}_{\text{infer}}\rangle\) as the output. According to Section II-B, the test should satisfy that after the architecture is trained with \(\mathbf{x}_{\text{train}}\), entering \(\mathbf{x}_{\text{infer}}\) in the inference phase results in a numerical failure.

We propose the novel technique of two-step test generation: first, generate failure-exhibiting unit test \(\langle\mathbf{w}_{\text{infer}},\mathbf{x}_{\text{infer}}\rangle\); then, generate training example \(\mathbf{x}_{\text{train}}\) that leads model weights to be close to \(\mathbf{w}_{\text{infer}}\) after training.

**Step a: Unit Test Generation**. As sketched in Section II-B, we strengthen the state-of-the-art unit test generation approach, GRIST [54], by combining it with random initialization to complete this step. Specifically, GRIST leverages the gradients of the defective node's input with respect to the inference input and weights to iteratively update the inference input and weights to generate failure-exhibiting unit tests. However, GRIST always conducts updates from the existing inference input and weights, suffering from local minima problem [23]. Instead, motivated by DNN adversarial attack literature [23, 45], a sufficient number of random starts help find global minima effectively. Hence, in RANUM, we first conduct uniform sampling 100 times for both the inference input and weights to trigger the numerical failure. If no failure is triggered, we use the sample that induces the smallest loss as the start point for gradient optimization. As Section IV-A shows, this strategy substantially boosts the efficiency, achieving 17.32X speedup.

**Step b: Training Example Generation**. For this step, RANUM takes the following inputs: (1) the DNN architecture, (2) the failure-exhibiting unit test \(t_{\text{unit}}=\langle\mathbf{w}_{\text{infer}},\mathbf{x}_{\text{infer}}\rangle\), and (3) the randomly initialized weights \(\mathbf{w}_{0}\). Our goal is to generate a legal training example \(\mathbf{x}_{\text{train}}\), such that the model trained with \(\mathbf{x}_{\text{train}}\) will contain weights close to \(\mathbf{w}_{\text{infer}}\).

DNNs are typically trained with gradient-descent-based algorithms such as stochastic gradient descent (SGD). In SGD, in each step \(t\), we sample a mini-batch of samples from the training dataset to compute their gradients on model weights and use these gradients to update the weights. We focus on one-step SGD training with a single training example, since generating a single one-step training example to exhibit a failure is more desirable for debugging because, in one-step training, the model weights are updated strictly following the direction of the gradients. Therefore, developers can inspect inappropriate weights, easily trace back to nodes with inappropriate gradients, and then fix these nodes. In contrast, in multi-step training, from inappropriate weights, developers cannot trace back to inappropriate gradients because weights are updated iteratively and interactions between gradients and weights are complex (even theoretically intractable [18]).

In this one-step training case, after training, the model weights \(\mathbf{w}_{\text{infer}}\) satisfy

\[\mathbf{w}_{\text{infer}}=\mathbf{w}_{0}-\gamma\nabla_{\mathbf{w}}\mathcal{L}(\mathbf{x}_{ \text{train}};\mathbf{w}_{0}), \tag{1}\]

where \(\gamma\in\mathbb{R}_{+}\) is a predefined learning rate, and \(\mathcal{L}\) is the predefined loss function in the DNN architecture. Hence, our goal becomes finding \(\mathbf{x}_{\text{train}}\) that satisfies

\[\nabla_{\mathbf{w}}\mathcal{L}(\mathbf{x}_{\text{train}};\mathbf{w}_{0})=(\mathbf{w}_{0}-\mathbf{ w}_{\text{infer}})/\gamma. \tag{2}\]

The DLG attack [63] is a technique for generating input data that induce specific weight gradients. The attack is originally designed for recovering training samples from monitored gradient updates. Since the right-hand side (RHS) of Equation (2) is known, our goal here is also to generate input example \(\mathbf{x}_{\text{train}}\) that induces specific weight gradients. Therefore, we leverage the DLG attack to generate training example \(\mathbf{x}_{\text{train}}\).

**Extending DLG Attack with Straight-Through Estimator**. Directly using DLG attack suffers from an optimization challenge in our scenario. Specifically, in DLG attack, suppose that the target weight gradients are \(\Delta\mathbf{w}_{\text{trarg}}\), we use gradient descent over the squared error \(\|\nabla_{\mathbf{w}}\mathcal{L}(\mathbf{x};\mathbf{w}_{0})-\Delta\mathbf{w}_{\text{trarg}}\|_ {2}^{2}\) to generate \(\mathbf{x}\). In this process, we need meaningful gradient information of this squared error loss to perform the optimization. However, the gradient of this loss involves second-order derivatives of \(\mathcal{L}(\mathbf{x};\mathbf{w}_{0})\), which could be zero. For
example, DNNs with ReLU as activation function are piecewise linear and have zero second-order derivatives almost everywhere [35]. This optimization challenge is partly addressed in DLG attack by replacing ReLU with Sigmoid, but it changes the DNN architecture (i.e., the system under test) and hence is unsuitable.

We leverage the straight-through estimator to mitigate the optimization challenge. Specifically, for a certain operator, such as ReLU, we do not change its forward computation but change its backward gradient computation to provide second-order derivatives within the DLG attack process. For example, for ReLU, in backward computation we use the gradient of \(\mathrm{Softplus}\) function, namely \(1-\frac{1}{1+\exp(\mathbf{x})}\), because \(\mathrm{Softplus}\) is an approximation of ReLU[7] with non-zero second-order derivatives. Note that we modify the computed gradients only within the DLG attack process. After such \(\mathbf{x}_{\text{train}}\) is generated by the attack, we evaluate whether it triggers a numerical failure using the original architecture and gradients in Equation (1).

Suppl. E lists hyperparameters used by our implementation.

### _Abstraction Optimization for Fix Suggestion_

In this task, we aim to generate the precondition fix given imposing locations. The inputs are the DNN architecture, the node \(n_{0}\) with numerical defects, and a node set \(\mathcal{V}_{\text{fix}}\) to impose the fix. We would like to generate interval preconditions for \(\mathcal{V}_{\text{fix}}\) node inputs so that after these preconditions are imposed, the defect on \(n_{0}\) is fixed.

Formally, our task is to find \(\langle l_{n},u_{n}\rangle\) for each \(n\in\mathcal{V}_{\text{fix}}\) (\(l_{n}\) and \(u_{n}\) are scalars so the same interval bound applied to all elements of \(n\)'s tensor), such that for any \(\mathbf{x},\mathbf{w}\) satisfying \(\mathbf{f}_{n}^{\text{in}}(\mathbf{x};\mathbf{w})\in[l_{n},u_{n}]\), \(\forall n\in\mathcal{V}_{\text{fix}}\), for the defective node \(n_{0}\), we have \(f_{n_{0}}^{\text{in}}(\mathbf{x};\mathbf{w})\not\in\mathcal{I}_{n_{0},\text{valid}}\), where the full list of invalid input ranges \(\mathcal{I}_{n_{0},\text{invalid}}\) is in Suppl. B. There is an infinite number of possible \(\langle l_{n},u_{n}\rangle\) interval candidates since \(l_{n}\) and \(u_{n}\) are floating numbers. Hence, we need an effective technique to find a valid solution from the exceedingly large search space that incurs a relatively small model utility loss. To achieve so, we formulate a surrogate optimization problem for this task.

\[\underset{l_{n},u_{n}\in\mathcal{V}_{\text{fix}}}{\text{maximize}} s\quad\text{s.t.}\quad u_{n}\geq l_{n}+s(u_{n}^{\text{valid}}-l_{n}^{\text{valid}}), \forall n\in\mathcal{V}_{\text{fix}}, \tag{3}\] \[\qquad\qquad\qquad\qquad\qquad\qquad\qquad\qquad\qquad\qquad \qquad\qquad\qquad\qquad\qquad\qquad\qquad\qquad\qquad\qquad\qquad\qquad\] (4) \[\qquad\qquad\qquad\qquad\qquad\qquad\qquad\qquad\qquad\mathcal{L} _{n_{0}}^{\text{precond}}(\{l_{n},u_{n}\}_{n\in\mathcal{V}_{\text{fix}}})<0. \tag{5}\]

Here, \(l_{n}^{\text{valid}}\) and \(u_{n}^{\text{valid}}\) are the valid ranges (of the node's input \(n\)), which are fixed and determined by the valid ranges of input and weights. \(\mathcal{L}_{n_{0}}^{\text{precond}}\) is the node-specific precondition generation loss that is the distance between the furthest endpoint of defective node \(n_{0}\)'s interval abstraction and \(n_{0}\)'s valid input range. Hence, when \(\mathcal{L}_{n_{0}}^{\text{precond}}(\{l_{n},u_{n}\}_{n\in\mathcal{V}_{\text{ fix}}})\) becomes negative, the solution \(\{l_{n},u_{n}\}_{n\in\mathcal{V}_{\text{fix}}}\) is a valid precondition. The optimization variables are the precondition interval endpoints \(l_{n}\) and \(u_{n}\) and the objective is the relative span of these intervals. The larger the span is, the looser the precondition constraints are, and the less hurt they are for the model's utility. Equation (3) enforces the interval span requirement. Equation (4) assures that the precondition interval is in the valid range. Equation (5) guarantees the validity of the precondition as a fix.

For any \(\{l_{n},u_{n}\}_{n\in\mathcal{V}_{\text{fix}}}\), thanks to RANUM's static analysis framework, we can compute induced intervals of defective node \(n_{0}\), and thus compute the loss value \(\mathcal{L}_{n_{0}}^{\text{precond}}\).

As shown in Algorithm 1, we propose the technique of **abstraction optimization** to effectively and approximately solve this optimization. Our technique works iteratively. In the first iteration, we set span \(s=1\), and in the subsequent iterations, we reduce the span \(s\) exponentially as shown in Line 13 where hyperparameter \(\gamma_{s}=0.9\). Inside each iteration, for each node to impose precondition \(n\in\mathcal{V}_{\text{fix}}\), we use the interval center \(c_{n}=(l_{n}+u_{n})/2\) as the optimizable variable and compute the _sign_ of its gradient: \(\mathrm{sgn}(\nabla_{c_{n}}\text{loss})\). We use this gradient sign to update each \(c_{n}\) toward reducing the loss value in Line 6. Then, we use \(c_{n}\) and the span \(s\) to recover the actual interval in Line 7 and clip \(l_{n}\) and \(u_{n}\) by the valid range \([l_{n}^{\text{valid}},u_{n}^{\text{valid}}]\) in Line 8. At the end of this iteration, for updated \(l_{n}\) and \(u_{n}\), we compute \(\mathcal{L}_{n_{0}}^{\text{precond}}(\{l_{n},u_{n}\}_{n\in\mathcal{V}_{\text{ fix}}})\) to check whether the precondition is a fix. If so, we terminate; otherwise, we proceed to the next iteration. We note that _if the algorithm finds a precondition, the precondition is guaranteed to be a valid fix_ by the soundness nature of our static analysis framework and the definition of \(\mathcal{L}_{n_{0}}^{\text{precond}}\). When no feasible precondition is found within \(\mathsf{maxiter}=1000\) iterations, we terminate the algorithm and report "failed to find the fix".

```
0: DNN architecture \(\mathcal{G}=\langle\mathcal{V},\mathcal{E}\rangle\), defective node \(n_{0}\in\mathcal{V}\), nodes to impose fix \(\mathcal{V}_{\text{fix}}\subseteq\mathcal{V}\)
1:\(s\gets 1,\gamma_{s}\gets 0.9,\gamma_{c}\gets 0.1,\text{minstep} \gets 0.1,\text{maxiter}\gets 1000\)
2:\(c_{n}\gets(l_{n}^{\text{valid}}+u_{n}^{\text{valid}})/2,l_{n} \gets l_{n}^{\text{valid}},u_{n}\gets u_{n}^{\text{valid}},\forall n\in \mathcal{V}_{\text{fix}}\)
3:for\(i=1\) to maxiterdo
4:for\(n\in\mathcal{V}_{\text{fix}}\)do
5:\(\text{loss}\leftarrow\mathcal{L}_{n_{0}}^{\text{precond}}(\{l_{n^{\prime}},u_{n^{ \prime}}\}_{n^{\prime}\in\mathcal{V}_{\text{fix}}})\)
6:\(c_{n}\gets c_{n}-\gamma_{c}\max\{[c_{n}],\text{minstep}(\nabla_{c_{n}} \text{loss})\)
7:\((l_{n},u_{n})\leftarrow(c_{n}-\frac{s(u_{n}^{\text{valid}}-\text{valid})}{2},c_{n} +\frac{s(u_{n}^{\text{valid}}-\text{valid})}{2})\)
8:\((l_{n},u_{n})\leftarrow(\max\{l_{n},l_{n}^{\text{valid}}\},\min\{u_{n},u_{n}^{ \text{valid}}\})\)
9:endfor
10:if\(\mathcal{L}_{n_{0}}^{\text{precond}}(\{l_{n},u_{n}\}_{n\in\mathcal{V}_{\text{ fix}}})<0\)then
11:return\(\{l_{n},u_{n}\}_{n\in\mathcal{V}_{\text{fix}}}\)// Find precondition fix
12:endif
13:\(s\leftarrow\gamma_{s}\cdot s\)
14:endfor
15:return"failed" // Failed to find precondition fix
```

**Algorithm 1** Abstraction Optimization (Section III-C)

_Remark_. The key ingredient in the technique is the gradient-sign-based update rule (shown in Line 6), which is much more effective than normal gradient descent for two reasons. (1) Our update rule can get rid of gradient explosion and vanishing problems. For early optimization iterations, the span \(s\) is large and interval bounds are generally coarse, resulting in too large or too small gradient magnitude. For example, the input range for Log could be \([1,10^{10}]\) where gradient can be \(10^{-10}\), resulting in almost negligible gradient updates. In contrast, our update rule leverages the gradient sign, which always points to the correct gradient direction. The update step size in our rule is the maximum of current magnitude \(|c_{n}|\) and minstep to avoid stagnation. (2) Our update rule mitigates the gradient
magnitude discrepancy of different \(c_{n}\). At different locations, the nodes in DNNs can have diverse value magnitudes that are not aligned with their gradient magnitudes, making gradient optimization challenging. Therefore, we use this update rule to solve the challenge, where the update magnitude depends on the value magnitude (\(|c_{n}|\)) instead of gradient magnitude (\(\nabla_{c_{n}}\) loss). We empirically compare our technique with standard gradient descent in Section IV-C.

## IV Experimental Evaluation

We conduct a systematic experimental evaluation to answer the following research questions.

* For tasks already supported by existing state-of-the-art (SOTA) tools (tasks 1 and 2a), how much more effective and efficient is RANUM compared to these SOTA tools?
* For feasibility confirmation via _generating failure-exhibiting system tests_ (task 2), how much more effectively and efficiently can RANUM confirm potential numerical defects compared to baseline approaches?
* For _suggesting fixes_ (task 3), how much more efficient and effective is RANUM in terms of guarding against numerical failures compared to baseline approaches and developers' fixes, respectively?

For RQ1, we compare RANUM with all SOTA tools. For RQ2 and RQ3, RANUM is the first approach to the best of our knowledge, so we compare RANUM with baseline approaches (constructed by leaving our novel techniques out of RANUM) and developers' fixes. We conduct the evaluation on the GRIST benchmarks [54], being the largest dataset of real-world DNN numerical defects to our knowledge. The benchmarks contain 63 real-world DL programs with numerical defects collected from previous studies and GitHub. Each program contains a DNN architecture, and each architecture has one or more numerical defects. There are 79 real numerical defects in total.

We perform our evaluation on a Linux workstation with a 24-core Xeon E5-2650 CPU running at 2.20 GHz. Throughout the evaluation, we stop the execution after reaching \(30\,\mathrm{min}\) limit by following the evaluation setup by the most recent related work [54].

### _RQ1: Comparison with SOTA Tools_

For two tasks, existing tools can provide automatic support: potential-defect detection (task 1) where the SOTA tool is DEBAR [61], and failure-exhibiting unit test generation (task 2a) where the SOTA tool is GRIST [54]. We compare RANUM with these tools on their supported tasks, respectively.

**Comparison with DEBAR**. RANUM successfully detects all 79 true defects and DEBAR detects only 48 true defects according to both our evaluation and the literature [54]. Hence, RANUM detects 64.58% more true defects than DEBAR. In terms of efficiency, DEBAR and RANUM have similar running time, and both finish in \(3\,\mathrm{s}\) per case.

We manually inspect the cases where DEBAR fails but RANUM succeeds. They correspond to DL programs written with the PyTorch library, which generates dynamic computational graphs that DEBAR cannot handle. In contrast, RANUM provides effective static analysis support for dynamic computational graphs thanks to our backward fine-grained node labeling technique (Section III-A) that is capable of disambiguating the control flow within dynamic graphs.

**Comparison with GRIST**. Results are shown in Table I. Since both RANUM and GRIST have a randomness component where RANUM uses random initialization and GRIST relies on DNN's randomly initialized weights, we repeat both approaches for 10 runs, record the total number of times where a failure-exhibiting unit test is generated, and the average execution time per run. RANUM succeeds in _all_ cases and _all_ repeated runs, and GRIST fails to generate such unit test in 24 out of 790 runs (i.e., 96.96% success rate). RANUM has \(6.66\,\mathrm{s}\) average execution time and is 17.32X faster than GRIST.

The superior effectiveness and efficiency of RANUM are largely due to the existence of random initialization as introduced in Section III-B. We observe that since GRIST always takes initial model weights and inference input as the starting point to update from, the generated unit test is just slightly changed from initial weights and input, being hard to expose the target numerical defect. In contrast, RANUM uses random initialization to explore a much larger space and combines gradient-based optimization to locate the failure-exhibiting instances from the large space. We also evaluate the pure random strategy that uses only random initialization without gradient-based optimization, and such strategy fails in 30 runs, being inferior to both RANUM and GRIST, implying that both random initialization and gradient-based optimization are important. Among all the 79 cases, RANUM is slower than GRIST on only one case (28a). For this case, we find the default inference input loaded by the DNN program (used by GRIST) is not far from a failure-exhibiting one, but a randomly sampled inference input (used by RANUM) is usually far from that. Hence, RANUM takes more iterations to find a failure-exhibiting inference input by the nature of gradient-based optimization.

### _RQ2: Feasibility Confirmation via System Test Generation_

In task 2, RANUM confirms the feasibility of potential numerical defects by generating failure-exhibiting system tests.

**Baseline**. Since RANUM is the first approach for this task, we do not compare with existing literature and propose one random-based approach (named "Random" hereinafter) as the baseline. In "Random", we first generate a failure-exhibiting unit test with random sampling. If there is any sample that triggers a failure, we stop and keep the inference example part as the desired \(\mathbf{x}_{\text{infer}}\). Then, we generate \(\mathbf{x}_{\text{train}}\) again by random sampling. If any sample, when used for training, could induce model weights \(\mathbf{w}\) that cause a numerical failure when using \(\mathbf{x}_{\text{infer}}\) as the inference input, we keep that sample as \(\mathbf{x}_{\text{train}}\) and terminate. If and only if both \(\mathbf{x}_{\text{infer}}\) and \(\mathbf{x}_{\text{train}}\) are found, we count this run as a "success" one for "Random".
For each defect, due to the randomness of the model's initial weights, we repeat both RANUM and "Random" for \(10\) runs. Both approaches use the same set of random seeds.

**Evaluation Result.** Results are in Table II. We observe that RANUM succeeds in \(733/(79\times 10)=92.78\%\) runs and the baseline "Random" succeeds in \(649/(79\times 10)=82.15\%\) runs. Moreover, RANUM spends only \(17.31\,\mathrm{s}\) time on average per run, which is a 19.30X speedup compared to "Random". We also observe that RANUM is more reliable across repeated runs. There are only 6 cases with unsuccessful repeated runs in RANUM, but there are 19 such cases in "Random". Hence, RANUM is substantially more effective, efficient, and reliable for generating system tests than the baseline.

**Discussion**. The high effectiveness of RANUM mainly comes from the advantage of gradient-guided search compared with random search. As described in Section III-B, RANUM leverages both first-order gradients (in step a) and second-order derivatives (in step b) to guide the search of system tests. In contrast, "Random" uses random sampling hoping that failure-exhibiting training examples can emerge after sufficient sampling. Hence, when such training examples are relatively rare in the whole valid input space, "Random" is less effective. We conduct an ablation study (in Suppl. F) for showing that RANUM improves over "Random" in both steps inside RANUM.

**Failing-Case Analysis**. We study all six defects where RANUM may fail and have the following findings. (1) For four defects (Case IDs 1, 15, 37, and 38), the architecture is challenging for gradient-based optimization, e.g., due to the Min/Max/Softmax operators that provide little or no gradient information. We leave it as future work to solve these cases, likely in need of dynamically detecting operators with vanishing gradients and reconstructing the gradient flow. (2) Two defects (Case IDs 28a and 28b) correspond to those caused by Div operators where only a close-to-zero divisor can trigger a numerical failure. Hence, for operators with narrow invalid ranges, RANUM may fail to generate failure-exhibiting system tests.

### _RQ3: Fix Suggestion_

In task 3, RANUM suggests fixes for numerical defects. We compare RANUM with fixes generated by baseline approaches and developers' fixes.

#### Iv-C1 **Comparison between RANUM and Baselines**

RANUM is the first approach for this task, and we propose two baseline approaches to compare with. (1) RANUM-E: this approach changes the abstraction domain of RANUM from interval with tensor partitioning to standard interval.
To some degree, RANUM-E represents the methodology of conventional static analysis tools that use standard interval domain for abstraction and search of effective fixes. (2) GD: this approach uses standard gradient descent for optimization instead of the abstraction optimization technique in RANUM.

**Evaluation Protocol.** We evaluate whether each approach can generate fixes that eliminate _all_ numerical defects for the DNN architecture under analysis given imposing locations. We consider three types of locations: on both weight and input nodes, on only weight nodes, and on only input nodes. In practice, model providers can impose fixes on weight nodes by clipping weights after a model is trained; and users can impose fixes on input nodes by clipping their inputs before loading them into the model. Since all approaches are deterministic, for each case we run only once. We say that the fix eliminates all numerical defects if and only if (1) the RANUM static analysis framework cannot detect any defects from the fixed architecture; and (2) 1,000 random samples cannot trigger any numerical failures after imposing the fix.

**Evaluation Result.** We report the statistics, including the number of successful cases among all the 79 cases and the total running time, in Table III. From the table, we observe that on all the three imposing location settings, RANUM always succeeds in most cases and spends much less time. For example, when fixes can be imposed on both weights and input nodes, RANUM succeeds on _all_ cases with a total running time \(54.23\,\mathrm{s}\). In contrast, RANUM-E requires \(>10\times\) time, and GD succeeds in only \(72.15\%\) cases. Hence, RANUM is substantially more effective and efficient for suggesting fixes compared to baseline approaches.

Since RANUM is based on iterative refinement (see Algorithm 1), we study the number of iterations needed for finding the fix. When fixes can be imposed on both weight and input nodes, where RANUM succeeds on all the 79 cases, the average number of iterations is \(29.80\), the standard deviation is \(14.33\), the maximum is \(53\), and the minimum is \(2\). Hence, when RANUM can find the fix, the number of iterations is small, coinciding with the small total running time \(54.23\,\mathrm{s}\).

**Discussion.** The two baseline approaches can be viewed as ablated versions of RANUM. Comparing RANUM and GD, we conclude that the technique of abstraction optimization substantially improves the effectiveness and also improves the efficiency. Comparing RANUM and RANUM-E, we conclude that the interval abstraction with tensor partitioning as the abstraction domain substantially improves the efficiency and also improves the effectiveness.

From Table III, it is much easier to find the fix when imposing locations are weight nodes compared to input nodes. Since model providers can impose fixes on weights and users impose on inputs, this finding implies that fixing numerical defects on the providers' side may be more effective than on the users' side.

#### V-B2 **Comparison between RANUM and Developers' Fixes**

We conduct an empirical study to compare the fixes generated by RANUM and by the developers.

**Evaluation Protocol.** We manually locate GitHub repositories from which the GRIST benchmarks are constructed. Among the 79 cases, we find the repositories for 53 cases on GitHub and we study these cases. We locate the developers' fixes of the numerical defects by looking at issues and follow-up pull requests. Since RANUM suggests different fixes for different imposing locations, for each case we first determine the imposing locations from the developer's fix, and then compare with RANUM's fix for these locations.

RANUM fixes are on the computational graph and developers' fixes are in the source code, so we determine to conduct code-centered comparison: RANUM fixes are considered feasible only when the fixes can be easily implemented by code (within 10 lines of code) given that developers' fixes are typically small, usually in 3-5 lines of code. In particular, our comparison is based on two criteria: (1) which fix is sound on any valid input; (2) if both are sound, which fix hurts less to model performance and utility (based on the span of imposed precondition, the larger span the less hurt). Two authors independently classify the comparison results for each case and discuss the results to reach a consensus.

**Results.** We categorize the comparison results as below.

1. _(30 cases) Better than developers' fixes or no available developer's fix._ Developers either propose no fixes or use heuristic fixes, such as reducing the learning rate or using the mean value to reduce the variance. These fixes may work in practice but are unsound, i.e., cannot rigorously guarantee the elimination of the numerical defect for any training or inference data. In contrast, RANUM generates better fixes since these fixes rigorously eliminate the defect.
2. _(7 cases) Equivalent to developers' fixes._ Developers and RANUM suggest equivalent or highly similar fixes.
3. _(13 cases) No need to fix._ For these cases, there is no need to fix the numerical defect in the given architecture. There are mainly three reasons. (1) The DNN is used in the whole project with fixed weights or test inputs. As a result, although the architecture contains defects, no system failure can be caused. (2) The architecture is injected a defect as a test case for automatic tools, such as a test architecture in the TensorFlow2[27] repository. (3) The defect can be hardly exposed in practice. For example, the defect is in a Div operator where the divisor needs to be very close to zero to trigger a divide-by-zero failure, but such situation hardly happens in practice since the divisor is randomly initialized.
4. _(3 cases) Inferior than developers' fixes or RANUM-generated fixes are impractical._ In two cases, RANUM-generated fixes are inferior to developers' fixes. Human developers observe that the defective operator is Log, and its input is non-negative. So they propose to add \(10^{-6}\) to the input of Log as the fix. In contrast, RANUM can generate only a clipping-based fix, e.g., clipping the input if it is less than \(10^{-6}\). When the input is small, RANUM's fix interrupts the gradient flow from output to input while the human's fix maintains it. As a result, the human's fix does less hurt to the model's trainability and is better than
RANUM's fix. In another case, the RANUM-generated fix imposes a small span for some model weights (less than \(0.1\) for each component of that weight node). Such a small weight span strongly limits the model's expressiveness and utility. We leave it as the future work to solve these limitations.

From the comparison results, we can conclude that for the 40 cases where numerical defects are needed to be fixed (excluding case C), RANUM suggests equivalent or better fixes than human developers in 37 cases. Therefore, RANUM is comparably effective as human developers in terms of suggesting numerical-defect fixes, and is much more efficient since RANUM is an automatic approach.

**Guidelines for Users**. We discuss two practical questions for RANUM users. (1) _Does RANUM hurt model utility, e.g., inference accuracy?_ If no training or test data ever exposes a numerical defect, RANUM does not confirm a defect and hence no fix is generated and there is no hurt to the utility. If RANUM confirms numerical defects, whether the fix affects the utility depends on the precondition-imposing locations. If imposing locations can be freely selected, RANUM tends to impose the fix right before the vulnerable operator, and hence the fix does not reduce inference performance. The reason is that the fix changes (by clipping) the input only when the input falls in the invalid range of the vulnerable operator. In practice, if the imposing locations cannot be freely selected and need to follow developers' requirements, our preceding empirical study shows that, in only 3 out of 40 cases, compared with developers' fixes, our fixes incur larger hurt to the inference or training performance of the architecture. (2) _Should we always apply RANUM to fix any architecture?_ We can always apply RANUM to fix any architecture since RANUM fixes do not visibly alter the utility in most cases. Nonetheless, in deployment, we recommend first using RANUM to confirm defect feasibility. If there is no such failure-exhibiting system test, we may not need to fix the architecture; otherwise, we use RANUM to generate fixes.

## V Related Work

**Understanding and Detecting Defects in DNNs**. Discovering and mitigating defects and failures in DNN based systems is an important research topic [60, 32, 14]. Following the taxonomy in previous work [12], DNN defects are at four levels from bottom to top. (1) Platform-level defects. Defects can exist in real-world DL compilers and libraries. Approaches exist for understanding, detecting, and testing against these defects [49, 37, 42, 52]. (2) Architecture-level defects. _Our work focuses on numerical defects, being one type of architecture-level defects_. Automatic detection and localization approaches [50, 19] exist for other architecture-level defects such as suboptimal structure, activation function, and initialization and shape mismatch [11]. (3) Model-level defects. Once a model is trained, its defects can be viewed as violations of desired properties as discussed by Zhang et al. [55]. Some example defects are correctness [44, 9], robustness [48], and fairness [57] defects. (4) Interface-level defects. DNN-based systems, when deployed as services, expose interaction interfaces to users where defects may exist, as shown by empirical studies on real-world systems [12, 46, 47].

**Testing and Debugging for DNNs**. A rich body of work exists for testing and debugging DNN defects [55]. Some representatives are DeepXplore [31] and DeepGauge [22]. Recent work enables automatic model debugging and repair via consistency checking [51], log checking [59], spectrum analysis [34], or analyzer-guided synthesis [41].

**DNN Static Analysis**. Another solution for eliminating DNN defects is conducting static analysis to rigorously guarantee the non-existence of defects [17, 2]. Although DNNs essentially conduct numerical computations, traditional tools of numerical analysis [10, 39] are inefficient for DNN analysis due to lack of support for multi-dimensional tensor computations. Recently, static analysis tools customized for DNNs are emerging, mainly focusing on proposing tighter abstractions [6, 26, 29] or incorporating abstractions into training to improve robustness [16, 25, 62]. Besides robustness, static analysis has also been applied to rigorously bound model difference [30]. Our approach includes a static analysis framework customized for numerical-defect detection and fixing.

**Detecting and Exposing Numerical Defects in DNNs**. Despite the widespread existence of numerical defects in real-world DNN-based systems [60, 12, 14], only a few automatic approaches exist for detecting and exposing these defects. To the best of our knowledge, DEBAR [61] and GRIST [54] are the only two approaches. We discuss and compare RANUM with both approaches extensively in Sections III and IV.

## VI Conclusion

In this paper, we have presented a novel automatic approach named RANUM for reliability assurance of DNNs against numerical defects. RANUM supports detection of potential numerical defects, confirmation of potential-defect feasibility, and suggestion of defect fixes. RANUM includes multiple novel extensions and optimizations upon existing tools, and includes three novel techniques. Our extensive evaluation on real-world DNN architectures has demonstrated high effectiveness and efficiency of RANUM compared to both the state-of-the-art approaches and developers' fixes.

**Data Availability**. All artifacts including the tool source code and experiment logs are available and actively maintained at [https://github.com/llyly/RANUM](https://github.com/llyly/RANUM).

## Acknowledgements

This work is sponsored by the National Natural Science Foundation of China under Grant No. 62161146003, the National Key Research and Development Program of China under Grant No. 2019YFE0198100, the Innovation and Technology Commission of HKSAR under Grant No. MHP/055/19, and the Tencent Foundation/XPLORER PRIZE.