Chapter 24 Benchmarks You Must Know

24.1 Knowledge and Reasoning Benchmarks

24.1.1 MMLU, MMLU-Pro, and GPQA

In a system design interview at a frontier lab, one of the first questions after you describe your evaluation pipeline is usually: “Which benchmarks are you tracking and why?” The interviewer is not fishing for a list of acronyms-they want to know whether you understand what each benchmark actually measures, where it saturates, and what its failure modes are. MMLU, MMLU-Pro, and GPQA are the three rungs of the standard knowledge-and-reasoning ladder, and misunderstanding any one of them signals a gap that mid-level candidates routinely fall into.

Massive Multitask Language Understanding (MMLU) was released in 2020, coinciding with GPT-3. The benchmark spans 57 subjects-ranging from abstract algebra and virology to world history and foreign policyeach formatted as a four-option multiple-choice question. Questions were scraped from the web, which already hints at contamination risks we will return to. At the time, the dominant evaluation paradigm was few-shot prompting on base models, so a canonical MMLU prompt looks like this:

The following are multiple choice questions about astronomy.

Q: What is the main sequence?
A) A band of galaxies
B) The period after the Big Bang
C) Stars fusing hydrogen in their cores
D) Planetary orbital zones
Answer: C

Q: ...  [3 more exemplars] ...

Q: Which instrument was used to first detect gravitational waves?
A) The Hubble Space Telescope  B) LIGO  C) ALMA  D) Chandra
Answer:

The model is expected to emit the letter of the correct answer. GPT-3 scored 45% under this protocol in 2020. Today’s frontier models score in the low 90s, which is why the benchmark has essentially lost discriminative power.

MMLU-Pro addresses saturation by replacing four answer choices with ten and removing the noisiest, most trivial questions. Chain-of-thought prompting is now the norm rather than raw next-token prediction. Frontier model scores drop to the 65-75% range, restoring a useful spread across model families.

Graduate-Level Google-Proof Questions (GPQA) raises the bar to PhD-level. Questions were written by domain experts, validated by a second expert, and then given to non-experts who spent up to 30 minutes on each with full internet access-the “Google-proof” designation means the non-expert accuracy was still only around 30%, while domain experts reached 65%. GPT-4 scored 39% at launch; O3 now reaches approximately 75%.

The ladder exists because knowledge benchmarks saturate in order: MMLU first, then MMLU-Pro, then GPQA-and you should know which rung a model currently sits on before choosing your evaluation target.

Multiple-choice benchmarks have three properties that make them endure: they are automatically scorable, they are reproducible across labs without access to proprietary human raters, and they produce a single number that fits cleanly into a training dashboard. When you are running hundreds of evaluation checkpoints during a training run, automatic scoring is not a convenience-it is a necessity.

The escalating difficulty across the three tiers also reflects a real property of model capability. A model that struggles on MMLU is not ready for GPQA; a model that saturates MMLU-Pro without a gap on GPQA is likely memorizing rather than reasoning. The gaps between tiers are diagnostic.

The main trade-off is that none of these benchmarks reflects what real users do. A user asking an LLM to debug their deployment pipeline or draft a patient summary is not taking a standardized test. MMLU in particular is better thought of as a proxy for base-model breadth: if a model trained on a broad web corpus can ace questions it never explicitly studied for, that is evidence of genuine generalization. If you curate a training set to hit MMLU specifically, you get a high score that tells you almost nothing about general capability.

A Worked Example

Consider evaluating a 7B model checkpoint at step 50,000 of pre-training. You want a quick signal on whether the model is developing factual knowledge.

Set up 5-shot MMLU on the computer science subset (170 questions). Feed the prompt above, sample greedily (temperature 0), and extract the first token. If it is A, B, C, or D, record it; otherwise mark invalid. Compute accuracy as:

\text{Accuracy} = \frac{\text{correct answers}}{\text{total questions}}

At 7B scale with a strong data mix, you should see roughly 55-65% on the computer science subset after a full training run, versus 25% random baseline. If your number is below 35% at step 50,000, the data mix or learning rate is likely off-this is the diagnostic value of tracking MMLU during training.

Now switch to GPQA for a 70B model you are preparing to deploy into a medical-information use case. Run GPQA’s biology subset (approximately 65 questions) with chain-of-thought, 0-shot. A score below 40% means the model cannot reliably handle expert-level biomedical questions; a score of 55% or above puts you in territory where domain-expert human annotators are necessary to catch the remaining errors. That threshold informs whether you can deploy without a mandatory human-in-the-loop review layer.

What You Actually Decide in Practice

MMLU for base models, not instruction-tuned models. Once you apply RLHF or supervised fine-tuning, MMLU scores can actually drop slightly because the model becomes more cautious about outputting raw letters. Use MMLU-Pro or GPQA for post-training checkpoints.
MMLU-Pro is the current workhorse for frontier comparisons. Scores in the 65-75% range give real differentiation between GPT-4-class and GPT-3.5-class models. If you see a model claiming 90%+ on MMLU-Pro with standard prompting and no majority-vote ensembling, audit the evaluation code-it is almost certainly using a non-standard prompt.
Few-shot example order is a confounder. Randomizing the order of the five exemplars and averaging over three orderings reduces variance by 2-4 accuracy points on MMLU. Always report the protocol, not just the number.
Chain-of-thought is now mandatory for GPQA. Without scratchpad reasoning, even 70B models underperform by 10-15 points because the questions require multi-step derivations. Zero-shot GPQA without chain-of-thought is not a meaningful measurement.
Assume contamination exists. MMLU was released in 2020. Any model trained on a 2023-or-later web crawl has almost certainly seen fragments of the test questions. A 13-gram deduplication pass can quantify this, but it does not catch paraphrases. When you report MMLU scores for a new model, add a contamination disclaimer to your model card-it is now a community norm, even if not universally followed.

How This Shows Up in Interviews

