Title: ConStat: Performance-Based Contamination Detection in Large Language Models
Venue: NeurIPS 2024
Accepted: yes
Keywords: large language models

model evaluation

contamination detection
Abstract: Public benchmarks play an essential role in the evaluation of large language models.  However, data contamination can lead to inflated performance, rendering them unreliable for model comparison. It is therefore crucial to detect contamination and estimate its impact on measured performance. Unfortunately, existing detection methods can be easily evaded and fail to quantify contamination. To overcome these limitations, we propose a novel definition of *contamination as artificially inflated and non-generalizing benchmark performance* instead of the inclusion of benchmark samples in the training data. This perspective enables us to detect *any* model with inflated performance, i.e., performance that does not generalize to rephrased samples, synthetic samples from the same distribution, or different benchmarks for the same task. Based on this insight, we develop ConStat, a statistical method that reliably detects and quantifies contamination by comparing performance between a primary and reference benchmark relative to a set of reference models. We demonstrate the effectiveness of ConStat in an extensive evaluation of diverse model architectures, benchmarks, and contamination scenarios and find high levels of contamination in multiple popular models including Mistral, Llama, Yi, and the top-3 Open LLM Leaderboard models.

ConStat: Performance-Based Contamination Detection in Large Language Models

Abstract

Public benchmarks play an essential role in the evaluation of large language models. However, data contamination can lead to inflated performance, rendering them unreliable for model comparison. It is therefore crucial to detect contamination and estimate its impact on measured performance. Unfortunately, existing detection methods can be easily evaded and fail to quantify contamination. To overcome these limitations, we propose a novel definition of contamination as artificially inflated and non-generalizing benchmark performance instead of the inclusion of benchmark samples in the training data. This perspective enables us to detect any model with inflated performance, i.e., performance that does not generalize to rephrased samples, synthetic samples from the same distribution, or different benchmarks for the same task. Based on this insight, we develop CONSTAT, a statistical method that reliably detects and quantifies contamination by comparing performance between a primary and reference benchmark relative to a set of reference models. We demonstrate the effectiveness of CONSTAT in an extensive evaluation of diverse model architectures, benchmarks, and contamination scenarios and find high levels of contamination in multiple popular models including MISTRAL, LLAMA, YI, and the top-3 Open LLM Leaderboard models. 1

1 Introduction

As large language models (LLMs) become increasingly effective at a wide range of tasks, many companies and research institutions compete to develop better models [2, 5, 28, 36]. To facilitate this development, a variety of benchmarks have been proposed that allow a standardized in-depth comparison of model performance across diverse tasks [15, 16, 26, 33].

Data Contamination Modern LLMs are trained on vast amounts of internet-sourced data, raising the risk of unintentionally including benchmark samples in the training set. Such data contamination can lead to artificially inflated benchmark performance that does not accurately reflect a model's true ability to generalize to unseen tasks. However, model providers argue that the impact of this contamination on model performance is negligible [2, 14, 36] and the enormous size of current training sets almost guarantees contamination to some extent. This casts doubt on the relevance of this traditional definition of contamination in the context of LLMs.

This Work: A New Perspective on Data Contamination We propose a new perspective on contamination, defining it based on its effect on model performance rather than its cause. Specifically, we define contamination as artificially inflated, non-generalizing performance , i.e., we say a model is contaminated if and only if its performance relative to other models is significantly higher on the original benchmark than on a similar reference benchmark. This definition captures the essence of the contamination problem, i.e., performance measurements becoming unreliable for model comparisons.

LogicStar.ai 2

̸

M

1

M

2

Benchmark

D

72.1%

72.1%

Which model

is contaminated?

2. Select References

Reference Models

M

ref

,

1

M

ref

,

2

M

ref

,

3

Rephrased

D

ref

≈

D

Synthetic

D

ref

∼

D

Similar

D

ref

=

D

3. Compute Test

25%

40%

55%

70%

85%

20%

35%

50%

65%

80%

δ

1

M

1

δ

2

M

2

HD

ref

M

ref

,i

4. Extract Results

δ

1

= 35

.

1

±

3

.

1

p

= 0

.

01%

δ

2

= 4

.

1

±

5

.

1

p

= 30%

Reference Performance

Furthermore, it enables principled detection methods that are robust against evasion attacks by malicious providers as this would require generalizing performance improvements.

Traditional Contamination Detection Existing contamination detection methods [18, 23, 24, 31, 34, 37, 40, 41, 49] aim to detect the inclusion of benchmark samples in the training data as a measure of contamination. However, these approaches show limited success, cannot quantify the contamination's effect on model performance, and have to make strict assumptions about the contamination process, making them easy to evade [17].

This Work: A Statistical Test for Contamination In contrast, we leverage our novel performancebased definition of data contamination to propose a statistical contamination test called CONSTAT, illustrated in Fig. 1. Given a target model ( M 1 or M 2 ) to check for contamination (first step in Fig. 1), we select a set of reference models for performance comparison and a reference benchmark D ref that is similar to the original benchmark D (second step). This reference benchmark can be a rephrased version of the original benchmark, a synthetic benchmark generated from the same distribution, or a different benchmark measuring performance on the same task. We then evaluate the reference models on both benchmarks D and D ref and fit the difficulty correction function H D ref describing the relation between performance on the reference and original benchmarks (blue curve). By evaluating H D ref at the target model's performance on the reference benchmark, we predict its expected performance on the original benchmark (third step). Finally, we compute the difference δ between this expected performance and the model's actual performance on the original benchmark. Using bootstrapping, we obtain an estimate of the contamination magnitude δ and a p-value that quantifies the likelihood of the observed performance difference under the null hypothesis that the target model is not contaminated (fourth step). In the illustrated case, model M 1 achieves 60% on the reference benchmark, which translates to an expected performance of 37% on the original benchmark. However, the measured performance of 72% indicates a large contamination effect δ 1 = 35% and thus strong contamination with a p-value of 0 . 01% . In contrast, model M 2 shows no signs of contamination.

Evaluation We evaluate CONSTAT on a wide range of contamination scenarios and model architectures, demonstrating that it is significantly more effective at detecting contamination than any prior method. We then use CONSTAT to study a range of popular open and proprietary models and find high levels of contamination in MISTRAL-7b-v0.1 [28], LLAMA-3-70b [2], LLAMA-2-INSTRUCT-70b [43], YI-34b [53], and a range of top Open LLM Leaderboard [7] models.

Key Contributions Our key contributions are:

We propose a new performance-based definition of benchmark contamination (§2).

We introduce CONSTAT, a statistical test that detects and quantifies contamination in language models (§3).

We empirically demonstrate CONSTAT's effectiveness in an extensive evaluation across various contamination scenarios (§4.2).

We leverage CONSTAT to study a range of popular models and find contamination for MISTRAL, LLAMA, YI, and the top-3 Open LLM Leaderboard models (§4.3-§4.5).

2 Defining Contamination

Before formalizing our novel definition, we first informally contrast the traditional, information-flowbased perspective on contamination with our novel performance-based one.

Information-Flow Perspective In traditional machine learning, contamination typically refers to any information flow between the benchmark used for performance measurement and model training. In the context of LLMs, this is usually restricted to the direct inclusion of test set samples (or their semantic equivalents) in the training dataset [37, 39, 51, 56].

However, this perspective suffers from several drawbacks. First, it does not fully capture the core issue of contamination, which is whether it renders test set performance an unreliable predictor of real-world performance. Second, in the era of zero-shot learning, we aim to measure performance on "unseen" tasks, yet we train on internet-scale data that likely contains samples of almost any task. This makes the threshold for contamination blurry. Third, limiting the definition to test sample inclusion neglects the possibility of model and hyperparameter selection based on benchmark performance as a source of contamination. Finally, even with this narrow definition, detecting contamination without access to the training data is challenging, which makes it easy to circumvent [17].

Performance Perspective To overcome these limitations, we propose to define contamination based on its outcome, rather than its cause . Informally, we define contamination as artificially inflated performance on a benchmark that does not generalize to real-world performance on the corresponding task, regardless of how it was achieved. This definition aligns better with the practical implications of contamination and enables a more principled detection method that makes evasion difficult.

To detect contamination, we compare the performance of a model M on a benchmark D to its performance on a reference benchmark D ref, the choice of which we will discuss later. It is crucial to account for differences in difficulty between D and D ref. Otherwise, a slightly harder reference benchmark D ref would falsely indicate inflated performance on D . Thus, direct performance comparison is only valid if the distribution over sample difficulties is the same for both benchmarks, which is a very strong assumption that is rarely true. To address this, we compare performances relative to a set of reference models, allowing us to determine if a model's performance on D is significantly higher than expected, given its difficulty. In the next section, we make this definition more formal.

2.1 Formal Definition of Performance-Based Contamination

Reference Models To accurately compare performance between benchmarks, we use reference models to correct for benchmark difficulty differences. For this purpose, we consider the set of all reliable LLMs M ref from reputable sources to estimate the performance distribution of uncontaminated models. Although we cannot guarantee these models are uncontaminated, we can perform leave-one-out contamination detection to remove suspicious models from the reference set. Furthermore, including contaminated models in M ref will only make our test more conservative, making it less likely for uncontaminated models to be detected as contaminated.

Contamination Detection For each benchmark D , we define a scoring function S D : M→ R that assigns a score (e.g., accuracy) to every model from the space of all possible language models M . Applied to the reference models M ref, it induces a cumulative distribution function F D over the uncontaminated performance on this benchmark.

We now use the cumulative distributions F D and F D ref to predict the performance of a model M on D given its performance on D ref. Specifically, we first map the performance on the reference data S D ref ( M ) to a percentile q = F D ref ( S D ref ( M )) and then map this percentile to the corresponding performance on the original benchmark F -1 D ( q ) using the percentile function F -1 D . To simplify notation, we define the hardness correction function H D ref : R → R as H D ref = F -1 D ◦ F D ref . This allows us to estimate the effect of contamination on the model's performance as S D ( M ) -H D ref ( S D ref ( M )) and gives our formal definition of contamination:

Definition 1 ( δ -Contamination) . A model M ∈ M is δ -contaminated on a benchmark D with respect to a reference benchmark D ref if S D ( M ) -H D ref ( S D ref ( M )) > δ .

2.2 Types of Contamination

Depending on the choice of reference benchmark D ref, we can measure different types of contamination, depending on how poorly the inflated performance generalizes.

Syntax-Specific Contamination occurs when the model fails to generalize to semantically equivalent samples. That is, the model has memorized the exact samples in the benchmark, and its performance drops as soon as the wording changes. We therefore consider it to be the worst kind of contamination. To measure syntax-specific contamination we create our reference benchmark D ref by rephrasing the samples in the original benchmark D to obtain a semantically equivalent benchmark.

Sample-Specific Contamination occurs when the model fails to generalize to new samples from the benchmark distribution. That is, while the model generalizes to samples that are semantically equivalent to those in the original benchmark, it does not generalize to new samples from the same distribution. To accurately measure sample-specific contamination, we would preferably generate samples for D ref following the same steps used to produce D . As this is often infeasible in practice, we instead generate synthetic samples for D ref by querying a strong LLM using few-shot prompting and varying the provided few-shot examples to increase diversity.

Benchmark-Specific Contamination occurs when the model fails to generalize to different benchmarks that aim to measure performance on the same task. That is, the model generalizes to new samples from the original benchmark distribution but does not generalize to closely related benchmarks. To measure benchmark-specific contamination we create (or select) a different benchmark D ref (e.g., MathQA) that aims to measure performance on the same task as D (e.g., GSM8k). We note that benchmark-specific contamination is by far the least severe type of contamination. Further, while strong sensitivity to the exact benchmark is undesirable, it is important to recognize that even small differences between benchmarks can impact model performance. Therefore, benchmark-specific contamination requires a more nuanced interpretation that takes into account these differences.

3 CONSTAT: A Statistical Test for Detecting Contamination

We now present CONSTAT, a novel method for detecting contamination as defined in §2 by computing confidence bounds on the estimated contamination effect using a statistical test.

Reference Models To approximate the underlying distribution of reference models M ref, we select a diverse sample of m models ˜ M ref = { M ref , 1 , ..., M ref ,m } ⊂ M ref . We additionally include an inherently uncontaminated random-guessing model to extend the coverage of our reference set.

Null Hypothesis To rigorously test for contamination, we derive a null hypothesis based on our definition of contamination. The null hypothesis is the assumption that the model M is not contaminated, meaning its actual score on the original data is at most δ worse than the predicted one: S D ( M ) -H D ref ( S D ref ( M )) ⩽ δ where δ ∈ R ≥ 0 can be chosen freely.

Estimating the Hardness Correction Function To compute the hardness correction function H D ref , we first estimate the CDFs F D and F D ref as the empirical CDFs ˜ F D and ˜ F D ref , respectively. To this end, let i 1 , ..., i n be an index such that S D ( M ref ,i k ) ⩽ S D ( M ref ,i k +1 ) . We obtain the CDF ˜ F D as

