Standard software testing relies on deterministic assertions. LLM testing relies on statistical distributions. Choosing the wrong metric leads to "benchmark chasing" where a model improves on paper but regresses in the hands of users.
| Metric Type | Example | Use Case | Limitations |
|---|---|---|---|
| Deterministic | Exact Match, JSON Schema Validity | Code Gen, Extraction, Structured I/O | Too rigid for creative tasks. |
| N-Gram Overlap | ROUGE-L, BLEU | Summarization, Translation | Penalizes synonyms; blind to factual correctness. |
| Model-Based | BERTScore, G-Eval | Semantic alignment, nuance | High cost; potential "Judge Bias". |
| Human-in-the-Loop | Likert Scale, Pairwise Pref | Final product validation | Extremely slow and expensive. |
For engineering tasks, n-gram overlap is useless. We use Pass@k. A model generates n samples for a coding problem. If c samples pass the unit tests, the probability that at least one of k samples passes is:
Practitioner Note: In production, always report Pass@1. Pass@10 and Pass@100 are often used to inflate results in academic papers.
Evaluating a Retrieval-Augmented Generation system requires breaking the problem into two parts: retrieval quality and generation quality.
Using a model like GPT-4o to grade a smaller model (e.g., Llama 3) is now the industry standard for subjective tasks.
# Reference rubric for a Judge LLM
JUDGE_PROMPT = """
Evaluate the assistant's response based on Accuracy and Conciseness.
Score 1-5.
A score of 5 means the answer contains zero hallucinations and no fluff.
Context: {retrieved_context}
Question: {user_query}
Response: {assistant_response}
"""
CRITICAL: Judge Calibration. You must manually grade 100 samples alongside the Judge LLM. If your agreement rate is below 80%, your rubric is too vague.