LLM evaluation becomes unreliable when every answer is compressed into one number.

A response can be fluent but unsupported, factually correct but irrelevant, complete but difficult to use, or concise because it omitted the most important constraint. These failures require different engineering responses. Averaging them into one score can hide the distinction.

This does not mean that aggregate metrics are useless. A single number can help summarize a large experiment, compare stable model versions, or monitor a production trend. The problem begins when the aggregate becomes the only result and no longer explains why one system performed better than another.

This article presents a diagnostic evaluation design based on separate quality dimensions, explicit failure gates, evidence-backed review records, and segmented analysis. The main argument is that an evaluation should not only rank answers. It should identify what failed and indicate where the system should be changed.

The real decision is whether an answer is acceptable

Suppose a company uses an LLM assistant to answer questions about internal policies.

A user asks:

Can an enterprise customer receive a refund after cancelling an annual contract?

The assistant returns a clear and confident answer. It cites the general refund policy, correctly explains the standard cancellation period, and gives the user a concrete next step.

However, it omits an exception that applies specifically to enterprise contracts.

How should this answer be evaluated?

Its style may be strong. Most of its claims may be supported. It may address the user's question directly. An average score across several dimensions could therefore be high.

Operationally, however, the missing exception may make the answer unacceptable. The answer failed on the dimension that mattered most for the decision.

Why a single score answers the wrong question

A scalar score imposes a total ordering. Model A receives 0.86, Model B receives 0.83, and Model A appears better.

This comparison is convenient, but it removes information. The same average can be produced by very different quality profiles.

Answer A is excellent on three dimensions but omits important information. Answer B is less impressive on its strongest dimensions, but it meets a minimum standard across all four.

If completeness is a critical requirement, Answer B may be production-ready while Answer A is not. Their identical means do not preserve that distinction.

This is one reason holistic evaluation frameworks report multiple metrics rather than treating accuracy or preference as a complete description of model quality. Different metrics expose different capabilities, limitations, and trade-offs.

Represent answer quality as a vector

Let \(a_i\) denote an answer to evaluation case \(i\). Instead of assigning one score immediately, represent its quality as a vector:

$$\mathbf{s}_i = \left[ g_i, r_i, c_i, l_i \right]$$

where:

• \(g_i\) is groundedness,
• \(r_i\) is relevance,
• \(c_i\) is completeness,
• \(l_i\) is clarity.

Additional task-specific dimensions can be added when they affect the real workflow. A code assistant may require executability and security. A support assistant may require policy compliance and correct escalation. A research assistant may require citation accuracy and uncertainty reporting.

An aggregate can still be calculated:

$$S_i = \sum_{d=1}^{D} w_d s_{i,d}$$

where \(w_d\) is the weight assigned to dimension \(d\).

The aggregate is a summary of the vector. It should not replace the vector.

Weights also introduce assumptions. A weighted average states that strength in one dimension can compensate for weakness in another. That may be acceptable for some qualities, but it is often inappropriate for critical failures.

For example, excellent writing style should not compensate for an unsupported medical claim. High completeness should not compensate for exposing restricted information. Strong relevance should not compensate for giving an incorrect operational instruction.

Use hard gates for critical dimensions

A production-readiness rule can combine an aggregate score with dimension-level thresholds.

Let \(t_d\) be the minimum acceptable score for dimension \(d\). A simple readiness rule is:

$$Ready(a_i) = \mathbf{1} \left\{ s_{i,d} \geq t_d \text{ for every critical dimension } d \right\}$$

This rule prevents a high score in one area from hiding a blocking failure elsewhere.

A more realistic policy may include three levels:

• Pass: all critical dimensions meet their thresholds.
• Review: no blocking failure is present, but one or more scores are uncertain or close to the threshold.
• Fail: at least one blocking condition is present.

Blocking conditions do not need to be numerical. They can include:

• an unsupported high-impact claim,
• an incorrect citation,
• disclosure of restricted information,
• failure to refuse an unanswerable request,
• execution of the wrong tool action,
• omission of a mandatory warning or constraint.

This structure aligns evaluation with the deployment decision rather than with the convenience of reporting one number.

The core dimensions must be defined precisely

A rubric is useful only when two reviewers can apply its dimensions with reasonably consistent interpretations.

Groundedness is not the same as correctness

Groundedness asks whether a claim follows from the evidence supplied to the system. Correctness asks whether the claim is true according to the relevant reference or external reality.

The distinction creates four possible cases:

In a knowledge-base assistant, an unsupported but correct answer may still be a failure. The system contract may require every material claim to be traceable to an approved source.