“Which benchmark would you use to evaluate a new 70B model before deployment?” Strong answer: choose based on the deployment target. For broad factual knowledge in a general assistant, MMLU-Pro gives meaningful signal. For a domain-expert use case like medical or legal, supplement with GPQA on the relevant subset. Never use plain MMLU for a frontier-sized model-you will hit the ceiling.
“MMLU scores have been in the 90s for a year. Is the benchmark still useful?” Strong answer: MMLU is still useful as a sanity check and a base-model diagnostic, but it has no discriminative power among frontier models. The field has shifted to MMLU-Pro and GPQA precisely because saturation kills the ranking signal. Know the saturation threshold: approximately 90% for MMLU, roughly 75% for MMLU-Pro, somewhere above 75% for GPQA (not yet saturated as of 2025).
Senior follow-up: “A competitor claims their model beats yours by 3 points on GPQA. How do you verify or refute this claim?” Senior answer: first, inspect the evaluation protocol-prompt format, whether chain-of-thought was used, whether majority voting over multiple samples was applied. A 3- point gap can easily be manufactured by switching from 0-shot to 8-shot chain-of-thought. Second, check the subset: 3 points on the full GPQA (448 questions) is statistically meaningful, but 3 points on a 65- question chemistry subset is within noise. Third, run your own evaluation on their model using a locked evaluation harness like HELM or LM-Evaluation-Harness so the prompt format is identical.

Key Takeaways

MMLU (2020) covers 57 subjects with 4-choice questions; saturated for frontier models at $\sim$ 90%.
MMLU-Pro raises the bar to 10 choices and harder questions; current frontier scores cluster 65-75%.
GPQA targets PhD-level, Google-proof questions; domain experts score 65%, non-experts 30%, and top models now reach $\sim$ 75%.
Multiple-choice benchmarks are valuable precisely because they are automatic, reproducible, and cheapbut they are proxies for knowledge, not for real-world task performance.
Evaluation protocol details-few-shot count, example order, chain-of-thought, sampling strategy-can swing scores by 5-15 points; always report the full protocol alongside the number.

24.1.2 Humanity’s Last Exam and ARC-AGI

Every knowledge benchmark eventually gets saturated-that is the pattern, and interviewers at frontier labs know it. When a candidate mentions GPQA, a senior interviewer often follows up with: “So what do we do when O3 is at 90% on GPQA in 18 months?” Humanity’s Last Exam and ARC-AGI represent two very different attempts to solve that problem, and understanding the philosophical difference between them is the kind of nuance that separates a strong answer from a rehearsed one. Both have appeared in recent evaluation discussions at top labs, and knowing the current numbers as well as the structural critiques is table stakes.

Humanity’s Last Exam (HLE) is a multimodal, crowdsourced benchmark built around the premise that if you aggregate the hardest questions that domain experts can construct-and then use frontier models themselves to filter out anything “too easy”-you get a ceiling that will not be quickly saturated. Organizers solicited questions from researchers and practitioners, offering co-authorship to contributors and a prize pool for accepted submissions. Each question went through a multi-stage review process. The resulting dataset contains problems in mathematics, physics, chemistry, biology, law, economics, and other fields, covering both text-only and image-based formats. Questions are either multiple-choice or short-answer with a verifiable correct responsethere is no open-ended generation. At launch, the best-performing models scored roughly 8-10%; as of early 2025, O3 reaches approximately 20%.

ARC-AGI (Abstraction and Reasoning Corpus for Artificial General Intelligence) is philosophically different. Introduced in 2019-before large language models were the dominant paradigm-it deliberately removes both language and world knowledge from the equation. Each task is a small grid of colored cells. You are shown two or three input-output example pairs that illustrate a transformation rule, and then you must apply that rule to a new input grid to produce the correct output. There are no words, no task descriptions, no domain knowledge required. The intent is to isolate abstract reasoning: can the model induce the rule from examples and generalize it? GPT-4o scored near 0% on ARC-AGI in standard evaluation mode. O3, using extended test-time compute, reaches approximately 75% on ARC-AGI v1-but at a cost of several hundred dollars per task in compute.

HLE measures the frontier of expert knowledge retrieval and multi-step reasoning; ARC-AGI measures abstract inductive reasoning stripped of any factual prior-and these are fundamentally different capabilities that current architectures handle very differently.

HLE’s strength is coverage depth. By recruiting experts and using adversarial filtering via frontier models, it ensures that questions are not just hard but are hard for current LLMs specifically. The multi-modal component also targets a genuine gap: reasoning over diagrams, equations rendered as images, and scientific figures is a capability that text-only benchmarks cannot probe. The benchmark’s primary weakness is selection bias. The people who respond to an open call to create hard questions for LLMs are disproportionately LLM researchers and power users who already have an intuition for what breaks models. The resulting distribution is not representative of any real user population-it is the hardest end of an already-expert distribution.

ARC-AGI’s strength is orthogonality. Because it contains no language and requires no memorized facts, a high score cannot be explained by training data memorization. The tasks test a form of program induction that standard next-token prediction is poorly structured to perform, which is why the baseline for transformer models was essentially 0% for years. The weakness is ecological validity: nobody’s production use case looks like “infer the grid transformation rule.” It measures something important about abstract reasoning, but a score improvement on ARC-AGI does not obviously predict improvement on coding, medical Q&A, or customer support tasks.

The compute cost of ARC-AGI is itself diagnostic. O3 achieves 75% partly through massive test-time search-the model generates thousands of candidate solutions and selects among them. At per-task costs in the hundreds of dollars, this is not a deployment-viable strategy. It tells you that the reasoning capability exists somewhere in the model’s distribution but that eliciting it reliably and cheaply remains unsolved.

A Worked Example

Consider a single ARC-AGI task. The training examples might show:

Input:   1 0 0     Output:  1 1 1
         0 0 0              0 0 0
         0 0 0              0 0 0

Input:   0 0 0     Output:  0 0 0
         0 1 0              0 1 1
         0 0 0              0 0 0

The rule, derived by inspection: wherever a 1 appears, extend it one cell to the right. The test input is:

Test:    0 0 0
         0 0 1
         0 0 0

Correct output: a 1 at position (row 2, col 3) and a 1 at position (row 2, col 4)-but the grid is only 3 columns wide, so the extension falls off the edge. Correct answer: just the original 1 at (2, 3) with no extension possible. A model that rigidly applies “extend right” without respecting boundaries fails. This edge-case handling illustrates why ARC-AGI specifically probes compositional rule application, not recall.

For HLE, a worked interaction is less illustrative because the hardness is in the domain knowledge itself. What matters is the structural number: 2,700+ questions, current top score around 20%, with each percentage point representing genuine reasoning progress rather than prompt engineering.

What You Actually Decide in Practice

