# Evaluation and Verification Infrastructure The tools and data used to check and score what a model produces. Distinct from, but related to, [[AI Verification]] in the enterprise sense (humans checking AI output at work). This note is about verification as an input to training. ## The components - **Benchmarks.** Fixed test sets used to compare models (coding, maths, agent tasks). A benchmark that frontier labs cite in their own model reports has become part of how progress is defined. - **Evals.** Broader, often private test suites a lab or customer runs to decide whether a model is good enough for a task. - **Verifiers.** Automatic checkers that say whether an answer is right: unit tests for code, proof checkers for maths, simulators for physical tasks. - **Reward models and graders.** Models trained to score outputs where no exact checker exists, including [[LLM-as-Judge]] setups. - **Annotation / data labelling.** Humans producing labels or example answers. The older, labour-heavy form of supervision. ## Why verification caps self-improvement Modern post-training ([[Pretraining, Post-Training and Fine-Tuning]]) increasingly uses reinforcement learning: the model tries, a verifier scores, the model updates. The model can only improve as far as the verifier can reliably tell good from bad. If the verifier is weak, the model learns to game it. So there are two candidate caps on self-improvement: - **Compute-bound:** progress is limited by how many attempts you can afford to run. Favours whoever has the most silicon. - **Verification-bound:** progress is limited by how well you can check the attempts. Favours whoever builds the best supervision, which is cheaper and easier to copy. Swapping better supervision for raw compute is the same trade as writing custom kernels ([[Systems and Compiler Depth]]). Related: [[recursive self-improvement]], [[recursive loops]], [[How AI Verification Tools Actually Work - A Technical Deep Dive]], [[RAG-based verification]]