A deceptively simple question
Ask someone whether a new car is good and they will ask back: good for what — racing, hauling, or fuel economy? Evaluating an LLM is the same. A large language model can write a sonnet, debug code, summarize a contract, and confidently invent a fake citation — sometimes all in one session. There is no single 'goodness' to read off a dial.
So the first job of evaluation is not to compute a score. It is to name the thing you care about: factual accuracy, helpfulness, reasoning, latency, cost, safety. Only then can you pick a way to measure it. Skip this step and you will optimize a number that does not match what you actually want.
Perplexity: the model's own report card
The most intrinsic metric falls right out of how the model is trained. Because an LLM does next-token prediction, we can ask: on a held-out body of text, how surprised is it by each real next token? Average that surprise and exponentiate it and you get perplexity — loosely, the effective number of choices the model was hesitating between at each step. Lower is better.
Perplexity is just the exponential of the average cross-entropy loss, so it is cheap, reproducible, and great for tracking pretraining. But it has a fatal limit for users: it measures how well the model predicts a particular text, not whether its answers are helpful, correct, or safe. A model can have wonderful perplexity and still hallucinate.
Perplexity is the exponential of the average per-token cross-entropy — lower means the model is less surprised.
Automatic metrics for text — and where they break
When there is a reference answer — a gold translation or summary — we can use automatic text metrics like BLEU and ROUGE. They count overlapping words and phrases between the model's output and the reference. They are fast, deterministic, and cheap, which is why they powered a decade of machine-translation research.
A Venn diagram of candidate and reference word sets: precision is the overlap over the candidate, recall the overlap over the reference.
The trouble: for open-ended generation there are many good answers that share almost no words with any one reference. 'The meeting is at noon' and 'We will gather at 12 p.m.' mean the same thing but score poorly against each other. Word-overlap metrics reward surface mimicry, not meaning — so for modern chat models they are a weak, easily-gamed signal, useful mainly as a coarse regression check.
What we actually care about: capability and safety
Two big families of questions sit behind almost every evaluation. Capability: can the model do the task at all — reason, code, recall facts, follow instructions? Safety: when it can, does it stay within bounds — refusing harmful requests, avoiding hallucination, resisting manipulation? This split is the capability-versus-safety distinction, and the two often trade off: a model that refuses everything is 'safe' but useless; a model that does anything is capable but dangerous.
The rest of this track follows this map. We will look at standardized benchmarks (capability, at scale), then human and AI judges (open-ended quality), then the ways benchmarks deceive us, and finally how to assemble an evaluation you can actually trust — covering both capability and safety.