How do I evaluate a fine-tuned LLM in 2026?

Evaluating a fine-tuned LLM requires three layers of evaluation: benchmarks, metrics, and judgment. No single metric captures LLM quality — you need all three. Layer 1: Benchmarks (model comparison): (1) MMLU — Massive Multitask Language Understanding. 57 subjects from elementary math to professional law. Multiple choice, unambiguous scoring. Top models score 85-90%. Good for comparing models and detecting regression. (2) HumanEval — 164 Python programming problems. Metric: pass@k (generate k samples, check if any passes unit tests). pass@1 = one attempt, pass@10 = ten attempts. (3) HellaSwag — commonsense reasoning. Multiple choice. Tests whether the model can complete scenarios. (4) Winogrande — coreference resolution. Tests pronoun disambiguation. (5) GSM8K — grade school math word problems. Tests mathematical reasoning. (6) MT-Bench — multi-turn conversation benchmark. Tests dialogue quality. (7) Tool: lm-evaluation-harness (EleutherAI) — 60+ benchmarks, supports LoRA adapters, vLLM, OpenAI, HuggingFace. The backend for HuggingFace's Open LLM Leaderboard. Used by NVIDIA, Cohere, BigScience. Layer 2: Metrics (task-specific): (1) Perplexity — how well the model predicts the next token. Lower is better. Proxy for language modeling quality but does not measure task-specific performance. A model with perplexity 5 might still generate factually wrong answers. Use during training to monitor convergence. (2) BLEU — n-gram overlap between generated text and reference. Originally for translation. Rewards literal similarity over semantic correctness. Sensitive to synonym choice. Best for translation and template-based generation. (3) ROUGE — recall-oriented overlap. ROUGE-1 (unigram), ROUGE-2 (bigram), ROUGE-L (longest common subsequence). Standard for summarization. More forgiving than BLEU for paraphrasing. (4) BERTScore — semantic similarity using BERT embeddings. Compares texts at the meaning level, not surface form. Correlates better with human judgment than BLEU/ROUGE. Best for open-ended generation (summarization, QA, creative writing). (5) Exact match / regex — for structured outputs (JSON, SQL, code, numeric answers). The right choice when there's one correct answer. (6) pass@k — for code generation. Generate k samples, check if any passes unit tests. Layer 3: Judgment (qualitative): (1) LLM-as-judge — use a capable model (GPT-4, Claude) to score outputs on correctness, helpfulness, format adherence, safety. GPT-4 as judge matches human agreement at over 80% on MT-Bench — the same level as human-human agreement. Correlates well with human preferences, scales to arbitrary tasks, provides explanations. Risks: judge bias, consistency, provider drift when model snapshots update. (2) Human evaluation — the gold standard. Rate on fluency, helpfulness, accuracy, safety. Expensive, slow, hard to scale. Use for periodic audits and calibrating LLM-as-judge. (3) A/B testing — deploy fine-tuned model alongside base model. Route traffic, compare user engagement, satisfaction, task completion. The ultimate test is real user behavior. The evaluation strategy by development phase: (1) During training — track perplexity and validation loss. If validation loss increases while training loss decreases, stop — you're overfitting. (2) After training — run task-specific evals (BLEU, ROUGE, BERTScore, exact match, pass@k) on held-out data. Run benchmark suite (MMLU, HellaSwag) to detect regression. (3) Before shipping — use LLM-as-judge for qualitative scoring on diverse test prompts. Run human evaluation on a sample. (4) In production — monitor quality metrics, user feedback, error rates. Set up alerts for quality degradation. The key: 'Evaluation is not one problem — it is several. You need metrics for training monitoring (perplexity, validation loss), metrics for capability measurement (benchmarks like MMLU, MT-Bench), and metrics for production quality (task-specific evals, LLM-as-judge). Each serves a different purpose and none is a substitute for the others.' Use all three layers. No single metric captures LLM quality (ailearnings 2026, machinelearningplus 2026, wandb 2026, hld 2026).

What is LLM-as-judge and how do I use it for evaluation?