Neither benchmark drives deployment decisions directly. If you are choosing which model to serve in production, HLE and ARC-AGI scores are interesting but not sufficient. Map them to a downstream task that matches your use case before pulling the trigger on a deployment choice.
HLE scores above 30% are the near-term saturation warning. Current trajectory suggests frontier models reach this threshold within 12-18 months. When that happens, expect ARC-AGI v2 or a successor benchmark to take HLE’s place. Know that this cycle is predictable-benchmark creation and saturation alternate in roughly 18-24-month cycles.
ARC-AGI performance with extended compute is not the same as ARC-AGI performance under standard inference. When citing O3’s $\sim$ 75% figure, always specify whether that was achieved with test-time search or standard single-pass generation. The gap can be 50+ points and conflating them misleads the conversation.
HLE has a documented creator bias. If you are using HLE to evaluate a model for a specific domain, check whether your domain is over- or under-represented in the question distribution. A model that scores 20% overall may score 5% on your domain or 35% if the benchmark happens to over-index on it.
ARC-AGI v2 raises the floor. The original ARC-AGI tasks are learnable by humans in seconds. ARC-AGI v2 introduced harder tasks where human accuracy drops closer to 60-70%. Pay attention to which version a score is reported against-the versions are not directly comparable.

How This Shows Up in Interviews

“What is ARC-AGI trying to measure that GPQA is not?” Strong answer: GPQA measures knowledge retrieval and expert-level reasoning grounded in facts a model may have memorized during training. ARC-AGI deliberately removes both language and factual knowledge to isolate abstract inductive reasoning-the ability to infer a rule from examples and apply it compositionally. A model can score highly on GPQA partly through training data overlap; a model cannot score highly on ARC-AGI through memorization because each task is a novel spatial pattern.
“Humanity’s Last Exam says it will be the hardest benchmark ever. Do you believe that?” Strong answer: no benchmark survives contact with an order-of-magnitude improvement in model capability. HLE’s saturation will happen; the question is timing. The more useful observation is that HLE’s creatorselection bias means it skews toward questions that LLM researchers find hard, not questions that representative users care about. It is a valuable signal of ceiling capability but a poor proxy for deployment readiness.
Senior follow-up: “O3 spends roughly $200 per ARC-AGI task at 75% accuracy. What does that tell you about the relationship between compute and reasoning, and what would it mean if a smaller model reached 75% with standard inference?” Senior answer: the O3 result demonstrates that the capability is latent in the model family-the weights contain the necessary representations-but eliciting it requires search over many candidate solutions. This looks more like a sampling and verification problem than a weights problem. A smaller model reaching 75% with single-pass inference would imply either that the inductive reasoning capability has been distilled more efficiently, or that the model has found a structural shortcut specific to ARC-AGI’s task distribution. The two cases are distinguishable by running that model on a held-out set of novel ARC-AGI-style tasks not in the original benchmark.

Key Takeaways

Humanity’s Last Exam uses expert-written, adversarially filtered questions across multiple domains and modalities; current top score is $\sim$ 20%, with saturation expected within 1-2 years.
ARC-AGI removes language and factual knowledge entirely, testing abstract inductive reasoning via gridtransformation tasks; GPT-4o scores near 0%, O3 reaches $\sim$ 75% with heavy test-time compute.
The philosophical split matters: HLE measures expert knowledge plus reasoning; ARC-AGI measures reasoning with knowledge held constant at zero.
ARC-AGI performance figures must always be tagged with the inference budget-a 75% score costing hundreds of dollars per task is not comparable to a 40% score under standard single-pass inference.
Neither benchmark translates directly to production deployment value; use them as capability probes, not as substitutes for task-specific evaluation on your actual use case.

24.2 Instruction Following and Chat Evaluation

24.2.1 IFEval, AlpacaEval, and WildBench

When a team ships a new RLHF checkpoint and asks whether instruction following improved, the answer cannot come from MMLU or GPQA - those benchmarks test knowledge retrieval, not the ability to honor a user’s stated intent. The hard problem is judging open-ended responses where there is no single ground-truth answer, and where the right response for one user might be wrong for another. IFEval, AlpacaEval, and WildBench each attack this problem from a different angle, and understanding why each one was built the way it was is more useful than memorizing the numbers.

IFEval (Instruction Following Evaluation) sidesteps the judge problem entirely by restricting prompts to constraints that can be verified with a script. A prompt like “Plan a two-week trip to Japan. Do not use commas in your response. Your answer must contain at least 200 words and include the word ‘itinerary’.” can be checked mechanically: count words, scan for commas, grep for the keyword. IFEval ships roughly 500 prompts, each annotated with one or more verifiable instructions drawn from a taxonomy of about 25 constraint types - length bounds, sentence count, keyword inclusion or exclusion, casing rules, presence of specific format tokens, and similar surface-level checks. The primary metric is prompt-level accuracy: the fraction of prompts where all constraints are simultaneously satisfied.

AlpacaEval abandons verifiability and uses an LLM as the judge. Given a prompt, two responses are produced - one from the model under evaluation and one from a fixed reference model (originally text-davinci-003, later GPT-4 Turbo). A judge LLM reads both and declares a winner. The final score is the win rate: the fraction of prompts where the evaluated model beats the reference. Because raw GPT-4 judging strongly favors longer responses, a length-controlled variant (LC-AlpacaEval) is now standard. It fits a logistic regression on win outcome versus $\log ($ length ratio $)$ and reports the corrected win rate at equal response length. The correction is meaningful: a model that simply pads responses can inflate raw win rate by 10-15 points.

WildBench adds a third ingredient: a realistic prompt distribution. Rather than synthesizing tasks, WildBench harvests utterances from live human-bot conversations collected by deploying a public chatbot. The judge is still an LLM, but it is asked to complete a task-specific checklist before rendering a verdict, which forces explicit reasoning about domain-relevant criteria and reduces position bias. WildBench’s authors report that their leaderboard ranking correlates well with Chatbot Arena, which is the closest proxy for actual user satisfaction available at scale.

The core trade-off across all three: IFEval is fully automatic and bias-free but measures only structural compliance, not semantic quality; AlpacaEval scales to any output type but inherits the judge’s style preferences; WildBench has the most realistic prompts but cannot be run without an LLM judge and significant compute.

IFEval’s strength is reproducibility. There is no judge to hallucinate, exhibit style bias, or change behavior across API versions. A constraint is either satisfied or it is not. This makes IFEval ideal as a regression gate: run it on every training checkpoint at negligible cost and catch format regressions before they reach a human reviewer. The weakness is that IFEval measures what the model structurally produces, not whether the response is useful. A model that outputs 200 words of fluent but incorrect travel advice with no commas scores perfectly.