Similarly, ˜ F D ref can be obtained from an index j 1 , ..., j n such that S D ref ( M ref ,j k ) ⩽ S D ref ( M ref ,j k +1 ) . Using Eq. (1), we find that H D ref ( S D ref ( M j k )) = S D ( M i k ) . Applying the empirical CDFs directly to other points x ∈ [0 , 1] would result in a step function estimate of H D ref , leading to an overly rough approximation of the hardness correction function. Thus, we compute the approximate hardness function ˜ H D ref by fitting the points ( S D ref ( M j k ) , S D ( M i k )) using a smoothing spline, minimizing the following loss function:

where λ is a smoothing parameter that is chosen using generalized cross-validation [46].

Significance Estimation We determine the statistical significance for rejecting the null hypothesis via bootstrapping over both the reference models and the samples in the benchmark, using pivotal intervals [42] to correct for uncertainty in the bootstrapping process. By bootstrapping the models, we consider the effect of our reference model selection ˜ M ref . By bootstrapping the samples, we additionally include the error in our estimation of the scores themselves. Thus, given the estimate ˆ δ = S D ( M ) -ˆ H D ref ( S D ref ( M )) and corresponding bootstrap estimates ˆ δ 1 , ..., ˆ δ n , we compute the p-confidence lower bound for δ as ˆ δ 1 -p = 2 ˆ δ -ˆ δ ′ 1 -p where ˆ δ ′ q is the q -quantile of ˆ δ 1 , ..., ˆ δ n . From this, we obtain the p-value by inverting this lower bound with respect to q . Thus, we reject the null hypothesis for a given δ with significance level p by computing the lowest p such that 2 ˆ δ -ˆ δ ′ 1 -p ⩾ δ .

Threat Model In accordance with [17], we briefly outline the threat model assumed by CONSTAT. Since we only require the ability to measure the performance of the model on the benchmark, our method is a black-box benchmark-level detection method that is robust to semantic preserving operations. Furthermore, we make no additional assumptions on potential metadata contamination. However, we do rely on the existence of reference models which we can use to estimate the performance of uncontaminated models. Notably, however, we do not assume these reference models to have a similar performance or architecture as the model we wish to test.

4 Evaluation

In this section, we evaluate CONSTAT empirically. We first demonstrate CONSTAT's effectiveness, showing it outperforms prior methods in detecting and quantifying contamination across a range of intentionally contaminated models (§4.2). Next, we investigate the contamination of our chosen reference models (§4.3), popular model families (§4.4), and top Open LLM Leaderboard models (§4.5). Further, we conduct an ablation study in a simulated environment in App. B to validate several design choices of CONSTAT.

4.1 Experimental Setup

Reference Models We select 20 models from reputable providers, including Meta's LLAMA model families [2, 43], Microsoft's PHI-2 [27] and PHI-3 [1], Google's GEMMA-1.1 [21], several MISTRAL models [28], FALCON-7b [3], and the fully open-source OLMO [25]. A detailed overview of these reference models is available in App. C.

Benchmarks We select a diverse set of four of the most popular LLM benchmarks to evaluate CONSTAT: GSM8k [16] is a benchmark for mathematical reasoning, ARC-Challenge [15] is a multiple-choice benchmark for science questions, MMLU [26] is a multiple-choice general purpose benchmark and Hellaswag [54] is a dataset for commonsense natural language inference. Due to computational constraints, we limit the number of samples in each benchmark to 2000 .

Reference Benchmarks To generate reference data for syntax-specific and sample-specific contamination we query GPT-4-TURBO [36] to rephrase samples from the original benchmark and generate new synthetic samples. We generate around 1000 synthetic samples per benchmark and refer to App. C for further details on the generation process. To detect benchmark-specific contamination, we select appropriate reference benchmarks that measure performance on the same task: for GSM8k, we use MathQA [4], for ARC-Challenge we use SCIQ [47], and for Hellaswag we use the LambadaOpenAI benchmark [38]. For MMLU, we did not select any reference benchmark and thus measured only syntax- and sample-specific contamination.

Evaluation For evaluation, we use the LM Evaluation Harness [20] in a 5 -shot setting. We report estimated effects ˆ δ along with the p-value for the null hypothesis that the effect δ is less than 0 .

4.2 Validating Contamination Detection with CONSTAT in a Controlled Setting

In this section, we demonstrate the effectiveness of CONSTAT in detecting and quantifying contamination in a controlled setting and compare it to multiple baselines. For this purpose, we finetune both LLAMA-2-INSTRUCT-7b and PHI-2 using a variety of hyperparameters and contamination scenarios on each benchmark separately. We vary the number of epochs, the learning rate, the portion of contaminated training samples, whether or not few-shot examples are used during fine-tuning, and whether the model is trained on the original benchmark samples or on rephrased data. For more details, we refer to App. C. We trained a total of 70 models, 9 of which finished training at a loss spike and were therefore excluded from further analysis. 46 of the remaining models were trained on the actual benchmark and should therefore exhibit both syntax- and sample-specific contamination. The rest were trained on rephrased benchmark data and should therefore only exhibit sample-specific contamination. To quantify the true sample-specific contamination effect, we only use half of each benchmark for contamination and measure the performance gap to the other half.

Detecting Contamination We first check whether CONSTAT can accurately detect the presence of contamination. We compare CONSTAT against several baselines [12, 35, 40, 41, 52] that aim to detect contamination based on the presence of benchmark samples in the training data. Most of these baselines [12, 35, 41, 52] require a detection threshold to be chosen for each model and benchmark separately. This tuning process requires uncontaminated samples, making it impossible to apply these methods in practice. For comparison to CONSTAT, we tuned these thresholds on the uncontaminated half of the benchmark, which is the most ideal (but unrealistic) scenario. We extract a p-value for these baselines by bootstrapping the samples in the benchmarks and checking how often TPR@ 1% FPR is bigger than 1% . Models are considered contaminated for any method if p < 0 . 05 . The only baseline applicable in a realistic setting is Shi [40] and we use their recommendation to consider a model contaminated if the score returned by their method is above 0 . 85 .

Results in Table 1 show that CONSTAT significantly outperforms all other methods without needing prior knowledge of uncontaminated samples. In particular, we find that CONSTAT can detect 89% of syntax-specifically contaminated models, while the best baseline achieves only 85% . The gap widens further for samplespecific contamination, where CONSTAT detects 98% of contaminated models, while the best baseline only detects 71% . The only baseline that can be applied in a realistic setting, Shi [40], performs significantly worse than CONSTAT.

* indicates that the method needs unrealistic access to uncontaminated samples for hyperparameter selection.

We thus conclude that CONSTAT is the only contamination detection method that can reliably detect contamination and significantly outperforms all baselines even if they are tuned optimally using oracle access to the uncontaminated samples.

Quantifying Contamination To evaluate CONSTAT's ability to estimate the samplespecific contamination effect, we compare its estimate to ground truth measurements on uncontaminated samples. As shown in Fig. 2, we observe excellent predictiveness at a coefficient of determination of r 2 = 0 . 94 . The only three models that show a significantly higher estimate than the true effect achieve a perfect score on the contaminated samples, capping the true effect and explaining the overestimation.

0%

25%

50%

75%

Actual

δ

0%

25%

50%

75%

Estimated ˆ

δ

Identity

Detailed Analysis on GSM8k We conduct an in-depth analysis of contaminated models finetuned on GSM8k, referring to App. A.2 for a detailed table with all p-values. We finetuned 18 models on this benchmark, one of which remained undetected under sample-specific contamination detection.

For the detected syntax-specifically contaminated models, we observe an average increase in ˆ δ with a factor of 2 . 28 when transitioning from syntax-specific to sample-specific contamination. This indicates that the models still generalize somewhat to semantically equivalent samples. Furthermore, the models that were not detected by the syntax-specific contamination detection are exactly those models that were trained on rephrased data or were trained for just one epoch. This indicates that these models can still generalize to semantically equivalent samples. Since these scenarios are also more likely to occur in practice, this shows that it is crucial to also consider sample-specific contamination when applying CONSTAT. Finally, the model that remained undetected by the sample-specific contamination detection was a PHI-2 model trained with a lower learning rate. For this model, the actual contamination effect is approximately 5% , which is relatively small and thus indicates that CONSTAT is not missing any major contamination.

4.3 Contamination of Reputable Reference Models

To determine if our set of reference models exhibit signs of contamination, we perform a leave-one-out analysis, where we evaluate the contamination of model M using ˜ M ref \ { M } as reference models. To control for performing multiple p-value tests and reduce the chance of false positives, we apply the Benjamini-Hochberg [9] procedure per benchmark and contamination type to control the false discovery rate at 5% . We report all significant results in Table 2 and we discuss them for each type of contamination below.

Syntax-Specific Contamination As expected, we do not find syntax-specific contamination in any reference model, i.e., none of the models fail to generalize to semantically equivalent samples.

Sample-Specific Contamination We find four instances of sample-specific contamination, all with very significant p-values of less than p = 0 . 5% and considerable estimated contamination effects between 3% and 8% . Specifically, we find contamination of LLAMA-3-70b on ARC, of MISTRAL-7b-v0.1 and LLAMA-2-INSTRUCT-70b on Hellaswag, and MISTRAL-7b-v0.1 on GSM8k. We note that the contamination of LLAMA-2-INSTRUCT-70b on Hellaswag is noted by its model provider [43], but the other model providers do not provide any contamination report for their models.

We investigate these models further on the other benchmarks where the corrected p-value using the Benjamini-Hochberg procedure was not significant. We discuss these results below and refer to App. A for a full overview of their sample-specific contamination. We find that MISTRAL-7b-v0.1 achieves relatively low p-values on both remaining benchmarks ( 8% for ARC, 15% for MMLU). Furthermore, we additionally evaluated MISTRAL-7b-v0.2 after obtaining these results and found similar results for this model (see Table 17 in App. E). Therefore, we exclude MISTRAL-7b-v0.1 from our set of reference models. While in particular LLAMA-3-70b also exhibits low p-values for other benchmarks, none fall below p ⩽ 1% . It is thus highly likely that also LLAMA-3-70b and LLAMA-2-INSTRUCT-70b are contaminated across several benchmarks, but we keep both as reference models to ensure that we do not obtain a higher false positive rate in our further analysis.

Benchmark-Specific Contamination While we find several instances of benchmark-specific contamination in the reference models, several at very low p-values ( p < 0 . 01% ), this requires a more nuanced interpretation. For example, both PHI models exhibit very large effect sizes ( > 15% ) and small p-values ( p < 0 . 01% ) for contamination on GSM8k. We suspect that this is due to their reasoning-focused training process and small model size. While GSM8k allows free text answers, giving the model tokens to reason, MathQA is a multiple-choice benchmark that requires the model to answer with a single token indicating the chosen option and therefore gives no room for this reasoning ability to shine.

4.4 Contamination of Popular Model Families

We now use CONSTAT to detect contamination in four popular model families, discussing results for QWEN-1.5 [6] and YI [53] below, while deferring discussions of STABLELM-2 [8] and INTERNLM2 [11] to App. A.1.

QWEN-1.5 We evaluate all chat models from the QWEN-1.5 model family, with sizes 1.8b, 4b, 7b, 14b, 72b, and 110b. The only case of sample-specific contamination is for the 4b model on GSM8k with p < 10 -4 and an estimated effect of 5 . 4% . The larger models show significant benchmarkspecific contamination on ARC and Hellaswag, with p-values smaller than 1% and estimated effects between 8% and 14% .

YI We evaluate both the 6b and 34b parameter base models of the YI model-family. Only YI-34b shows significant contamination, with sample-specific contamination at p < 0 . 2% and estimated effects of around 6% on both ARC and Hellaswag. We find additional sample-specific contamination on GSM8k of around 4% at a p-value of p = 6% and syntax-specific contamination on Hellaswag at a p-value of p = 5% . Thus, we conclude that this model shows significant contamination across multiple benchmarks.

4.5 Contamination of Top Open LLM Leaderboard Models

We use CONSTAT to investigate contamination in the top three 7B models on the open LLM Leaderboard 2 , BARRAHOME/MISTROLL-7b-v2.2, YAM-PELEG/EXPERIMENT26-7b, and MTSAIR/-MULTI_VERSE_MODEL and find that all three models exhibit significant benchmark-specific contamination. Specifically, all models show strong contamination with estimated effects of ˆ δ > 10 % for the benchmarks where the reference benchmark is not included in the Open LLM Leaderboard (GSM8k, Hellaswag, and ARC). Further, all models show significant sample-specific contamination on GSM8k with ˆ δ ≈ 9 %. For more detailed results, we refer to App. A.