LLM-as-judge is an evaluation technique where a capable language model (GPT-4, Claude) scores the outputs of another model on dimensions like correctness, helpfulness, format adherence, and safety. It is the most practical evaluation method for open-ended tasks where multiple valid outputs exist. Why LLM-as-judge works: (1) GPT-4 as judge matches human agreement at over 80% on MT-Bench — the same level as human-human agreement. (2) Correlates well with human preferences. (3) Scales to arbitrary tasks — any task that can be described in a prompt can be judged. (4) Provides explanations — the judge can explain why it gave a particular score. (5) Faster and cheaper than human evaluation. Two dominant forms: (1) Pairwise comparison — present two outputs (A and B) to the judge, ask which is better. Good for ranking models. Mitigations for bias: randomize order, run both directions (A vs B and B vs A), average the results. (2) Rubric scoring (1 to 5 with explicit anchors) — give the judge a rubric with specific criteria for each score. G-Eval formalized this by having the judge generate chain-of-thought evaluation steps, then fill a score form. G-Eval with GPT-4 achieved Spearman 0.514 with human ratings on SummEval. How to set up LLM-as-judge: (1) Choose a judge model — GPT-4, Claude, or another capable model. Use the same judge consistently — different judges have different biases. GPT-4o and Claude 3.5 produce different relative rankings. (2) Define scoring criteria — what dimensions to score: correctness, helpfulness, format adherence, safety, conciseness, tone. Be specific about what each score means. (3) Create a rubric — for each dimension, define what a 1, 3, and 5 look like. Explicit anchors reduce judge variability. (4) Write the judge prompt — include the input, the output to evaluate, the rubric, and instructions to score. For G-Eval, include chain-of-thought steps. (5) Run the judge — send the prompt to the judge model, parse the score. (6) Calibrate — on a sample of 50-100 outputs, have humans rate quality on the same scale. If judge scores and human scores correlate at r > 0.8, the judge is reliable. If not, adjust your judge prompt or rubric. Risks and mitigations: (1) Judge bias — the judge may prefer longer outputs, outputs from its own family, or outputs that match its style. Mitigation: use a judge outside the candidates' family, normalize or cap length, randomize order for pairwise. (2) Consistency — the judge may give different scores to the same output on different runs. Mitigation: run multiple times and average, use temperature 0 for deterministic scoring. (3) Provider drift — when the judge model's provider updates the model snapshot, scores may change silently. Mitigation: pin the judge model version, periodically re-calibrate against human ratings. (4) Cost — judging requires API calls. Mitigation: judge a sample (50-100 outputs) rather than the full dataset. (5) Judge limitations — the judge may not understand domain-specific content (medical, legal, financial). Mitigation: use domain experts for domain-specific evaluation, or use a domain-specific judge model. When to use LLM-as-judge: (1) Open-ended tasks — summarization, QA, creative writing, dialogue. Where multiple valid outputs exist. (2) When human evaluation is too expensive — scale to hundreds or thousands of outputs. (3) For qualitative scoring — correctness, helpfulness, safety, tone. (4) For pairwise comparison — ranking models or comparing fine-tuned vs base. (5) For CI/CD — automated quality gates before deployment. When NOT to use LLM-as-judge: (1) Structured tasks — use exact match, regex, or pass@k instead. (2) Domain-specific tasks — use domain experts or domain-specific benchmarks. (3) When you need ground truth — use reference-based metrics (BLEU, ROUGE, BERTScore). (4) High-stakes decisions — always have human review for high-stakes outputs. The key: 'GPT-4 as judge matches human agreement at over 80% on MT-Bench, the same level as human-human agreement. Calibrate your LLM-as-judge by comparing its scores to human ratings on 50-100 outputs. If correlation is r > 0.8, the judge is reliable.' LLM-as-judge is the most practical evaluation method for open-ended tasks. Calibrate it, use it consistently, and supplement with human evaluation for high-stakes decisions (hld 2026, ailearnings 2026, machinelearningplus 2026).

How do I detect overfitting and catastrophic forgetting in a fine-tuned LLM?