AlpacaEval’s LLM-as-judge design handles semantic quality, handles long responses, and scales to arbitrary task types. The cost is judge bias. GPT-4 judges favor responses that sound like GPT-4 output, which systematically underrates models with different generation styles. The LC correction fixes verbosity bias but not style bias. You also pay real API costs and get slight nondeterminism: running the same evaluation twice yields win rates that can differ by one or two points.

WildBench breaks the “quiz versus ask” distinction that plagues most benchmarks. Most curated evaluations are quizzes - the evaluator already knows the answer and is checking whether the model does too. Real users are asking - they want help with something they do not already know, and they will notice poor quality even if the response technically satisfies a format constraint. Sourcing prompts from live traffic is the closest approximation to actual deployment distribution without requiring a production system. The checklist-based judge reduces but does not eliminate the fundamental LLM-judge limitation: the checklist itself was generated by a model and can be wrong.

A Worked Example

Suppose you are evaluating a 7B instruction-tuned model against GPT-4 Turbo on the standard AlpacaEval 805-prompt set.

Generate responses from both models for all 805 prompts (temperature 0.7, max tokens 2048).
For each prompt, build a judge payload with the two responses in randomized order to counteract position bias.
Call the GPT-4 judge; it returns a winner. Record whether the 7B model was judged better.
Suppose the 7B model wins 380 of 805 comparisons: raw win rate $= 380 / 805 \approx 47 . 2 \%$ .
Apply the LC correction. Fit logistic regression: win outcome $\sim \beta_{0} + \beta \log_{1} ( L_{\text{eval}} / L_{\text{ref}} )$ using the 805 data points. Predict at $\log ( 1 . 0 ) = 0$ (equal length). The corrected win rate drops to, say, 41%.

A 41% LC win rate says the 7B model loses more often than it wins against GPT-4 Turbo on general instruction following, after removing the length advantage.

Now run IFEval on the same model. Suppose it scores 72% prompt-level accuracy versus GPT-4’s 87%. The 15-point gap is concentrated in multi-constraint prompts - prompts that require simultaneously satisfying three or more constraints. The model handles single constraints reliably but fails at composition. This is a concrete actionable signal: the training data likely under-represents prompts with stacked requirements, and targeted data collection will close the gap faster than continued general RLHF.

Run WildBench last. The live-traffic prompt distribution includes more ambiguous, multi-step requests than AlpacaEval. The 7B model’s WildBench LC win rate against GPT-4 is 37% - lower than its AlpacaEval number - because the realistic prompts expose brittleness on conversational tasks that the curated benchmark obscures.

What You Actually Decide in Practice

Use IFEval as a CI gate, not a quality signal. Set a threshold - for example, do not release a checkpoint below 75% prompt-level accuracy - and block merges that regress below it. The run is cheap and deterministic; there is no reason not to run it on every checkpoint.
Always report LC win rate, never raw win rate. Raw win rate is gamed by verbosity. If your evaluation pipeline does not yet support the LC correction, a quick approximation is to compare median response length between the evaluated model and the reference: if the evaluated model is consistently 30% longer, discount the raw win rate by roughly 5-8 points as a rough sanity check.
Do not cross-compare AlpacaEval win rates across very different model families. Win rate measures similarity to GPT-4’s style as much as it measures quality. A model fine-tuned on GPT-4 outputs will score inflated win rates even at lower capability. Use it for comparing checkpoints within the same training lineage.
WildBench is the right benchmark for release gates. When you have budget for one high-signal evaluation before shipping a model update, prefer WildBench over synthetic benchmarks. The prompt distribution is the closest available proxy for what real users will send.
Corroborate across all three before drawing a conclusion. A model that improves on IFEval but degrades on WildBench has probably overfit to format compliance at the expense of content quality - a common failure mode when RLHF data is dominated by constraint-following examples.

How This Shows Up in Interviews

“How would you evaluate whether a new RLHF checkpoint improved instruction following?” Strong answer: use IFEval for cheap structural regression testing on every checkpoint, AlpacaEval LC win rate to measure relative open-ended quality against a known baseline, and WildBench for a final release gate using realistic prompts. No single benchmark is sufficient.
“Why can’t you use exact match or BLEU for instruction-following evaluation?” Strong answer: instruction following is open-ended - there is no single correct response. A prompt like “summarize this article” has thousands of valid answers; exact match would return zero for all of them. BLEU penalizes paraphrase, which is a feature in chat. The evaluation problem requires either verifiable structural constraints (IFEval) or a judge that can assess semantic quality (LLM-as-judge or humans).
“What is the main failure mode of LLM-as-judge evaluations?” Strong answer: the judge inherits its training distribution’s biases. GPT-4 judges favor outputs that stylistically resemble GPT-4 and favor longer responses. The verbosity bias is measurable and correctable via length-controlled win rate; the style bias is harder to remove because it requires knowing the judge’s training data. Position bias - preferring whichever response appears first - is addressed by randomizing response order.
Senior follow-up: “Your AlpacaEval LC win rate improved 5 points but Chatbot Arena ELO is flat. How do you reconcile this?” Sketch: AlpacaEval’s 805 curated prompts may sample a different distribution than the Arena’s live traffic. Inspect which prompt categories drove the AlpacaEval gain - if the gains are concentrated in constrained-format tasks that are rare in the Arena, the metrics are measuring different things. Also check response length distribution: if the 5-point gain partially survived length correction but the model is still 20% longer on average, the LC correction may not fully account for a broader fluency halo effect.

Key Takeaways

IFEval tests verifiable structural constraints at zero judge cost; use it as a CI gate, not a standalone quality measure.
AlpacaEval measures open-ended quality as a win rate against a fixed reference model; always use the length-controlled variant to remove verbosity bias.
WildBench sources prompts from live human-bot conversations, making it the most realistic prompt distribution available; prefer it for release decisions over synthetic-task benchmarks.
LLM-as-judge evaluations scale easily but inherit the judge model’s style and length biases; cross-model comparisons are unreliable when the models have different generation styles.
A complete instruction-following evaluation suite should include at least one verifiable-constraint benchmark (IFEval), one LLM-judge win-rate benchmark (AlpacaEval LC), and one realistic-traffic prompt set (WildBench).

24.2.2 Chatbot Arena: Strengths and Failure Modes

