An LLM-as-Judge Won't Save The Product—Fixing Your Process Will
- Source
- eugeneyan.com
- Author
- Eugene Yan
- Date
Context
An automated evaluator becomes useful when a team has already identified what failure looks like. In the evaluation-process essay, Eugene Yan recommends inspecting real outputs, labeling defects and testing explanations for why they happen.
A proposed fix then needs a baseline comparison: changing a prompt or retrieval step should produce a measurable improvement on the relevant examples. Human labels can also be used to check an before extending it to more outputs. Continued sampling and user feedback keep that checking process connected to actual product behavior as the system changes.
- eval — A repeatable test for AI quality — a set of tasks plus scoring — used the way software teams use test suites, because model output is too variable to judge by eyeballing.
- LLM-as-judge — Using one model to score another's output against a rubric, so quality can be measured at a scale human grading cannot reach.
“Evals aren’t static artifacts or quick fixes; they’re practices that apply the scientific method, eval-driven development, and AI output monitoring.”
Eugene Yan
“Building product evals is simply the scientific method in disguise. That’s the secret sauce.”
Eugene Yan
“Ideally, we should have a 50:50 split of passes and fails that spans the distribution of inputs.”
Eugene Yan
“While automated evals help scale monitoring, they can’t compensate for neglect. If we’re not actively reviewing AI outputs and customer feedback, automated evaluators won’t save our product.”
Eugene Yan
“First, write some evals; then, build systems that pass those evals.”
Eugene Yan
Checking sign-in…
Loading comments…