Overfitting and catastrophic forgetting are the two most common failure modes of LLM fine-tuning. Both can be detected with proper evaluation. Overfitting: the model performs well on training data but poorly on new data. It has memorized the training examples rather than learning the underlying pattern. Detection: (1) Monitor validation loss — track both training loss and validation loss during training. Training loss always decreases — that's what gradient descent does. If validation loss decreases along with training loss, the model is learning. If validation loss starts increasing while training loss continues decreasing, the model is overfitting — stop training. (2) Compare training and evaluation performance — if the model scores 99% on training data but 70% on held-out evaluation data, it's overfitting. The gap between training and evaluation performance is the overfitting gap. (3) Test on diverse inputs — if the model performs well on inputs similar to training data but poorly on different inputs, it has memorized rather than generalized. (4) Check for memorization — if the model produces training examples verbatim, it's memorizing. Test with slightly modified inputs to see if the model generalizes. Prevention: (1) Hold out 10-15% for evaluation — never evaluate on training data. (2) Use regularization — LoRA dropout (0.05), weight decay (0.01), early stopping when validation loss increases. (3) Limit epochs — 2-4 epochs is typical. More epochs increase overfitting risk. (4) Use LoRA/QLoRA — the frozen base model prevents extreme overfitting. Only adapter parameters are updated. (5) More data — 500-1,000 diverse examples generalize better than 100 repetitive ones. (6) Data augmentation — add varied examples to prevent memorization of specific patterns. (7) Cross-validation — split data into K folds, train on K-1, evaluate on 1. Repeat K times. Average the results. Catastrophic forgetting: the model loses general capabilities after fine-tuning. It becomes excellent at your specific task but forgets how to do everything else. Detection: (1) Run general benchmarks — run MMLU, HellaSwag, Winogrande on both the base model and the fine-tuned model. If the fine-tuned model scores significantly lower, it has experienced catastrophic forgetting. (2) Compare against base model — always compare your fine-tuned model against the base model on general benchmarks. This tells you exactly how much general capability was lost. (3) Test on general tasks — evaluate the model on general tasks (not just your specific task). If general performance drops, the fine-tuning has degraded general capabilities. (4) Monitor in production — track quality on general queries in production. If general query quality drops after deploying the fine-tuned model, it has forgotten general capabilities. Prevention: (1) Use LoRA/QLoRA — the frozen base model preserves general capabilities. Only adapter parameters are updated. This is the single most effective prevention strategy. (2) Low learning rate — for full fine-tuning, use 1e-5 or below. The model should be nudged, not shoved. (3) Data mixing — mix 10-20% general data with 80-90% task-specific data. This reminds the model of general knowledge. (4) Limit epochs — 2-4 epochs. More epochs increase forgetting risk. (5) EWC (Elastic Weight Consolidation) — regularize changes to important weights. (6) Monitor general benchmarks during training — run MMLU periodically during training. If it drops, reduce learning rate or epochs. The lm-evaluation-harness workflow: (1) Run benchmarks on base model — lm_eval --model hf --model_args pretrained=meta-llama/Meta-Llama-3-8B-Instruct --tasks mmlu,hellaswag,winogrande --output_path ./eval_results/base/. (2) Run benchmarks on fine-tuned model — lm_eval --model hf --model_args pretrained=./merged-model --tasks mmlu,hellaswag,winogrande --output_path ./eval_results/fine-tuned/. (3) Compare results — if fine-tuned model scores lower on MMLU/HellaSwag, catastrophic forgetting has occurred. If it scores higher on your task but lower on general tasks, you need to adjust your training (lower LR, fewer epochs, data mixing, or use LoRA). The key: 'Always compare your fine-tuned model against the base model on a general benchmark. Fine-tuning often degrades general capabilities — this is called catastrophic forgetting. Running MMLU or HellaSwag on both the base and fine-tuned model before deploying tells you exactly how much general capability was lost.' Overfitting and catastrophic forgetting are detectable and preventable. Monitor validation loss, compare against the base model, and use LoRA to prevent both (ailearnings 2026, wandb 2026, hld 2026).

What is a golden set and why do I need one for LLM evaluation?