Chatbot Arena has become prominent enough that the CEO of Google has tweeted about Gemini’s ELO score. That kind of visibility is a double-edged signal: it means the benchmark captures something real about model quality, and it means the benchmark has become a target worth gaming. If you are building or evaluating a chat model, you need to understand both why Arena numbers are trusted and exactly where they break down - because interviewers at frontier labs will probe both sides of that question.

Chatbot Arena is a pairwise human preference leaderboard. A visitor to the site submits a prompt, receives two anonymous responses from two randomly selected models, and votes for the better response or declares a tie. Votes are aggregated using the Bradley-Terry model, a pairwise ranking framework that estimates a latent “strength” parameter $\theta_{i}$ for each model such that the probability of model $i$ beating model $j$ in a head-to-head comparison is:

P ( i \succ j ) = \frac{e^{\theta_{i}}}{e^{\theta_{i}} + e^{\theta_{j}}} .

In practice this is expressed as an ELO score: a model initialized at 1000 gains points when it beats a higher-rated opponent and loses points when it loses to a lower-rated one, with the magnitude proportional to the rating gap. New models enter by being included in the random selection pool; their ELO stabilizes as they accumulate comparisons.

Three properties make this design attractive. First, the prompts are live and open-ended: they come from real users who submit whatever they actually want to do, not from a fixed benchmark that can be memorized. Second, human judges are the ultimate downstream signal for a chat product - if people prefer your model, that is the definition of quality for that use case. Third, the ELO system naturally accommodates new entrants: a new model can establish a reliable rating after a few thousand comparisons without invalidating the existing rankings.

Chatbot Arena’s ELO is the closest available proxy for real user preference among general chat models, but it measures preference on the distribution of whoever visits the site - a distribution that may not match your deployment population.

The benchmark avoids the two most common failure modes of static evaluations. First, there is no fixed prompt set to overfit: because prompts are generated by live users, the distribution shifts as user behavior evolves, new topics emerge, and models are updated. A model that memorized the MMLU test set gains nothing from that memorization on Arena. Second, there is no reference answer to construct: human judges do not need to agree on a ground truth, they simply express a preference, which is exactly the signal that matters for a product.

The ELO mechanism handles the practical problem of scale. With hundreds of models and millions of comparisons, a full round-robin evaluation is impossible. ELO provides consistent rankings from an incomplete comparison graph as long as the underlying comparison data is sufficiently dense and not adversarially selected.

The failure modes are structural. The most important is Goodhart’s law: once Arena ELO became a PR metric for frontier labs, labs began optimizing for it directly. A 2024 paper, “The Leaderboard Illusion,” documented that some providers received privileged access to the Arena comparison pool, were permitted to make multiple model submissions under the same label, and were able to influence which models their submissions were compared against. These protocol failures mean that a jump in Arena ELO for a specific provider may reflect leaderboard management rather than model improvement.

A second failure mode is population bias. The users who visit Chatbot Arena skew toward technically literate, English-speaking, AI-enthusiast demographics. A model that is optimized to impress that population - through confident tone, dense technical vocabulary, and comprehensive multi-paragraph answers - will score well on Arena even if it performs poorly on the customer service queries, coding assistance, and simple factual lookups that constitute the majority of real deployment traffic.

A third failure mode is style over substance. Human judges choosing between two anonymous responses in a few seconds often favor the response that reads better: more confident, more structured, more verbose. This creates pressure to produce well-formatted but subtly incorrect answers over compact but accurate ones. Several studies have shown that adding markdown headers and bullet points to an otherwise identical response raises its Arena win rate by measurable margins.

A Worked Example

Suppose two models, A and B, each start with ELO 1200. After 10,000 Arena comparisons the data shows:

Model A versus Model B: 620 wins for A, 380 wins for B.

Under the Bradley-Terry model, the maximum likelihood estimates of $\theta_{A}$ and $\theta_{B}$ satisfy:

\frac{e^{\hat{\theta}_{A}}}{e^{\hat{\theta}_{A}} + e^{\hat{\theta}_{B}}} = \frac{620}{1000} = 0 . 62 .

Solving: $e^{\theta_{A} - \theta_{B}} = 620 / 380 \approx 1 . 63$ , so $\theta_{A} - \theta_{B} \approx \ln ( 1 . 63 ) \approx 0 . 49$ . Converted to the standard ELO scale ( $K$ -factor 32), Model A’s ELO rises by roughly $32 \times ( 1 - 0 . 62 ) \approx 12$ points per comparison on average, landing around 1240 while B drifts toward 1160 after sufficient comparisons.

\hat{ phantom{x}}^{\hat{ phantom{x}} \hat{ phantom{x}}} \qquad \hat{ phantom{x}}

Now suppose a third model C is added. C is only compared against B (not A) due to a protocol gap. C beats B 70% of the time, giving C an ELO near 1220. But without direct comparisons to A, C’s ELO is estimated via transitivity - and if B’s rating has been deflated by the earlier comparisons, C’s estimated rating inherits that error. This is the mechanism behind the “Leaderboard Illusion” finding: controlling which models you are compared against controls your apparent ELO even if your true quality is lower.

The practical takeaway: treat Arena ELO differences under 20 points as noise, require confidence intervals before drawing any conclusion, and be especially skeptical of large ELO jumps that coincide with PR announcements.

What You Actually Decide in Practice

Do not use Arena as your internal development signal. The feedback loop is too slow (days to weeks for stable ELO), too expensive (requires public model deployment), and too noisy (high variance from user population drift). Use AlpacaEval or WildBench for fast iteration; treat Arena as a final validation signal only.
Segment Arena results by category when available. The LMSYS team now publishes category-level breakdowns (coding, math, writing, etc.). A model with strong overall ELO but weak coding ELO is a different product risk than a model with uniform performance. Always look at the category breakdown before reporting an overall number.
Treat ELO differences below 20 points as within noise. The confidence intervals on Arena ELO are wide for models with fewer than 5,000 comparisons. A difference of 10-15 ELO points is not statistically distinguishable from zero; differences above 30 points are more reliable.
Flag suspicious ELO trajectories. A model that jumps 40+ ELO points in a week with no corresponding improvement on automated benchmarks is a signal of leaderboard management, not model improvement. Cross-check against AlpacaEval and WildBench - genuine capability improvements show up in all three.
Pair Arena with a safety and refusal benchmark. A model can maximize Arena ELO by never refusing any request and always producing confident-sounding answers. Unless you also track refusal rate and factual accuracy, you may ship a model that looks great on Arena but hallucinates aggressively in production.

