{
  "source_file": "0930",
  "source_platform": "个人博客",
  "author": "Sebastian Ruder",
  "title_listed": "The Evolving Landscape of LLM Evaluation",
  "keywords": "LLM评估,基准,评测",
  "domain": "大模型算法",
  "content_type": "深度技术解析",
  "is_paid_flag": "否",
  "url": "https://www.ruder.io/the-evolving-landscape-of-llm-evaluation/",
  "publish_date": "2024-05",
  "corpus_stage": "推理部署",
  "notes": "LLM评估体系演进与基准危机",
  "id": "1950092ff420",
  "collected_at": "2026-10-02T14:15:18",
  "title": "The Evolving Landscape of LLM Evaluation",
  "body_markdown": "evaluation\nThe Evolving Landscape of LLM Evaluation\nThis post explores problems contributing to a benchmark crisis in LLM evaluation and potential solutions.\nSebastian Ruder\n13 May 2024\n•\n5 min read\nShare\nRecent models have been observed to overfit to evaluation benchmarks such as GMS8k (lower is worse;\nZhang et al., 2024\n).\nThroughout recent years, LLM capabilities have outpaced evaluation benchmarks. This is\nnot a new development\n. The set of canonical LLM evals has further narrowed to a small set of benchmarks such as\nMMLU\nfor general natural language understanding,\nGMS8k\nfor mathematical reasoning, and\nHumanEval\nfor code, among others. Recently, concerns regarding the reliability of even this small set of benchmarks have emerged.\n\"Datasets are the telescopes of our field.\"—\nAravind Joshi\nWithout reliable benchmarks, we are effectively flying blind. With many public benchmarks no longer seen as hallmarks of objectivity, ML researchers and practitioners increasingly rely on their intuition to assess a model’s ‘vibe’, i.e., how interactions with it\nfeel\nlike. Let’s explore how we got here and what the path forward may look like.\nThis post was first published in\nNLP News\n.\nLooking Back on Benchmarking\nBenchmarks have been integral to the development of ML and NLP (see\nmy previous post\nfor a brief history of ML benchmarking). Break-through architectures such as\nResNets\nor\nTransformers\nfirst captured people’s attention through their impressive ImageNet and WMT results respectively. Benchmarks such as\nMNIST\n,\nCIFAR-100\n, and\nImageNet\nhave been around for more than a decade and are still used to date.\nIn recent years, in light of rapidly improving model capabilities, the time between a benchmark’s creation to its saturation—when model performance exceeds human performance—has dramatically reduced.\nBenchmark saturation over time for popular benchmarks. Initial performance and human performance are normalised to -1 and 0 respectively (\nKiela et al., 2021\n). Performance on MNIST and Switchboard saturated only after 20+ years while performance on GLUE and SQuAD 2.0 saturated already within 1–2 years.\nIn addition to recent benchmarks more quickly saturating, two additional problems are contributing to the current benchmark crisis: memorization and overfitting.\nMemorization\nMost popular benchmarks are either directly available on the web or may have been uploaded in different forms on GitHub or other platforms. Current models are trained on much of the Internet, with newer models trained on more recent snapshots of CommonCrawl. Unless filtering measures are taken to specifically remove benchmark data from pre-training, models are invariably exposed to test data through their pre-training. While they may not memorize every example, training on the data makes it more likely for the model to produce the correct prediction.\nAs a result, LLMs including Aquila2 and Qwen models\nrepeat verbatim training and even test examples from MATH and GSM8k\n. GPT models perform much better on coding problems\nreleased before their pre-training data cut-off\n. LLMs also\nperform much better on datasets released before the pre-training data cut-off\n—and barely improve over a majority baseline (!) on uncontaminated classification tasks in zero and few-shot settings.\nWhat can we do to mitigate memorization?\nRavaut et al. (2024)\nhighlight some best practices to reduce contamination in their survey:\nEncrypting evaluation datasets\n. The authors of the\nMTOB\ndataset (discussed in a\nprevious newsletter\n) did this. The downside: if the dataset is shared unencrypted at any point, it is hard to contain it again.\nScanning newly released evaluation datasets\n. We can make sure to only evaluate on uncontaminated data.\nPreventing data leakage to closed-source APIs\n. Evaluating on closed-source APIs inadvertently leaks data to them whether or not the data is made available online or not.\nOverfitting\nWith increased attention afforded to LLMs and billions of dollars in funding at play, the pressure to do well on public benchmarks has increased. A couple percentage points on an established benchmark such as\nMMLU\ncan make or break an investor presentation or convince potential customers to try a model.\nAs a result, there is the risk of overfitting to public benchmarks if models are optimized to do well on them. One way of overfitting is through the creation of synthetic data, which may inadvertently reflect use cases in the test data rather than a broader set of model applications. For example,\na recent study\nfound that several model families such as Phi and Mistral models show evidence of systematic overfitting on the GSM8k grade school math dataset.\nModels arranged by their drop in performance between GSM8k and the newly created GSM1k (lower is worse). Mistral and Phi models show a drop of 10% on GSM1k compared to GSM8k (\nZhang et al., 2024\n).\nFor benchmarks such as\nMT-Bench\nthat employ a specific model (often GPT4) as evaluator, there is the additional risk of overfitting to biases of the evaluator. If we optimize our model to do well on MT-Bench, we may end up training on GPT4-created data. This can lead to higher scores on GPT4-rated evals but worse performance when tested by humans as models\nmimic GPT4’s style but not other aspects such as its factuality\n.\nTraining on such model-created synthetic data may thus lead to gains and improve evals in the short term; in the long term, it can lead to unanticipated biases and blind spots in the user experience. Taking into account the possibility of both memorization and overfitting, the results on popular static evaluation benchmarks should be taken with a grain of salt.\nTo Vibe or Not to Vibe?\nInstead of blindly trusting public benchmarks or result tables in press releases, it is thus more important than ever to run your own tests. LLMs are versatile and different people have different preferences and use cases.\nUtility is in the eye of the user\n. However, very few have the means to exhaustively evaluate and compare many different LLMs.\nThe currently preferred evaluation benchmark for such ‘vibe-based’ evals is\nChatbot Arena\n, which crowd-sources user ratings in blind A/B test conversations with various LLMs. The platform enables large-scale user testing and aggregates win rates across 10,000s of conversations in a central leaderboard.\nChatbot Arena is not perfect. Humans can get fooled and may prefer a response due to a variety of factors including its formatting, style, type of humor, etc, which can be exploited and optimized for. Chatbot Arena covers a narrow range of domains and conversations vary wildly in quality. Nevertheless, it provides an uncontaminated evaluation of chat user interactions (I’ve\nwritten previously\nabout it); you can also check out\nNathan Lambert\n’s thoughts on Chatbot Arena in\nhis recent post\n.\nThe Future of Evaluation\nThe time when benchmarks lasted multiple decades has passed. Going forward, we will rely less on public benchmark results. Instead, the\nability to evaluate a model directly for a specific downstream use case will be much more important\n.\nThis requires\na) knowledge on how to efficiently and robustly evaluate LLMs\n;\nb) the infrastructure\nto enable this; and\nc) domain expertise\nto know how the problem can be modeled using an LLM. Institutions will be less likely to share such evals given that a release means they will become contaminated, reducing their usefulness.\nBenchmark creators should mitigate the risk of contamination\nin the design of their test data as much as possible.\nInternet data should be used sparingly\n—and not as the source of the solution.\nNew benchmark data should ideally be created by humans\nfrom scratch.\nAs we already evaluate LLMs how we assess humans—on standardized exams and general aptitude and proficiency tests—\nwe should also follow a similar design process for future LLM evals: With regularly updated tests, assuming access to all prior exam data and accounting for a willingness to exploit loopholes\n.\nOverall, we need to rethink the way we evaluate LLMs and shift to efficient evaluation processes that can keep track with the pace of model advances.",
  "metadata": {
    "title": "The Evolving Landscape of LLM Evaluation",
    "description": "This post explores problems contributing to a benchmark crisis in LLM evaluation and potential solutions.",
    "keywords": null,
    "author": null,
    "og:site_name": "ruder.io",
    "og:type": "article",
    "og:title": "The Evolving Landscape of LLM Evaluation",
    "og:description": "This post explores problems contributing to a benchmark crisis in LLM evaluation and potential solutions.",
    "og:url": "https://www.ruder.io/the-evolving-landscape-of-llm-evaluation/",
    "og:image": "https://storage.ghost.io/c/bd/89/bd89d480-b8e0-47e6-8bae-dcb0d061b8d7/content/images/size/w1200/2024/10/gsm8k_vs_gsm1k.jpg",
    "og:image:width": "1200",
    "og:image:height": "647",
    "twitter:card": "summary_large_image",
    "twitter:title": "The Evolving Landscape of LLM Evaluation",
    "twitter:description": "This post explores problems contributing to a benchmark crisis in LLM evaluation and potential solutions.",
    "twitter:url": "https://www.ruder.io/the-evolving-landscape-of-llm-evaluation/",
    "twitter:image": "https://storage.ghost.io/c/bd/89/bd89d480-b8e0-47e6-8bae-dcb0d061b8d7/content/images/size/w1200/2024/10/gsm8k_vs_gsm1k.jpg",
    "twitter:label1": "Written by",
    "twitter:data1": "Sebastian Ruder",
    "twitter:label2": "Filed under",
    "twitter:data2": "evaluation, llms",
    "twitter:site": "@seb_ruder",
    "article:published_time": "2024-05-13T09:48:00.000Z",
    "article:modified_time": "2024-10-24T09:51:59.000Z",
    "article:tag": "llms"
  },
  "paywall": {
    "listed_paid": false,
    "detected": false,
    "marker": "",
    "public_only": false,
    "policy": "付费/会员内容只保留页面公开可见部分，不绕过付费墙"
  },
  "crawl": {
    "success": true,
    "status_code": 200,
    "error": ""
  },
  "code_blocks": [],
  "images": [
    {
      "status": "ok",
      "url": "https://storage.ghost.io/c/bd/89/bd89d480-b8e0-47e6-8bae-dcb0d061b8d7/content/images/size/w2000/2024/10/gsm8k_vs_gsm1k.jpg",
      "bytes": 136445,
      "reused": true,
      "local_path": "attachments/1950092ff420/images/001.jpg",
      "src": "https://storage.ghost.io/c/bd/89/bd89d480-b8e0-47e6-8bae-dcb0d061b8d7/content/images/size/w2000/2024/10/gsm8k_vs_gsm1k.jpg",
      "alt": "The Evolving Landscape of LLM Evaluation",
      "downloaded": true
    },
    {
      "status": "ok",
      "url": "https://substackcdn.com/image/fetch/w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F7ada3dd7-cff8-4c63-b582-7686d31f5e20_2046x984.png",
      "bytes": 60306,
      "reused": true,
      "local_path": "attachments/1950092ff420/images/005.png",
      "src": "https://substackcdn.com/image/fetch/w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F7ada3dd7-cff8-4c63-b582-7686d31f5e20_2046x984.png",
      "alt": "",
      "downloaded": true
    },
    {
      "status": "ok",
      "url": "https://substackcdn.com/image/fetch/w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fe92dc248-5d16-43b1-81db-02616bce3e58_2384x1286.png",
      "bytes": 191169,
      "reused": true,
      "local_path": "attachments/1950092ff420/images/006.png",
      "src": "https://substackcdn.com/image/fetch/w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fe92dc248-5d16-43b1-81db-02616bce3e58_2384x1286.png",
      "alt": "",
      "downloaded": true
    }
  ],
  "audio": [],
  "videos": [
    {
      "url": "https://www.youtube.com/watch?v=t_A36DDcG_0",
      "status": "ok",
      "local_path": "attachments/1950092ff420/videos/t_A36DDcG_0.mp4",
      "bytes": 83073327,
      "valid": true,
      "height": 1080,
      "width": 1920,
      "duration": "2755.941000"
    }
  ],
  "links": [
    {
      "href": "https://www.ruder.io/tag/evaluation/",
      "label": "evaluation",
      "type": "a"
    },
    {
      "href": "https://www.ruder.io/author/sebastian/",
      "label": "",
      "type": "a"
    },
    {
      "href": "https://arxiv.org/abs/2405.00332",
      "label": "Zhang et al., 2024",
      "type": "a"
    },
    {
      "href": "https://www.ruder.io/nlp-benchmarking/",
      "label": "not a new development",
      "type": "a"
    },
    {
      "href": "https://arxiv.org/abs/2009.03300?ref=ruder.io",
      "label": "MMLU",
      "type": "a"
    },
    {
      "href": "https://arxiv.org/abs/2110.14168?ref=ruder.io",
      "label": "GMS8k",
      "type": "a"
    },
    {
      "href": "https://arxiv.org/abs/2107.03374?ref=ruder.io",
      "label": "HumanEval",
      "type": "a"
    },
    {
      "href": "https://youtu.be/t_A36DDcG_0?t=964&ref=ruder.io",
      "label": "Aravind Joshi",
      "type": "a"
    },
    {
      "href": "https://newsletter.ruder.io/p/the-evolving-landscape-of-llm-evaluation?ref=ruder.io",
      "label": "NLP News",
      "type": "a"
    },
    {
      "href": "https://arxiv.org/abs/1512.03385?ref=ruder.io",
      "label": "ResNets",
      "type": "a"
    },
    {
      "href": "https://arxiv.org/abs/1706.03762https://arxiv.org/abs/1706.03762?ref=ruder.io",
      "label": "Transformers",
      "type": "a"
    },
    {
      "href": "https://paperswithcode.com/dataset/mnist?ref=ruder.io",
      "label": "MNIST",
      "type": "a"
    },
    {
      "href": "https://paperswithcode.com/dataset/cifar-100?ref=ruder.io",
      "label": "CIFAR-100",
      "type": "a"
    },
    {
      "href": "https://paperswithcode.com/dataset/imagenet?ref=ruder.io",
      "label": "ImageNet",
      "type": "a"
    },
    {
      "href": "https://aclanthology.org/2021.naacl-main.324.pdf?ref=ruder.io",
      "label": "Kiela et al., 2021",
      "type": "a"
    },
    {
      "href": "https://arxiv.org/abs/2404.18824?ref=ruder.io",
      "label": "repeat verbatim training and even test examples from MATH and GSM8k",
      "type": "a"
    },
    {
      "href": "https://arxiv.org/abs/2310.10628?ref=ruder.io",
      "label": "released before their pre-training data cut-off",
      "type": "a"
    },
    {
      "href": "https://arxiv.org/abs/2312.16337?ref=ruder.io",
      "label": "perform much better on datasets released before the pre-training data cut-off",
      "type": "a"
    },
    {
      "href": "https://arxiv.org/abs/2404.00699?ref=ruder.io",
      "label": "Ravaut et al. (2024)",
      "type": "a"
    },
    {
      "href": "https://arxiv.org/abs/2309.16575?ref=ruder.io",
      "label": "MTOB",
      "type": "a"
    },
    {
      "href": "https://newsletter.ruder.io/p/true-zero-shot-mt?ref=ruder.io",
      "label": "previous newsletter",
      "type": "a"
    },
    {
      "href": "https://arxiv.org/pdf/2009.03300?ref=ruder.io",
      "label": "MMLU",
      "type": "a"
    },
    {
      "href": "https://arxiv.org/abs/2405.00332?ref=ruder.io",
      "label": "a recent study",
      "type": "a"
    },
    {
      "href": "https://arxiv.org/abs/2306.05685?ref=ruder.io",
      "label": "MT-Bench",
      "type": "a"
    },
    {
      "href": "https://arxiv.org/abs/2305.15717?ref=ruder.io",
      "label": "mimic GPT4’s style but not other aspects such as its factuality",
      "type": "a"
    },
    {
      "href": "https://aclanthology.org/2020.emnlp-main.393/?ref=ruder.io",
      "label": "Utility is in the eye of the user",
      "type": "a"
    },
    {
      "href": "https://chat.lmsys.org/?ref=ruder.io",
      "label": "Chatbot Arena",
      "type": "a"
    },
    {
      "href": "https://newsletter.ruder.io/p/command-r?ref=ruder.io",
      "label": "written previously",
      "type": "a"
    },
    {
      "href": "https://open.substack.com/users/10472909-nathan-lambert?utm_source=mentions",
      "label": "Nathan Lambert",
      "type": "a"
    },
    {
      "href": "https://www.interconnects.ai/p/chatbotarena-the-future-of-llm-evaluation?ref=ruder.io",
      "label": "his recent post",
      "type": "a"
    }
  ],
  "repair_version": 2,
  "repaired_at": "2026-10-14T10:51:56Z",
  "source_url": "https://www.ruder.io/the-evolving-landscape-of-llm-evaluation/",
  "papers": [
    {
      "status": "ok",
      "url": "https://arxiv.org/pdf/2405.00332",
      "bytes": 7180592,
      "reused": false,
      "local_path": "papers/repair/c33ef96055660e965a1b.pdf"
    },
    {
      "status": "ok",
      "url": "https://arxiv.org/pdf/2009.03300",
      "bytes": 2074939,
      "reused": true,
      "local_path": "papers/repair/eabe88a3d618ccd5d1e4.pdf"
    },
    {
      "status": "ok",
      "url": "https://arxiv.org/pdf/2110.14168",
      "bytes": 2935719,
      "reused": true,
      "local_path": "papers/repair/24399c3ca2bf9370f2d9.pdf"
    },
    {
      "status": "ok",
      "url": "https://arxiv.org/pdf/2107.03374",
      "bytes": 1885177,
      "reused": true,
      "local_path": "papers/repair/c41850b212e88f282029.pdf"
    },
    {
      "status": "ok",
      "url": "https://arxiv.org/pdf/1512.03385",
      "bytes": 819383,
      "reused": true,
      "local_path": "papers/repair/523013cf51110acbfe60.pdf"
    },
    {
      "status": "http_404",
      "url": "https://arxiv.org/pdf/1706.03762https://arxiv.org/abs/1706.03762",
      "retried_at": "2026-10-20T17:40:14Z"
    },
    {
      "status": "ok",
      "url": "https://aclanthology.org/2021.naacl-main.324.pdf?ref=ruder.io",
      "bytes": 480678,
      "reused": false,
      "local_path": "papers/repair/43864c278284d54a6b91.pdf"
    },
    {
      "status": "ok",
      "url": "https://arxiv.org/pdf/2404.18824",
      "bytes": 745747,
      "reused": false,
      "local_path": "papers/repair/4a877ea8c6ec57ac53bf.pdf"
    },
    {
      "status": "ok",
      "url": "https://arxiv.org/pdf/2310.10628",
      "bytes": 3360600,
      "reused": false,
      "local_path": "papers/repair/7e0e4b2320d9c83e0122.pdf"
    },
    {
      "status": "ok",
      "url": "https://arxiv.org/pdf/2312.16337",
      "bytes": 666527,
      "reused": true,
      "local_path": "papers/repair/17e300bc6a50846edb39.pdf"
    },
    {
      "status": "ok",
      "url": "https://arxiv.org/pdf/2404.00699",
      "bytes": 821144,
      "reused": false,
      "local_path": "papers/repair/66b3df81b896ba5eb7b7.pdf"
    },
    {
      "status": "ok",
      "url": "https://arxiv.org/pdf/2309.16575",
      "bytes": 402284,
      "reused": false,
      "local_path": "papers/repair/c0d0c409fb80f4e43987.pdf"
    },
    {
      "status": "ok",
      "url": "https://arxiv.org/pdf/2009.03300?ref=ruder.io",
      "bytes": 2074939,
      "reused": false,
      "local_path": "papers/repair/e24a8b645708686d7ef7.pdf"
    },
    {
      "status": "ok",
      "url": "https://arxiv.org/pdf/2405.00332",
      "bytes": 7180592,
      "reused": true,
      "local_path": "papers/repair/c33ef96055660e965a1b.pdf"
    },
    {
      "status": "ok",
      "url": "https://arxiv.org/pdf/2306.05685",
      "bytes": 1580141,
      "reused": true,
      "local_path": "papers/repair/d2e940e28ba60d6a1822.pdf"
    },
    {
      "status": "ok",
      "url": "https://arxiv.org/pdf/2305.15717",
      "bytes": 1051380,
      "reused": true,
      "local_path": "papers/repair/bc4305bd40664b25adcc.pdf"
    }
  ],
  "actual_video_files": [
    {
      "local_path": "attachments/1950092ff420/videos/t_A36DDcG_0.mp4",
      "bytes": 83073327,
      "valid": true,
      "height": 1080,
      "width": 1920,
      "duration": "2755.941000",
      "status": "ok"
    }
  ],
  "body_chars": 8160,
  "expected_body_images": 3,
  "discovery_status": "ok",
  "delivery_status": "partial",
  "missing_reason": "http_404",
  "raw_html": "attachments/1950092ff420/pages/source.html",
  "local_html": "attachments/1950092ff420/pages/article.html",
  "body_base_path": "attachments/1950092ff420/pages/",
  "body_markdown_path": "attachments/1950092ff420/pages/article.md"
}