A golden set is a small, carefully curated set of examples from your actual use case, hand-labeled with agreed-upon answers. It is the most reliable evaluation tool for fine-tuned LLMs. You run the golden set whenever you change anything — model, prompt, training data, or hyperparameters. Why you need a golden set: (1) Benchmarks don't reflect your task — MMLU measures general knowledge, not your specific task. A model scoring 90% on MMLU might fail at your task. (2) Automated metrics miss meaning — BLEU and ROUGE measure surface overlap, not semantic quality. A model can score 0.0 BLEU and be perfectly correct. (3) LLM-as-judge can drift — judge models change when providers update snapshots. A golden set with human labels provides a stable reference. (4) Regression detection — when you retrain or change the prompt, the golden set tells you if quality improved, stayed the same, or regressed. (5) CI/CD gate — wire the golden set into CI. If quality drops below threshold, block the deployment. How to build a golden set: (1) Curate 50-200 examples — small enough to run quickly, large enough to be statistically meaningful. Each example should be from your actual use case, not a benchmark. (2) Hand-label each example — write the ideal output for each input. This is the 'gold' in golden set. Have multiple annotators label the same examples and calculate inter-annotator agreement. (3) Include edge cases — don't just include easy examples. Include edge cases, ambiguous inputs, and challenging scenarios. The golden set should test the model's limits. (4) Cover the input distribution — include examples that cover the variety of inputs the model will face in production. Different topics, lengths, difficulty levels. (5) Never use golden set examples for training — the golden set is for evaluation only. If any golden set example appears in training data, the evaluation is contaminated. (6) Version control the golden set — track changes to the golden set over time. When you add new examples, version them. (7) Defend against drift — periodically review the golden set to ensure it still reflects your production distribution. If your production inputs have changed, update the golden set. (8) Defend against poisoning — if someone can modify the golden set, they can make a bad model look good. Restrict access and review changes. How to use the golden set: (1) Run on every change — whenever you change the model, prompt, training data, or hyperparameters, run the golden set. Compare results to the previous run. (2) Score with multiple metrics — use task-specific metrics (exact match, BLEU, ROUGE, BERTScore) AND LLM-as-judge. Multiple metrics give a more complete picture. (3) Track over time — maintain a history of golden set scores. Track trends — is quality improving, stable, or degrading? (4) Set thresholds — define minimum acceptable scores. If the model scores below threshold on any metric, block deployment. (5) Use for A/B testing — run both models (base and fine-tuned, or old and new) on the golden set. Compare scores to determine which is better. (6) Use for model selection — when comparing multiple fine-tuned models, run all of them on the golden set. Choose the one with the best scores. CI integration: (1) Use pytest-style harnesses — DeepEval, Ragas, promptfoo, Inspect AI. These wrap judge calls, compute metric aggregates, and exit non-zero on regression. (2) Typical gates — faithfulness >= 0.90, answer relevance >= 0.85, format adherence >= 0.95. (3) Block on regression — if any metric drops below threshold, the CI pipeline fails. The model cannot be deployed until the regression is fixed. (4) Run on every PR — every change to the model, prompt, or training data triggers the golden set evaluation. The key: 'Create a small, carefully curated set of examples from your actual use case. Hand-label them with agreed-upon answers. Run this set whenever you change anything. It becomes your regression baseline.' A golden set is the most reliable evaluation tool for fine-tuned LLMs. It is small, fast, and directly relevant to your task. Build one before you start fine-tuning and use it throughout the development lifecycle (wandb 2026, hld 2026, ailearnings 2026).

How do I evaluate a RAG system?

Evaluating a RAG (Retrieval-Augmented Generation) system requires different metrics than evaluating a fine-tuned LLM. RAG has two components — retrieval and generation — and both need to be evaluated. Standard LLM metrics (BLEU, ROUGE) don't work well for RAG because RAG outputs depend on retrieved context, not just the model's weights. RAG evaluation with Ragas: Ragas (RAG Assessment) is the standard framework for evaluating RAG systems. It provides reference-free metrics that don't require ground-truth answers. Ragas metrics: (1) Faithfulness — extracts atomic claims from the answer, then asks a judge LLM to mark each claim as supported (1) or not supported (0) by the retrieved context. Score = supported_claims / total_claims. A low faithfulness with high context precision means the generator is hallucinating over correct context. Critical for production RAG. (2) Answer relevance — measures how relevant the answer is to the question. The judge evaluates whether the answer actually addresses what was asked. High answer relevance with low faithfulness means the model is confidently wrong. (3) Context precision — measures whether the retrieved context is relevant to the question. Did the retrieval system find the right documents? Low context precision means the retrieval system is returning irrelevant documents. (4) Context recall — measures whether the retrieved context contains all the information needed to answer the question. Low context recall means the retrieval system is missing relevant documents. (5) Context relevancy — measures how much of the retrieved context is actually useful. High context with low relevancy means the system retrieved too many irrelevant documents. How to interpret Ragas scores: (1) High faithfulness + high answer relevance = good RAG. The answer is correct and relevant. (2) Low faithfulness + high answer relevance = hallucination. The answer sounds relevant but contains unsupported claims. Fix the generator. (3) High faithfulness + low answer relevance = poor generation. The answer is grounded in context but doesn't address the question. Fix the generator prompt. (4) Low context precision = poor retrieval. The system is retrieving irrelevant documents. Fix the retrieval system (better chunking, better embeddings, better search). (5) Low context recall = missing documents. The system can't find the right information. Fix the knowledge base (add more documents, better indexing). RAG evaluation pipeline: (1) Prepare test set — create a set of questions with expected answers. Include diverse question types (factual, reasoning, multi-hop). (2) Run the RAG system — for each question, retrieve context and generate an answer. (3) Evaluate with Ragas — compute faithfulness, answer relevance, context precision, context recall for each question. (4) Analyze results — identify patterns in failures. Are answers unfaithful? Is retrieval returning irrelevant documents? (5) Iterate — fix the identified issues (better chunking, better prompts, better embeddings). (6) Monitor in production — track Ragas metrics in production. Set up alerts for faithfulness drops. Page on faithfulness drops, not GPU utilization. Other RAG evaluation tools: (1) DeepEval — pytest-style framework for LLM evaluation. Supports RAG metrics, CI integration. (2) LangSmith — LangChain's evaluation and observability platform. Tracks RAG quality in production. (3) TruLens — production monitoring for LLM applications. Tracks RAG metrics. (4) promptfoo — CLI tool for testing prompts and models. Supports RAG evaluation. (5) Inspect AI — evaluation framework with CI integration. Production RAG monitoring: (1) Track faithfulness in production — if faithfulness drops, the model is hallucinating. (2) Track context precision — if it drops, the retrieval system is degrading. (3) Track answer relevance — if it drops, the generator is not addressing questions. (4) Use OpenTelemetry GenAI semantic conventions — standard instrumentation for LLM applications. (5) Set up alerts — page on faithfulness drops, not GPU utilization. (6) Monitor retrieval latency — if retrieval slows down, users experience delays. (7) Monitor context length — if retrieved context is too long, it wastes tokens and degrades quality. The key: 'RAG evaluation requires different metrics than LLM evaluation. Ragas provides faithfulness, answer relevance, context precision, and context recall. Wire evaluation into CI with a golden set, observe production with OpenTelemetry, and page on faithfulness drops, not GPU utilization.' RAG evaluation is about both retrieval and generation. Evaluate both components separately and together (hld 2026, machinelearningplus 2026, wandb 2026).

