Failure Modes Specific to LLM-as-Judge Systems

LLM-as-judge has become the default way teams evaluate language models and AI agents on questions no deterministic metric can settle. The judge is itself a language model, so it inherits every bias, every inconsistency, and every exploitable weak point found in the systems it's supposed to be grading, and those weaknesses behave differently when the model is scoring.

Three tools split the evaluation space between them. Skipping a judge where real reasoning is needed produces a score that looks like a measurement and isn't one.

The failure modes catalogued across 2025 and 2026 research are structural properties of how an LLM processes an evaluation task, not rare glitches at the margins of an eval run, and they stack on top of each other inside a single judgment. A judge working from a mismatched rubric will also pick up on cues that have nothing to do with content quality, and the pointwise score it hands back can end up contradicting the verdict the same judge gives in a head-to-head comparison of the same two outputs. Building reliable evaluation infrastructure starts with naming each of these failure modes on its own terms, because the fixes that work for one do nothing for the others.

Position bias: how answer order corrupts pairwise verdicts

In a pairwise comparison, where a response sits in the prompt changes the verdict on its own, regardless of the response's actual quality. Putting the stronger answer in slot B instead of slot A can flip the judge's preference, with nothing about the text itself having changed.

Zheng and colleagues documented this directly in the MT-Bench paper (arXiv:2306.05685): the win rate for a response swung by a meaningful margin depending on which slot it occupied, and the size of that swing varied a lot from one model to the next, with some judges showing the effect only faintly.

Lin Shi and colleagues took this further at IJCNLP 2025, running a large number of judges across a large number of evaluation instances to ask whether the swing was just noise, and found that it wasn't. The bias varied significantly across judges and tasks, which rules out random chance as the explanation. Their choice-pair framework sorts judge behavior into three signatures: position-consistent judges that land on the same call regardless of order, primacy-preferred judges that favor whichever answer comes first, and recency-preferred judges that favor whichever comes last. Position bias is a family of behaviors rather than one artifact with one shape, and a team has to characterize which one its specific judge exhibits rather than assuming a single universal correction applies.

That produces a genuinely uncomfortable result for anyone relying on repeat-run testing to validate a judge: a judge can return the identical verdict every time it's asked, run after run, and still be wrong in a consistent direction because it always favors the first slot. A judge can score as perfectly stable on the internal consistency numbers while systematically distorting every single comparison it makes, because those numbers were never built to look for that kind of error.

The standard fix, running the comparison both ways (A versus B, then B versus A) and averaging the two verdicts, cuts down the distortion without eliminating it. When the two orderings disagree outright, treating the pair as a tie is the conservative call. That mitigation matters, but it's a patch on a mechanism, not a cure for it, and the mechanism survives even after the patch is applied.

Verbosity bias: why longer responses win even when they shouldn't

Judges rate longer responses higher even when the extra length adds no new information, and the bias holds up even when two responses are matched for token count but differ in how elaborately they're phrased. The judge is scoring the appearance of effort in that scenario.

This isn't confined to conversational text. Research on code evaluation tasks (arXiv:2604.16790) found that LLM judges scoring software engineering outputs could be swayed toward a higher rating simply by padding a submission with redundant code that changed nothing about whether the program actually worked. That's a second, independent demonstration that verbosity bias operates on structured, technical content the same way it operates on prose, which rules out the idea that the problem is somehow specific to how language models read natural-language style cues.

The practical cost appears fastest in production support systems. If the judge scoring a support agent's replies consistently rewards elaboration over getting to the point, the agent gets pushed toward longer and longer answers purely because that's what scores well, not because customers are better served by it. Where judge scores feed back into reward modeling or prompt tuning, that distortion doesn't stay contained to the eval dashboard: it becomes a property of the deployed model's behavior.

Length also interacts with a separate problem: direct numeric scoring tends to cluster in the middle of whatever scale is used, so when two outputs are otherwise close in quality, verbosity can be the deciding factor that breaks the tie. The concise, equally correct response stays stuck in it.

Self-preference and family bias: when the judge and generator share a lineage

Same-family models, one model acting as judge over text generated by a model from its own family, share more than a company name. They share training data distributions, the same inductive biases, and the same gaps in what they know. That means a judge from the same family as the generator can hand out a high score to a response containing an error the entire model family is structurally unable to recognize as an error. The blind spot is correlated between the two models, and because it's correlated, the evaluator never sees it.

Research presented at EMNLP 2025 drew a distinction that matters operationally: not every instance of a model favoring its own outputs is biased in the harmful sense. The damaging part is narrower than "self-preference" as a blanket label suggests: it's specifically when the model fails to penalize its own mistakes. Measuring self-preference in the aggregate hides this, because the aggregate number averages in all the cases where the preference was earned, diluting the cases where it wasn't, which are exactly the cases that matter for catching real failures.

The pattern that plays out in production teams follows roughly the same shape across reports: a team builds a groundedness judge using the same model family as its generator, the dashboard reads green for months, and the problem only surfaces when a domain expert sits down and reads raw outputs directly. At that point it becomes clear the judge has spent months over-rewarding same-family responses and under-penalizing hallucinations that happened to be fluent. Nothing in the automated pipeline flagged it, because the automated pipeline was the same family doing the scoring.