For a RAG system, groundedness should also be separated from retrieval quality. A generator cannot ground an answer in a passage that was never retrieved, but it can still ignore or misuse a passage that was retrieved successfully. Frameworks such as RAGAS reflect this modular distinction by evaluating retrieval and generation through separate dimensions.

Relevance is about the task, not shared vocabulary

An answer can mention the same entities and technical terms as the question while solving a different problem.

For example, a user asking how to compare two model versions under a latency constraint does not need a general explanation of benchmark design. The explanation may be correct and well written, but it does not support the requested decision.

Relevance should therefore be evaluated against the user's intent, required output, constraints, and decision context.

Completeness depends on required facts

Completeness is difficult to score without defining what the answer must contain.

A vague instruction such as "cover the important points" leaves too much room for reviewer interpretation. A stronger evaluation case specifies expected facts or constraints:

• state the applicable refund period,
• identify the enterprise-contract exception,
• explain whether the fee is refundable,
• provide the correct escalation path.

The answer does not need to reproduce a reference response word for word. It does need to cover the information required for the intended action.

Clarity is audience-dependent

Clarity is not equivalent to brevity. A one-sentence answer can be unclear because it omits context. A longer answer can be clear when the task requires a sequence of steps or a careful qualification.

The rubric should identify the intended reader. An explanation written for an ML engineer should not be evaluated using the same expectations as an explanation written for a customer or an executive.

Use anchored rating levels

Human reviewers should not be asked to assign an unexplained score from 0 to 100. Fine numerical scales suggest more precision than the review process can usually support.

A small number of anchored levels is easier to apply consistently.

Anchor examples should accompany the definitions. Reviewers should see examples of a clear pass, a borderline case, and a blocking failure.

Scores can later be normalized to a 0 to 1 range for reporting. The original review should retain the discrete label, rationale, and evidence.

A example: the same mean, different decision

The following Python example represents answer quality as four separate scores. Both sample answers have the same arithmetic mean, but only one satisfies the minimum threshold on every dimension.

The scores are synthetic and serve only to demonstrate the decision rule.

from dataclasses import dataclass, fields


@dataclass(frozen=True)
class LlmAnswerScore:
    groundedness: float
    relevance: float
    completeness: float
    clarity: float

    def __post_init__(self) -> None:
        for field in fields(self):
            value = getattr(self, field.name)

            if not 0.0 <= value <= 1.0:
                raise ValueError(
                    f"{field.name} must be between 0 and 1"
                )

    def mean_score(self) -> float:
        values = [
            getattr(self, field.name)
            for field in fields(self)
        ]
        return sum(values) / len(values)

    def weakest_dimension(self) -> tuple[str, float]:
        return min(
            (
                (field.name, getattr(self, field.name))
                for field in fields(self)
            ),
            key=lambda item: item[1],
        )

    def production_ready(
        self,
        threshold: float = 0.80,
    ) -> bool:
        return all(
            getattr(self, field.name) >= threshold
            for field in fields(self)
        )


scores = {
    "answer_a": LlmAnswerScore(
        groundedness=0.98,
        relevance=0.94,
        completeness=0.58,
        clarity=0.90,
    ),
    "answer_b": LlmAnswerScore(
        groundedness=0.86,
        relevance=0.84,
        completeness=0.85,
        clarity=0.85,
    ),
}

for answer_id, score in scores.items():
    weakest_name, weakest_value = (
        score.weakest_dimension()
    )

    print(
        f"{answer_id}: "
        f"mean={score.mean_score():.3f} "
        f"ready={score.production_ready()} "
        f"weakest={weakest_name}:{weakest_value:.2f}"
    )

The following values are the actual output produced by executing the code:

answer_a: mean=0.850 ready=False weakest=completeness:0.58
answer_b: mean=0.850 ready=True weakest=relevance:0.84

What the example shows

The mean score cannot distinguish the two answers. Both receive 0.850.

Answer A fails the production rule because its completeness score is 0.58. Answer B passes because every dimension exceeds the threshold of 0.80.

This does not prove that 0.80 is the correct threshold for a real application. Thresholds must be selected from the failure costs, reviewer behavior, and acceptable risk of the specific system.

The example demonstrates a structural property of averaging: an aggregate allows compensation between dimensions. A gated policy does not.

In practice, I would report both:

• the score vector for diagnosis,
• the aggregate for summary and trend monitoring,
• the blocking decision for deployment.

Store the evidence behind each judgement

A score without supporting evidence is difficult to audit. Several weeks later, the team may no longer know why an answer received 0.58 for completeness or whether the rubric has changed since the review.

A useful evaluation record should preserve:

