Applied GenAI Curriculum for AI PMs · Depth Layer · Optional Background
Why foundation models are uniquely hard to evaluate, exact evaluation, and comparative / arena-style ranking — enough to parse vendor benchmark claims critically.
The eval thread (06 → 16) was about evaluating your product. This unit is about evaluating the models themselves — the vocabulary researchers and vendors use when they say "we top the leaderboard" or "89% on MMLU." You can build great products without it, but when a vendor waves a benchmark number, this is what lets you ask the right skeptical question instead of nodding along. It complements, from the research side, the "why public benchmarks mislead" material back in Unit 07.
Evaluating any ML model is hard; foundation models are harder, for reasons worth naming:
Anyone can mark a first-grader's math; few can grade a PhD proof. Judging a coherent-but-possibly-wrong summary may require reading the whole book first.
Classic ML is close-ended (output vs. expected category). Open-ended tasks have countless valid answers — you can't curate a complete list to compare against.
Providers often hide architecture, data, and training. Without those, you can only judge a model by its outputs.
Models hit perfect scores and the benchmark dies — GLUE → SuperGLUE, MMLU → MMLU-Pro. A leaderboard win ages quickly.
A fifth wrinkle: general-purpose models mean evaluation isn't just measuring known tasks but discovering what the model can do. And bluntly — evaluation is under-invested relative to modeling, so infrastructure is thin and a lot of teams still "just eyeball it."
Exact evaluation produces judgment without ambiguity (pick B when the answer is A → wrong). Contrast with subjective evaluation (essay grading, AI-as-judge) where the score shifts with the grader. Two exact approaches:
Did it actually do the job? For code, run it: does gcd(15,20) return 5? Automatable for anything with a measurable objective — code (HumanEval), text-to-SQL, game bots, optimization tasks. The ultimate metric, but not always automatable.
Compare the output to a known-correct answer (input → reference response). Human references treat human performance as the gold standard. Bottlenecked by how fast you can produce references — increasingly AI-generated, then human-reviewed.
For similarity metrics, "reference-based" needs a gold answer; "reference-free" doesn't (usable in production where there's no ground truth). And a recurring trap: low-quality reference data poisons the score — a correct translation can be marked wrong just because it wasn't in the reference set.
Often you don't care about a model's absolute score — you want to know which is best. Two ways to rank:
| Pointwise | Score each model alone, then sort. Like scoring each dancer individually. |
| Comparative | Put models head-to-head and ask which wins. Easier for subjective quality — telling which of two songs is better beats scoring each. This powers arena leaderboards (Chatbot Arena) and the "which response is better?" prompts you've seen in ChatGPT. |
Each head-to-head is a match; the fraction A beats B is A's win rate. With many models, a rating algorithm (Elo, Bradley–Terry, TrueSkill — borrowed from chess and games) turns match histories into a ranking. Key insight: a ranking is really a prediction — there's no ground-truth "correct" ranking; a good one predicts future match outcomes well.
One more distinction to keep straight: comparative evaluation (two outputs shown at once, pick the better) is not A/B testing (one output per user, measure downstream behavior — Unit 06's Level 3).
That completes all 24 units. The series' shared reference list — every source, for further reading — follows as the closing page.