What is benchmark contamination and how do I avoid it?

Benchmark contamination occurs when benchmark questions and answers appear in a model's training data. The model memorizes the answers and scores well on the benchmark, but the scores don't reflect genuine capability. This is a significant problem in LLM evaluation. The scale of contamination: (1) HumanEval — roughly 40% of HumanEval has been identified as contaminated. Models that score well on HumanEval may have memorized the solutions rather than learned to code. (2) GSM8K — removing contaminated items from GSM8K drops measured accuracy by about 13 points. A model scoring 85% on contaminated GSM8K might score 72% on decontaminated GSM8K. (3) MMLU — some MMLU questions have been found in training data. The contamination rate varies by subject. (4) General problem — as models are trained on more internet data, the chance of benchmark contamination increases. Most web-scraped training corpora include benchmark questions. How contamination happens: (1) Web scraping — benchmarks are published online. When training data is scraped from the web, benchmark questions and answers are included. (2) Synthetic data — if synthetic data is generated using a model that was trained on benchmarks, the synthetic data may contain benchmark questions. (3) Data collection — if training data is collected from forums (Stack Overflow, Reddit), it may contain benchmark discussions and solutions. (4) Multi-stage training — if a model is fine-tuned on data that includes benchmarks, the model memorizes them. Impact of contamination: (1) Inflated scores — the model appears more capable than it is. Scores on contaminated benchmarks are not reliable. (2) False confidence — teams believe their model is better than it is, leading to poor production performance. (3) Misleading comparisons — comparing a contaminated model to a non-contaminated model is unfair. The contaminated model appears better. (4) Poor generalization — a model that memorized benchmarks may not generalize to real tasks. How to detect contamination: (1) Suspiciously high scores — if your model scores 99% on a benchmark when similar models score 80%, suspect contamination. (2) Exact output matching — if the model produces benchmark answers verbatim, including formatting and explanations, it has memorized them. (3) Permutation testing — slightly modify benchmark questions (change names, numbers, context). If the model's performance drops dramatically on modified questions, it memorized the originals. (4) N-gram matching — search your training data for benchmark questions. Tools: n-gram matching against benchmark datasets. How to avoid contamination: (1) Use private golden set — maintain a private domain-specific golden set that never leaves your infrastructure. This set is not published online and cannot be scraped into training data. (2) Decontaminate training data — search your training data for benchmark questions and remove them. Tools: n-gram matching against benchmark datasets. (3) Use decontaminated benchmarks — some benchmarks provide decontaminated versions. Use these when available. (4) Create custom benchmarks — build your own benchmark from your domain data. This cannot be contaminated by web scraping. (5) Use temporal splits — if your data has timestamps, use only data from before the benchmark was published. (6) Permutation testing — modify benchmark questions and re-test. If performance drops, the model has memorized the originals. (7) Use multiple benchmarks — if a model scores well on one benchmark but poorly on others, suspect contamination on the high-scoring benchmark. (8) Use benchmarks published after training cutoff — benchmarks published after the model's training data cutoff cannot be contaminated. Best practices: (1) Use public benchmarks as directional signal only — MMLU, GSM8K, HumanEval are useful for comparison but may be contaminated. Don't rely on them as the sole measure of quality. (2) Maintain a private golden set — this is your most reliable evaluation tool. It cannot be contaminated. (3) Decontaminate your training data — search for and remove benchmark questions before training. (4) Test on modified benchmarks — permute questions to detect memorization. (5) Track scores over time — if a model's benchmark scores suddenly jump after a new training run, suspect contamination. (6) Be transparent — if you publish benchmark scores, disclose whether you decontaminated the training data. The key: 'Roughly 40% of HumanEval has been identified as contaminated, and removing contaminated items from GSM8K drops measured accuracy by about 13 points. Use public benchmarks as directional signal only. Maintain a private domain-specific golden set that never leaves your infrastructure.' Benchmark contamination is a real and significant problem. Don't rely on public benchmarks alone. Build a private golden set and decontaminate your training data (hld 2026, ailearnings 2026).

