---
title: 'QuantifyML: Counting-Based ML Evaluation'
url: https://www.emergentmind.com/topics/quantifyml
type: topic
---

# QuantifyML: Counting-Based ML Evaluation

Searching arXiv for the specified paper and closely related work to ground the article.
arxiv_search(query="2110.12588 QuantifyML How Good is my Machine Learning Model", max_results=5)
QuantifyML is a framework for evaluating trained machine learning models by translating them into a C program, feeding that program to the CBMC model checker to obtain a formula in conjunctive normal form, and then using projected model counting to compute precise counts of model behavior over a bounded input domain [2110.12588]. Its central claim is that test-set accuracy is often an imperfect proxy for what a model has learned, especially when the test data are not representative, when different architectures fail in different regions of the input space, or when safety and adversarial behavior arise in sparsely sampled regions [2110.12588]. QuantifyML therefore replaces sampling-based evaluation with counting over a bounded, precisely defined input space, and uses these counts to quantify learnability, safety, and robustness [2110.12588].

## 1. Conceptual basis

QuantifyML starts from the observation that the efficacy of machine learning models is typically determined by computing their accuracy on test data sets, but that this may be misleading because the test data may not be representative of the problem being studied [2110.12588]. The framework addresses three recurrent issues: a held-out test set may not cover the full problem space, different models may appear comparable even though their errors are concentrated in different regions, and safety or adversarial failures may occur in rare but important parts of the domain [2110.12588].

The framework evaluates a model relative to a bounded input scope and a formal specification. For learnability, the specification is a ground-truth predicate over the input domain. For safety, it is a property of the form \(Pre \Rightarrow Post\). For local robustness, it is a neighborhood specification around a concrete input, typically defined by constraining each dimension to \([x_j-\epsilon, x_j+\epsilon]\) [2110.12588]. The resulting counts are used to compute quantities analogous to accuracy, precision, recall, F1-score, safety satisfaction, safety violation, and robustness fractions [2110.12588].

This design places QuantifyML in the model-checking tradition rather than in statistical evaluation. The framework quantifies behavior over all inputs in the chosen bounded domain, rather than estimating behavior from a sample [2110.12588].

## 2. Translation and counting pipeline

QuantifyML operates through a fixed toolchain: model translation, bounded verification, CNF generation, and projected model counting [2110.12588].

| Stage | Artifact | Role |
|---|---|---|
| Model translation | C program | Encodes a trained decision tree or neural network |
| CBMC encoding | CNF formula | Captures bounded executions and logical predicates |
| Projected counting | Input-space counts | Counts satisfying assignments projected to primary input variables |

The inputs to the framework are a trained model, a logical specification, and an input-domain bound [2110.12588]. The trained model is translated into C. For decision trees, the C control flow mirrors the tree’s branching. For neural networks, the translation encodes the standard layer-by-layer computation [2110.12588].

The C program and the relevant predicates are then passed to CBMC. CBMC constructs a control-flow graph, encodes bounded executions as bit-vector constraints, and flattens them to CNF [2110.12588]. Because this encoding introduces auxiliary variables, QuantifyML uses projected model counting, treating input variables as primary variables and CBMC-introduced variables as auxiliary variables [2110.12588].

The framework uses projMC for exact projected model counting and ApproxMC for scalable approximate counting [2110.12588]. The output is a set of counts for conjunctions and disjunctions of model predicates and specification predicates, from which evaluation metrics are derived [2110.12588].

## 3. Formalization of learnability

For multi-class classification with labels \(l \in \{1,\dots,L\}\), QuantifyML introduces, for each label \(l\), two predicates: one that returns \(1\) if the model predicts label \(l\), and one that returns \(1\) if the ground truth for the input is \(l\) [2110.12588]. True positives, false positives, true negatives, and false negatives are then expressed as projected model counts over conjunctions of these predicates [2110.12588].

From these counts, QuantifyML computes accuracy, precision, recall, and F1-score [2110.12588]. The key methodological point is that these are not sample estimates; they are derived from counts over the entire bounded input domain [2110.12588].

The neural-network encoding is explicit at the level of neuron computation. The paper describes each neuron as applying an activation function to a weighted sum of its inputs,
\[
N(X) = o\!\left(\sum_i w_i \cdot N_i(X) + b\right),
\]
where \(N_i\) denotes the value of the \(i\)-th neuron in the previous layer, \(w_i\) are weights, \(b\) is a bias term, and \(o\) is the activation function [2110.12588]. The final decision layer is represented with max or softmax logic in C [2110.12588].

For decision trees, each root-to-leaf path becomes a conjunction of predicates on attributes, again encoded directly in C [2110.12588]. The framework supports non-binary inputs and multi-class outputs [2110.12588].

## 4. Safety and local robustness

QuantifyML extends beyond learnability to safety properties and local robustness [2110.12588]. A safety property is written as \(Pre \Rightarrow Post\), where \(Pre\) constrains inputs and \(Post\) constrains model outputs [2110.12588]. The framework defines two quantities: the portion of the input region for which the model satisfies the property, denoted QuantifyMLS, and the portion for which the model violates the property, denoted QuantifyMLN [2110.12588].