This inflated performance could be caused by a model selection bias, as the Open LLM Leaderboard features thousands of models. This issue is exacerbated by the recent trend of merging models [22, 50] where hyperparameters are frequently selected based on their benchmark performance. We therefore urge the community to be more cautious when selecting models from the leaderboard.

5 Related Work

Contamination Detection Contamination detection methods can be broadly divided into two main categories. The first category [10, 14, 19, 29, 36, 43, 45, 51] focuses on analyzing the training data directly to identify overlaps with the benchmarks used for model evaluation. However, training data is rarely shared, even for open-weight models, making it irrelevant for third-party contamination detection. The second category [18, 23, 24, 31, 34, 37, 40, 41, 49] relies solely on access to the model and its predictions, aiming to detect contamination through model queries. As noted by Dekoninck et al. [17], some of these methods require metadata (e.g., benchmark name, canonical ordering) to be leaked along with the benchmark samples in the training data [23, 24, 37]. Methods that do not require metadata depend on perplexity-based metrics to measure the model's uncertainty on benchmark samples, but these can be easily circumvented by training on rephrased samples [17]. It is important to note that none of these methods can estimate the influence of contamination and that they are outperformed by CONSTAT in terms of detection accuracy (see §4.2).

An alternative approach is presented by Zhu et al. [57], who measure model performance on rephrased benchmarks instead of the original benchmarks to obtain more accurate estimates of model performance. However, their results vary significantly across benchmarks, they do not provide a statistical framework for contamination detection, and they only demonstrate that evaluating on rephrased samples partially recovers the results of uncontaminated base models. Furthermore, they do not go beyond measuring performance on rephrased benchmarks and can therefore also be evaded by training on rephrased samples [17].

Reference Benchmarks Recent studies have introduced new benchmarks designed to evaluate performance on tasks similar to those in prior popular benchmarks and thus can be used to estimate the degree of contamination. GSM1k [55] was developed to closely replicate the efforts behind GSM8k and to compare model performances between these benchmarks. However, GSM1k lacks a statistical test, and the slight variations between GSM8k and GSM1k might partially explain the contamination levels observed in their analysis. Another recent benchmark, SWE-bench [30], focuses on evaluating performance on coding tasks. By comparing their results with those of Human-Eval [13], one can visually interpret potential contamination in Human-Eval. However, the absence of a statistical test hinders precise contamination detection. In both scenarios, CONSTAT can improve their findings, enabling accurate estimations of contamination in existing models.

6 Discussion

Limitations Our method estimates the effect of contamination on performance relative to a set of reference models. Therefore, if these reference models are also contaminated, our method only measures the effect relative to this base level of contamination. However, our leave-one-out experiment, presented in §4.3, helps identify and exclude contaminated models, partially mitigating this limitation. Furthermore, it is important to note that accurate relative performance measurements are sufficient for both model selection and to assess methodological improvements, which are the most important use cases of benchmarks.

Further, our work uses an LLM to generate synthetic samples, introducing potential distributional biases into the synthetic benchmark D ref . We briefly discuss these biases here. Firstly, synthetic benchmark may contain more mislabeled samples. However, since these samples equally affect all models, CONSTAT accounts for this in its difficulty correction. Secondly, synthetic samples generated by a model are likely easier for that model itself to solve. Therefore, contamination results for the model used to generate the samples would be unreliable for sample-specific contamination detection. However, these limitations are not inherent flaws of CONSTAT, and can be mitigated by using more sophisticated synthetic benchmark generation techniques.

Impact Model evaluation is a crucial part of LLM development, with benchmarks playing a key role in evaluating model performance on tasks like code generation, question answering, and summarization. Contamination of these benchmarks can inflate performance estimates, potentially misleading researchers and practitioners. To address this, CONSTAT provides a statistical framework to estimate the impact of contamination on model performance. This enables more accurate evaluations and allows for the removal of suspicious models from leaderboards, ensuring a fairer evaluation of model capabilities. Furthermore, it is important to note that CONSTAT can be applied to any model, not just LLMs, as long as the model's performance can be measured on a benchmark.

7 Conclusion

We present CONSTAT, a statistical framework designed to detect contamination and estimate its effect on model performance. Unlike existing methods, CONSTAT is based on a novel, performance-based definition of contamination and compares performance with various reference benchmarks to obtain a detailed contamination analysis that distinguishes between syntax-, sample-, and benchmark-specific contamination. We investigate CONSTAT's effectiveness in an extensive control study and demonstrate that it not only outperforms existing methods but also, in contrast to them, does not require prior knowledge about uncontaminated samples. Finally, we use CONSTAT to investigate contamination in popular models and find, among others, very high levels of contamination in MISTRAL-7b-v0.1 and YI-34b and high levels of contamination in LLAMA-3-70b and LLAMA-2-INSTRUCT-70b.

References

Marah Abdin, Sam Ade Jacobs, Ammar Ahmad Awan, Jyoti Aneja, Ahmed Awadallah, Hany Awadalla, Nguyen Bach, Amit Bahree, Arash Bakhtiari, Harkirat Behl, Alon Benhaim, Misha Bilenko, Johan Bjorck, Sébastien Bubeck, Martin Cai, Caio César Teodoro Mendes, Weizhu Chen, Vishrav Chaudhary, Parul Chopra, Allie Del Giorno, Gustavo de Rosa, Matthew Dixon, Ronen Eldan, Dan Iter, Amit Garg, Abhishek Goswami, Suriya Gunasekar, Emman Haider, Junheng Hao, Russell J. Hewett, Jamie Huynh, Mojan Javaheripi, Xin Jin, Piero Kauffmann, Nikos Karampatziakis, Dongwoo Kim, Mahoud Khademi, Lev Kurilenko, James R. Lee, Yin Tat Lee, Yuanzhi Li, Chen Liang, Weishung Liu, Eric Lin, Zeqi Lin, Piyush Madan, Arindam Mitra, Hardik Modi, Anh Nguyen, Brandon Norick, Barun Patra, Daniel Perez-Becker, Thomas Portet, Reid Pryzant, Heyang Qin, Marko Radmilac, Corby Rosset, Sambudha Roy, Olatunji Ruwase, Olli Saarikivi, Amin Saied, Adil Salim, Michael Santacroce, Shital Shah, Ning Shang, Hiteshi Sharma, Xia Song, Masahiro Tanaka, Xin Wang, Rachel Ward, Guanhua Wang, Philipp Witte, Michael Wyatt, Can Xu, Jiahang Xu, Sonali Yadav, Fan Yang, Ziyi Yang, Donghan Yu, Chengruidong Zhang, Cyril Zhang, Jianwen Zhang, Li Lyna Zhang, Yi Zhang, Yue Zhang, Yunan Zhang, and Xiren Zhou. Phi-3 technical report: A highly capable language model locally on your phone, 2024.

AI@Meta. Llama 3 model card. 2024. URL https://github.com/meta-llama/llama3/blob/ main/MODEL _ CARD.md .

Ebtesam Almazrouei, Hamza Alobeidli, Abdulaziz Alshamsi, Alessandro Cappelli, Ruxandra Cojocaru, Merouane Debbah, Etienne Goffinet, Daniel Heslow, Julien Launay, Quentin Malartic, Badreddine Noune, Baptiste Pannier, and Guilherme Penedo. The falcon series of language models: Towards open frontier models. 2023.

Aida Amini, Saadia Gabriel, Shanchuan Lin, Rik Koncel-Kedziorski, Yejin Choi, and Hannaneh Hajishirzi. Mathqa: Towards interpretable math word problem solving with operation-based formalisms. In Jill Burstein, Christy Doran, and Thamar Solorio, editors, Proceedings of the 2019 Conference of the North American Chapter of the Association for Computational Linguistics: Human Language Technologies, NAACL-HLT 2019, Minneapolis, MN, USA, June 2-7, 2019, Volume 1 (Long and Short Papers) , pages 2357-2367. Association for Computational Linguistics, 2019. doi: 10.18653/V1/N19-1245. URL https://doi.org/10.18653/v1/n19-1245 .

Rohan Anil, Sebastian Borgeaud, Yonghui Wu, Jean-Baptiste Alayrac, Jiahui Yu, Radu Soricut, Johan Schalkwyk, Andrew M. Dai, Anja Hauth, Katie Millican, David Silver, Slav Petrov, Melvin Johnson, Ioannis Antonoglou, Julian Schrittwieser, Amelia Glaese, Jilin Chen, Emily Pitler, Timothy P. Lillicrap, Angeliki Lazaridou, Orhan Firat, James Molloy, Michael Isard, Paul Ronald Barham, Tom Hennigan, Benjamin Lee, Fabio Viola, Malcolm Reynolds, Yuanzhong Xu, Ryan Doherty, Eli Collins, Clemens Meyer, Eliza Rutherford, Erica Moreira, Kareem Ayoub, Megha Goel, George Tucker, Enrique Piqueras, Maxim Krikun, Iain Barr, Nikolay Savinov, Ivo Danihelka, Becca Roelofs, Anaïs White, Anders Andreassen, Tamara von Glehn, Lakshman Yagati, Mehran Kazemi, Lucas Gonzalez, Misha Khalman, Jakub Sygnowski, and et al. Gemini: A family of highly capable multimodal models. CoRR , abs/2312.11805, 2023. doi: 10.48550/ARXIV.2312.11805.

Jinze Bai, Shuai Bai, Yunfei Chu, Zeyu Cui, Kai Dang, Xiaodong Deng, Yang Fan, Wenbin Ge, Yu Han, Fei Huang, Binyuan Hui, Luo Ji, Mei Li, Junyang Lin, Runji Lin, Dayiheng Liu, Gao Liu, Chengqiang Lu, Keming Lu, Jianxin Ma, Rui Men, Xingzhang Ren, Xuancheng

Ren, Chuanqi Tan, Sinan Tan, Jianhong Tu, Peng Wang, Shijie Wang, Wei Wang, Shengguang Wu, Benfeng Xu, Jin Xu, An Yang, Hao Yang, Jian Yang, Shusheng Yang, Yang Yao, Bowen Yu, Hongyi Yuan, Zheng Yuan, Jianwei Zhang, Xingxuan Zhang, Yichang Zhang, Zhenru Zhang, Chang Zhou, Jingren Zhou, Xiaohuan Zhou, and Tianhang Zhu. Qwen technical report. CoRR , abs/2309.16609, 2023. doi: 10.48550/ARXIV.2309.16609. URL https: //doi.org/10.48550/arXiv.2309.16609 .

Edward Beeching, Clémentine Fourrier, Nathan Habib, Sheon Han, Nathan Lambert, Nazneen Rajani, Omar Sanseviero, Lewis Tunstall, and Thomas Wolf. Open llm leaderboard. https: //huggingface.co/spaces/HuggingFaceH4/open _ llm _ leaderboard , 2023.

Marco Bellagente, Jonathan Tow, Dakota Mahan, Duy Phung, Maksym Zhuravinskyi, Reshinth Adithyan, James Baicoianu, Ben Brooks, Nathan Cooper, Ashish Datta, Meng Lee, Emad Mostaque, Michael Pieler, Nikhil Pinnaparju, Paulo Rocha, Harry Saini, Hannah Teufel, Niccoló Zanichelli, and Carlos Riquelme. Stable LM 2 1.6b technical report. CoRR , abs/2402.17834, 2024. doi: 10.48550/ARXIV.2402.17834. URL https://doi.org/10.48550/arXiv.2402. 17834 .

Yoav Benjamini and Yosef Hochberg. Controlling the false discovery rate: A practical and powerful approach to multiple testing. Journal of the Royal Statistical Society: Series B (Methodological) , 57(1):289-300, 1995. doi: https://doi.org/10.1111/j.2517-6161.1995. tb02031.x. URL https://rss.onlinelibrary.wiley.com/doi/abs/10.1111/j.2517-6161. 1995.tb02031.x .

Tom B. Brown, Benjamin Mann, Nick Ryder, Melanie Subbiah, Jared Kaplan, Prafulla Dhariwal, Arvind Neelakantan, Pranav Shyam, Girish Sastry, Amanda Askell, Sandhini Agarwal, Ariel Herbert-Voss, Gretchen Krueger, Tom Henighan, Rewon Child, Aditya Ramesh, Daniel M. Ziegler, Jeffrey Wu, Clemens Winter, Christopher Hesse, Mark Chen, Eric Sigler, Mateusz Litwin, Scott Gray, Benjamin Chess, Jack Clark, Christopher Berner, Sam McCandlish, Alec Radford, Ilya Sutskever, and Dario Amodei. Language models are few-shot learners. In Proc. of NeurIPS , 2020.

