Evaluation and Benchmarking MOC

Evaluation is how a lab decides whether a model is better, safer, cheaper, or more reliable. Bad evals are one of the fastest ways to fool yourself.

Why It Matters

Frontier models are broad. A single benchmark score can hide:

• Data contamination.
• Prompt sensitivity.
• Overfitting.
• Judge bias.
• Latency/cost regressions.
• Safety failures.
• Long-tail failure modes.

Core existing note:

• Evaluation Benchmarks and Scientific Method

Evaluation Types

Capability Evals

Measure what the model can do:

• Knowledge.
• Math.
• Code.
• Reasoning.
• Multilingual ability.
• Long-context tasks.
• Tool use.

Sources:

• MMLU
• GSM8K
• MATH
• HumanEval

Holistic Evals

Measure many axes together:

• Accuracy.
• Robustness.
• Fairness.
• Bias.
• Toxicity.
• Efficiency.
• Calibration.

Source:

• HELM

Agent Evals

Measure multi-step work:

• Tool use.
• Web navigation.
• Software engineering.
• Planning.
• Recovery from errors.

Example:

• SWE-bench

Safety Evals

Measure:

• Jailbreak resistance.
• Harmful compliance.
• Misuse capabilities.
• Deception indicators.
• Sycophancy.
• Privacy leakage.

Connects to:

• AI Safety and Security MOC

Starter Project

Build a mini eval harness:

• Define 20 tasks.
• Store prompts and expected answer criteria.
• Run two models or two prompts.
• Log exact prompts, outputs, latency, and cost.
• Grade with deterministic checks where possible.
• Use model-as-judge only with spot-checked human review.
• Write failure clusters.

Deliverable:

• A memo: "What changed, and how do I know?"

What Good Looks Like

You can:

• Identify contamination risk.
• Design a private eval.
• Separate capability from elicitation.
• Include latency and cost.
• Inspect failures manually.
• Avoid overclaiming from a benchmark.

Related

• Frontier Lab Readiness MOC
• Evaluation Benchmarks and Scientific Method
• Agents and Tool Use MOC
• AI Safety and Security MOC