LLM evaluation and RLHF: reviewing model output before it reaches users.
Prompt design, rubric-based review, data annotation and RLHF on LLM responses at SeamHealth, with flags for hallucinations and inconsistencies.
- Engineer · LLM evaluation and RLHF
- 2023 — Present
- SeamHealth Group. Team size not listed.
- LLM APIs · internal review
- OpenAI API
- Anthropic API
- Prompt engineering
- Rubrics
This was internal SeamHealth work on model output. No prompts, responses, screenshots or datasets are shown, and the review flow is simplified.
Context
SeamHealth used LLM APIs for generative tasks. A fluent answer can still miss the instruction, contradict the source, or invent a fact, so responses were reviewed before they were used.
My responsibility
I owned
- Prompt design for the tasks under review
- Rubric-based review of model responses
- Annotation of failures: hallucination, inconsistency, and missed instructions
- RLHF: the human feedback recorded on those labels
I collaborated on
- The product and engineering teammates who decided what a passing response had to do
The challenge
Reading a response and deciding whether it “seems fine” does not travel. Two reviewers describe the same failure differently, and a fluent wrong answer gets through. The review needed a written rubric and a small set of labels so the same mistake was marked the same way each time.
Constraints
- Written guidelines
- A response passes or fails against the rubric, not against how polished it sounds.
- Source of truth
- Claims were checked against the material the prompt was given. A detail that was not in that material was a hallucination, even if it was plausible.
- No published counts
- How many responses were reviewed, and how often reviewers agreed, was not recorded. Those figures are left unstated.
Architecture
- Prompt
- Source material
- OpenAI API
- Anthropic API
- Written rubric
- Annotation labels
- RLHF labels
- Hallucination flag
- Inconsistency flag
- Labels sit on the response before it is used. A miss is named (hallucination, inconsistency, missed instruction) instead of being waved through because the prose reads well.
Key decisions
01Annotate against a rubric instead of a free-text impression
- Free-text review does not tell the next person what failed, and it treats fluent prose as evidence of correctness.
- Accept a response when it reads well
- Score it against a written rubric and label the failure
- A rubric takes time to write and to apply, and it misses failures nobody thought to name. An impression is faster and is not repeatable.
- Review each response against the rubric and annotate the specific failure.
- The label is what makes the same mistake findable the next time, and it keeps a fluent wrong answer from passing.
- Failures were recorded as hallucination, inconsistency, or a missed instruction, and flagged before the response was used.
Implementation
- Prompts
- Wrote and revised the prompts for the tasks under review, then checked the output against what the prompt actually asked for.
- Rubric
- Graded responses on instruction following, consistency with the source, and whether a fact had been invented.
- Annotation
- Marked each failure with a fixed label so later reviews used the same words for the same kind of miss.
- RLHF
- Those labels are the human feedback: a response is accepted or sent back from the rubric, not from how fluent it sounds.
Production
- Gate
- Hallucination and inconsistency flags were applied before a response was treated as usable.
Outcome
The review turned “does this sound right?” into a rubric check with named failure labels. How many responses that covered, and how often two reviewers agreed, was not recorded.
- Responses reviewed
- —
- Unavailable. The review volume was not recorded.
Lessons
A rubric is the annotation guideline. Without it, review notes describe tone instead of the failure.
Next iteration
- Record the review volume and how often two people apply the same label, so the rubric itself can be checked.