Zheng Cai, Maosong Cao, Haojiong Chen, Kai Chen, Keyu Chen, Xin Chen, Xun Chen, Zehui Chen, Zhi Chen, Pei Chu, Xiaoyi Dong, Haodong Duan, Qi Fan, Zhaoye Fei, Yang Gao, Jiaye Ge, Chenya Gu, Yuzhe Gu, Tao Gui, Aijia Guo, Qipeng Guo, Conghui He, Yingfan Hu, Ting Huang, Tao Jiang, Penglong Jiao, Zhenjiang Jin, Zhikai Lei, Jiaxing Li, Jingwen Li, Linyang Li, Shuaibin Li, Wei Li, Yining Li, Hongwei Liu, Jiangning Liu, Jiawei Hong, Kaiwen Liu, Kuikun Liu, Xiaoran Liu, Chengqi Lv, Haijun Lv, Kai Lv, Li Ma, Runyuan Ma, Zerun Ma, Wenchang Ning, Linke Ouyang, Jiantao Qiu, Yuan Qu, Fukai Shang, Yunfan Shao, Demin Song, Zifan Song, Zhihao Sui, Peng Sun, Yu Sun, Huanze Tang, Bin Wang, Guoteng Wang, Jiaqi Wang, Jiayu Wang, Rui Wang, Yudong Wang, Ziyi Wang, Xingjian Wei, Qizhen Weng, Fan Wu, Yingtong Xiong, and et al. Internlm2 technical report. CoRR , abs/2403.17297, 2024. doi: 10.48550/ARXIV.2403.17297. URL https://doi.org/10.48550/arXiv.2403.17297 .

Nicholas Carlini, Florian Tramèr, Eric Wallace, Matthew Jagielski, Ariel Herbert-Voss, Katherine Lee, Adam Roberts, Tom B. Brown, Dawn Song, Úlfar Erlingsson, Alina Oprea, and Colin Raffel. Extracting training data from large language models. In 30th USENIX Security Symposium, USENIX Security 2021, August 11-13, 2021 , 2021.

Mark Chen, Jerry Tworek, Heewoo Jun, Qiming Yuan, Henrique Pondé de Oliveira Pinto, Jared Kaplan, Harrison Edwards, Yuri Burda, Nicholas Joseph, Greg Brockman, Alex Ray, Raul Puri, Gretchen Krueger, Michael Petrov, Heidy Khlaaf, Girish Sastry, Pamela Mishkin, Brooke Chan, Scott Gray, Nick Ryder, Mikhail Pavlov, Alethea Power, Lukasz Kaiser, Mohammad Bavarian, Clemens Winter, Philippe Tillet, Felipe Petroski Such, Dave Cummings, Matthias Plappert, Fotios Chantzis, Elizabeth Barnes, Ariel Herbert-Voss, William Hebgen Guss, Alex Nichol, Alex Paino, Nikolas Tezak, Jie Tang, Igor Babuschkin, Suchir Balaji, Shantanu Jain, William Saunders, Christopher Hesse, Andrew N. Carr, Jan Leike, Joshua Achiam, Vedant Misra, Evan Morikawa, Alec Radford, Matthew Knight, Miles Brundage, Mira Murati, Katie Mayer, Peter Welinder, Bob McGrew, Dario Amodei, Sam McCandlish, Ilya Sutskever, and Wojciech Zaremba. Evaluating large language models trained on code. CoRR , abs/2107.03374, 2021. URL https://arxiv.org/abs/2107.03374 .

Aakanksha Chowdhery, Sharan Narang, Jacob Devlin, Maarten Bosma, Gaurav Mishra, Adam Roberts, Paul Barham, Hyung Won Chung, Charles Sutton, Sebastian Gehrmann, Parker Schuh, Kensen Shi, Sasha Tsvyashchenko, Joshua Maynez, Abhishek Rao, Parker Barnes, Yi Tay, Noam Shazeer, Vinodkumar Prabhakaran, Emily Reif, Nan Du, Ben Hutchinson, Reiner Pope, James Bradbury, Jacob Austin, Michael Isard, Guy Gur-Ari, Pengcheng Yin, Toju Duke, Anselm Levskaya, Sanjay Ghemawat, Sunipa Dev, Henryk Michalewski, Xavier Garcia, Vedant Misra, Kevin Robinson, Liam Fedus, Denny Zhou, Daphne Ippolito, David Luan, Hyeontaek Lim, Barret Zoph, Alexander Spiridonov, Ryan Sepassi, David Dohan, Shivani Agrawal, Mark Omernick, Andrew M. Dai, Thanumalayan Sankaranarayana Pillai, Marie Pellat, Aitor Lewkowycz, Erica Moreira, Rewon Child, Oleksandr Polozov, Katherine Lee, Zongwei Zhou, Xuezhi Wang, Brennan Saeta, Mark Diaz, Orhan Firat, Michele Catasta, Jason Wei, Kathy Meier-Hellstern, Douglas Eck, Jeff Dean, Slav Petrov, and Noah Fiedel. Palm: Scaling language modeling with pathways. CoRR , abs/2204.02311, 2022. doi: 10.48550/arXiv.2204.02311.

Peter Clark, Isaac Cowhey, Oren Etzioni, Tushar Khot, Ashish Sabharwal, Carissa Schoenick, and Oyvind Tafjord. Think you have solved question answering? try arc, the AI2 reasoning challenge. ArXiv preprint , abs/1803.05457, 2018.

Karl Cobbe, Vineet Kosaraju, Mohammad Bavarian, Mark Chen, Heewoo Jun, Lukasz Kaiser, Matthias Plappert, Jerry Tworek, Jacob Hilton, Reiichiro Nakano, Christopher Hesse, and John Schulman. Training verifiers to solve math word problems. ArXiv preprint , abs/2110.14168, 2021.

Jasper Dekoninck, Mark Niklas Müller, Maximilian Baader, Marc Fischer, and Martin T. Vechev. Evading data contamination detection for language models is (too) easy. CoRR , abs/2402.02823, 2024. doi: 10.48550/ARXIV.2402.02823. URL https://doi.org/10.48550/arXiv.2402. 02823 .

Chunyuan Deng, Yilun Zhao, Xiangru Tang, Mark Gerstein, and Arman Cohan. Investigating data contamination in modern benchmarks for large language models. CoRR , abs/2311.09783, 2023. doi: 10.48550/ARXIV.2311.09783.

Jesse Dodge, Maarten Sap, Ana Marasovi´ c, William Agnew, Gabriel Ilharco, Dirk Groeneveld, Margaret Mitchell, and Matt Gardner. Documenting large webtext corpora: A case study on the colossal clean crawled corpus. In Proc. of EMNLP , 2021. doi: 10.18653/v1/2021.emnlp-main. 98.

Leo Gao, Jonathan Tow, Baber Abbasi, Stella Biderman, Sid Black, Anthony DiPofi, Charles Foster, Laurence Golding, Jeffrey Hsu, Alain Le Noac'h, Haonan Li, Kyle McDonell, Niklas Muennighoff, Chris Ociepa, Jason Phang, Laria Reynolds, Hailey Schoelkopf, Aviya Skowron, Lintang Sutawika, Eric Tang, Anish Thite, Ben Wang, Kevin Wang, and Andy Zou. A framework for few-shot language model evaluation, 2023.

Thomas Mesnard Gemma Team, Cassidy Hardin, Robert Dadashi, Surya Bhupatiraju, Laurent Sifre, Morgane Rivière, Mihir Sanjay Kale, Juliette Love, Pouya Tafti, Léonard Hussenot, and et al. Gemma. 2024. doi: 10.34740/KAGGLE/M/3301. URL https://www.kaggle.com/m/ 3301 .

Charles Goddard, Shamane Siriwardhana, Malikeh Ehghaghi, Luke Meyers, Vlad Karpukhin, Brian Benedict, Mark McQuade, and Jacob Solawetz. Arcee's mergekit: A toolkit for merging large language models. CoRR , abs/2403.13257, 2024. doi: 10.48550/ARXIV.2403.13257. URL https://doi.org/10.48550/arXiv.2403.13257 .

Shahriar Golchin and Mihai Surdeanu. Data contamination quiz: A tool to detect and estimate contamination in large language models. CoRR , abs/2311.06233, 2023. doi: 10.48550/ARXIV. 2311.06233.

Shahriar Golchin and Mihai Surdeanu. Time travel in llms: Tracing data contamination in large language models. CoRR , abs/2308.08493, 2023. doi: 10.48550/ARXIV.2308.08493.

Dirk Groeneveld, Iz Beltagy, Pete Walsh, Akshita Bhagia, Rodney Kinney, Oyvind Tafjord, Ananya Harsh Jha, Hamish Ivison, Ian Magnusson, Yizhong Wang, Shane Arora, David Atkinson, Russell Authur, Khyathi Raghavi Chandu, Arman Cohan, Jennifer Dumas, Yanai Elazar,

Yuling Gu, Jack Hessel, Tushar Khot, William Merrill, Jacob Morrison, Niklas Muennighoff, Aakanksha Naik, Crystal Nam, Matthew E. Peters, Valentina Pyatkin, Abhilasha Ravichander, Dustin Schwenk, Saurabh Shah, Will Smith, Emma Strubell, Nishant Subramani, Mitchell Wortsman, Pradeep Dasigi, Nathan Lambert, Kyle Richardson, Luke Zettlemoyer, Jesse Dodge, Kyle Lo, Luca Soldaini, Noah A. Smith, and Hannaneh Hajishirzi. Olmo: Accelerating the science of language models. CoRR , abs/2402.00838, 2024. doi: 10.48550/ARXIV.2402.00838. URL https://doi.org/10.48550/arXiv.2402.00838 .

Dan Hendrycks, Collin Burns, Steven Basart, Andy Zou, Mantas Mazeika, Dawn Song, and Jacob Steinhardt. Measuring massive multitask language understanding. In Proc. of ICLR , 2021.

Mojan Javaheripi, Sébastien Bubeck, Marah Abdin, Jyoti Aneja, Caio César Teodoro Mendes, Weizhu Chen, Allie Del Giorno, Ronen Eldan, Sivakanth Gopi, Suriya Gunasekar, et al. Phi2: The surprising power of small language models. https://www.microsoft.com/en-us/ research/blog/phi-2-the-surprising-power-of-small-language-models/ , 2023.

Albert Q. Jiang, Alexandre Sablayrolles, Arthur Mensch, Chris Bamford, Devendra Singh Chaplot, Diego de Las Casas, Florian Bressand, Gianna Lengyel, Guillaume Lample, Lucile Saulnier, Lélio Renard Lavaud, Marie-Anne Lachaux, Pierre Stock, Teven Le Scao, Thibaut Lavril, Thomas Wang, Timothée Lacroix, and William El Sayed. Mistral 7b. CoRR , abs/2310.06825, 2023. doi: 10.48550/ARXIV.2310.06825.

Minhao Jiang, Ken Ziyu Liu, Ming Zhong, Rylan Schaeffer, Siru Ouyang, Jiawei Han, and Sanmi Koyejo. Investigating data contamination for pre-training language models. CoRR , abs/2401.06059, 2024. doi: 10.48550/ARXIV.2401.06059. URL https://doi.org/10.48550/ arXiv.2401.06059 .

Carlos E. Jimenez, John Yang, Alexander Wettig, Shunyu Yao, Kexin Pei, Ofir Press, and Karthik Narasimhan. Swe-bench: Can language models resolve real-world github issues? CoRR , abs/2310.06770, 2023. doi: 10.48550/ARXIV.2310.06770. URL https://doi.org/10. 48550/arXiv.2310.06770 .

Yucheng Li. An open source data contamination report for large language models. CoRR , abs/2310.17589, 2023. doi: 10.48550/ARXIV.2310.17589.

Wing Lian, Bleys Goodson, Eugene Pentland, Austin Cook, Chanvichet Vong, and "Teknium". Openorca: An open dataset of gpt augmented flan reasoning traces. https://https: //huggingface.co/Open-Orca/OpenOrca , 2023.

Stephanie Lin, Jacob Hilton, and Owain Evans. TruthfulQA: Measuring how models mimic human falsehoods. In Proc. of ACL , 2022. doi: 10.18653/v1/2022.acl-long.229.

Justus Mattern, Fatemehsadat Mireshghallah, Zhijing Jin, Bernhard Schölkopf, Mrinmaya Sachan, and Taylor Berg-Kirkpatrick. Membership inference attacks against language models via neighbourhood comparison. In Findings of ACL , 2023. doi: 10.18653/V1/2023. FINDINGS-ACL.719.

Fatemehsadat Mireshghallah, Kartik Goyal, Archit Uniyal, Taylor Berg-Kirkpatrick, and Reza Shokri. Quantifying privacy risks of masked language models using membership inference attacks. In Proc. of EMNLP , 2022. doi: 10.18653/V1/2022.EMNLP-MAIN.570.

OpenAI. GPT-4 technical report. CoRR , abs/2303.08774, 2023. doi: 10.48550/arXiv.2303. 08774.