July 13, 2026

TL;DR — Evaluate fine-tuned LLM in 2026: three layers — benchmarks (MMLU 57 subjects, HumanEval pass@k, HellaSwag), metrics (BLEU, ROUGE, BERTScore, perplexity), judgment (LLM-as-judge 80%+ human agreement, human eval). lm-evaluation-harness: 60+ benchmarks, supports LoRA, vLLM. Overfitting: validation loss vs training loss. Catastrophic forgetting: compare vs base on MMLU/HellaSwag. Golden set: 50-200 curated examples, run on every change. CI: faithfulness >= 0.90, answer relevance >= 0.85. RAG: Ragas faithfulness, context precision, answer relevance. Contamination: 40% of HumanEval contaminated, GSM8K drops 13 points decontaminated. Best practices: multiple metrics, compare vs base, calibrate judge (r > 0.8), build golden set, wire into CI, monitor production.

How to Evaluate a Fine-Tuned LLM in 2026: Metrics, Benchmarks, LLM-as-Judge, and Production Monitoring

Evaluation is not one problem — it is several. You need metrics for training monitoring, metrics for capability measurement, and metrics for production quality. Each serves a different purpose and none is a substitute for the others. The most common evaluation mistake is measuring the wrong thing.

Key Statistics

Metric	Value	Source
GPT-4 judge vs human agreement	80%+ on MT-Bench	hld 2026
HumanEval contamination	~40%	hld 2026
GSM8K decontamination drop	~13 points	hld 2026
G-Eval Spearman correlation	0.514 with human	hld 2026
lm-evaluation-harness benchmarks	60+	eleutherai 2026
Golden set size	50-200 examples	wandb 2026
Judge calibration threshold	r > 0.8	ailearnings 2026
CI faithfulness gate	>= 0.90	hld 2026
CI answer relevance gate	>= 0.85	hld 2026
MMLU top model score	85-90%	wandb 2026

Evaluation Layers

Layer	What It Measures	Tools	When to Use
Benchmarks	Model comparison	MMLU, HumanEval, HellaSwag, lm-eval-harness	Model selection, regression detection
Metrics	Task-specific quality	BLEU, ROUGE, BERTScore, perplexity, pass@k	After training, on held-out data
Judgment	Qualitative quality	LLM-as-judge, human eval, A/B testing	Before shipping, in production
Golden set	Your actual task	Custom examples, hand-labeled	Every change, CI/CD gate
RAG metrics	RAG pipeline quality	Ragas (faithfulness, context precision)	RAG systems

Sources: ailearnings (2026), machinelearningplus (2026), wandb (2026), hld (2026).

Metrics Comparison