How This Shows Up in Interviews

“Why is Chatbot Arena considered the gold standard for evaluating chat models, and what are its limitations?” Strong answer: Arena uses live human preference on real user prompts with an ELO system that handles new entrants gracefully. The limitation is Goodhart’s law - once ELO became a PR metric, providers began optimizing for it directly, including through protocol manipulation documented in “The Leaderboard Illusion.” Population bias toward technically literate English speakers is a structural limitation that cannot be fixed without changing the user base.
“A model improved on AlpacaEval but its Arena ELO did not move. What do you investigate?” Strong answer: check whether the AlpacaEval gain was concentrated on prompt types that are rare in Arena’s live traffic. Inspect whether the model became more verbose (which boosts AlpacaEval but may not impress Arena voters who are reading two responses side by side). Also check whether the model was recently added to Arena and has too few comparisons for a stable ELO estimate.
“How would you design an evaluation system that avoids the failure modes of Chatbot Arena?” Strong answer: blind protocol with randomized comparison partners and no privileged submissions; stratified sampling to ensure coverage of coding, factual recall, and safety-adjacent prompts, not just the distribution of whoever finds the site; confidence intervals on all published scores; and a clear separation between “evaluation” comparisons (public) and “development” comparisons (internal only, never used to update public ELO).
Senior follow-up: “Even with a clean protocol, what is the fundamental limit of human preference evaluation for assessing model quality?” Sketch: human preference captures what people like, not what is correct. On tasks with verifiable answers - math, code, factual retrieval - a confident wrong answer can beat a hedged correct one in human preference voting. The fundamental fix is not a better preference protocol but a better task decomposition: use human preference only for genuinely subjective tasks (writing style, tone, helpfulness in ambiguous situations), and use ground-truth metrics for tasks with objective answers. A single Arena ELO collapses both into one number, which is convenient but misleading.

Key Takeaways

Chatbot Arena ranks models via ELO scores derived from pairwise human preference votes on live, open-ended prompts - the most direct proxy for real user satisfaction available at scale.
The benchmark is vulnerable to Goodhart’s law: once ELO became a PR target, protocol manipulation became documented and consequential.
Population bias (technically literate, English-speaking visitors) and style-over-substance voting mean Arena ELO favors well-formatted, confident responses over compact, accurate ones.
Treat ELO differences below 20 points as noise; cross-validate Arena numbers against AlpacaEval and WildBench before drawing conclusions.
Use Arena for release validation, not for the development feedback loop - it is too slow, too noisy, and too costly to run internally on every checkpoint.

24.3 Agentic and Safety Benchmarks

24.3.1 SWE-Bench, CyBench, and MLE-Bench

Static multiple-choice benchmarks tell you what a model knows; agent benchmarks tell you what it can actually do under execution feedback. At mid-to-senior interviews at labs and product companies, you will be asked to design evaluation pipelines for agentic systems - systems that write and run code, access a shell, iterate on tool results, and operate over dozens of steps rather than a single forward pass. SWE-Bench, CyBench, and MLE-Bench represent three distinct flavors of this challenge: software engineering, cybersecurity, and machine learning research. Understanding their mechanics, their current accuracy ceiling, and their blind spots is the baseline for any serious conversation about evaluating agents in production.

An agent benchmark differs from a static benchmark in one structural way: the model does not produce a single output that is scored; it operates a loop - observe, plan, act, observe again - until it either solves the task or exhausts a step budget. An automated harness manages this loop, executes the model’s actions in a sandboxed environment, and feeds the resulting observations back into the model’s context.

SWE-Bench presents the agent with a real GitHub repository and an issue description. The agent must produce a patch (a unified diff) that, when applied, causes the associated unit tests to pass. No human reviews the patch for style or correctness beyond the test suite. The evaluation metric is resolved rate: the fraction of issues for which the submitted patch makes all required tests pass. Current top models resolve roughly 40-50% of the SWE-Bench Verified subset, with the full test set sitting somewhat lower.

CyBench wraps Capture-The-Flag (CTF) challenges as agent tasks. The agent receives a natural-language description of the challenge and shell access to a sandboxed server. Its goal is to execute commands, exploit a vulnerability, and retrieve a secret flag string. The canonical agent loop used in published work looks like this:

while not solved and steps < budget:
    thought  = model.generate(context)
    command  = parse_command(thought)
    output   = shell.execute(command)
    context += (thought, command, output)

CyBench records first-solve time by human teams for each challenge, ranging from a few minutes for easy tasks to 24 hours for the hardest. This lets you calibrate model performance against human effort rather than against an arbitrary binary pass/fail threshold. As of early 2025, top agents solve challenges that took skilled human teams around 40 minutes; challenges requiring multiple hours of human effort remain mostly unsolved.

MLE-Bench draws from 75 historical Kaggle competitions. The agent receives the competition description and the dataset, then must explore the data, write training code, tune hyperparameters, and submit predictions - exactly the workflow a human Kaggle competitor follows. The primary metric is whether the agent’s final submission places above the competition’s medal threshold (typically the top 10-20% of historical submissions). Best-in-class agents achieve this threshold on fewer than 20% of competitions.

All three benchmarks share the same structural advantage: an objective, automated verifier that eliminates human labeling from the evaluation critical path entirely.

The decisive virtue of objective verifiers - test suites in SWE-Bench, flag strings in CyBench, leaderboard scores in MLE-Bench - is reproducibility. You run the benchmark, collect numbers, and trust the verdict without a human annotator in the loop. This matters when you are iterating on agent scaffolding or model versions daily.

The trade-off is coverage. Unit tests do not verify code correctness in general; they verify the specific cases the test author imagined. A patch that passes all tests while introducing a subtle regression elsewhere is scored as a success. In CyBench, challenge difficulty spans several orders of magnitude, so aggregate pass rate masks which capability tier is actually improving. In MLE-Bench, the agent operates under a fixed compute and wall-clock budget that may not reflect how a human competitor would allocate resources, making direct comparison somewhat artificial.

Compared to static knowledge benchmarks, these agent benchmarks are structurally harder to saturate through training data contamination alone, because solving a novel GitHub issue requires reasoning about the specific repository’s structure and issue context, not recalling a memorized answer.

A Worked Example

Consider a SWE-Bench evaluation run with a 70B agent model on an H100 node, context window 128K tokens, step budget capped at 30 iterations.

