Foundations — Evaluation of LLMs (benchmarks, LLM-as-judge)
This page assumes you have seen nothing. Every letter, every squiggle, every fraction on the parent page is built here from the ground up, in an order where each idea leans only on the ones before it.
0. The very first picture: what "evaluate" means
Imagine a machine that eats a question and spits out an answer. We want a score — a single number that says how trustworthy the machine is. The whole topic is a toolbox of ways to make that score honest.

Look at the figure. The box is the model. The arrow in is a prompt (the question). The arrow out is the output (the answer). The scale on the right is the score we are trying to compute. Keep this picture in your head — everything below fills in how the scale gets its number.
1. Counting and fractions — the atom of every metric
The picture: slice a bar into equal pieces and shade . The shaded length is the fraction. That shaded share, written as or , is what we will call accuracy later.
Why the topic needs it: every benchmark number ("MMLU ", "Pass@1 ") is a fraction of successes over attempts. If fractions are shaky, nothing else stands.
2. Letters that stand for numbers (variables)
We keep writing things like " questions" instead of a fixed number. A variable is a box that holds some number we haven't fixed yet.
The picture: think of , , as labelled jars. Right now they're empty; in a real experiment you pour a number in. The math works no matter which number lands in the jar.
3. Probability — a fraction that predicts the future
The picture: the same shaded bar from §1, but now the shaded share means "chance it happens" instead of "how many happened." A share of shaded means a chance.

In the figure the full bar is "everything that could happen." The blue part is success, the pink part is failure. Because they cover the whole bar, blue pink . This one fact is the seed of a trick we use constantly:
Why the topic needs it: the parent writes . Every piece of that is now legible: is "one try fails", the power is " tries all fail" (next section), and the leading is the complement trick.
4. Powers — "the same thing happening several times in a row"
Why multiply, and why this tool? When two things happen independently (one doesn't affect the other), the chance they both happen is the product of their chances. "Try 1 fails and try 2 fails and ... and try fails" is independent failures, so we multiply by itself times — which is exactly . We reach for a power precisely because we have the same event repeated a fixed number of times.

The figure is a tree: at each try the path splits into "pass" (blue) or "fail" (pink). The single all-pink path — fail, fail, fail — is the one Pass@k subtracts away. As grows, that all-fail path gets thinner and thinner, so the curve of climbs toward : more tries, more chance at least one works.
5. Estimating the unknown from data
We never know the true . We only see results. So we estimate it.
The simplest honest guess: the fraction that actually worked, . If of problems were solved, our best guess of the true success rate is . This is why the parent writes — it is with replaced by its estimate .
6. Combinations — counting "ways to choose" (the symbol)
The parent's unbiased Pass@k uses . Let's earn that symbol.
The picture: you have marbles in a bag and scoop out . Different groups of marbles count as different picks, but the order you scooped doesn't. is the number of possible groups.
The ratio then reads plainly: out of all ways to choose samples (), how many ways choose only from the failing ones (, since samples failed). That ratio is the chance every chosen sample is a failure — the complement again — so subtracting it from gives the chance at least one passes, without pretending we had infinite samples.
Recall Why two Pass@k formulas?
The simple pretends samples are drawn with replacement (infinite pool). The version corrects for a finite set of samples drawn without replacement, which is what really happens in a benchmark run. ::: Same idea (complement of "all fail"), different counting model.
7. Averaging over many problems — the symbol
The picture: one dot per problem on a number line; is the balance point where the see-saw levels off. When the parent writes , it means "compute this quantity for each problem, then average across all of them."
8. From fractions to agreement — comparing a judge to a human
When there's no right answer, we test the judge by asking: does it pick the same winner a human would?
But there's a trap: in a two-way choice, even random guessing agrees about half the time. We must subtract that lucky-agreement floor.

The figure shows the agreement line. The full height to is perfect agreement. The dashed line at is the "luck floor." Cohen's Kappa measures how far above the floor you climbed, as a share of the room left above the floor:
9. Where these letters live on the parent page
The judge's answers are tagged , , or — see A, B, and Tie for what those preference labels represent. The reason we need a judge at all traces back to RLHF (learning from human preference) and Constitutional AI (learning from written rules), and the outputs being judged are shaped by Prompt Engineering Best Practices, Few-Shot Learning, and RAG. Watch for the Alignment Tax: making a model safer can dent its benchmark score.
The prerequisite map
Equipment checklist
Test yourself — reveal only after you have answered out loud.