Yonatan Oren, Nicole Meister, Niladri S. Chatterji, Faisal Ladhak, and Tatsunori B. Hashimoto. Proving test set contamination in black box language models. CoRR , abs/2310.17623, 2023. doi: 10.48550/ARXIV.2310.17623.

Denis Paperno, Germán Kruszewski, Angeliki Lazaridou, Quan Ngoc Pham, Raffaella Bernardi, Sandro Pezzelle, Marco Baroni, Gemma Boleda, and Raquel Fernández. The LAMBADA dataset: Word prediction requiring a broad discourse context. In Proceedings of the 54th Annual Meeting of the Association for Computational Linguistics, ACL 2016, August 7-12, 2016, Berlin,

Germany, Volume 1: Long Papers . The Association for Computer Linguistics, 2016. doi: 10.18653/V1/P16-1144. URL https://doi.org/10.18653/v1/p16-1144 .

Oscar Sainz, Jon Ander Campos, Iker García-Ferrero, Julen Etxaniz, Oier Lopez de Lacalle, and Eneko Agirre. NLP evaluation in trouble: On the need to measure LLM data contamination for each benchmark. In Findings of the Association for Computational Linguistics: EMNLP 2023, Singapore, December 6-10, 2023 , 2023.

Weijia Shi. Detect-pretrain-code-contamination. https://github.com/swj0419/ detect-pretrain-code-contamination , 2023.

Weijia Shi, Anirudh Ajith, Mengzhou Xia, Yangsibo Huang, Daogao Liu, Terra Blevins, Danqi Chen, and Luke Zettlemoyer. Detecting pretraining data from large language models. CoRR , abs/2310.16789, 2023. doi: 10.48550/ARXIV.2310.16789.

Robert J Tibshirani. Bootstrap confidence intervals . Stanford University. Department of Statistics. Laboratory for Computational . . . , 1984.

Hugo Touvron, Louis Martin, Kevin Stone, Peter Albert, Amjad Almahairi, Yasmine Babaei, Nikolay Bashlykov, Soumya Batra, Prajjwal Bhargava, Shruti Bhosale, Dan Bikel, Lukas Blecher, Cristian Canton-Ferrer, Moya Chen, Guillem Cucurull, David Esiobu, Jude Fernandes, Jeremy Fu, Wenyin Fu, Brian Fuller, Cynthia Gao, Vedanuj Goswami, Naman Goyal, Anthony Hartshorn, Saghar Hosseini, Rui Hou, Hakan Inan, Marcin Kardas, Viktor Kerkez, Madian Khabsa, Isabel Kloumann, Artem Korenev, Punit Singh Koura, Marie-Anne Lachaux, Thibaut Lavril, Jenya Lee, Diana Liskovich, Yinghai Lu, Yuning Mao, Xavier Martinet, Todor Mihaylov, Pushkar Mishra, Igor Molybog, Yixin Nie, Andrew Poulton, Jeremy Reizenstein, Rashi Rungta, Kalyan Saladi, Alan Schelten, Ruan Silva, Eric Michael Smith, Ranjan Subramanian, Xiaoqing Ellen Tan, Binh Tang, Ross Taylor, Adina Williams, Jian Xiang Kuan, Puxin Xu, Zheng Yan, Iliyan Zarov, Yuchen Zhang, Angela Fan, Melanie Kambadur, Sharan Narang, Aurélien Rodriguez, Robert Stojnic, Sergey Edunov, and Thomas Scialom. Llama 2: Open foundation and fine-tuned chat models. CoRR , abs/2307.09288, 2023. doi: 10.48550/arXiv.2307.09288.

Pauli Virtanen, Ralf Gommers, Travis E. Oliphant, Matt Haberland, Tyler Reddy, David Cournapeau, Evgeni Burovski, Pearu Peterson, Warren Weckesser, Jonathan Bright, Stéfan J. van der Walt, Matthew Brett, Joshua Wilson, K. Jarrod Millman, Nikolay Mayorov, Andrew R. J. Nelson, Eric Jones, Robert Kern, Eric Larson, C J Carey, ˙ Ilhan Polat, Yu Feng, Eric W. Moore, Jake VanderPlas, Denis Laxalde, Josef Perktold, Robert Cimrman, Ian Henriksen, E. A. Quintero, Charles R. Harris, Anne M. Archibald, Antônio H. Ribeiro, Fabian Pedregosa, Paul van Mulbregt, and SciPy 1.0 Contributors. SciPy 1.0: Fundamental Algorithms for Scientific Computing in Python. Nature Methods , 17:261-272, 2020. doi: 10.1038/s41592-019-0686-2.

Thuy-Trang Vu, Xuanli He, Gholamreza Haffari, and Ehsan Shareghi. Koala: An index for quantifying overlaps with pre-training corpora. In Proc. of EMNLP , 2023.

Grace Wahba. Estimating the Smoothing Parameter , pages 45-65. 1990. doi: 10.1137/1. 9781611970128.ch4. URL https://epubs.siam.org/doi/abs/10.1137/1.9781611970128. ch4 .

Johannes Welbl, Nelson F. Liu, and Matt Gardner. Crowdsourcing multiple choice science questions. In Leon Derczynski, Wei Xu, Alan Ritter, and Tim Baldwin, editors, Proceedings of the 3rd Workshop on Noisy User-generated Text, NUT@EMNLP 2017, Copenhagen, Denmark, September 7, 2017 , pages 94-106. Association for Computational Linguistics, 2017. doi: 10.18653/V1/W17-4413. URL https://doi.org/10.18653/v1/w17-4413 .

Thomas Wolf, Lysandre Debut, Victor Sanh, Julien Chaumond, Clement Delangue, Anthony Moi, Pierric Cistac, Tim Rault, Remi Louf, Morgan Funtowicz, Joe Davison, Sam Shleifer, Patrick von Platen, Clara Ma, Yacine Jernite, Julien Plu, Canwen Xu, Teven Le Scao, Sylvain Gugger, Mariama Drame, Quentin Lhoest, and Alexander Rush. Transformers: State-of-the-art natural language processing. In Proc. of EMNLP , 2020. doi: 10.18653/v1/2020.emnlp-demos.6.

Ruijie Xu, Zengzhi Wang, Run-Ze Fan, and Pengfei Liu. Benchmarking benchmark leakage in large language models, 2024.

Prateek Yadav, Derek Tam, Leshem Choshen, Colin A. Raffel, and Mohit Bansal. Tiesmerging: Resolving interference when merging models. In Alice Oh, Tristan Naumann, Amir Globerson, Kate Saenko, Moritz Hardt, and Sergey Levine, editors, Advances in Neural Information Processing Systems 36: Annual Conference on Neural Information Processing Systems 2023, NeurIPS 2023, New Orleans, LA, USA, December 10 - 16, 2023 , 2023. URL http://papers.nips.cc/paper _ files/paper/2023/hash/ 1644c9af28ab7916874f6fd6228a9bcf-Abstract-Conference.html .

Shuo Yang, Wei-Lin Chiang, Lianmin Zheng, Joseph E. Gonzalez, and Ion Stoica. Rethinking benchmark and contamination for language models with rephrased samples. CoRR , abs/2311.04850, 2023. doi: 10.48550/ARXIV.2311.04850.

Samuel Yeom, Irene Giacomelli, Matt Fredrikson, and Somesh Jha. Privacy risk in machine learning: Analyzing the connection to overfitting. In 31st IEEE Computer Security Foundations Symposium, CSF 2018, Oxford, United Kingdom, July 9-12, 2018 , 2018. doi: 10.1109/CSF. 2018.00027.

Alex Young, Bei Chen, Chao Li, Chengen Huang, Ge Zhang, Guanwei Zhang, Heng Li, Jiangcheng Zhu, Jianqun Chen, Jing Chang, Kaidong Yu, Peng Liu, Qiang Liu, Shawn Yue, Senbin Yang, Shiming Yang, Tao Yu, Wen Xie, Wenhao Huang, Xiaohui Hu, Xiaoyi Ren, Xinyao Niu, Pengcheng Nie, Yuchi Xu, Yudong Liu, Yue Wang, Yuxuan Cai, Zhenyu Gu, Zhiyuan Liu, and Zonghong Dai. Yi: Open foundation models by 01.ai. CoRR , abs/2403.04652, 2024. doi: 10.48550/ARXIV.2403.04652. URL https://doi.org/10.48550/arXiv.2403.04652 .

Rowan Zellers, Ari Holtzman, Yonatan Bisk, Ali Farhadi, and Yejin Choi. Hellaswag: Can a machine really finish your sentence? In Anna Korhonen, David R. Traum, and Lluís Màrquez, editors, Proceedings of the 57th Conference of the Association for Computational Linguistics, ACL 2019, Florence, Italy, July 28- August 2, 2019, Volume 1: Long Papers , pages 47914800. Association for Computational Linguistics, 2019. doi: 10.18653/V1/P19-1472. URL https://doi.org/10.18653/v1/p19-1472 .

Hugh Zhang, Jeff Da, Dean Lee, Vaughn Robinson, Catherine Wu, Will Song, Tiffany Zhao, Pranav Raja, Dylan Slack, Qin Lyu, Sean Hendryx, Russell Kaplan, Michele Lunati, and Summer Yue. A careful examination of large language model performance on grade school arithmetic, 2024.

Kun Zhou, Yutao Zhu, Zhipeng Chen, Wentong Chen, Wayne Xin Zhao, Xu Chen, Yankai Lin, Ji-Rong Wen, and Jiawei Han. Don't make your LLM an evaluation benchmark cheater. CoRR , abs/2311.01964, 2023. doi: 10.48550/ARXIV.2311.01964.

Wenhong Zhu, Hongkun Hao, Zhiwei He, Yunze Song, Yumeng Zhang, Hanxu Hu, Yiran Wei, Rui Wang, and Hongyuan Lu. CLEAN-EVAL: clean evaluation on contaminated large language models. CoRR , abs/2311.09154, 2023. doi: 10.48550/ARXIV.2311.09154.

A Additional Results

We present the complete results for the experiments discussed in §4 here and include a discussion on the STABLELM-2 and INTERNLM-2 model families. We provide a table with the results for all evaluated model families where p < 1% in Table 4.

A.1 Discussion on INTERNLM-2 and STABLELM-2

INTERNLM-2 We evaluated four models in the INTERNLM-2 model family: the models with size 1.8b and 7b, and the math-base and math models, also of 7b parameters. Overall, we found very little evidence of contamination in these models, with no model showing significant ( p < 1% ) samplespecific contamination. However, we did find some evidence for benchmark-specific contamination for GSM8k and Hellaswag for several models in the model family. Specifically, INTERNLM-2-7b and INTERNLM-2-MATH-7b show significant benchmark-specific contamination on GSM8k with p < 0 . 5% and estimated effects of 20% and 40% respectively. The size of this effect is likely due to the same reasons as the measured contamination in the PHI models, where the models are too small to solve mathematical questions in one go and have been trained/finetuned to perform chain-of-thought mathematics. The benchmark-specific contamination on Hellaswag is present for all three 7b models in the family, with 0 . 5% < p < 1% and estimated effects of 6% to 11% .

STABLELM-2 For STABLELM-2, we evaluated 6 models in the model family (12b, INSTRUCT12b, 1.6b, INSTRUCT-1.6b, ZEPHYR-3b and ALPHA-7b-v2). We found only one instance of samplespecific contamination, with the 12b model showing slight ( p = 0 . 7% ) contamination for ARC. Notably, we found that all of the models in this family show benchmark-specific contamination for GSM8k with estimated effects between 15% and 40% .

A.2 Results for GSM8k Contaminated Models

We present the complete results for the contaminated models finetuned on the GSM8k benchmark in Table 5. For a detailed explanation of each of the settings, we refer to App. C. We do mention here that in the realistic setting, we only train for 1 epoch, without any few-shot samples in the prompt and with additional background instruction-tuning data from the OpenOrca dataset [32].

B Ablation Study via Simulation

To further investigate the performance of CONSTAT, we conduct an ablation study using simulations. This approach allows us to test various scenarios and understand the behavior of CONSTAT under different conditions without the need for finetuning or computationally intense evaluations. Furthermore, it helps in verifying the p-values returned by various tests while avoiding the risk of tuning our final test to our analysis in §4. We first explain the simulation setup and then present the results.

B.1 Simulation and Setup

Simulation In the simulation, samples are modeled as real numbers representing their complexity. Each sample x in a benchmark D is drawn from a benchmark-specific distribution D . Therefore, a benchmark D can be specified by a number n ∈ Z > 0 , indicating the number of samples, and a distribution D , from which the samples are drawn. Given the benchmarks ( n, D ) and ( n ref , D ref ) , a model is represented as M = ( m,m ref ) ∈ R 2 , where each number indicates the quality of the model on the respective benchmarks. The probability that a model M answers a sample x ∈ D correctly is given by the formula min(1 , exp( -x/m )) . Note that this probability increases as the quality of the model m grows and decreases as the complexity of the sample x increases.

