Explore more topics
Developer guides

How I built a training dataset to fine-tune an LLM judge for my AI agent

I built 889 graded AI agent decisions to fine-tune an LLM judge. An AI checker flipped 12 of 29 grades, so I used blind review. Here is the method and the training plan.

As of 2026-11-01

Jump to a section

TL;DR

An LLM judge for an AI agent reads one recorded decision and grades it. I built 889 graded decisions from real runs of Aurora, my trading research agent, to fine-tune one. An AI checker changed 12 of its own 29 grades when I reran it, so I checked the labels with blind review instead, and 71 of them changed.

Training comes next: Qwen 3.5 9B with LoRA on one rented GPU, scored against hand-checked runs. The judge is step one of an agent that builds profitable trading strategies.

Training rows
889graded agent decisions, three critics
AI checker
12 of 29grades it changed on a rerun
Grades fixed
71by blind review and reconciliation
Tokens scored
0.23%223,685 of 96,128,264

Why my trading agent needs a judge

Two numbered cards, 1 Critic and 2 RL model running Qwen 3.5 9B on a rented H200, above a red card reading: the bar, today about 1 in 3 beat the S&P 500 going forward.
The plan: a critic first, then my own model trained with reinforcement learning.

I'm building Aurora into an AI agent that builds profitable trading strategies. Profitable means beating the S&P 500 on downside-risk-adjusted return (the Sortino ratio) going forward.

Language models are trained to sound right, and a strategy that sounds right can still lose money. So the plan has two models. The first is a critic that grades the agent's work. The second is my own model, trained with reinforcement learning, and the critic decides which of its attempts count.

What an LLM judge for an agent grades

An agent run drawn as a chain: request, plan, two tool calls and a final answer, with the critic's grade beside each step: GOOD, REPAIR and BAD. A crossed-out chart notes that returns are not an input.
The critic grades the plan, each step and the final answer. Returns are never an input.
A recorded final answer with line 4002 highlighted, Total Fees $30,790.70, and line 4006 underlined in red: The strategy never executed a single trade.
A real answer told a user their strategy never traded, while the same run recorded $30,790.70 in fees.

A request like "which AI stocks grew revenue four quarters straight?" has a right answer and a right path to it. The critic checks both, based only on whether the work was correct and honest. It never sees how a strategy performed, so a lucky result can't cover for bad work.

GOOD means the work was done right. REPAIR means it has a gap I can fix. BAD means something critical is wrong, such as an invented number, a false claim that something was verified, or an answer its own run contradicts.

  1. Plan critic

    It grades the planner's plan before anything runs.

  2. Executor critic

    It grades one executor step, which is a tool call or the final answer.

  3. Whole-run critic

    It grades the finished run end to end.

Step 1: Turn real runs into self-contained packets

Three real user requests above three boxes, TRAIN, VAL and TEST, with TEST locked and labeled opened once, at the end.
Real requests, every step the agent took, and a test set that stays locked.
One grading packet for case A, with five blocks: the user's request, the agent's full instructions including the rule retry at most once, every tool the agent called, what came back, and the answer being graded.
One packet holds everything the critic needs, including the agent's full instructions.
Show the table · 3 rows, 3 columns

Scroll sideways to compare all columns. Select a heading to sort.

Usable training rows768889
Training tokens35.9M96.1M
Median row32K tokens96K tokens

The cost of carrying the agent's full instructions in every packet.

I used real recorded Aurora runs: what users actually asked, and every plan, tool call, result and answer the agent produced. Real runs carry the mistakes my agent actually makes.

I split them into training, validation and test sets by source family, so near-copies of one run never land on both sides. The test set is 300 source families, sealed until the end.

Each decision becomes one packet: the user's request, the agent's full instructions, every tool it called, what came back, and the answer being graded. The critic grades a packet in one call with no lookups, so everything a grade depends on has to be inside it.

My first packets left out the agent's instructions, and 127 grades cited rules the critic couldn't see, such as "retry at most once." Adding them made the data 2.7 times larger.

Step 2: Check the answer key before you train on it

A chart of 13 decision models grading 29 known cases. The best, typesafe/jev-1.14, got 19 of 29; most bars are mostly GOOD.
13 decision models on 29 cases with known answers. The best got 19.
DeepSeek V4.1 Flash grading the same 29 cases in three runs, with 12 rows marked changed.
Same 29 cases, three runs: DeepSeek changed its grade on 12.

My first grades came from Codex and Claude Code sessions, so I needed a way to check them. I built 29 cases where I already knew the right grade and tested AI checkers on them, for about $6.35 in API spend.

