This page presents the average per-position byte compression rate, demonstrating the long-context capabilities of the models.

Calculated at the byte level, these metrics allow for direct comparison across different tokenizers.

Benchmarks utilize the UncheatableEval-Long dataset series, with sequence lengths extending up to 32k characters.

Compression Ratio Scaling Law

Explore how compression ratio scales with model parameters across different datasets.

Uncheatable Eval

GitHub page: https://github.com/Jellyfish042/uncheatable_eval

Dataset page: https://huggingface.co/collections/Jellyfish042/uncheatableeval

Introduction

Traditional LLM benchmarks are easily compromised by unintentional or intentional data leakage, making many benchmarks unreliable and unable to truly reflect the capabilities of LLMs.

Uncheatable Eval addresses this issue by testing LLMs on real-time, newly generated data from the internet, ensuring that the evaluation is immune to data leaks and cannot be gamed.

How?

Uncheatable Eval assesses the language modeling capabilities of LLMs on new data from various sources such as recent papers on arXiv, new projects on GitHub, news articles, and more. Since this data is brand new (e.g., from the past 1-2 weeks), it is impossible for these data to be included in the training sets of publicly released models, thus avoiding the impact of unintentional or intentional data leaks.

Specifically, we calculate the sum of negative log probabilities of the models on these texts. In other words, models that are more likely to generate these texts are considered better.

Note : Uncheatable Eval only tests base models.

Q&A

Why Calculate the Sum of Negative Log Probabilities?

First, the goal of language models, at least today's language models, is to generate text that is as realistic as possible, maximizing the probability of real text. They are trained and designed to do exactly this. Calculating the sum of negative log probabilities on real text is the most direct way to test this capability.

Second, from the perspective of "compression is intelligence," a good way to test a language model would be to use the model with an entropy coding algorithm for compression and test the model's compression rate [1][2]. A model with a lower compression rate is considered better. Using a language model + arithmetic coding as an example, it is easy to prove that a model's ability to compress a piece of text is proportional to the sum of its negative log probabilities on that text (see proof). Therefore, the compression rate of a model can be directly calculated through the sum of negative log probabilities, and the method for this has been provided in show_results_v2.ipynb.

Can Models Using Different Tokenizers Be Directly Compared?

Yes. When calculating the sum of negative log probabilities, we essentially treat the model + tokenizer as a single entity or system. As long as this system has a high probability of generating real text, we consider it better. From the perspective of compression, you can choose any tokenizer. From the compression rate perspective, we don't care; we only care about whether your system can compress the text more effectively.

Enter a public HF repo id, then hit Submit to add it to the evaluation queue.