Metric	What It Measures	Best For	Limitations
Perplexity	Next-token prediction quality	Training monitoring	Doesn't measure task performance
BLEU	N-gram overlap (precision)	Translation, template output	Punishes paraphrasing
ROUGE	N-gram overlap (recall)	Summarization	Surface-level only
BERTScore	Semantic similarity	Open-ended generation	Slower than BLEU/ROUGE
Exact match	Correctness	Structured output (JSON, SQL)	Only for single-answer tasks
pass@k	Code correctness	Code generation	Requires unit tests
LLM-as-judge	Quality, helpfulness	Open-ended tasks	Judge bias, cost, drift
Human eval	Ground truth quality	High-stakes, calibration	Expensive, slow

Sources: machinelearningplus (2026), wandb (2026), hld (2026).

Evaluation Strategy by Phase

flowchart TD Train["During Training"] --> Perplexity["Track perplexity\nand validation loss\nIf val loss ↑ while\ntrain loss ↓ → overfitting\nStop training"] Perplexity --> After["After Training"] After --> TaskEval["Task-specific evals\nBLEU, ROUGE, BERTScore\nexact match, pass@k\nOn held-out 10-15%"] After --> Benchmark["Benchmark suite\nMMLU, HellaSwag\nCompare vs base model\nDetect catastrophic forgetting"] TaskEval --> Ship["Before Shipping"] Benchmark --> Ship Ship --> Judge["LLM-as-judge\nScore on correctness,\nhelpfulness, safety\nCalibrate vs human (r > 0.8)"] Ship --> Human["Human evaluation\n50-100 outputs\nRate quality\nGold standard"] Ship --> Golden["Golden set\n50-200 curated examples\nRun on every change\nCI/CD gate"] Judge --> Prod["In Production"] Human --> Prod Golden --> Prod Prod --> Monitor["Monitor\nQuality metrics\nUser feedback\nError rates\nFaithfulness drops\nSet up alerts"] Monitor --> Iterate["Iterate\nRetrain with new data\nUpdate golden set\nRe-evaluate\nDeploy if passes gates"] Iterate --> Prod

Source: ailearnings (2026), wandb (2026), hld (2026).

Benchmark Comparison

Benchmark	Tasks	Metric	Top Score	Contamination Risk
MMLU	57 subjects, multiple choice	Accuracy	85-90%	Moderate
HumanEval	164 Python problems	pass@k	85-95%	High (~40%)
HellaSwag	Commonsense reasoning	Accuracy	85-90%	Low
GSM8K	Grade school math	Accuracy	85-90%	High (13pt drop)
Winogrande	Coreference resolution	Accuracy	80-85%	Low
MT-Bench	Multi-turn conversation	LLM-as-judge	8-9/10	Low
SWE-Bench	Software engineering	pass@k	20-40%	Moderate

Sources: wandb (2026), hld (2026), machinelearningplus (2026).

RAG Evaluation Metrics (Ragas)

Metric	What It Measures	Good Score	Problem Indicated
Faithfulness	Claims supported by context	>= 0.90	Low = hallucination
Answer relevance	Answer addresses question	>= 0.85	Low = poor generation
Context precision	Retrieved docs relevant	>= 0.80	Low = poor retrieval
Context recall	All needed docs retrieved	>= 0.80	Low = missing documents

Source: hld (2026), machinelearningplus (2026).

Implementation Guide

Phase	What to Do	Timeline
1. Build golden set	50-200 curated examples, hand-labeled	1-2 weeks
2. Benchmark base model	Run MMLU, HellaSwag on base model	1 day
3. Fine-tune	SFT with LoRA/QLoRA, monitor validation loss	1-3 hours
4. Detect overfitting	Compare training vs validation loss	During training
5. Benchmark fine-tuned	Run same benchmarks on fine-tuned model	1 day
6. Detect forgetting	Compare fine-tuned vs base on benchmarks	1 day
7. Task-specific eval	BLEU, ROUGE, BERTScore, exact match on held-out	1-2 days
8. LLM-as-judge	Score 50-100 outputs on quality dimensions	1 day
9. Calibrate judge	Compare judge scores to human ratings (r > 0.8)	1-2 days
10. Human evaluation	Have 3+ evaluators rate outputs	1 week
11. Wire into CI	Golden set as CI gate, block on regression	1-2 days
12. Deploy	Deploy if all gates pass	1 day
13. Monitor production	Track quality, faithfulness, user feedback	Ongoing

Best Practices

