LLM Evaluation: Metrics and LLM-as-Judge
LLM evaluation measures whether a generative application is good enough to ship and stays good once running. The decision rule is: use reference-based metrics (ROUGE, BLEU, BERTScore) when a known correct answer exists, use reference-free judged metrics (groundedness, relevance, coherence) when it does not, and always check retrieval separately from generation. Accuracy, the classifier’s metric, rarely applies, because there is usually no single right answer.
Two moments: offline and online
Offline evaluation runs before release on a fixed test set: questions, optionally reference answers and retrieved context, run against each version of the prompt, model or index. The set is fixed so a score change can be attributed to the change you made. Online evaluation scores a sample of real production traffic on a schedule, plus user feedback and operational data such as latency and token cost. Offline answers “should this version ship?”, online answers “is it still good?” and catches things a test set missed, such as new question types or a stale document index. A mature setup uses both, and offline evaluation runs automatically in a CI pipeline with thresholds that fail the build (see CI/CD explained).
Metrics that need a reference answer
These compare generated text with a human-written reference.
| Metric | What it compares | Typical task |
|---|---|---|
| ROUGE | Overlap of words or word sequences with the reference, recall-oriented | Summarisation |
| BLEU | Overlap of word sequences, precision-oriented | Machine translation |
| BERTScore | Similarity of contextual embeddings, so paraphrases score well | Any text where wording varies |
Overlap metrics punish a correct answer worded differently, and reward a fluent wrong answer that reuses the reference’s words. BERTScore reduces the first problem by comparing meaning in embedding space rather than exact words (see embeddings and vector search). None of them detects whether a statement is true.
Metrics that need no reference
For RAG and agents, the useful questions are about the answer relative to the question and the retrieved content.
| Metric | Question it answers | Needs |
|---|---|---|
| Groundedness (faithfulness) | Is every claim supported by the retrieved context? | Response, context |
| Relevance | Does the answer address what was asked? | Query, response |
| Coherence and fluency | Is it logically connected and well formed? | Response |
| Retrieval quality | Did the right documents come back? | Query, context, often ground truth |
| Safety | Is there harmful, biased or leaked content? | Response |
Groundedness is the one examined most, because it catches the characteristic RAG failure: a fluent, relevant, confident answer that the sources do not support. Microsoft Foundry and Amazon Bedrock both document judged metrics of this kind, with Bedrock’s RAG evaluations listing correctness, completeness, helpfulness, logical coherence and faithfulness for the answer, and context relevance and coverage for retrieval. Names differ by vendor; the meaning is the same. If quality drops, test retrieval first: if the right passage was never retrieved, no prompt change will fix it (see RAG explained).
LLM-as-a-judge
Instead of humans scoring thousands of outputs, a second model scores each one against a rubric and gives an explanation. Bedrock calls these judge-model evaluation jobs; Foundry’s quality evaluators are mostly AI-assisted in the same way. It scales, and it works without references. Its weaknesses are known and examinable:
- Judges tend to favour longer answers and answers resembling their own style.
- Scores can vary with the rubric wording or position of options when comparing two answers.
- The judge costs tokens and needs its own deployment.
- It should be calibrated against a sample of human ratings, which stay the reference for subjective quality.
So the usual pattern is automatic metrics and a judge for breadth, human review for a sample and for high-stakes cases.
A small worked run
A support assistant answers from a policy library. The team builds 40 test questions: 25 ordinary, 5 the assistant should decline, 5 adversarial, 5 whose answer is not in the documents. They run version A and B of the prompt.
| Version A | Version B | |
|---|---|---|
| Relevance (mean 1 to 5) | 4.6 | 4.7 |
| Groundedness (mean 1 to 5) | 3.1 | 4.4 |
| Mean completion tokens | 210 | 240 |
The difference is groundedness, not relevance, so B is better where it matters, at a small token cost. Had both stayed low, the next check would be retrieval quality on the same questions. Before shipping, a slice of B’s answers is reviewed by humans to confirm the judge agrees.
Which exams test this
| Exam | How the topic appears | Where on this site |
|---|---|---|
| AI-103 | Implement generative AI and agentic solutions (30–35%): evaluating models and apps for fabrications, relevance, quality and safety, and evaluating agent behaviour; Plan and manage (25–30%): evaluators and safety evaluations as responsible AI instrumentation | Generative AI and agents |
| AI-300 | Implement generative AI quality assurance and observability (10–15%): test datasets, groundedness, relevance, coherence and fluency, risk and safety evaluations, automated evaluation workflows, continuous monitoring and tracing | Quality and observability |
| AIF-C01 | Applications of Foundation Models (28%), task 3.4: human-in-the-loop evaluation, benchmark datasets, Amazon Bedrock Model Evaluation, the metrics ROUGE, BLEU, BERTScore and LLM-as-a-judge, and evaluating RAG apps and agents | Foundation model applications |
| Databricks GenAI Engineer | Evaluation and Monitoring (12%): choosing metrics, MLflow scoring and tracing, judges that need ground truth, custom scorers, inference tables and Agent Monitoring for live endpoints | Governance and evaluation |
| MLA-C02 | ML Model and FM Development (24%): BLEU, ROUGE, BERTScore and semantic similarity, LLM-as-a-judge frameworks, human evaluation of generated text, and RAG retrieval accuracy | MLA-C02 model and FM development |
| AB-620 | Test and manage agents (20–25%): creating a test set, choosing an evaluation method and reviewing results for a Copilot Studio agent | Test and manage |
| Agentforce Specialist | Testing, Deployment, and Maintenance (10%): how Testing Center evaluations of an agent work. A small share of the exam | Testing and governance |
How the questions are built
- “Supported by the retrieved documents” or “hallucination in a RAG app” is groundedness. “On topic” is relevance. Do not swap them.
- “Summarisation compared with a reference summary” points to ROUGE; “translation” to BLEU; “paraphrases should score well” to BERTScore.
- “No reference answers available” rules out ROUGE, BLEU and BERTScore and points to a judged metric.
- “Before release” is offline evaluation; “after deployment” or “sampled live traffic” is online.
- “Which step failed, retrieval or generation” asks for evaluating retrieval separately.
Practice questions
Question 1. A RAG chatbot produces fluent answers that sometimes include policy details found in none of the retrieved documents. The team needs a number that tracks this problem across releases. Which metric should they report?
- A. Fluency
- B. Relevance
- C. Groundedness
- D. Coherence
Show answer
Answer: C
Groundedness measures whether the answer is supported by the retrieved context, which is exactly the fabrication being described. Fluency and coherence measure language quality, and relevance only checks the answer addresses the question, so a fabricated but on-topic answer can still score well on them.
Question 2. A team has thousands of generated product descriptions and no human-written reference text. They want a scalable quality score using a rubric for tone and completeness. What is the most suitable approach?
- A. Compute ROUGE against the product titles
- B. Use a judge model with a rubric, validated against a sample of human ratings
- C. Compute BLEU against the previous version
- D. Have one reviewer read every description
Show answer
Answer: B
An LLM acting as judge scores outputs against a rubric without reference text and scales to thousands of rows, ideally calibrated on a human-rated sample. ROUGE and BLEU require reference texts. Having a person read every description does not scale.
Go deeper
- Evaluate the performance of Amazon Bedrock resources, AWS documentation
- Observability in generative AI, Microsoft Learn
- Evaluate and monitor GenAI apps, Databricks documentation
- Related on this site: RAG explained, fine-tuning vs RAG vs prompting, MLOps basics