If m ref < m for a given model, the model is contaminated. Reference models can be drawn from a distribution M over the real numbers such that m ref = m for each reference model. To simulate noise in the evaluation of models, we can add noise to the quality of the reference models, resulting in m ref ≈ m .

Statistical Tests We compare CONSTAT against various other statistical tests that one could construct. First, we include various variants of CONSTAT. CONSTAT-NO-SORT does not sort the reference models by their and fits the hardness correction function H D ref directly on the scores ( S D ref ( M i ) , S D ( M i )) . CONSTAT-NO-RANDOM does not include a random model in the set of reference models. CONSTAT-NO-BOOTSTRAP only performs bootstrapping over the samples and not over the reference models.

We also include two alternative tests. MEAN-TEST directly compares performance on the reference and original benchmarks, considering a model contaminated if its performance on the original benchmark is significantly higher. NORMALIZED-TEST instead computes the normalized performance with respect to the models by computing the means µ D , µ D ref and standard deviations σ D , σ D ref of the reference models on each benchmark. It then bootstraps the reference models and samples to obtain the p-value as the probability that the normalized performance σ -1 D ( S D ( M ) -µ D ) of the model on the original benchmark is higher than on the reference benchmark. Therefore, NORMALIZED-TEST essentially corrects for first- and second-order distributional differences between D and D ref .

Reporting Results We report results for specific distributions M , D and D ref for a model M for which we aim to detect possible contamination. For each choice of distributions, we run 1000 simulations, each drawing new reference models and benchmarks from the given distributions and performing the tests described before. This ablation focuses on the uncontaminated case, where m = m ref, as avoiding false positives is crucial. In Fig. 3a, we show an example plot of the resulting CDF of the returned p-value when D = D ref. As expected, the CDF for each method is very close to the identity line for the uncontaminated model. Ideally, the curve for uncontaminated models should be as close as possible to this identity line to ensure reliable p-values. Above the line is especially problematic, as this would be the cause of false positives. Furthermore, by swapping the distributions D and D ref, one would obtain a mirror image of the plot. This means that a CDF that is below the identity line in a given situation, would be above the identity line in the mirror image, and is therefore also problematic for the same reason.

We now report results for various scenarios. In each case, we aim to ensure that a specific test fails and explain why this is the case. In all explored scenarios, CONSTAT performs as expected, while the other methods fail. Unless specified otherwise, we use 20 reference models and 1000 samples for each benchmark, in line with our results presented in §4. A full overview of each parameter setting can be found in Table 6. We always set the quality of the model under consideration to (1 , 1) .

B.2 Results

Different Distributions The MEAN-TEST should fail if the difficulty of one benchmark is different than the other. We slightly decrease the difficulty of the samples in the original benchmark to make MEAN-TEST return false positives, as shown in Fig. 3b. Despite M being uncontaminated, the p-values returned by MEAN-TEST show a very steep CDF.

Non-Linearity NORMALIZED-TEST assumes a linear relationship between performances on reference and original benchmarks, but non-linear relationships can occur. For instance, it is non-linear for sample-specific contamination in the GSM8k benchmark (see Fig. 1). Therefore, we change the benchmark distributions to ensure a non-linear relationship. The result shown in Fig. 3c shows that NORMALIZED-TEST returns a very steep CDF. We note that CONSTAT-NO-SORT also returns a steep CDF in this particular case.

Noise When reference models do not have the same quality on both benchmarks, noise is introduced in the signal that the test receives. Our theoretical analysis in §3 corrects for this noise by sorting the reference models by performance on each benchmark. CONSTAT-NO-SORT is more susceptible to this noise. We showcase this for an uncontaminated model in Fig. 3d by keeping D = D ref, but now adding a small amount of noise to the reference models. CONSTAT-NO-SORT returns a steep CDF and should not be used in practice due to the noisy nature of real-world scenarios.

Bootstrapping Models Bootstrapping over reference models is necessary for reliable p-values. Without bootstrapping, the test would rely on the specific instantiation of the reference models, leading to p-values that are either too certain, always returning 0 or 1 . We repeat the non-linear scenario with added noise to the reference models and a wider distribution over them. As shown in Fig. 3e, CONSTAT-NO-BOOTSTRAP returns a CDF that is very steep at either edge.

No Random Model Adding a random model to the reference models in CONSTAT provides further regularization. The effect of this addition only becomes apparent when we use fewer reference models in a non-linear scenario. In such cases, all reference models are relatively close together and the smoothing spline overfits to this local part of the curve. We demonstrate this in Fig. 3f, using only five reference models and a non-linear relationship between the benchmarks. CONSTAT-NO-RANDOM shows a rather steep CDF in this scenario.

We conclude that CONSTAT is robust to various scenarios and provides reliable p-values in all cases. The other tests fail in the scenarios we have presented, highlighting the importance of the design choices made in CONSTAT.

0

.

0

0

.

2

0

.

4

0

.

6

0

.

8

1

.

0

p

0

.

0

0

.

2

0

.

4

0

.

6

0

.

8

1

.

0

ConStat

Mean-Test

Normalized-Test

ConStat-No-Sort

ConStat-No-Bootstrap

ConStat-No-Random

Identity

0

.

0

0

.

2

0

.

4

0

.

6

0

.

8

1

.

0

p

0

.

0

0

.

2

0

.

4

0

.

6

0

.

8

1

.

0

ConStat

Mean-Test

Normalized-Test

ConStat-No-Sort

ConStat-No-Bootstrap

ConStat-No-Random

Identity

0

.

0

0

.

2

0

.

4

0

.

6

0

.

8

1

.

0

p

0

.

0

0

.

2

0

.

4

0

.

6

0

.

8

1

.

0

ConStat

Mean-Test

Normalized-Test

ConStat-No-Sort

ConStat-No-Bootstrap

ConStat-No-Random

Identity

e The reference models are noisy and the relationship between the benchmarks is non-linear.

0

.

0

0

.

2

0

.

4

0

.

6

0

.

8

1

.

0

p

0

.

0

0

.

2

0

.

4

0

.

6

0

.

8

1

.

0

ConStat

Mean-Test

Normalized-Test

ConStat-No-Sort

ConStat-No-Bootstrap

ConStat-No-Random

Identity

0

.

0

0

.

2

0

.

4

0

.

6

0

.

8

1

.

0

p

0

.

0

0

.

2

0

.

4

0

.

6

0

.

8

1

.

0

ConStat

Mean-Test

Normalized-Test

ConStat-No-Sort

ConStat-No-Bootstrap

ConStat-No-Random

Identity

0

.

0

0

.

2

0

.

4

0

.

6

0

.

8

1

.

0

0

.

0

0

.

2

0

.

4

0

.

6

0

.

8

1

.

0

ConStat

Mean-Test

Normalized-Test

ConStat-No-Sort

ConStat-No-Bootstrap

ConStat-No-Random

Identity

C Experimental Details

We describe the full details for the experiments presented in §4. This includes the preprocessing stage of the benchmarks, the data generation process, the fine-tuning of the models on the benchmarks, and the evaluation of the models, including the reference models used. Additionally, we provide details on the computational resources necessary to run the experiments. Licensing information for all assets used in the experiments is provided in App. D.

Preprocessing We select four benchmarks for our experiments, ARC [15], GSM8k [16], Hellaswag [54], and MMLU [26]. Due to the large size of MMLU, we first select a subset of the topics from which it consists. Specifically, we select the following topics: Abstract Algebra, Anatomy, Astronomy, Business Ethics, Clinical Knowledge, College Biology, College Chemistry, College Computer Science, College Mathematics, College Medicine, College Physics, Computer Security, Conceptual Physics, Econometrics, and Electrical Engineering. We randomly select 2000 samples from each of the benchmarks. These samples were then split into two equally-sized sets, one of which was used for contaminating the fine-tuned models.

For the chosen reference benchmarks we limit the number of samples to 2000. We choose this number based on the trade-off between tight confidence bounds and computational budget. Computational complexity increases linearly with the number of samples, while the size of confidence intervals decreases. We found that 2000 samples provide tight confidence bounds and allow us to evaluate over 50 models within our budget.

Data Generation For each benchmark, we generate a rephrased version of the benchmark and a synthetic benchmark. For both these purposes, we use GPT-4-TURBO [36]. Specifically, for the rephrased benchmarks, we use a system prompt asking the model to rephrase the input (including options for multiple-choice benchmarks) of a given sample. We use a different system prompt to generate rephrased training samples, including the input and output, to finetune the models trained on rephrased data for our experiments in §4.2. By using separate prompts for training and evaluation, we ensure that the evaluation did not occur on the same data as the training.

For the synthetic benchmarks, we write a system prompt that asks to generate new synthetic samples for the benchmark. To obtain faithful synthetic samples, we use few-shotting where the model is given several examples of the benchmark. By placing these generated samples in the "assistant" field of the chat model and changing the given few-shot examples for each sample we generate, we ensure both faithful and diverse samples. We generate 1000 samples for each benchmark.

To ensure high data quality for rephrasing and synthetic sample generation, we performed the following procedure:

We manually tested around 10 samples for each benchmark with various system prompts, iteratively refining the prompts until we were satisfied with the output quality.

We performed a manual check of approximately 100 samples for each benchmark to identify common mistakes and evaluate overall data quality. For instance, for the GSM8k benchmark, we found that some generated samples did not result in an integer answer, or the model used a rounding operation. These samples were removed by checking if the answer was an integer and ensuring no rounding was involved.

Post-processing was then applied to the synthetically generated benchmark samples. First, duplicates within the synthetic samples were removed by searching for high 1-gram overlap ratios between two samples. Second, we removed samples with a high 1-gram overlap ratio with the original benchmark samples, ensuring the synthetic samples were not too similar to the originals.

The system prompts used for the rephrased benchmarks and synthetic benchmarks are available in the code repository.

Finetuning We explain the finetuning process for the PHI-2 and LLAMA-2-INSTRUCT-7b models that were used in §4.2. We use the Hugging Face Transformers library [48] for the finetuning process.

Specifically, we applied full finetuning with batch size 16 and the Adam optimizer on different datasets and using different hyperparameters. We use the following default hyperparameters:

A learning rate of 5 · 10 -5 .

The dataset on which we train is the contaminatable part of a given benchmark.

We train for 5 epochs.

The prompt includes the exact few-shot samples used for evaluation.

We then train 8 other models where we always change specific parameters in this default setting. Specifically, we train models that diverge from the default setting in the following ways:

Instead of training with the exact samples from the benchmark, we train on the rephrased benchmark.

We change the learning rate to 10 -5 .

We change the learning rate to 10 -4 .

We only train for 1 epoch.

We train without any few-shot samples in the prompt.

We train with a random set of few-shot samples instead of the few-shot samples from the benchmark.

We do not include any few-shot samples in the prompt, include additional background instruction-tuning data from the OpenOrca dataset [32], and only train for 1 epoch.

We do the same as in the previous setting, with the additional change that we train on the rephrased benchmark instead of the actual one.

By including such a wide range of possible settings, we ensure that we cover a wide range of possible contamination effects. As can be seen in Fig. 2, the resulting models indeed show varying levels of contamination from 0% up to 80% .

Reference Models The following models were used as reference models in our experiments: PHI-2, PHI-3, LLAMA-2-7b, LLAMA-2-INSTRUCT-7b, LLAMA-2-13b, LLAMA-2-INSTRUCT-13b, LLAMA2-INSTRUCT-70b, LLAMA-3-8b, LLAMA-3-INSTRUCT-8b, LLAMA-3-70b, LLAMA-3-INSTRUCT70b, MISTRAL-7b-v0.1, MISTRAL-INSTRUCT-7b-v0.1, MISTRAL-INSTRUCT-7b-v0.2, MIXTRALINSTRUCT-8x7b, MIXTRAL-INSTRUCT-8x22b, FALCON-7b,FALCON-INSTRUCT-7b, GEMMA-1.17b, GEMMA-1.1-INSTRUCT-7b, OLMO-INSTRUCT-7b. As discussed in §4.3, we removed MISTRAL7b-v0.1 from the reference models after a contamination analysis.

Evaluation We evaluate the models with v0.4.1 of the LM Evaluation Harness [20]. We use 5 -shot evaluation for all models and provide the custom fork of the evaluation harness to allow for the evaluation on all the synthetic and rephrased benchmarks in our code repository.

Compute We spent around 300 USD on the OpenAI API to generate all benchmarks. Furthermore, we used a single Nvidia H100 GPU for around 1 month to finetune and evaluate all models. Finally, for models that were too large to fit on a single GPU, we used the Together API to run inference. We spent an additional 263 USD on this platform.

D Licensing Information

We include the license for all models, benchmarks and other assets used in this paper in Table 7.

E All Test Results

We present all results for each performed test in this section. Tables Table 8-Table 23 contain these results, grouped by model family.