• the input and expected task,
• the generated answer,
• retrieved evidence and citations,
• dimension-level scores,
• the reviewer rationale,
• blocking failures,
• model, prompt, tool, and index versions,
• the evaluator type and version.

review_record = {
    "question_id": "policy-017",
    "question": (
        "Can an enterprise customer receive a refund "
        "after cancelling an annual contract?"
    ),
    "retrieved_sources": [
        "policy.md#refunds",
        "contracts.md#enterprise-exceptions",
    ],
    "scores": {
        "groundedness": 0.92,
        "relevance": 0.88,
        "completeness": 0.58,
        "clarity": 0.91,
    },
    "blocking_failures": [
        "enterprise_exception_omitted",
    ],
    "review_note": (
        "The answer states the general refund rule "
        "but omits the enterprise-contract exception."
    ),
    "versions": {
        "model": "candidate-model-2026-07",
        "prompt": "support-answer-v12",
        "retrieval_index": "policies-2026-07-20",
        "rubric": "policy-answer-rubric-v4",
    },
}

This record can become a regression test. When the model, prompt, retrieval system, or source corpus changes, the same case can be replayed and compared at the dimension level.

Human review needs calibration

Human judgement is not automatically reliable. Reviewers may interpret dimensions differently, apply thresholds inconsistently, or allow writing style to influence factual scoring.

Before a large evaluation, I would run a calibration round:

1. Select a small set containing clear passes, clear failures, and borderline cases.
2. Ask reviewers to score the cases independently.
3. Compare disagreements by dimension.
4. Discuss which words in the rubric caused different interpretations.
5. Add or revise anchor examples.
6. Repeat until the remaining disagreement is understood.

The objective is not perfect agreement. Some tasks contain legitimate ambiguity. The objective is to determine whether disagreement comes from the answer or from an underspecified rubric.

Agreement should also be inspected separately for each dimension. Reviewers may agree strongly on relevance but disagree on completeness or clarity. A single agreement statistic can conceal that pattern just as an average answer score can.

LLM-as-a-judge is useful but not an oracle

Using another language model as an evaluator can reduce cost and increase evaluation coverage. Studies such as MT-Bench and G-Eval reported meaningful alignment between strong LLM judges and human preferences in their evaluated settings.

Those results do not establish that every judge, prompt, rubric, task, or domain will behave reliably.

LLM judges can be sensitive to:

• the order in which candidate answers are presented,
• answer length and writing style,
• the wording of the evaluation prompt,
• the model family that generated the answer,
• the scale and labels used by the rubric,
• the presence or absence of a reference answer,
• the difficulty of verifying domain-specific claims.

Research on LLM evaluators has demonstrated position bias: swapping the order of two candidate answers can change the preference. G-Eval also reported concerns about possible evaluator preference for LLM-generated text.

I would therefore treat an LLM judge as a measurement instrument that requires validation.

Calibrate against reviewed cases

Create a human-reviewed calibration set and compare the automated evaluator against it. Inspect disagreement cases rather than reporting only a global correlation.

The calibration set should contain:

• clear factual failures,
• subtle omissions,
• well-written but unsupported answers,
• correct answers with poor style,
• borderline refusals,
• answers from several model families,
• short and long responses.

Reverse pairwise order

For pairwise evaluation, score both answer orders:

• Answer A followed by Answer B,
• Answer B followed by Answer A.

A preference that changes after the swap should be marked as unstable or sent for human review.

Require dimension-specific evidence

Do not ask only for a score. Ask the evaluator to identify the claim, sentence, or missing requirement that justifies the score.

The rationale should not be treated as proof that the score is correct. It is an audit artifact that makes obvious mismatches easier to detect.

Version the judge

A judge model, system prompt, sampling configuration, rubric, and reference set define one evaluator configuration. Changing any of them can change the score distribution.

Historical scores should not be compared as though the measurement instrument remained constant when the judge configuration changed.

Combine deterministic checks with judgement

Not every evaluation criterion requires an LLM or a human reviewer.

Deterministic checks are preferable when the requirement can be measured directly:

• valid JSON or schema compliance,
• presence of required fields,
• successful code execution,
• unit-test results,
• citation identifiers that exist,
• maximum response length,
• tool-call arguments,
• forbidden data patterns.

Semantic judgement is more appropriate for qualities such as:

• whether a citation supports a claim,
• whether the answer addresses the intended question,
• whether an explanation is complete for the target audience,
• whether uncertainty is communicated appropriately.

A robust evaluation suite usually combines:

1. deterministic validators,
2. reference-based checks where reliable references exist,
3. rubric-based human or model review,
4. end-to-end task or policy outcomes.

Using an LLM judge for a condition that could be checked exactly adds unnecessary variance.

