Search Tech Journey

Find topics, journeys and posts

back to blog
systemsadvanced 25m read

Designing for Scale · LLM-as-a-Judge and Release Gates

How to ship generative AI to production without shipping a liability. Breaking subjective prompts into deterministic grading rubrics, automated evaluation pipelines, and multimodal scoring.

The problem this post solves

A standard software system is deterministic. If the code is correct, the output is correct. A test suite can assert that 2 + 2 = 4, and that test will pass reliably for years.

Generative AI systems are probabilistic. If you ask an LLM to "summarize this meeting in a professional tone", the output will be different every time. Standard unit tests cannot assert on subjective text. If you change the prompt, change the model version, or change the RAG retrieval pipeline, you have no automated way of knowing if the system got better or worse.

Without automated evaluation, every release is a terrifying gamble that requires days of manual human review.

This post covers how to build an evaluation pipeline that scores subjective AI outputs at scale, allowing engineering teams to ship generative features with the same confidence as deterministic code.

First principles

From first principles
Start with the question
Why can't humans just review the model's output before a release?
  1. 1
    A reliable evaluation requires hundreds of test cases.
    forced by · You must cover edge cases, adversarial inputs, and various expected user intents.
  2. 2
    Human review is slow and expensive.
    forced by · Reading a 5-page document and grading the model's summary takes a human ten minutes per case.
  3. 3
    Engineering velocity requires fast feedback loops.
    forced by · A developer iterating on a prompt needs to know if the change worked in minutes, not days.
  4. 4
    Therefore, human review bottlenecks the entire development cycle.
    forced by · The team will either ship blindly or ship rarely.
⇒ Therefore
We must automate the human. A machine must grade the machine.

LLM-as-a-Judge

The core architectural pattern is "LLM-as-a-Judge". We use a highly capable, expensive model (like GPT-4) to grade the outputs of the production model.

This is not a general "rate this from 1 to 10" prompt. An LLM judge will hallucinate scores if given vague instructions. The evaluation must be broken down into narrow, independently scored dimensions.

The Rubric Decomposition

Instead of one massive prompt, the judge executes several distinct grading rubrics against the output:

  1. Fidelity (Grounding): Does the output contain facts that are not present in the source document? (Checking for hallucinations).
  2. Completeness: Did the output cover all the key points requested in the user's prompt?
  3. Tone: Is the language professional, or is it overly conversational/robotic?
  4. Formatting: Did the model follow the requested structural constraints (e.g., bullet points, JSON, maximum length)?
Mental modelThe One-Dimension Judge
A panel of judges at a diving competition. One judge ONLY looks at the splash. One judge ONLY looks at the rotation. They do not talk to each other.
  • Do not ask one LLM prompt to grade tone, formatting, and accuracy simultaneously. It will confuse them and average the scores.
  • Fire a separate, isolated prompt for each grading dimension.
  • Ask the judge to write its reasoning *before* it writes the final score (Chain of Thought). This forces the model to deliberate, drastically improving grading accuracy.
🔔 Fires when you see
Use whenever an automated evaluation returns inconsistent or erratic scores.

Architecture: The Evaluation Pipeline

The evaluation pipeline is an offline, asynchronous batch system. It does not run in production; it runs in CI/CD or as a scheduled nightly job.

The Golden Dataset

The foundation of the pipeline is a curated set of test cases. A good dataset contains:

  • The user prompt.
  • The required context (the retrieved RAG chunks).
  • (Optional) A human-written ideal answer, for reference.

Multimodal Evaluation

If the AI system generates more than just text—for example, a narrated video presentation or a slide deck—the evaluation architecture must decompose the modalities.

A single LLM cannot grade a video. The pipeline must separate the video into discrete streams:

  1. Audio Track: Transcribed via Speech-to-Text, then passed to an LLM judge to grade pacing, tone, and script fidelity.
  2. Visual Track: Frames extracted at intervals, passed to a Vision model (or OCR) to grade slide layout, text accuracy, and brand compliance.

The scores from the separate modalities are weighted and merged into a single composite score.

Release Gates and Thresholds

The output of the evaluation pipeline is a set of metrics (e.g., "Fidelity: 98%, Completeness: 85%").

These metrics form a Release Gate. In CI/CD, if a developer opens a Pull Request changing the system prompt, the evaluation pipeline runs against a subset of the Golden Dataset. If the Fidelity score drops below the established baseline (e.g., drops from 98% to 92%), the CI build fails. The Pull Request cannot be merged.

The tradeoff
Choosing the Judge Model
Use the same model as Production
+ you gain Cheaper and faster.
− you pay Blind spots. A model is terrible at finding its own logical errors. It will grade its own hallucinations as correct.
pick when Never for production release gates. (Okay for syntax/formatting checks).
Use a larger, more capable model (e.g., GPT-4 grading GPT-3.5)
+ you gain High correlation with human graders. Can detect subtle logical errors and hallucinations.
− you pay Expensive and slow.
pick when Mandatory for accuracy and fidelity evaluations.

Failure modes

Drifting Golden Datasets. If the product changes (e.g., adding support for a new language), but the Golden Dataset is not updated to include those new test cases, the evaluation pipeline will falsely report that the system is perfect. Datasets must be treated as living code and updated constantly from real production traffic.

Judge Bias. LLM judges suffer from known biases. They often prefer longer answers (verbosity bias), or answers where the most important information is at the very beginning or end (positional bias). If you do not control for these in the rubric prompts, your team will accidentally optimize the product to generate long, repetitive text simply to appease the automated judge.

What to carry forward

Key points
    You can now
    • Explain why human review is a bottleneck to generative AI development.
    • Design a multi-dimensional LLM-as-a-Judge grading rubric.
    • Architect an offline evaluation pipeline that handles multimodal outputs.
    • Implement a Release Gate in CI/CD that prevents prompt regressions.