NeurIPS Paper Checklist

1. Claims

Question: Do the main claims made in the abstract and introduction accurately reflect the paper's contributions and scope?

Answer: [Yes]

Justification: We show the effectiveness of our method in §4 and give a detailed analysis of the contamination of the model families mentioned in the abstract and introduction.

Guidelines:

The answer NA means that the abstract and introduction do not include the claims made in the paper.

The abstract and/or introduction should clearly state the claims made, including the contributions made in the paper and important assumptions and limitations. A No or NA answer to this question will not be perceived well by the reviewers.

The claims made should match theoretical and experimental results, and reflect how much the results can be expected to generalize to other settings.

It is fine to include aspirational goals as motivation as long as it is clear that these goals are not attained by the paper.

2. Limitations

Question: Does the paper discuss the limitations of the work performed by the authors?

Answer: [Yes]

Justification: In §6 we explicitly discuss the limitations of our approach.

Guidelines:

The answer NA means that the paper has no limitation while the answer No means that the paper has limitations, but those are not discussed in the paper.

The authors are encouraged to create a separate "Limitations" section in their paper.

The paper should point out any strong assumptions and how robust the results are to violations of these assumptions (e.g., independence assumptions, noiseless settings, model well-specification, asymptotic approximations only holding locally). The authors should reflect on how these assumptions might be violated in practice and what the implications would be.

The authors should reflect on the scope of the claims made, e.g., if the approach was only tested on a few datasets or with a few runs. In general, empirical results often depend on implicit assumptions, which should be articulated.

The authors should reflect on the factors that influence the performance of the approach. For example, a facial recognition algorithm may perform poorly when image resolution is low or images are taken in low lighting. Or a speech-to-text system might not be used reliably to provide closed captions for online lectures because it fails to handle technical jargon.

The authors should discuss the computational efficiency of the proposed algorithms and how they scale with dataset size.

If applicable, the authors should discuss possible limitations of their approach to address problems of privacy and fairness.

While the authors might fear that complete honesty about limitations might be used by reviewers as grounds for rejection, a worse outcome might be that reviewers discover limitations that aren't acknowledged in the paper. The authors should use their best judgment and recognize that individual actions in favor of transparency play an important role in developing norms that preserve the integrity of the community. Reviewers will be specifically instructed to not penalize honesty concerning limitations.

3. Theory Assumptions and Proofs

Question: For each theoretical result, does the paper provide the full set of assumptions and a complete (and correct) proof?

Answer: [NA]

Justification: We do not include any theoretical results in this paper. However, in §3 we do discuss how CONSTAT can be derived from statistical principles.

Guidelines:

The answer NA means that the paper does not include theoretical results.

All the theorems, formulas, and proofs in the paper should be numbered and crossreferenced.

All assumptions should be clearly stated or referenced in the statement of any theorems.

The proofs can either appear in the main paper or the supplemental material, but if they appear in the supplemental material, the authors are encouraged to provide a short proof sketch to provide intuition.

Inversely, any informal proof provided in the core of the paper should be complemented by formal proofs provided in appendix or supplemental material.

Theorems and Lemmas that the proof relies upon should be properly referenced.

4. Experimental Result Reproducibility

Question: Does the paper fully disclose all the information needed to reproduce the main experimental results of the paper to the extent that it affects the main claims and/or conclusions of the paper (regardless of whether the code and data are provided or not)?

Answer: [Yes]

Justification: We provide experimental details in §4 and App. C and publish the code for reproducing the results.

Guidelines:

The answer NA means that the paper does not include experiments.

If the paper includes experiments, a No answer to this question will not be perceived well by the reviewers: Making the paper reproducible is important, regardless of whether the code and data are provided or not.

If the contribution is a dataset and/or model, the authors should describe the steps taken to make their results reproducible or verifiable.

Depending on the contribution, reproducibility can be accomplished in various ways. For example, if the contribution is a novel architecture, describing the architecture fully might suffice, or if the contribution is a specific model and empirical evaluation, it may be necessary to either make it possible for others to replicate the model with the same dataset, or provide access to the model. In general. releasing code and data is often one good way to accomplish this, but reproducibility can also be provided via detailed instructions for how to replicate the results, access to a hosted model (e.g., in the case of a large language model), releasing of a model checkpoint, or other means that are appropriate to the research performed.

While NeurIPS does not require releasing code, the conference does require all submissions to provide some reasonable avenue for reproducibility, which may depend on the nature of the contribution. For example

(a) If the contribution is primarily a new algorithm, the paper should make it clear how to reproduce that algorithm.

(b) If the contribution is primarily a new model architecture, the paper should describe the architecture clearly and fully.

(c) If the contribution is a new model (e.g., a large language model), then there should either be a way to access this model for reproducing the results or a way to reproduce the model (e.g., with an open-source dataset or instructions for how to construct the dataset).

(d) We recognize that reproducibility may be tricky in some cases, in which case authors are welcome to describe the particular way they provide for reproducibility. In the case of closed-source models, it may be that access to the model is limited in some way (e.g., to registered users), but it should be possible for other researchers to have some path to reproducing or verifying the results.

5. Open access to data and code

Question: Does the paper provide open access to the data and code, with sufficient instructions to faithfully reproduce the main experimental results, as described in supplemental material?

Answer: [Yes]

Justification: We will publish the code to reproduce our results with clear instructions on how to reproduce them. We note that we will not include the synthetically generated benchmarks to avoid further contamination of LLMs. However, our code includes instructions on how to generate these benchmarks.

Guidelines:

The answer NA means that paper does not include experiments requiring code.