13 decision models, which are built to answer quick multiple-choice questions, mostly answered GOOD to everything. The best got 19 of 29. The mistakes hide across a long run: in the case above, the fees and the claim that the strategy never traded sit 771 lines apart.

DeepSeek V4.1 Flash did best, with 21 of 29. Then I ran it three times on the same cases, and it changed its grade on 12 of them. A checker that changes its mind that often can't tell you which grades are wrong.

How blind review checked the key

Two panels. What a reviewer sees: the raw run with the request, tools and answer. What it never sees: the old grade, sealed in a locked folder.
Each reviewer sees the raw run and never the old grade, so it can't just agree with it.
Step 1 of 5

Review blind

A fresh Claude Code subagent reads the raw run and never sees the saved grade.

What you should see

A grade, a reason and exact quotes with line numbers.

Step 2 of 5

Lock the verdicts

Every review is frozen by hash before anything is revealed.

What you should see

No review can be quietly edited to match the old grade.

Step 3 of 5

Reveal and compare

Only then does the saved grade come out.

What you should see

Agreements stand, and every disagreement moves on.

A reconciliation sheet listing old and blind claims about case A, each marked verified except the old claim that the answer was fixable, which is unsupported. Final grade: BAD.
Case A's reconciliation: the old grade's claim that the answer was fixable did not hold up.
Step 4 of 5

Reconcile

A fresh reviewer checks every factual claim on both sides against the source and applies the written rules.

What you should see

A final grade with each claim marked verified or unsupported.

Step 5 of 5

Send rule questions to me

When the written rules don't cover a case, the question comes to me.

What you should see

I made 19 of these calls.

What the review changed

71 training grades changed, shown as three grids of squares: 16 of 67 whole-run REPAIR labels, 14 of 90 whole-run GOOD labels and 41 of 173 plan and step REPAIR labels.
Each square is one reviewed training grade; filled squares changed.
Show the table · 4 rows, 4 columns

Scroll sideways to compare all columns. Select a heading to sort.

Validation, whole run468All too lenient
Training, whole-run REPAIR671615 should have been BAD
Training, whole-run GOOD9010, plus 4 after rulingsToo lenient
Training, plan and step REPAIR1734127 to GOOD, 14 to BAD

Saved labels checked by blind review and reconciliation.

In the end, 71 training grades changed. Whole-run labels were mostly too lenient: 15 of the 16 wrong REPAIR labels should have been BAD. Plan and step labels leaned the other way, and 27 of them went up to GOOD.

On the 46 hand-checked validation runs, 8 saved grades were wrong (17%), all too lenient.

The blind reviewers were overruled in 43 of 117 reconciliations (37%), so one fresh review alone would have left errors in place too.

The final training set

Stacked bars of the training set by critic and grade: whole run 137 BAD, 65 REPAIR, 84 GOOD; plan 19, 88, 199; step 34, 51, 212; 889 examples in total.
889 training rows after review.
Show the table · 4 rows, 5 columns

Scroll sideways to compare all columns. Select a heading to sort.

Whole run1376584286
Plan1988199306
Executor3451212297
Total889

Training rows by critic and grade.

Validation is separate: 46 hand-checked whole-run cases (13 GOOD, 13 REPAIR, 20 BAD) and 50 adjudicated plan cases (39 GOOD, 11 REPAIR, 0 BAD).

How I'm training the critic, in five steps

A long bar split into rules, agent run and answer, labeled 135,802 tokens in this example, 280 of them the answer.
One example, glued together.
Step 1 of 5

Turn each example into tokens

A token is a chunk of a word, the piece a model reads in one bite. Each example glues three parts together: the grading rules, the full agent run with the agent's prompt, and the right answer. The answer lists the evidence first, then the reason, then the grade, so the model finds the proof before it judges.

What you should see

The example shown is 135,802 tokens, and its answer is about 280.

Rows of nearly empty bars with a thin green tip on each, labeled 223,685 scored out of 96,128,264 tokens, 0.23%, fewer than 1 in 400.
Only the answer counts toward the score.
Step 2 of 5

Decide what gets graded

The model reads the whole run, but the loss, the training score it learns to lower, counts only the answer it writes.

What you should see

223,685 of 96,128,264 tokens are scored: 0.23%, fewer than 1 in 400.

Example lengths sorted as bars against a 262K line; 879 of 889 fit, and 10 red bars run past it, up to 768,722 tokens.
Ten examples run past Qwen's window.
Step 3 of 5

Make the runs fit

Qwen reads 262,144 tokens at once. I leave the 10 longer examples out instead of truncating them, because truncation can cut the evidence a grade depends on. Qwen can stretch to about 1,010,000 tokens with YaRN, which stretches how it tracks word positions, and I'll switch that on only when the finished critic grades a very long run.

What you should see

