Obsidian Metadata

Reference Answers and Rubrics

  • Reference answer: an example of a correct response.
  • Rubric: criteria for judging a response (e.g., “follows the refund policy”).

Do you need one before annotating? No.

Writing a rubric before reviewing examples can get in the way:

  • Reviewers get so focused on checking rubric items that they miss problems outside the rubric.
  • Your idea of “good” will change as you review. That’s Criteria Drift, and it’s usually bigger than people expect.
  • Example: a refund agent that escalates to a human exactly as policy says, but you only learn from reading interactions that the process frustrates users.

Treat initial expectations as a starting point you’ll revise.

  1. Do Error Analysis: open-ended notes, then group them to see what recurs.
  2. Then write the rubric from observed user and application behavior.
  3. Re-run error analysis periodically to keep the rubric current.
  4. When multiple annotators disagree, update the rubric with a definition, rule, or example for the disputed case and relabel (see Benevolent Dictator).

Cautionary tale: Nova Escola wrote a rubric before error analysis. Most criteria never showed up as failures, so the team labeled data it didn’t need.

Where reference answers help

  • Reference-based checks against known correct values are cheap and reliable.
  • CI regression sets for known workflows.
  • RAG retrieval evals: query → relevant-chunk pairs.
  • Anthropic recommends a reference solution per agent task to prove it’s solvable and that graders are configured correctly.

Production traffic usually has no reference outputs, which is why online monitoring leans on reference-free evaluators such as judges (see CI Evals vs Production Monitoring).

Criteria Drift · Error Analysis · Eval Maintenance and Cadence