Use multiple metrics — no single metric captures LLM quality. Combine surface metrics (BLEU, ROUGE) with semantic metrics (BERTScore) and judgment (LLM-as-judge). If all metrics move together, you're making real progress (wandb 2026).
Always compare against the base model — run the same benchmarks on both base and fine-tuned models. This tells you if fine-tuning improved your task and how much general capability was lost (ailearnings 2026).
Build a golden set — 50-200 curated examples from your actual use case, hand-labeled. Run on every change. Wire into CI as a quality gate. This is your most reliable evaluation tool (wandb 2026).
Calibrate LLM-as-judge — compare judge scores to human ratings on 50-100 outputs. If correlation is r > 0.8, the judge is reliable. Use the same judge consistently — different judges have different biases (ailearnings 2026).
Monitor validation loss — if validation loss increases while training loss decreases, stop training. You're overfitting. The model is memorizing, not learning (ailearnings 2026).
Use public benchmarks as directional signal only — 40% of HumanEval is contaminated. GSM8K drops 13 points when decontaminated. Maintain a private golden set that can't be contaminated (hld 2026).
Wire evaluation into CI — use pytest-style harnesses (DeepEval, Ragas, promptfoo). Block deployment on regression. Typical gates: faithfulness >= 0.90, answer relevance >= 0.85 (hld 2026).
Monitor in production — track quality metrics, user feedback, error rates, and faithfulness. Set up alerts for quality degradation. Page on faithfulness drops, not GPU utilization (hld 2026).

For related topics, see our how to fine-tune LLM, LoRA vs QLoRA, training data preparation, domain-specific AI, and small language models guides.

FAQ

What is lm-evaluation-harness and how do I use it?

lm-evaluation-harness (EleutherAI) is the standard framework for evaluating language models on academic benchmarks. It is the backend for HuggingFace's Open LLM Leaderboard and is used internally by NVIDIA, Cohere, BigScience, BigCode, Nous Research, and Mosaic ML. What it provides: (1) 60+ standard academic benchmarks — MMLU, HellaSwag, Winogrande, HumanEval, GSM8K, TruthfulQA, ARC, and more. Hundreds of subtasks and variants. (2) Multiple model backends — HuggingFace transformers (including GPTQ and AutoGPTQ quantization), vLLM, llama.cpp, OpenAI API, TextSynth. (3) LoRA adapter support — evaluate LoRA adapters directly using HuggingFace's PEFT library. No need to merge adapters before evaluation. (4) Reproducible evaluation — publicly available prompts ensure reproducibility and comparability between papers. (5) Custom prompts and metrics — easy support for custom prompts and evaluation metrics for domain-specific tasks. (6) Visualization — integrate with Weights & Biases (W&B) and Zeno for visualizing and analyzing results. How to use it: (1) Install — pip install lm-eval. (2) Run benchmarks on your model — lm_eval --model hf --model_args pretrained=./merged-model,dtype=bfloat16 --tasks mmlu,hellaswag,winogrande --device cuda:0 --batch_size 8 --output_path ./eval_results/. (3) Run benchmarks on base model — lm_eval --model hf --model_args pretrained=meta-llama/Meta-Llama-3-8B-Instruct,dtype=bfloat16 --tasks mmlu,hellaswag,winogrande --device cuda:0 --batch_size 8 --output_path ./eval_results/base/. (4) Compare results — compare fine-tuned vs base model scores. If fine-tuned scores lower on MMLU/HellaSwag, catastrophic forgetting has occurred. (5) Evaluate LoRA adapters — lm_eval --model hf --model_args pretrained=meta-llama/Meta-Llama-3-8B-Instruct,peft=./lora-adapter --tasks mmlu. No need to merge. (6) Use vLLM for faster evaluation — lm_eval --model vllm --model_args pretrained=./merged-model --tasks mmlu,hellaswag --batch_size 32. vLLM is faster than HuggingFace for generative tasks. (7) Log to W&B — add --log_samples --wandb_args project=llm-eval to log results and samples to Weights & Biases. Tips: (1) Start with --limit 10 — verify answer extraction and scoring on a few examples before running the full benchmark. (2) Use HuggingFace as reference — vLLM occasionally differs from HuggingFace. Use the model_comparator.py script to check validity. (3) Check data integrity — use --check_integrity to verify benchmark data hasn't been corrupted. (4) Use consistent settings — same batch size, device, and dtype for fair comparisons between models. The key: 'lm-evaluation-harness is the standard framework for evaluating language models. It provides 60+ benchmarks, supports LoRA adapters, vLLM, and OpenAI. It is the backend for HuggingFace's Open LLM Leaderboard.' Use it to benchmark your fine-tuned model against the base model and detect catastrophic forgetting (eleutherai 2026, ailearnings 2026)."