879 of 889 examples fit; the longest is 768,722 tokens.

A grid of grey circles with a padlock, labeled frozen: all 9 billion, beside a small green panel labeled trained: a small extra set.
LoRA trains a small extra set and freezes the rest.
Step 4 of 5

Train with LoRA

LoRA trains a small set of extra numbers on top of the model and leaves all 9 billion original numbers frozen. It is far cheaper, and the whole job fits on one GPU.

What you should see

I measured memory and speed on one H200 rented on RunPod at $5.29 an hour. The full run, all 879 examples twice, runs on one B200 at $7.99 an hour. I estimate $110 to $150, with a hard stop at $200.

Three scorecards, base Qwen 3.5 9B, DeepSeek V4.1 Flash and my critic, each with BAD runs caught out of 20 and false alarms on GOOD out of 13, all still question marks.
The scoreboard, empty until training runs.
Step 5 of 5

Race it against two baselines

My critic, base Qwen with no training, and DeepSeek V4.1 Flash all grade the same 46 hand-checked runs, which the critic never trains on. I save a copy after each round of training and keep the one that does best.

What you should see

Mine wins only if it catches more BAD runs than both without raising more false alarms on GOOD ones.

This part is planned and has not run yet. The base model is Qwen 3.5 9B. I picked it over Liquid's LFM 2.5, whose 128,000-token window can't fit 138 of my 286 whole-run examples, and which got cut off mid-answer on 12 of 30 plan grades in a small test.

What the race leaves open

BAD runs come first, because a bad run that slips through is the one that would let a cheating strategy earn a reward.

After the race, the sealed test set of 300 source families gets opened once, at the end, so I can't keep tweaking the critic until it passes.

Two gaps remain. The executor critic has no validation set yet, and plan validation has 0 BAD cases, so I can't measure how many BAD plans the critic catches. The fix is to label new validation cases from the reserved families with the same blind review.

What comes after the critic

A loop: 1 RL model builds a strategy, 2 Sortino on time periods it never saw, 3 critic checks the work and never sees returns. Two checks, did it do what the user asked and are its numbers real, lead to SCORE if yes to both and ZERO if not.
The critic gates every score in the reinforcement learning loop.
A grid of 521 dots for agent-built paper portfolios with 30 or more days forward, 170 filled green: 170 beat the S&P 500 on Sortino (32.6%). The bar: about 1 in 3.
170 of 521 agent-built paper portfolios beat the S&P 500 on Sortino.

Next I train my own model with reinforcement learning. It builds strategies over and over, and each one gets a Sortino score from real live or paper results, or from a walk-forward test on periods it never saw when it has none.

Before any score counts, the critic checks how the model got there. If it didn't do what the user asked, or its numbers aren't real, the score is zero.

Today, about 1 in 3 strategies my agent builds beats the S&P 500 going forward: 170 of 521 paper portfolios with at least 30 days of forward history (32.6%). That is the bar.

Watch the series

Part 1. Why my AI trading agent needs a critic before reinforcement learning. The video includes sound.
Part 2. How I built the critic's answer key from real agent runs and blind review. The video includes sound.
Part 3. How I'm training the critic with LoRA in five steps, and the race it has to win. The video includes sound.

Questions

  1. How many examples do you need to fine-tune an LLM judge?

    I can only speak to my own set: 889 training rows across three critics, plus 96 validation cases. Training hasn't run yet, so I don't know yet whether that is enough.

  2. Can an AI model check my judge's labels?

    Measure it first on cases where you know the answer, and run it more than once. My best checker got 21 of 29 right and changed 12 of 29 grades on a rerun.

  3. Should judge training data be synthetic or real?

    I used real recorded runs. The defects that matter most to me, like a claim the run's own tool results contradict, come from real tool output.

  4. How will you evaluate the judge?

    On hand-checked validation cases, never the old labels. I'll measure how many BAD runs it catches, how many GOOD runs it wrongly flags, the full confusion matrix of grades, and whether every quote it cites exists in the case. Then the sealed test set, once.

How I measured

Methodology and costs

The known-answer set has 29 cases, and every automated label check together cost about $6.35 in API spend. Blind reviews ran as independent Claude Code subagents, were frozen by hash before saved labels were revealed, and were reconciled by a fresh reviewer against the source record and the written rules.

Token counts use the Qwen tokenizer on the final rows, counted October 31, 2026. The forward baseline comes from a read-only audit of 521 agent-built paper portfolios with at least 30 days of forward history. The test set remains sealed, and training has not run, so this guide reports no trained-critic accuracy.

The figures are frames from my three-part video series on this project.

Continue exploring

Discussion

Sign in or create a free account to join the discussion.

No comments yet.