Please see the NeurIPS code and data submission guidelines ( https://nips.cc/ public/guides/CodeSubmissionPolicy ) for more details.

While we encourage the release of code and data, we understand that this might not be possible, so 'No' is an acceptable answer. Papers cannot be rejected simply for not including code, unless this is central to the contribution (e.g., for a new open-source benchmark).

The instructions should contain the exact command and environment needed to run to reproduce the results. See the NeurIPS code and data submission guidelines ( https: //nips.cc/public/guides/CodeSubmissionPolicy ) for more details.

The authors should provide instructions on data access and preparation, including how to access the raw data, preprocessed data, intermediate data, and generated data, etc.

The authors should provide scripts to reproduce all experimental results for the new proposed method and baselines. If only a subset of experiments are reproducible, they should state which ones are omitted from the script and why.

At submission time, to preserve anonymity, the authors should release anonymized versions (if applicable).

Providing as much information as possible in supplemental material (appended to the paper) is recommended, but including URLs to data and code is permitted.

6. Experimental Setting/Details

Question: Does the paper specify all the training and test details (e.g., data splits, hyperparameters, how they were chosen, type of optimizer, etc.) necessary to understand the results?

Answer: [Yes]

Justification: We provide an overview of the experimental setup in §4.1. Further details are provided in App. C.

Guidelines:

The answer NA means that the paper does not include experiments.

The experimental setting should be presented in the core of the paper to a level of detail that is necessary to appreciate the results and make sense of them.

The full details can be provided either with the code, in appendix, or as supplemental material.

7. Experiment Statistical Significance

Question: Does the paper report error bars suitably and correctly defined or other appropriate information about the statistical significance of the experiments?

Answer: [Yes]

Justification: CONSTAT is a statistical test and thus has a well-defined statistical significance which we always report in our experiments.

Guidelines:

The answer NA means that the paper does not include experiments.

The authors should answer "Yes" if the results are accompanied by error bars, confidence intervals, or statistical significance tests, at least for the experiments that support the main claims of the paper.

The factors of variability that the error bars are capturing should be clearly stated (for example, train/test split, initialization, random drawing of some parameter, or overall run with given experimental conditions).

The method for calculating the error bars should be explained (closed form formula, call to a library function, bootstrap, etc.)

The assumptions made should be given (e.g., Normally distributed errors).

It should be clear whether the error bar is the standard deviation or the standard error of the mean.

It is OK to report 1-sigma error bars, but one should state it. The authors should preferably report a 2-sigma error bar than state that they have a 96% CI, if the hypothesis of Normality of errors is not verified.

For asymmetric distributions, the authors should be careful not to show in tables or figures symmetric error bars that would yield results that are out of range (e.g. negative error rates).

If error bars are reported in tables or plots, The authors should explain in the text how they were calculated and reference the corresponding figures or tables in the text.

8. Experiments Compute Resources

Question: For each experiment, does the paper provide sufficient information on the computer resources (type of compute workers, memory, time of execution) needed to reproduce the experiments?

Answer: [Yes]

Justification: We give a brief explanation of the cost for reproducing our experiments in App. C. Our code also includes details on the computing resources needed.

Guidelines:

The answer NA means that the paper does not include experiments.

The paper should indicate the type of compute workers CPU or GPU, internal cluster, or cloud provider, including relevant memory and storage.

The paper should provide the amount of compute required for each of the individual experimental runs as well as estimate the total compute.

The paper should disclose whether the full research project required more compute than the experiments reported in the paper (e.g., preliminary or failed experiments that didn't make it into the paper).

9. Code Of Ethics

Question: Does the research conducted in the paper conform, in every respect, with the NeurIPS Code of Ethics https://neurips.cc/public/EthicsGuidelines ?

Answer: [Yes]

Justification: We confirm that all authors have read and understood the NeurIPS Code of Ethics and that the research conducted in this paper conforms to it.

Guidelines:

The answer NA means that the authors have not reviewed the NeurIPS Code of Ethics.

If the authors answer No, they should explain the special circumstances that require a deviation from the Code of Ethics.

The authors should make sure to preserve anonymity (e.g., if there is a special consideration due to laws or regulations in their jurisdiction).

10. Broader Impacts

Question: Does the paper discuss both potential positive societal impacts and negative societal impacts of the work performed?

Answer: [Yes]

Justification: We discuss the impact of this work in a separate paragraph in §6.

Guidelines:

The answer NA means that there is no societal impact of the work performed.

If the authors answer NA or No, they should explain why their work has no societal impact or why the paper does not address societal impact.

Examples of negative societal impacts include potential malicious or unintended uses (e.g., disinformation, generating fake profiles, surveillance), fairness considerations (e.g., deployment of technologies that could make decisions that unfairly impact specific groups), privacy considerations, and security considerations.

The conference expects that many papers will be foundational research and not tied to particular applications, let alone deployments. However, if there is a direct path to any negative applications, the authors should point it out. For example, it is legitimate to point out that an improvement in the quality of generative models could be used to generate deepfakes for disinformation. On the other hand, it is not needed to point out that a generic algorithm for optimizing neural networks could enable people to train models that generate Deepfakes faster.

The authors should consider possible harms that could arise when the technology is being used as intended and functioning correctly, harms that could arise when the technology is being used as intended but gives incorrect results, and harms following from (intentional or unintentional) misuse of the technology.

If there are negative societal impacts, the authors could also discuss possible mitigation strategies (e.g., gated release of models, providing defenses in addition to attacks, mechanisms for monitoring misuse, mechanisms to monitor how a system learns from feedback over time, improving the efficiency and accessibility of ML).

11. Safeguards

Question: Does the paper describe safeguards that have been put in place for responsible release of data or models that have a high risk for misuse (e.g., pretrained language models, image generators, or scraped datasets)?

Answer: [NA]

Justification: None of the data or models released in this paper pose a high risk for misuse.

Guidelines:

The answer NA means that the paper poses no such risks.

Released models that have a high risk for misuse or dual-use should be released with necessary safeguards to allow for controlled use of the model, for example by requiring that users adhere to usage guidelines or restrictions to access the model or implementing safety filters.

Datasets that have been scraped from the Internet could pose safety risks. The authors should describe how they avoided releasing unsafe images.

We recognize that providing effective safeguards is challenging, and many papers do not require this, but we encourage authors to take this into account and make a best faith effort.

12. Licenses for existing assets

Question: Are the creators or original owners of assets (e.g., code, data, models), used in the paper, properly credited and are the license and terms of use explicitly mentioned and properly respected?

Answer: [Yes]

Justification: We provide the necessary licenses and terms of use in App. D. We obliged by all these licenses.

Guidelines:

The answer NA means that the paper does not use existing assets.

The authors should cite the original paper that produced the code package or dataset.

The authors should state which version of the asset is used and, if possible, include a URL.

The name of the license (e.g., CC-BY 4.0) should be included for each asset.

For scraped data from a particular source (e.g., website), the copyright and terms of service of that source should be provided.

If assets are released, the license, copyright information, and terms of use in the package should be provided. For popular datasets, paperswithcode.com/datasets has curated licenses for some datasets. Their licensing guide can help determine the license of a dataset.

For existing datasets that are re-packaged, both the original license and the license of the derived asset (if it has changed) should be provided.

If this information is not available online, the authors are encouraged to reach out to the asset's creators.

13. New Assets

Question: Are new assets introduced in the paper well documented and is the documentation provided alongside the assets?

Answer: [Yes]

Justification: We release our code with an Apache-2.0 License. We provide a README file with instructions on how to use our code and generate the benchmarks.

Guidelines:

The answer NA means that the paper does not release new assets.

Researchers should communicate the details of the dataset/code/model as part of their submissions via structured templates. This includes details about training, license, limitations, etc.

The paper should discuss whether and how consent was obtained from people whose asset is used.

At submission time, remember to anonymize your assets (if applicable). You can either create an anonymized URL or include an anonymized zip file.

14. Crowdsourcing and Research with Human Subjects

Question: For crowdsourcing experiments and research with human subjects, does the paper include the full text of instructions given to participants and screenshots, if applicable, as well as details about compensation (if any)?

Answer: [NA]

Justification: We do not include crowdsourcing experiments or research with human subjects in this paper.

Guidelines:

The answer NA means that the paper does not involve crowdsourcing nor research with human subjects.

Including this information in the supplemental material is fine, but if the main contribution of the paper involves human subjects, then as much detail as possible should be included in the main paper.

According to the NeurIPS Code of Ethics, workers involved in data collection, curation, or other labor should be paid at least the minimum wage in the country of the data collector.

15. Institutional Review Board (IRB) Approvals or Equivalent for Research with Human Subjects

Question: Does the paper describe potential risks incurred by study participants, whether such risks were disclosed to the subjects, and whether Institutional Review Board (IRB) approvals (or an equivalent approval/review based on the requirements of your country or institution) were obtained?

Answer: [NA]

Justification: We do not include crowdsourcing experiments or research with human subjects in this paper.

Guidelines:

The answer NA means that the paper does not involve crowdsourcing nor research with human subjects.

Depending on the country in which research is conducted, IRB approval (or equivalent) may be required for any human subjects research. If you obtained IRB approval, you should clearly state this in the paper.

We recognize that the procedures for this may vary significantly between institutions and locations, and we expect authors to adhere to the NeurIPS Code of Ethics and the guidelines for their institution.

For initial submissions, do not include any information that would break anonymity (if applicable), such as the institution conducting the review.

Peer reviews:
{"IS_META_REVIEW": false, "comments": "SUMMARY:\nAuthors propose a new definition of contamination: \"artificially inflated and non-generalizing benchmark performance\" rather than \"the inclusion of benchmark samples in the training data\". They develop ConStat, a statistical method that reliably detects and quantifies contamination by comparing performance between a primary and reference benchmark relative to a set of reference models.  They demonstrate the effectiveness of ConStat through an evaluation of diverse model architectures, benchmarks, and contamination scenarios, and find high levels of contamination in multiple popular models.\n\nSTRENGTHS:\n•\tA new method to detect benchmark contamination from a new perspective\n\n•\tGreat performance on syntax and sample-specific contaminated models\n\n•\tGood motivation, presentation and organisation\n\nWEAKNESSES:\n•\tThe paper uses reference datasets that are synthetically composed, authors briefly comment on this in the limitations. More ellaboration on this is need it since it is one of the basis of the experiments. Authors could potentially estimate by human analysis what is the expected error on their approach.\n\n•\tBenchmark-specific contamination is complex and it is not covered with enough in-depth.\n\nQUESTIONS:\n•\tThere is a short paragraph explaining results on benchmark-specific contamination, could authors elaborate more? How does it compare to other methods?\n\n•\tSome statements need clarification, e.g.\n“MathQA is a multiple-choice benchmark that requires the model  to answer immediately and therefore gives no room for this reasoning ability to shine.” ->•\tThere is a section on exposing the limitations. Maybe authors could further comment on the limitation of experiments due to computational complexity. what does it mean that requires the model to answer immediately? Could authors further support “no room for this reasoning ability to shine”\n\nLIMITATIONS:\n•\tThere is a section on exposing the limitations. Maybe authors could further comment on the limitation of experiments due to computational complexity.", "TITLE": "Official Review", "RECOMMENDATION": 6, "REVIEWER_CONFIDENCE": 3, "SOUNDNESS_CORRECTNESS": 2, "DATE": "2024-07-02"}

{"IS_META_REVIEW": false, "comments": "SUMMARY:\nThe paper proposes a performance-based approach to detect data contamination in large language models. First, a set of reference models is evaluated on the original benchmark and a proxy of it. Next, a difficulty correction function is fitted to find the relationship between the performance from the original benchmark and the proxy benchmark. Then, the performance of a target model is evaluated on the proxy benchmark, and using the correction function, the expected performance on the original benchmark is predicted. Lastly, the difference between the actual performance on the original benchmark and the expected performance is computed and checked for significance to label the target model as contaminated.\n\nSTRENGTHS:\n1. The paper is well-written.\n2. The experiments are comprehensive.\n3. The proposed method can be used with both open-weight and closed-weight models, which is important.\n\nWEAKNESSES:\n1. The main weakness of the proposed method is that it identifies data contamination based on changes in performance. Performance can change for several reasons, so it cannot be solely the indicator of contamination. In fact, the method assumes that any performance increase means contamination, leading to a high rate of false positives in situations where performance improvements come from other sources. For example, this method incorrectly detects contamination when performance improves due to unsupervised domain adaptation while it is not.\n\n2. This method can only be applied to models that are similar to the reference models, especially in terms of size, architecture, and pre-training data, as it detects contamination with respect to these reference models. This limits its generality and makes it unsuitable for models that differ from the reference set. For example, if a target model just generalizes better than the reference models, the method incorrectly identifies this as contamination. Conversely, a contaminated model can be deemed uncontaminated if it cannot translate the contamination into improved performance, e.g., when a model is contaminated with a dataset but cannot follow instructions very well. Therefore, the proposed method measures the lack of generalization relative to the reference models rather than actual contamination. In short, this method does not guarantee whether a model has seen the datasets or not.\n\n3. Building on the previous comment, this method does not actually measure contamination; it captures situations where excessive memorization has replaced generalization. In fact, the scenarios discussed in Section 2.2 **are not types of contamination**. Instead, they are examples of excessive memorization, which the method captures.\n \n4. The results of the proposed method are relative, not absolute. In this method, detection is only meaningful when compared to the reference models. So, if the reference models are contaminated, the target model will still appear uncontaminated.\n\nQUESTIONS:\n**Question:**\n1. In Table 1, what is the difference between \"Shi et al. [40]\" and \"Shi [39]\"?\n\n**Comment:**\n1. Lines 11-14 and 343-345: Your method does not quantify/measure contamination.\n\nLIMITATIONS:\n1. The outcomes cannot be interpreted individually. Specifically, detection heavily depends on the reference models and how they generalize/behave. This means that better generalization or steerability in models can be mistaken for contamination. Also, if the reference models are contaminated, this contamination can spread to the target models and go undetected.\n2. The proposed method does not detect contamination, as none of the scenarios studied in Section 2.2 involve contamination. Instead, the method captures the lack of generalization or situations with excessive memorization.", "TITLE": "Official Review", "RECOMMENDATION": 5, "REVIEWER_CONFIDENCE": 4, "SOUNDNESS_CORRECTNESS": 2, "DATE": "2024-07-10"}

{"IS_META_REVIEW": false, "comments": "SUMMARY:\nThe authors introduce a definition for “contamination” based on its outcome rather than its cause, unlike many previous approaches. The authors propose ConStat, a novel method for quantifying the contamination of a model on some benchmark and demonstrate that it outperforms other methodologies for detecting contamination.\n\nSTRENGTHS:\n- This paper was a pleasure to read. It is both written and structured in a clear way that communicates the ideas well\n- The authors used ConStat to show strong contamination of some models from the Open LLM Leaderboard on specific benchmarks. This research can be used to build trust in our evaluations\n\nWEAKNESSES:\nThe authors generated a synthetic version of each benchmark they used in their experiments. They described their methodology for doing so in Appendix C. I don’t believe the authors used a sufficiently rigorous method to ensure this generated dataset was sufficiently high-quality. For example, it is possible that some of their samples did not have a high 1-gram overlap but did ask similar questions. I believe a manual review of a subset of the dataset for duplication, and perhaps other traits, would be necessary to guarantee data quality. Though I view this as a minor weakness given that their methodology was successful despite potential problems with this dataset.\n\nQUESTIONS:\n1. Why did the authors not select a reference benchmark for MMLU?\n2. Do the authors believe this methodology will work well when the measured task between the benchmark and reference benchmark is similar (e.g. coding) but the \"form\" between the benchmark and reference benchmark is significantly different, for example, multiple choice question answering evaluation vs. open-ended agentic evaluation?\n3. What further research are the authors excited to see in this area? Are the authors planning on discussing this within the paper?\n\nLIMITATIONS:\nThe authors sufficiently address this.", "TITLE": "Official Review", "RECOMMENDATION": 8, "REVIEWER_CONFIDENCE": 3, "SOUNDNESS_CORRECTNESS": 3, "DATE": "2024-07-11"}

{"IS_META_REVIEW": false, "comments": "SUMMARY:\nThis paper targets the problem of contamination detection of LLMs by proposing ConStat, a performance-based statistical approach. \n- Instead of detecting the inclusion of test samples as contamination, the authors define interpretation as \"abnormal\" performance on benchmarks.\n- ConStat builds on this definition, and leverages reference models and synthetic benchmarks for statistical testing at syntax-, sample-, and benchmark-specific levels.\n- ConStat is empirically verified as effective. The authors also provide comprehensive analyses.\n\nSTRENGTHS:\n- The definition of contamination from a performance-based perspective is novel and interesting to my knowledge.\n- Based on the definition, the proposed ConStat is intuitive and looks effective based on experiments. The experiments and analyses are comprehensive and solid.\n- Contamination detection is timely and important in the current community.\n- The paper is well-written and a joy to read.\n\nWEAKNESSES:\n- As the paper discussed in Section 6, it can only estimate the contamination relative to reference models. \n- It would be a little costly to construct a synthetic dataset using close-sourced LLMs each time we want to detect contamination of a specific benchmark.\n- This paper lacks some related works that need to be discussed. I just list a few below.\n\n[1] Yang, Shuo, et al. \"Rethinking benchmark and contamination for language models with rephrased samples.\" arXiv preprint arXiv:2311.04850 (2023).\n\n[2] Jiang, Minhao, et al. \"Investigating data contamination for pre-training language models.\" arXiv preprint arXiv:2401.06059 (2024).\n\nQUESTIONS:\n- According to lines 1118-1120, it seems that the authors only used 1000 samples for fine-tuning. How is this number determined and will the number of chosen samples affect the performance? if so, how?\n- The above question applies to the number of synthetic data samples.\n\nLIMITATIONS:\nThe authors offered a limitation paragraph in Section 6.", "TITLE": "Official Review", "RECOMMENDATION": 6, "REVIEWER_CONFIDENCE": 3, "SOUNDNESS_CORRECTNESS": 3, "DATE": "2024-07-13"}

{"IS_META_REVIEW": false, "comments": "SUMMARY:\nThe paper introduces a new performance-based definition of data contamination, shifting the focus from the cause of contamination to its effect on performance. The paper also presents ConStat, a statistical method that detects and quantifies contamination by comparing performance on primary and reference benchmarks using a set of reference models. The effectiveness of ConStat is demonstrated through extensive evaluations on diverse model architectures, benchmarks, and contamination scenarios, revealing significant contamination in several popular models.\n\nSTRENGTHS:\n1. The motivation for proposing new definition of contamination is clear and easy to understand.\n2. The experiments are extensive to demonstrate the effectiveness of the proposed method. It shows that ConStat can outperform the previous methods on contamination detection and is effective for contamination quantification.\n3. The paper extends the analysis to the current model families to show that these models are contaminated in different degrees for current benchmarks. And the observation basically matches other papers' findings, suggesting that these methods can be potentially used for contamination examination of LLMs in the future applications.\n\nWEAKNESSES:\n1. The assumptions in the paper are too strong for me. I don't think the difference of performance in different benchmarks means that there would be contamination. The abnormal high performance in one dataset but normal performance in other benchmarks only imply higher possibility of contamination.\n2. On line 152, the authors mentioned \"additionally include an inherently uncontaminated random-guessing model\". I wonder if more details could be provided about this.\n3. I think the descriptions and writings in the methodology section should be re-written to provide more details and motivations for how the method is developed. The current version is somewhat hard to follow and lacks explanations.\n4. Missing citations to many recent works. E.g., https://arxiv.org/abs/2311.04850 (Yang et al.), https://arxiv.org/abs/2401.06059 (Jiang et al.), etc.\n\nQUESTIONS:\nSee the weaknesses above.\n\nLIMITATIONS:\nYes, the authors included a limitations sections.", "TITLE": "Official Review", "RECOMMENDATION": 5, "REVIEWER_CONFIDENCE": 4, "SOUNDNESS_CORRECTNESS": 3, "DATE": "2024-07-13"}