What LLM-as-Judge Actually Means in Practice

LLM-as-judge means using a language model to evaluate properties that do not have a reliable deterministic oracle. It does not mean asking one model to decide whether the entire agent worked.

That distinction matters because language quality is contextual. Relevance, grounding, completeness and conversational appropriateness can require interpretation. Exact identifiers, amounts, permissions, tool calls and state changes usually have stronger sources of truth.

What the judge is actually doing

A judge receives an observable interaction, a rubric and enough context to apply that rubric.

USER GOAL + CONTEXT
        |
        v
     RUBRIC
        |
        v
   AGENT RESPONSE
        |
        v
   LLM-AS-JUDGE
        |
        +--> score
        +--> rationale
        +--> evidence references

The rubric is part of the test design.

"Is this a good answer?" is too vague to be a reliable release criterion.

A better criterion is explicit:

criterion: answer grounding
score: 0-4
context:
  - user request
  - retrieved sources
  - agent response
rule:
  score 4 only when every material claim is supported
failure:
  unsupported claim or source mismatch

Now the judge has a bounded question to answer.

Judge what requires judgment

A useful separation looks like this:

Delegating everything to the judge weakens the test because the evaluator is being asked to recreate facts that another system can establish directly.

Context changes the evaluation

The same response can be correct in one context and wrong in another.

A judge may need:

• the user goal;
• relevant previous turns;
• applicable policy;
• retrieved sources;
• expected constraints;
• the actual agent response.

Too little context can make the judgement arbitrary. Too much irrelevant context can make it noisy.

The engineering objective is to provide enough evidence to make the criterion decidable.

Calibration is part of the test design

A judge should be treated like any other evaluation component.

Build a reference set containing clear passes, clear failures and borderline examples. Compare judge decisions with expert decisions, inspect disagreement patterns, and revise the rubric when the disagreement reveals an ambiguous criterion.

Useful controls include:

• representative reference cases;
• explicit scoring anchors;
• separate review of false positives and false negatives;
• versioned rubrics;
• recorded judge model/version;
• stable evaluation context.

Do not compare scores across major rubric changes as though they were identical measurements.

Reliability is not the same as authority

A judge can be highly consistent and still be wrong about a fact outside its authority.

This is a crucial distinction.

                 RELEASE DECISION
                        |
             +----------+----------+
             |                     |
       HARD CONTRACTS        SEMANTIC QUALITY
             |                     |
   deterministic/security       LLM judge
   execution evidence

The judge contributes evidence. It does not become the source of truth for the entire system.

A high semantic score can still fail

Suppose the judge returns 4/4 for answer quality. The agent may still have:

• selected the wrong intent;
• skipped a required tool;
• changed the wrong record;
• violated an authorization boundary;
• failed to complete the business goal.

That is not a contradiction. The judge measured the answer.

The release decision must consider the rest of the evidence chain.

Make the judge auditable

Every important semantic evaluation should retain enough information to explain the result:

TEST CASE
   |
   +--> rubric version
   +--> model/version
   +--> evaluation context
   +--> response under evaluation
   +--> score + rationale
   +--> supporting evidence
   |
   v
SEMANTIC RESULT

This matters when teams compare releases, investigate disagreement, or change the rubric.

Conclusion

LLM-as-judge is strongest when it is precise about what it knows how to judge. Use it for semantic dimensions that genuinely require interpretation, then combine its result with deterministic contracts, orchestration evidence, security checks and execution-integrity controls.

A judge can evaluate an answer. Assurance must evaluate the system.