3. LLM Evaluation

Part 3

Language models produce open-ended text, which makes scoring harder than classification. This part covers the practical toolkit: humans, LLM judges, pairwise comparisons, rubrics, and the specialized checks for hallucination, faithfulness, groundedness, instruction following, structured output, and standard benchmarks.

Human Evaluation

People read model answers and rate them against a scale. It is the most direct measure of what users experience and remains the gold standard for quality, tone, and helpfulness. Its costs are real: slow, expensive, and subjective. Manage that subjectivity with clear rubrics, multiple raters per example, and agreement checks.

LLM-as-a-Judge

A separate model — often a stronger one — rates the candidate answer. You give the judge a prompt, the question, and the answer, and ask for a score plus a reason.

SYSTEM: You are a strict grader. Score the assistant answer 1-5.
Use these anchors:
  1 = irrelevant or harmful
  3 = correct but incomplete
  5 = correct, complete, and well-structured

QUESTION: {question}
ASSISTANT ANSWER: {answer}

Output JSON: {"score": int, "reason": "..."}

Pairwise Comparison

Instead of absolute scores, show two answers (A and B) to a rater and ask which is better, or whether they tie. Humans and models both find "which is better?" far more reliable than "how good is this?" The results are commonly combined with Bradley-Terry or Elo-style models to turn wins and losses into a single strength number per system.

Rubric Engineering

A rubric turns "good answer" into concrete, checkable criteria. Write each level so a different rater would reach the same score. Good rubric anchors name observable properties: "explains why, not just what," "cites a specific source," "contains no fabricated statistics." Test the rubric on a sample first; if two raters disagree, tighten the wording.

Hallucination Detection

Hallucination means the model produced content that is not supported by its sources — a made-up fact, a wrong date, a nonexistent citation. Detecting it is the difference between "sounds confident" and "is correct." Detection approaches include: fact-checking claims against a knowledge base, cross-checking the answer against the retrieved context, and LLM judges prompted to flag unsupported statements.

Faithfulness

Faithfulness asks: does the answer stay consistent with the information it was given? In RAG, an answer can be unfaithful even when every sentence sounds plausible, if the model twisted the meaning of the source. Judge it by checking whether the answer is entailed by the provided context.

Groundedness

Groundedness extends faithfulness to reality: every claim should trace back to a verifiable fact, not just to the prompt's context. A grounded answer can point to the source of each statement; an ungrounded one cannot. In practice, check two things: no invented content, and every important claim covered by evidence.

Instruction Following

Models are judged on whether they actually obey the user's instructions: answering in the requested format, respecting length limits, not being asked for a summary and delivering an essay. Build test cases that probe specific constraints (tone, length, structure, language) and score the output against each constraint separately.

Structured Output Validation

For production use, models are often asked to emit JSON or XML. Validation checks that the output parses, contains the required fields, and that values match expected types and allowed enums. This is usually cheap, deterministic, and non-negotiable before the output can be consumed by an API.

import json
try:
    data = json.loads(output)
    required = {"name": str, "price": float}
    ok = all(isinstance(data.get(k), t) for k, t in required.items())
except json.JSONDecodeError:
    ok = False

Benchmark Evaluation

Standard benchmarks let you compare models against published results using fixed prompts and scoring. Familiar examples include MMLU for knowledge, HumanEval and SWE-bench for code, and MT-Bench for conversation quality. Benchmarks are valuable for choosing models, but they saturate and can be overfitted, so pair them with task-specific evaluation of your own golden dataset.