The rubric must depend on the use case

A support assistant, coding agent, summarizer, research assistant, and autonomous workflow agent should not share one universal production rubric.

They may reuse dimensions, but the definitions, thresholds, and blocking failures differ.

The evaluation should reflect the decision the system supports and the cost of each failure. A style regression and an unauthorized tool action should not receive equivalent treatment merely because both reduce an overall score.

Evaluate segments, not only global averages

A model can improve globally while becoming worse on a critical subset.

Useful segments may include:

• answerable and unanswerable questions,
• questions with strong and weak evidence,
• single-source and multi-source tasks,
• short and long contexts,
• different languages, products, or customer groups,
• normal, ambiguous, and adversarial instructions,
• tasks requiring tools and tasks requiring only generation.

Suppose a new model improves average relevance from 0.84 to 0.88 but reduces correct refusal behavior from 0.92 to 0.70. The global improvement does not determine whether the release is acceptable.

For each important segment, I would report:

• sample size,
• dimension-level means or pass rates,
• blocking-failure frequency,
• uncertainty intervals where appropriate,
• differences from the production baseline,
• examples of regressions.

Small segments should be interpreted cautiously. Large score changes based on a few cases may represent sampling noise rather than stable behavior.

Build the dataset from requirements and failures

An evaluation set should contain more than a random sample of ordinary interactions.

I would combine several sources:

• Core capability cases: representative tasks the system must perform.
• Known regressions: failures previously found during testing or production use.
• Boundary cases: requests near policy, data, or tool limits.
• Unanswerable cases: prompts where the evidence is insufficient.
• Ambiguous cases: prompts where clarification is better than guessing.
• Adversarial cases: prompts designed to expose instruction-following or grounding weaknesses.
• Recent production samples: new behavior not represented in the original test set.

Stable regression cases and changing production samples serve different purposes.

The stable set makes model versions comparable. The recent sample detects distribution shift and new failure modes. Replacing all evaluation cases on every run would make historical comparison difficult, while never updating the set would allow it to become unrepresentative.

A practical validation workflow

I would operationalize the evaluation in the following sequence:

1. Define the deployment decision. State what must be true for an answer to be accepted.
2. List critical failure modes. Identify failures that cannot be compensated by strengths elsewhere.
3. Select core and task-specific dimensions. Avoid dimensions that do not lead to an engineering action.
4. Write anchored rubric levels. Include pass, fail, and borderline examples.
5. Create the evaluation dataset. Combine representative, adversarial, unanswerable, and regression cases.
6. Calibrate human reviewers. Investigate disagreement by dimension.
7. Validate automated judges. Compare them with reviewed cases and test order sensitivity.
8. Run deterministic checks first. Reserve semantic judgement for criteria that require it.
9. Report vectors and gates. Use aggregates only as secondary summaries.
10. Analyze important segments. Do not rely only on global averages.
11. Store versions and evidence. Preserve enough information to reproduce each judgement.
12. Convert failures into regression cases. Keep the suite connected to real engineering work.

The result should be more than a leaderboard. It should be a decision record explaining whether the new system is acceptable, where it improved, where it regressed, and what should be investigated next.

Key takeaways

• A single LLM evaluation score is useful as a summary, but it is too lossy to serve as the complete evaluation.
• Answer quality should be represented as separate dimensions linked to identifiable engineering actions.
• Critical requirements should use thresholds or blocking gates so that strong style cannot compensate for a factual or operational failure.
• Groundedness, correctness, retrieval quality, and source validity are related but distinct properties.
• Human reviewers need anchored rubrics and calibration; LLM judges need validation, versioning, and bias checks.
• Evaluation results should be segmented by task and failure type, not reported only as global averages.
• Every material production failure should produce evidence, a diagnosis, and a reusable regression case.

Sources

1. Liang, P., Bommasani, R., Lee, T., et al. (2022). Holistic Evaluation of Language Models.
2. Liu, Y., Iter, D., Xu, Y., Wang, S., Xu, R., and Zhu, C. (2023). G-Eval: NLG Evaluation using GPT-4 with Better Human Alignment. Proceedings of EMNLP 2023, 2511-2522.
3. Zheng, L., Chiang, W.-L., Sheng, Y., et al. (2023). Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena.
4. Wang, P., Li, L., Chen, L., et al. (2024). Large Language Models are not Fair Evaluators. Proceedings of ACL 2024, 9440-9450.
5. Es, S., James, J., Espinosa Anke, L., and Schockaert, S. (2024). RAGAs: Automated Evaluation of Retrieval Augmented Generation. Proceedings of EACL 2024 System Demonstrations, 150-158.