---
title: "LLM evaluation"
description: "Ayush Rai on LLM evaluation: rubrics, review loops, and reliability for model outputs, grounded in contract evaluation work."
canonical: "https://www.ayushrai.site/ai-engineering/llm-evaluation/"
last-updated: "2026-10-16"
---

# LLM evaluation

Source: https://www.ayushrai.site/ai-engineering/llm-evaluation/
Markdown: https://www.ayushrai.site/ai-engineering/llm-evaluation.md

Ayush Rai on LLM evaluation: rubrics, review loops, and reliability for model outputs, grounded in contract evaluation work.

Evidence level: Mixed: shipped pieces and explicit limits.

## Scope

LLM evaluation here means deciding whether an output is acceptable for a stated task, recording why, and noticing when the rubric itself is vague. It includes code-oriented review, STEM and coding-task analysis, and dataset-quality work described on the experience page.

It does not mean I am publishing a leaderboard, a pairwise arena, or a statistically powered benchmark. I have not released those artifacts.

## Problems this work is for

A fluent wrong answer is expensive when the task is code, a calculation, or a workflow that will be trusted later. 'Looks good' feedback does not tell a later training or review step what failed.

The practical problems are rubric design, disagreement, and leakage of the answer into the prompt. Those show up in review work even when the employer cannot be described in detail.

## What I do in the review loop

At FoCDoT I reviewed model outputs against evaluation criteria and analyzed coding and STEM tasks. Through Outlier I have worked on dataset quality, prompting strategies for Python and JavaScript tasks, and review loops aimed at brittle behavior. The public description stops where the task materials stop.

The note I am willing to stand behind is simple: correctness, edge cases, and security smells need to be explicit criteria. Brand proximity to a lab is not a substitute for that.

- Name the task and the failure that matters before scoring.
- Separate 'runs' from 'is safe to ship' for code outputs.
- Treat a rubric change as a change of the measurement, not as a quiet quality improvement.
- Do not cite a win rate I cannot show.

## Failure modes

Rubrics drift toward style. Reviewers reward familiar patterns. A pairwise preference can hide a shared blind spot if both outputs miss the same bug. Prompt examples can leak the expected answer.

I keep an idea note, Honest rubrics for code-oriented LLM eval, in the exploring state. It is not a published rubric pack.

## Security and reliability

For code tasks, a review that ignores injection, unsafe defaults, and tests that do not exercise the branch is incomplete. I treat those as evaluation criteria, not as a separate security audit practice I am selling on its own.

## Evidence

- [Outlier evaluation work](/experience#outlier-genai): Dataset quality, Python/JavaScript prompting, review of brittle outputs.
- [FoCDoT evaluation work](/experience#focdot-sde-ai): Criteria-based review and STEM/coding-task analysis, through August 2025.
- [Evaluation is the job](/notes/eval-is-the-job): Short note on explicit rubrics.
- [Code-eval rubrics idea](/ideas): Status: exploring. Not a shipped rubric.

## Related

- [RLHF and preference feedback](/ai-engineering/rlhf)
- [AI engineering hub](/ai-engineering)
- [MedVoice, where the model does not decide](/work/medvoice)


## Further reading

- [Training language models to follow instructions with human feedback](https://arxiv.org/abs/2203.02155): The InstructGPT paper. Background reading, not my result.

## Gaps

- No public inter-annotator agreement, sample size, or error analysis from paid review work.
- No side-by-side benchmark against a named model.
- The code-eval rubric idea is not written up as a reusable document yet.

Contact: /contact

_Unverified award metrics are omitted. Wording matches the public site._