TL;DR: Evaluation-Driven Development (EDD) is test-driven development for LLM systems: write the eval suite and a small "golden" dataset before or alongside the feature, and require every change to clear it before shipping. In 2026 it's moved from a niche practice to the default way serious teams ship anything backed by an LLM.
Why TDD alone doesn't work for LLM features
Traditional unit tests check for exact, deterministic outputs. LLM outputs are probabilistic and can be correct in more than one phrasing, which makes naive assert-equals tests either too brittle or too loose to mean anything. EDD adapts the spirit of TDD — define the bar before you build — while swapping exact-match assertions for graded metrics, often scored by another LLM acting as a judge.
The core workflow
- Curate a small, high-quality "golden" dataset — commonly on the order of 100–500 examples — that exercises real failure modes, not just happy paths.
- Define a handful of metrics that actually correlate with what "good" means for the feature: factual correctness, tool-calling accuracy, refusal behavior, tone, latency, or safety (prompt injection, PII leakage, jailbreak resistance).
- Write one evaluator per metric, run it against the golden set, and treat a passing score as the release gate — enforced in CI on every pull request, not just before a big release.
EDD vs. classic TDD, side by side
- Dataset: EDD favors a small number of carefully curated goldens over an exhaustive test suite — quality over volume, since each case may cost real API spend to run.
- Judgement: Many EDD checks are graded (LLM-as-judge, similarity scoring) rather than a strict pass/fail assertion.
- Cost and speed: classic unit tests are essentially free and instant; eval runs cost money and take longer, which is why teams split them into fast "unit-style" checks for local iteration and slower full regression suites for CI.
Why 2026 is the tipping point
Frontier models change underneath a team's prompts every few weeks as providers ship new versions. An eval suite that runs automatically on every change is the only reliable way to catch a silent regression when the underlying model shifts — which is exactly why EDD has become baseline practice rather than a nice-to-have for teams building on top of frontier LLMs.
FAQ
How big does a golden dataset need to be?
Research behind approaches like LIMA suggests that a few hundred to a thousand carefully curated examples can be enough to meaningfully align and evaluate a system — the emphasis is on curation quality, not raw volume.
Do evals replace human review entirely?
No. Evals catch regressions cheaply and continuously; human review still matters for judgment calls the automated metrics weren't designed to catch, especially for new failure modes.
What tools do teams use to run EDD?
Open-source and commercial eval frameworks such as DeepEval and Promptfoo are common choices for defining metrics, running them against golden datasets, and wiring the results into CI.
Further reading:
No comments
Post a Comment