Large Language Model Evaluation
LLM evaluation measures how well a large language model performs on specific tasks through benchmarks, human judgments, and automated metrics. It assesses accuracy, safety, reasoning, hallucination rates, and task-specific quality to inform model selection and improvement.
itArtificial intelligence and machine learning | OpenSkills.info
Intro
Large Language Model Evaluation
Large language model evaluation is the practice of measuring how well a model or an application built on one performs against defined criteria — accuracy, safety, tone, cost, latency, and task success among them. It exists because generative models don't fail the way traditional software does. A function either returns the right value or it doesn't; a language model can be right, wrong, partially right, right but badly phrased, or confidently wrong in a way no unit test catches.
Evaluation is what turns "the demo looked good" into a measurable, repeatable judgment you can act on before and after shipping.
Why LLM evaluation is hard
Three properties of generative models break the testing habits most engineers already have.
- No single correct output. A summarization or chat response can be phrased many valid ways. There is rarely one string to assert equality against.
- Non-determinism. The same input can produce different outputs across calls, especially at nonzero sampling temperature, so a single pass/fail run tells you less than it would for deterministic code.
- Multidimensional quality. A response can be factually correct but off-tone, or on-topic but unsafe, or fast but wrong. One metric rarely captures whether an output is actually good enough to ship.
These properties don't make evaluation optional — they make it a distinct discipline, with its own methods, rather than an extension of unit testing.
Continue the course
This section is part of the paid course.
See pricing to subscribe, or log in if you already have access.
Where this skill leads
Relevant careers
See how this topic contributes to broader role-level skill maps.
Sources
- https://developers.openai.com/api/docs/guides/evaluation-best-practices
Supports
- Evaluations are a continuous process, not a one-time launch activity
- Five-step evaluation workflow: define success criteria, collect representative dataset, specify metrics, run and compare evals, continuously evaluate
- Metric-based evals (exact match, ROUGE/BLEU, function call accuracy) for automated regression testing
- Human evals as highest quality but expensive and slow
- LLM-as-judge subtypes: pairwise comparison, single-answer grading, reference-guided grading
- Evaluation needs vary by architecture: single-turn, workflows, single-agent, multi-agent
- Vibe-based evals and generic academic metrics disconnected from production are anti-patterns
- https://developers.openai.com/api/docs/guides/evals
Supports
- Evals API for configuring evaluations programmatically or via dashboard
- https://github.com/openai/evals
Supports
- Evals is an open-source framework and registry of benchmarks for evaluating LLMs and LLM systems
- https://platform.claude.com/docs/en/docs/test-and-evaluate/develop-tests
Supports
- Success criteria should be specific, measurable, achievable, and relevant
- Evaluation dimensions include task fidelity, consistency, relevance and coherence, tone and style, privacy, context utilization, latency, price
- Grading methods: exact match/string comparison, similarity-based metrics (cosine similarity, ROUGE-L), LLM-based grading (Likert scale, binary classification, ordinal scales)
- Evaluations should mirror real-world task distribution and factor in edge cases
- Prioritize volume with automated grading over fewer hand-graded tests
- Example multidimensional target table (task fidelity F1, safety toxicity rate, error severity, latency)
- https://docs.cloud.google.com/vertex-ai/generative-ai/docs/models/run-evaluation
Supports
- Computation-based evaluation (no model inference) vs. model-based evaluation (judge models)
- Pointwise evaluation (individual outputs) vs. pairwise evaluation (comparing two outputs, AutoSxS)
- General evaluation workflow: define metrics, prepare dataset, run evaluation, interpret results
- https://docs.cloud.google.com/vertex-ai/generative-ai/docs/model-reference/evaluation
Supports
- Gen AI evaluation service lets you evaluate LLMs with custom criteria, returning task-specific metrics
- Metric types include model-based metrics (PointwiseMetric, PairwiseMetric) and in-memory computed metrics (ROUGE, BLEU, tool function-call metrics)
- Batch evaluation for large datasets via asynchronous long-running operations
- Agent evaluation metrics for AI agents built with different frameworks
- https://learn.microsoft.com/en-us/azure/foundry/how-to/evaluate-generative-ai-app
Supports
- Evaluations measure performance, quality, and safety before deployment and to monitor production quality after
- Built-in evaluators cover general-purpose quality (coherence, fluency), RAG-specific metrics (groundedness, relevance), safety/security metrics, and agent-specific metrics (tool call accuracy, task completion)
- Three metric categories: AI Quality (AI-Assisted), AI Quality (NLP), Risk and Safety
- Agentic metrics: Intent Resolution, Tool Call Accuracy, Task Adherence
- Integration with Azure Monitor Application Insights for real-time dashboards tracking operational metrics, token consumption, latency, error rates, quality scores
- https://crfm-helm.readthedocs.io/en/latest/
Supports
- HELM is an open-source Python framework created by Stanford CRFM for holistic, reproducible, transparent evaluation of foundation models
- HELM taxonomizes scenarios (use cases) and metrics (desiderata) rather than relying on a single aggregate score
- HELM evaluates across multiple dimensions including accuracy, fairness, robustness, and efficiency
- https://github.com/stanford-crfm/helm
Supports
- HELM is an open source Python framework for holistic, reproducible, and transparent evaluation of foundation models, including LLMs and multimodal models