LLM applications should be evaluated against explicit rubrics before they are deployed, since free-text quality is difficult to measure directly.
2
A useful rubric defines the task goal, breaks quality into measurable components, describes performance levels, and assigns scores to each component.
3
Teams should manually grade validation examples, compare those grades with an evaluator LLM, adjust the rubric and prompt, then keep checking calibration after deployment.
Summary
Stephanie Kirmer applies her experience teaching college classes to LLM evaluation. She argues that teams should not put an LLM into production based on confidence or informal metrics. For free-text responses, they can define a rubric that states what a successful answer must do, such as being friendly, professional, complete, and on topic. The rubric should describe performance levels clearly enough that a person can distinguish between adjacent scores. Kirmer recommends creating validation examples with different failure modes, grading them manually, asking an evaluator LLM to grade the same examples, and adjusting the evaluator prompt until its scores match the human grades. Teams can then use the evaluator to monitor production outputs, detect drift, support prompt work, or block low-scoring responses. She is also clear about the limits: LLMs are imperfect evaluators, some tasks are poor fits, and the rubric must measure what matters to the task rather than what is easiest to measure.
Production use requires evidence that an LLM can perform the task
Kirmer says teams need more than hope before putting an LLM into production because models can make mistakes, including catastrophic ones. Free-text responses create a measurement problem. Human judges can be slow and expensive, while using another LLM raises the question of whether that evaluator can be trusted. Generic metrics such as correctness or conciseness may also be vague about what they measure. Her proposal is to use an LLM as an evaluator, while reducing ambiguity with a detailed rubric.
Kirmer borrows the rubric from teaching. A teacher writes an assignment and defines what students should learn and what evidence would show that they learned it. The rubric makes expectations clear to the student and keeps the teacher accountable. For an LLM, the same structure defines whether the model completed the requested task. It turns an otherwise broad judgment about response quality into criteria that the evaluator can inspect.
Kirmer warns that an LLM is not suitable for every kind of evaluation. Truthfulness and accuracy can be uncertain, and arithmetic is an obvious example of a task where the model may not be a reliable judge. Teams also have to accept that machine learning systems will not be correct 100 percent of the time. The rubric design therefore has to account for the task itself and for the risk of evaluation errors.
The rubric should measure what matters to the task
To define an acceptable response, the team needs a deep understanding of the problem and of what a good answer looks like. Kirmer recommends separating important traits from secondary ones. In an essay about reading a research paper, grammar may affect readability, but understanding the paper may matter more. She also recommends user or customer research when people will read the output, since those users can explain what makes an answer successful.
Kirmer's example asks an LLM to give friendly, professional responses to users asking for product details. The rubric measures friendliness, professionalism, completeness, and being on topic. For completeness, zero means the response does not answer the question, one means it covers only part with major gaps, two means it answers most of the question with a few gaps, and three means it fully addresses the question. If a human cannot tell whether an answer deserves one or two points, the rubric needs more detail.
After writing the rubric, the team creates validation examples that resemble production outputs and cover different failure modes. Kirmer specifically recommends including very bad examples, such as a rude response and an incomplete but polite response. A person grades every example first. The evaluator LLM then grades the same examples with the same rubric. The team compares the scores and adjusts the evaluator prompt or rubric until the evaluator reaches the human judgments. The human scores remain the ground truth during this process.
Calibration continues after the evaluator enters production
Kirmer recommends generating fresh samples from the task LLM and having both the human and evaluator LLM review them as an additional calibration step. Once deployed, the evaluator can produce numeric scores that help monitor the task LLM for drift and unusual outputs. Teams can use spot checks or sampling when evaluation costs are a concern. They should also periodically check that the evaluator still behaves as intended.
Evaluator scores can control and improve the application
The evaluation scores can feed back into prompt engineering for the task LLM. They can also act as a quality gate that stops low-scoring responses from reaching the user or moving further through an agent pipeline. Kirmer mentions reinforcement learning from AI feedback as a further option. She cautions that the rubric still has to match the real task. A rubric may be impossible for the underlying method or data to satisfy, which can reveal that an LLM is the wrong tool.
"You can't just put an LLM into production based on hope and good vibes because we know LLMs can make mistakes, sometimes even catastrophic mistakes."01:08
Who should watch
You are preparing an LLM feature for production and need a practical way to evaluate free-text responses before release.
Your team is using an evaluator LLM but has not compared its judgments with consistent human grades.
You need to monitor an agent or task LLM over time and want scores that can support quality gates or prompt changes.