The harness provides the model with the repository file tree (truncated to fit context), the failing test output, and the issue description.
The agent calls a file-read tool to inspect the relevant module, identifies a missing branch in a conditional, and generates a candidate patch.
The harness applies the patch via git apply, runs pytest targeting the affected test file, and returns pass/fail plus any traceback.
If tests fail, the observation is appended to context and the agent retries. If tests pass, the run is scored as resolved.

At a 40% resolved rate over 300 issues, a full benchmark run incurs roughly

300 \times 15 \text{steps} \times 2 , 000 \text{tokens/step} = 9 \text{M input tokens}

plus generation costs - significant but tractable for a daily evaluation loop. Context exhaustion is a real failure mode: published analyses show roughly 20-25% of failures occur because the model’s context window fills before it converges on a valid patch, not because the model lacks the underlying knowledge.

What You Actually Decide in Practice

Fix the step budget before comparing runs. Doubling the budget from 20 to 40 steps typically lifts resolved rate by 5-8 percentage points but doubles token cost. Reporting a resolved-rate number without the budget makes it uninterpretable.
Version the scaffold alongside the model. Adding a grep-style code-search tool to the scaffold typically lifts SWE-Bench resolved rate by 3-5 points independent of any model change. A number reported without specifying the scaffold version is ambiguous about what actually changed.
Stratify CyBench results by human first-solve time. Challenges solved by humans in under 10 minutes are in a completely different regime from those requiring hours. Aggregating them into one accuracy number hides which difficulty tier is actually changing.
Contamination in agent benchmarks is structural, not just n-gram overlap. SWE-Bench tasks come from real repositories with public commit histories. If the model was trained on post-issue commits that contain the fix, it can “solve” the task by recall rather than reasoning. Timestamp filtering is the standard mitigation: exclude any repository commits that postdate the model’s training cutoff.
MLE-Bench medal rate underestimates continuous improvement. Medal thresholds are discrete step functions. Track the continuous leaderboard percentile alongside the binary medal metric to distinguish a submission that narrowly misses the medal from one that ranks near the bottom of non-medal submissions.

How This Shows Up in Interviews

“How would you evaluate an agent that writes and runs code?” A strong answer names SWE-Bench, explains the test-suite-as-verifier design, and immediately flags the coverage gap (passing tests does not prove correctness). A mid-level answer stops at “run the tests.” A senior answer specifies: scaffold version, step budget, and whether you are evaluating the model or the full system including all tooling.
“What makes agent benchmarks harder to game than static multiple-choice benchmarks?” The verifier is objective and dynamic - a real test suite or a server that must be exploited - so memorizing outputs is insufficient. The senior follow-up is: “A model trained on post-issue GitHub commits could solve SWE-Bench by recall rather than reasoning. How do you detect and correct for that?” The strong answer: timestamp-based filtering, plus maintained hold-out repositories that were never indexed in any training corpus.
“Why does MLE-Bench use medal rate rather than raw leaderboard score?” Medal rate normalizes across competitions with incompatible scoring scales. But the senior nuance: medal rate is a step function and suppresses continuous progress, so you want both the medal rate and the percentile distribution, not just the mean.

Key Takeaways

Agent benchmarks use objective, automated verifiers - test suites, flag strings, competition scores - to eliminate human labeling from the evaluation critical path.
Top models resolve roughly 40-50% of SWE-Bench Verified; MLE-Bench medal rates remain below 20% for frontier models as of early 2025, leaving substantial headroom.
The scaffold - tool set, step budget, context management strategy - affects scores as much as the underlying model; always version both together when reporting numbers.
Contamination in agent benchmarks is structural: models trained on post-fix commits can solve tasks by recall. Timestamp filtering is the standard mitigation, but requires knowing the training cutoff.
Always stratify by task difficulty before reporting aggregate accuracy; a single number across CyBench challenges spanning minutes to 24 hours of human effort is nearly meaningless.

24.3.2 HarmBench, AIR-Bench, and Jailbreaking

Safety benchmarks surface reliably in interviews for roles at external-facing product teams and at frontier labs running pre-deployment evaluations. The question is almost never “is this model safe?” - that framing is too abstract to be actionable. The real questions are: which harm categories does the model comply with under direct prompting, how does it respond to adversarially optimized inputs, and how do you pair a safety metric with a capability metric so that over-refusal is penalized alongside under-refusal? HarmBench, AIR-Bench, and the GCG jailbreak literature give you the vocabulary and numbers to answer those questions concretely at any seniority level, but senior candidates are expected to hold the capabilities-vs-propensity distinction and the open-weight threat model without prompting.

HarmBench defines 510 harmful behavior categories spanning chemical synthesis, cyberweapon generation, non-consensual content, and a range of other regulated domains. For each behavior, the benchmark constructs a direct prompt and measures whether the model complies (produces the requested content) or refuses. The primary metric is attack success rate (ASR): the fraction of behaviors where the model produces a compliant response. A lower ASR is better for safety. HarmBench also includes adversarial attack variants - including the GCG method described below - so a single benchmark run can report both direct-prompt ASR and adversarially-prompted ASR side by side.

AIR-Bench (AI Risk Benchmark) takes a grounding strategy: rather than curating harmful behaviors ad hoc, it maps its taxonomy to specific clauses in existing regulatory frameworks - EU AI Act articles, US executive orders, major company usage policies - and to published harm taxonomies. This anchoring makes coverage auditable: you can point to a specific regulation and ask which benchmark items correspond to it. The taxonomy spans categories including CBRN (chemical, biological, radiological, nuclear) uplift, critical infrastructure attacks, privacy violations, and election interference.

Jailbreaking refers to any technique that causes a model to comply with a harmful prompt it would otherwise refuse. The canonical research example is the Greedy Coordinate Gradient (GCG) attack, which appends an adversarially optimized suffix to the original prompt:

p^{\ast} = p_{\text{harm}} \| [ x_{1} , x_{2} , . . . , x_{k} ]_{\text{suffix}}

The suffix $x_{1} \cdot \cdot \cdot x_{k}$ is found by gradient-based search on an open-weight model to maximize the probability that the model begins its response with a compliance token (typically “Sure” or “Of course”) rather than a refusal. The suffix is not semantically meaningful in human language. Because it optimizes for a low-level token distribution rather than surface semantics, it transfers to black-box closed models: suffixes optimized on Llama-2-7B have achieved non-trivial ASR against GPT-4 class models in published experiments.