The diagnostic fix is adding a second judge built on a model from an entirely separate family and watching where the two disagree. Disagreement between the two is the signal. It marks the cases where the family-biased judge is likely mis-scoring, giving a team a concrete place to start a manual audit.

Format-induced inconsistency: the same judgment, different scores depending on how you ask

The same judge model can produce different scores for the identical input purely because the requested output format changed, a 1-to-5 rating instead of a True/False label, a pointwise score instead of a pairwise verdict, even when the underlying judgment ought to come out the same either way.

The Judge Circuits paper (Feldhus et al., arXiv:2605.16023) offers the clearest mechanistic account of why. Using a technique called Position-aware Edge Attribution Patching across five open-weight instruction-tuned models spanning three families, Gemma-3, Qwen2.5, and Llama-3.1, the authors traced how these models actually compute a judgment internally. They found a sparse circuit they call the Latent Evaluator, sitting in the mid-to-late MLP layers, that computes a single continuous judgment signal shared across formats. That shared signal then gets routed through separate, fragile, format-specific branches that translate it into whatever output shape was requested. The inconsistency enters downstream, at the translation step, not at the evaluation step.

The surface answer flips.

FairJudge (Bo Yang and colleagues, February 2026) documents a related problem across scoring modes rather than within one: Score-Comparison Inconsistency, where a response that earns a higher number in pointwise scoring still loses when placed head-to-head against a response that scored lower. Chain enough of these together and the judge produces circular preferences: A beats B, B beats C, and C turns around and beats A, a ranking that can't be made coherent no matter how it's sorted.

Calibration drift: how a well-calibrated judge quietly stops meaning what it measured

A rubric calibrated against one version of a judge model produces a different distribution of scores once that judge is bumped to a newer version, with the average shifting and the spread narrowing. The number that used to mean something specific stops meaning that same thing, even though nothing about the rubric changed.

Picture a helpfulness score that holds steady for a full quarter. But the meaning of the signal changed the day the judge changed, and the monitoring built to catch drift wasn't built to catch this kind, because the number itself never left its normal band.

RAND Corporation's Judge Reliability Harness (Sunishchal Dev and colleagues) tested this directly across four judges on safety, persuasion, misuse, and agentic benchmarks, and found consistency broke down on changes as mundane as reformatting, paraphrasing the same question, or shifting the verbosity of the input. No judge among the four held up uniformly across these shifts, which rules out the possibility that drift is a quirk of one particular model rather than a property of the approach itself.

The "Reliability without Validity" study (arXiv:2606.19544), the largest systematic test run on this question so far, covering 21 models from nine providers across three benchmarks and three evaluation protocols, found that how well a benchmark separates good models from bad ones varies sharply by benchmark. MT-Bench in particular compressed nearly every judge into a narrow band, with adjacent model ranks separated by a gap of only a fraction of a point. A gap that small means a minor shift in the underlying distribution can reorder which model looks best, without anything in the pipeline flagging that a change happened at all. The same study documented acute swings for specific models, some showing a multi-fold spread in reliability moving from one benchmark to another; a judge validated as reliable on one workload can turn unreliable the moment it's pointed at a different one in production.

Agreeableness bias compounds all of this invisibly. LLM judges are reliably good at recognizing a correct output as correct, a high true positive rate, but they're considerably worse at catching an output that's actually wrong, a weak true negative rate. As the quality of what's being generated degrades gradually over time, a judge with this asymmetry keeps passing most of it, the collapse in the judge's ability to catch bad outputs never appears as a visible drop in the dashboard, and the reliability metrics a team is watching keep reading high while the thing they're meant to protect against is quietly getting worse. Without a recurring calibration check run against a human-labeled gold set, a team watching these dashboards is running on faith that the scores still mean what they meant at launch, and the gap between the dashboard and reality only closes when someone reads the raw outputs by hand.

Compounding failure modes in production agent evaluation

Agent evaluation exposes every one of these failure modes more severely than evaluating a single LLM response ever does. An agent's behavior unfolds across multi-step trajectories, tool calls, and live external systems, and each of those extra steps is another place where position bias, verbosity bias, family bias, format sensitivity, and calibration drift can enter the judgment, while the number of fixed reference points available to catch a judge going wrong shrinks as the steps multiply.

An agent can call every tool correctly and get a clean success status back from each one while still failing the task the user actually asked for. An agent can also land on the right final answer by way of an intermediate plan that broke every rule it was supposed to follow along the way. Both of these are the failures that matter most in a deployed product, and both are also what a deterministic exact-match check will miss and what a miscalibrated judge will wave through as a pass.

Empirical study of production agentic systems found that no standard metric, across the full set tested, catches more than two of seven documented failure modes. Accuracy metrics can stay flat across an entire evaluation window while the actual diversity of what the agent produces collapses underneath that flat line, so a judge-scored quality metric can read green on the dashboard at the exact moment the agent's real capability is degrading.

Family bias carries the sharpest risk in this setting. When the agent generating the behavior and the judge scoring it come from the same model family, they don't just share a writing style, they share the same knowledge gaps about what correct behavior actually looks like. A judge in that position can fail to flag an agent that invents an order number, promises a refund outside the policy window, or drifts into an action nobody approved, because the judge and the agent were built on the same foundation and inherited the same blind spot about where the line sits.