Writing Rubrics for Grading Outputs

When an AI system produces an answer, someone has to decide whether that answer is good. For some outputs this is easy. If the task has one correct value, a simple check can compare the output to that value and report pass or fail. Many real tasks do not work this way. A reply to a customer, a summary of a document, or an explanation of a concept can be good in many different ways, and no single expected string captures what a good result looks like.

This article follows one problem through the course material: how to grade outputs that are hard to check with a fixed comparison. The answer the source gives is the LLM-as-judge, and the work of using it well depends on writing a rubric, which is the written standard the judge applies.

Consider two outputs an AI system might produce. In the first, the task asks for the result of a calculation and the correct value is one specific number. Grading is straightforward: compare the output to that number and report pass or fail. In the second, the task asks for a reply to a customer who wrote in about a late delivery. Many replies could be acceptable. One reply might apologize and give a tracking update, another might offer a refund, and a third might be short but correct. No single expected string describes all the good replies.

The source frames this problem through the idea of an eval set, which is a collection of cases used to evaluate a system. Within that collection, some cases can be checked with a precise assertion. Others are harder. The source states that the hardest part of building an eval set is the middle layer.

The middle layer is defined by two conditions that must both hold. First, the right answer is hard to express as an assertion. Second, getting a human to grade the case would be too expensive to do at scale. If a human could grade the case cheaply, a human grader would be a reasonable choice. If an assertion could express the right answer, a simple check would be a reasonable choice. The middle layer is the set of cases where neither simpler option works well.

The diagram shows the middle layer as the hardest region and the judge as the tool the source ties to it. The source does not describe every layer of an eval set, so the diagram does not show a complete structure. It establishes only that the middle layer is the hardest part and is the case type the judge is meant to handle.

Each part of this definition matters. The word separate means the judge is its own LLM call, distinct from the call that produced the output being evaluated. The judge does not generate the answer to the original task. It reads an existing output and assigns a grade.

In an evaluation pipeline there are two separate roles. The system under test is the component whose output is being checked. It takes a task input and produces an output. The judge is a second LLM call that receives that output along with the rubric and produces a grade. The two must be kept separate. If they were the same component, the judge would become a second producer rather than a grader.

Read the diagram from left to right. The system under test is the only component that answers the task. The output it produces, together with the rubric, is handed to the judge. The judge's only job in this flow is to produce a grade. The diagram shows the two roles and their connection, not a full testing framework.

The judge receives two things that the source names directly: the output being graded and the rubric. The rubric is part of the judge's input alongside the output. Without a rubric, a grade would only reflect the judge's general impression. With a rubric, the grade is tied to specific criteria that someone wrote down in advance. The judge returns a grade. The source does not say whether the original task input is also passed to the judge, so this article does not assume it is.