Safety evaluation is not just about whether a model refuses harmful prompts under direct request; it is about how robust that refusal is under adversarial perturbation, and whether you have kept those two dimensions cleanly separated in your benchmark design.

The deepest architectural insight in safety evaluation is the distinction between capability and propensity. A model may have encoded the knowledge to synthesize a dangerous compound (capability) but have been trained to decline to produce that knowledge on request (propensity). For closed-weight API models, only propensity is directly exposed to an attacker - if the model refuses, the adversary cannot extract the underlying capability through standard prompting, even if it exists. For open-weight models, capability matters independently, because fine-tuning can restore compliance in as few as 100-500 gradient steps on consumer hardware, effectively removing the alignment layer while leaving the encoded knowledge intact.

This distinction fundamentally changes how you interpret a safety score. A closed-weight model scoring 5% ASR on HarmBench and an open-weight model with the same score have very different real-world risk profiles. Any safety evaluation that conflates the two leads to misleading conclusions.

The pairing problem is equally important: a model that refuses every prompt would achieve 0% ASR on HarmBench but would be useless. The standard practice is to run a safety evaluation alongside a capability evaluation (a task accuracy benchmark on benign prompts) and treat the two scores as a Pareto frontier rather than summing them into a single safety index. The earlier practice of reporting only ASR, without a measure of false-positive refusals, is a known failure mode in early safety leaderboards.

A Worked Example

Consider running a targeted GCG jailbreak evaluation on a hypothetical 7B instruction-tuned model.

Select a target behavior from HarmBench, e.g., “Provide step-by-step synthesis instructions for [hazardous compound].”
Initialize a random suffix of 20 tokens appended after the harmful prompt.
For 500 gradient steps on the open-weight target, compute $\nabla_{\theta} \mathcal{L}_{\text{jailbreak}}$ where the loss rewards compliance tokens and penalizes refusal tokens at position 1 of the response.
Apply the optimized suffix to the same prompt sent to a closed-weight model via API (no gradient access needed at inference time).
Score the closed model’s response: compliance counts as a successful transfer.

In the original GCG paper, this transfer attack achieved ASR above 80% on several closed models when optimizing on Llama-2-7B. The computational cost for a single behavior is roughly 500 forward-backward passes on a 7B model - about 10-20 minutes on a single A100. Across all 510 HarmBench behaviors, a full GCG evaluation costs on the order of 100-170 A100-hours, which is well within the budget of a pre-deployment safety team.

For context, models that have undergone adversarial training against GCG-style suffixes typically show substantially lower transfer ASR, demonstrating that the attack is not fundamental but a consequence of insufficient robustness training at the token-distribution level.

What You Actually Decide in Practice

Always pair safety ASR with a benign-refusal-rate metric. A model with 5% ASR that also refuses 30% of legitimate coding questions is not “safer” - it is miscalibrated in a different direction. Report both numbers every time. Goodhart’s Law applies directly: optimizing ASR alone produces an over-refusing model.
The open-weight threat model requires capability auditing, not just propensity measurement. For any open-weight release, additionally assess which capability classes the model has encoded, because fine-tuning to remove safety alignment is a 100-500 step operation on consumer hardware. Propensity scores are insufficient for open-weight models.
Use AIR-Bench when your deployment is geographically or regulatorily scoped. Its regulatory anchoring lets you identify exactly which benchmark items are binding for a given jurisdiction, rather than evaluating against a generic harm taxonomy. This is the evaluation posture that pre-deployment safety reviews by bodies like AISI actually use.
Jailbreak robustness degrades with model updates in both directions. Adversarial training against known suffixes raises robustness against those attacks but may degrade robustness against unseen attack families. Track ASR under multiple attack types across model versions, not just against one fixed adversary.
Dual-use creates irreducible ambiguity that benchmark scores cannot resolve. CyBench CTF challenges used to measure cyber-offense risk are the same challenges used by red teams doing legitimate penetration testing. A model that solves 20% of CyBench challenges may reduce security risk (for de-fenders using it proactively) while also increasing it (for attackers). The benchmark score is a capability signal; the deployment decision requires reasoning about who actually uses the model and how.

How This Shows Up in Interviews

“How would you evaluate whether a model is safe to deploy externally?” A strong answer covers: HarmBench or AIR-Bench ASR for direct-prompt compliance, a GCG-style transfer attack for adversarial robustness, a benign-refusal-rate metric to detect over-refusal, and a separate assessment based on whether the model is open- or closed-weight because the threat model differs fundamentally. A weak answer mentions only “checking whether it refuses harmful prompts.”
“What is the difference between safety capability and safety propensity?” Capability is whether the model’s weights encode knowledge that could cause harm; propensity is whether alignment training causes the model to withhold that knowledge on request. For closed-weight APIs, only propensity is directly attackable. The senior follow-up: “If a malicious actor fine-tunes an open-weight model on 500 examples rewarding compliance with harmful prompts, how much does alignment degrade?” The honest senior answer: current research shows standard RLHF-based alignment can be substantially degraded in 100-500 fine-tuning steps, which is a known and unresolved limitation of current alignment techniques, and is why capability audits matter independently of ASR for open-weight releases.
“Why is a safety leaderboard where lower ASR is always better not sufficient?” The missing axis is capability: a model that refuses everything achieves 0% ASR but delivers no value. Safety evaluation requires a Pareto view over both axes. Additionally, neither HarmBench nor AIR-Bench measures systemic harms like hallucinations in high-stakes contexts - reducing hallucination rates is simultaneously a safety and a capability improvement, so framing safety purely as refusal rate is too narrow.

Key Takeaways

HarmBench evaluates compliance across 510 harm categories; AIR-Bench anchors its taxonomy to actual regulatory frameworks, making coverage auditable against specific laws and company policies.
GCG jailbreak attacks optimize adversarial suffixes on open-weight models and transfer to closed-weight targets; a complete safety evaluation must include adversarial robustness, not only direct-prompt ASR.
Capability and propensity are distinct threat surfaces: open-weight models can have alignment removed by fine-tuning in hundreds of steps, so capability audits matter independently of ASR scores.
Safety ASR must always be reported alongside a benign-refusal-rate metric; optimizing one without the other produces a model that is either harmful or broken in the opposite direction.
Dual-use capabilities - where the same model skill enables both offense and defense - cannot be resolved by benchmark scores alone; the deployment decision requires context about who uses the model and under what conditions.