llm-evaluation

Overview

LLM evaluation is the discipline of measuring what your model or system actually does, not what you believe it does. Without systematic evaluation, you are guessing. With it, you catch regressions before users do.

When to Use

• Before deploying any LLM-powered feature
• When changing a model version, provider, or prompt
• When users report quality issues
• As a recurring health check for production LLM features

Process

Step 1: Define the evaluation dimensions

Common dimensions (pick those relevant to your task):

• Correctness — Is the answer factually right?
• Relevance — Does the answer address the question?
• Groundedness — Is the answer supported by the provided context?
• Safety — Does the output avoid harmful content?
• Format — Does the output match the required schema/format?
• Tone/Style — Does the output match the required voice?
• Latency — Is the response fast enough?
• Cost — Is the per-request cost within budget?

Step 2: Build the evaluation dataset

A good eval dataset:

• Covers the full distribution of expected inputs (not just the easy cases)
• Includes adversarial examples and edge cases
• Has verified ground-truth answers for correctness dimensions
• Has at least 100 examples for production features; 1000+ for critical systems
• Is versioned and never modified (only appended to)

Step 3: Choose evaluation methods

• Automated exact match — for structured outputs with known correct answers
• Automated metric — BLEU/ROUGE for text overlap, custom scoring functions
• LLM-as-judge — use a strong model (GPT-4, Claude Opus) to score outputs on rubrics; calibrate against human judgments
• Human evaluation — ground truth; use for calibrating automated evals

Step 4: Implement automated evals in CI

Every change to a prompt, model version, or system prompt must trigger the eval suite in CI. Define a threshold: "if correctness drops below 85% or safety failures increase, block the PR."