Local robustness is handled by fixing a region \(R_\epsilon\) around a specific input. In the paper’s formulation, \(R_\epsilon\) is defined by altering each component within a bounded interval, such as \([x_j-\epsilon, x_j+\epsilon]\) [2110.12588]. Robustness is then the fraction of points in that region for which the model preserves the label of interest [2110.12588].

This distinction between existence and fraction is important. Traditional verification often asks whether a counterexample exists. QuantifyML instead asks how much of the region satisfies or violates the relevant condition [2110.12588]. For adversarial analysis, that yields a graded robustness measure rather than a Boolean certificate.

## 5. Empirical studies

The framework was evaluated on relational graph properties, MNIST local robustness, and ACAS Xu safety properties [2110.12588].

In the relational setting, QuantifyML was applied to \(11\) graph properties over adjacency matrices with a scope of \(4\) nodes, comparing decision trees and small neural networks trained on the same data [2110.12588]. Several properties that appeared nearly perfect under statistical evaluation were substantially weaker under counting-based evaluation. For example, for the decision-tree model on **PreOrder**, statistical precision was \(1.0000\), but QuantifyML precision was \(0.1499\); statistical F1-score was \(1.0000\), but QuantifyML F1-score was \(0.2607\) [2110.12588]. For **Connex**, the decision tree’s statistical accuracy was \(0.9932\), whereas QuantifyML accuracy was \(0.8179\); statistical recall was \(1.0000\), whereas QuantifyML recall was \(0.0625\) [2110.12588]. These examples show that a model can look nearly perfect on sampled data while performing poorly over the full bounded domain [2110.12588].

For neural networks on the same graph tasks, QuantifyML often revealed weaker generalization than statistical metrics suggested. On **Antisymmetric**, statistical accuracy was \(0.8058\), while QuantifyML accuracy was \(0.7614\); statistical precision was \(0.7520\), while QuantifyML precision was \(0.4211\) [2110.12588]. The paper reports that decision trees generalized better than neural networks across these relational tasks under QuantifyML metrics, even when statistical metrics were similar [2110.12588].

On MNIST, the framework quantified local robustness for a decision tree with \(83.64\%\) test accuracy [2110.12588]. For labels \(5\), \(7\), and \(8\), the robustness fraction was reported as \(99.99\), while random sampling over \(100\), \(1000\), and \(10000\) perturbations misleadingly returned \(100\%\) [2110.12588]. By contrast, labels \(1\), \(2\), and \(9\) showed low robustness, with reported values \(32.81\), \(25.00\), and \(37.50\), respectively [2110.12588]. This demonstrates that the framework can expose adversarial fragility hidden by sample-based estimates.

On ACAS Xu, QuantifyML analyzed \(9\) published safety properties for a small \(4\)-layer neural network trained to \(96.0\%\) test accuracy [2110.12588]. The framework could compute counts even for properties whose precondition regions were absent from the test set. The paper reports that for properties \(2\), \(3\), and \(4\), no test inputs fell into the precondition region, yet QuantifyML still returned counts, and that “the neural network never satisfies property 4” [2110.12588].

## 6. Position, limitations, and research context

QuantifyML generalizes the “Model Counting meets Machine Learning” idea from binary decision trees to multi-class decision trees and neural networks, and extends the scope from learnability to safety and robustness [2110.12588]. Its distinguishing feature is that it turns model evaluation into a projected model-counting problem over a finite domain [2110.12588].

The framework’s main limitation is scalability. CNFs generated by CBMC can become large, especially for neural networks and high-dimensional inputs, and exact counting is computationally hard [2110.12588]. In the ACAS Xu study, ApproxMC used a \(5000\)-second timeout, and the paper reports timeouts for some analyses [2110.12588]. For MNIST, partial evaluation and changing the representation of weights and biases from floats to longs reduced formula size, and making \(10\%\) of the pixels concrete led to a \(51.37\%\) decrease in the number of variables and a \(53.08\%\) decrease in the number of clauses, but the resulting formulas still remained challenging for model counters [2110.12588].

A further limitation is semantic rather than computational: the counts are always relative to a user-specified bounded domain [2110.12588]. This makes QuantifyML precise within scope, but any conclusions depend on whether the chosen scope is representative of the problem of interest [2110.12588].

The term *quantification* also has a distinct meaning elsewhere in machine learning. In the prevalence-estimation literature, quantification denotes estimating test-data class proportions under shifts such as prior-probability shift [1606.00868], and this line has been extended to multi-label quantification [2211.08063] and end-to-end bag-level prevalence estimation with Gaussian latent representations [2501.13638]. This suggests that QuantifyML is not a quantification method in that prevalence-estimation sense, but rather a counting-based framework for assessing trained models against formal specifications over bounded domains [2110.12588].

Source: https://www.emergentmind.com/topics/quantifyml