# How to run human evaluation of LLM outputs

> Run human evaluation of LLM outputs by reviewing about 100 real traces, labeling pass or fail, using one domain expert, and checking agreement.

Source: https://www.honeyhive.ai/learn/human-evaluation-llm (updated 2026-11-08)

Human evaluation of LLM outputs means people read real outputs and label them against criteria you care about. A workable way to run it is to review about 100 diverse traces, write down what goes wrong, label with pass or fail, and have one domain expert make the calls. Then use the labels to build automated checks and judges.

## When to use people

Anthropic's evaluation guide [advises](https://platform.claude.com/docs/en/test-and-evaluate/develop-tests) automating grading when possible and says more questions with automated grading beat fewer, high-quality hand-graded ones. Humans are for what automation cannot yet judge, and for deciding what to automate. HoneyHive's docs name [subjective qualities](https://docs.honeyhive.ai/v2/evaluation/annotation-queues.md) such as brand voice, creative quality and domain-specific accuracy as cases where people beat automated evaluators.

## The steps

1. **Pick the reviewer.** Husain and Shankar [recommend](https://hamel.dev/blog/posts/evals-faq/) appointing a single domain expert as a "benevolent dictator", which avoids annotation conflicts. They also call outsourcing error analysis "usually a big mistake".
2. **Sample real traces.** The evals FAQ [says](https://hamel.dev/blog/posts/evals-faq/) to start with about 100 diverse ones and annotate at least the first 30 yourself. For production traffic, the same FAQ suggests sampling live traces and running evaluators asynchronously.
3. **Write open notes first.** The FAQ describes open coding (free-text notes on each trace), followed by axial coding, which groups the notes into a failure taxonomy. It warns that writing a rubric before reviewing examples can get in the way, because reviewers overlook problems outside the rubric. Keep going until new reviews stop revealing failure modes. The method is covered in [error analysis](/learn/error-analysis-llm).
4. **Turn failure modes into pass/fail questions.** Husain and Shankar say binary labels force clearer thinking and more consistent labeling, and that numeric labels are advanced and usually not necessary. A 3 versus a 4 on a Likert scale is where annotators drift apart.
5. **Check agreement if several people label.** Have them label the same examples independently, measure agreement with Cohen's kappa, discuss disagreements and update the criteria, as the evals FAQ [advises](https://hamel.dev/blog/posts/evals-faq/). See [inter-annotator agreement](/learn/inter-annotator-agreement) for how to compute and read it.
6. **Hand the labels to automation.** Use the labeled traces to test code-based checks and an LLM judge. Zheng et al. [report](https://arxiv.org/abs/2306.05685) that strong judges match human preferences over 80% of the time, and also describe position, verbosity and self-enhancement bias, so verify against your labels ([LLM-as-a-judge](/learn/llm-as-a-judge)).

## Making review fast

The evals FAQ says great interfaces make review "fast, clear, and motivating". Its tips:

| Practice | Why |
|---|---|
| Keep the context reviewers need on the same screen | Less switching between systems |
| Show progress, such as "45 of 100 examples reviewed" | Reviewers know how much work remains |
| Render outputs in the format the domain expects | Intuitive for the domain |
| For a very large trace, focus on the first upstream failure | Quality matters more than quantity, the FAQ says |

The FAQ also says teams with custom annotation tools iterate about 10x faster in Husain's experience, and that off-the-shelf tools can be justified when you coordinate dozens of distributed annotators.

## Collecting labels in HoneyHive

HoneyHive [annotation queues](https://docs.honeyhive.ai/v2/evaluation/annotation-queues.md) hold the events you want reviewed. In the docs' words, queues organize which events to review and human evaluators define what to assess, so you create the [human evaluator](https://docs.honeyhive.ai/v2/evaluators/human.md) fields first. These return binary, numeric, categorical or free-text values, and the docs advise writing criteria as questions an annotator can answer while reviewing.

To fill a queue, filter in Traces, select events and choose Add to Queue. For continuous review, turn on queue automation, and matching events, such as those with `metrics.accuracy < 0.7`, are added as they arrive. In Review Mode, reviewers see the input and output, fill in the fields, and move through events with the arrow keys and Enter.

## FAQ

### How many LLM outputs should humans review?

Hamel Husain and Shreya Shankar [recommend](https://hamel.dev/blog/posts/evals-faq/) reviewing at least 100 diverse traces, with the first 30 annotated by you, and continuing until new reviews stop revealing failure modes.

### Should human reviewers use a 1 to 5 scale or pass/fail?

Start with pass/fail. The same [FAQ](https://hamel.dev/blog/posts/evals-faq/) says binary labels force a decision instead of hiding uncertainty in middle values, and that numeric labels are usually not necessary.

### Can an LLM judge replace human evaluation?

It can take over the volume once it matches human labels. Zheng et al. [found](https://arxiv.org/abs/2306.05685) GPT-4-level judges agree with human preferences over 80% of the time, but the judge still has to be checked against your own human labels. See [LLM-as-a-judge](/learn/llm-as-a-judge).