LLM Application Evaluation: Measuring Whether the Entire System Completes Real Tasks

The first question evaluation must answer is: what does “good answer” mean? If two reviewers understand this term differently—one thinks “polite enough” counts as good, another thinks “no errors” counts as good—then the scores they give do not share a common measurement basis. Once scores lose a common basis, they cannot answer the truly important question: whether this change can be released. Release decisions do not need a vague “overall feeling” but an acceptance contract that both parties can verify item by item.

Taking a refund assistant as an example, the fact that “the user successfully obtained a refund” cannot be evaluated as a whole. It must be broken down into a series of atomic properties: whether the eligibility judgment is correct (those who should not get a refund did not, and those who should did), whether the refund amount is correct, whether every policy claim is supported by evidence, whether it promises actions it has no authority to perform, whether it asks before guessing when information is missing, whether the output structure can be directly parsed by the frontend, and whether the entire processing stays within latency and cost budgets. After decomposition, “good” is no longer a subjective impression but a set of pass/fail judgments that can be checked individually.

Each atomic property must also be paired with three things: applicable conditions, evidence, and decision rules. Applicable conditions specify in which scenarios this property needs to be checked—for example, “ask for missing information” applies only when user input is incomplete; evidence specifies what to judge by, for example which field in the final reply text; decision rules specify what standard must be met to pass. Without these three, a property is just a slogan, and evaluation will still fall back to scoring by feel.

The decomposed properties are not equal. Errors in eligibility judgment, amount errors, privacy leakage, and unauthorized promises are hard constraints: a single occurrence may directly block release, because the loss they cause is not “slightly worse experience” but substantive damage to funds, compliance, or trust. Natural wording falls under soft goals: its role is to rank qualified candidates that have already passed hard constraints, not to compensate for unqualified solutions. Mixing the two types together first and averaging scores creates a dangerous compensation effect—“better-sounding” wording can offset “more dangerous” errors, and the average score thereby conceals the failures that should actually block release.

To prevent this conflation, scoring must follow a fixed contract structure: sample input + run context + expected properties + scorer + failure severity + system version. Sample input is the specific request to be evaluated this time; run context records the environment and conditions under which the evaluation occurs; expected properties are the atomic properties and their decision rules decomposed above; scorer specifies how the judgment is made; failure severity distinguishes hard constraints from soft goals; system version ensures results can be mapped to the specific system under test. If any of these six items is missing, reproducibility and attribution both weaken—without reproducibility, it is unclear whether a result is caused by the environment or by the system; without attribution, it is unclear which component to change.

The contract's operation can be summarized as an input-output relationship: inputs are samples, run context, expected properties, scorer, severity, and system version; outputs are a reproducible pass or fail conclusion and the reason for failure. The execution order also matters: hard constraints are judged first; as long as one hard constraint fails, the evaluation result is a release block, and soft goal scores no longer participate; only when all hard constraints pass can feasible solutions be ranked by soft goals. If this order is reversed, returning to the old path of “first compute the average score and then decide,” the acceptance contract becomes ineffective.

Therefore the causal chain of the whole matter is: when reviewers cannot share decision rules, the total score cannot guide release; to share rules, business success must be decomposed into atomic properties; to prevent soft-hard conflation, hard constraints must be judged first and soft goals used for ranking; to make the whole process reproducible and attributable, samples, context, properties, scorer, severity, and version must be fixed into a contract. A contract is not a formal table, but the prerequisite that turns the decision to “release” from a subjective impression into a checkable judgment.

When an answer is wrong, the team's first reaction is often “try a stronger model.” This reaction is dangerous because it assumes the error must have occurred at the generation step. But a real LLM application is not a single-point model; it is a chain that extends from input, retrieval, generation, tool calls all the way to business results. Errors can occur at any link in the chain; switching models only affects the generation link; if the problem is not in the generation link at all, a stronger model only makes the error continue to appear in a more confident way.

Layering the evaluation target is precisely to solve this problem. Taking a refund assistant as an example, evaluation should unfold layer by layer along the chain: the input layer handles how user requests enter the system, the retrieval layer decides which policy clauses to recall, the generation layer produces replies based on the recalled content, the tool layer is responsible for executing actions such as refunds and order queries, and finally lands on business results—whether the user actually completed the refund correctly. Each layer corresponds to its own component metrics, while the result of the whole chain corresponds to end-to-end metrics.

End-to-end results determine whether it can go live; component metrics are responsible for explaining why. These two directions are indispensable: with only component metrics and no end-to-end results, the team falls into local optima—each component appears to be improving individually, but the complete task has not gotten better; with only end-to-end results and no component metrics, problems cannot be diagnosed—you only know “the final answer is wrong,” but not which link went wrong. Figure 1 expresses this division of labor: go-live decisions hang on end-to-end, attribution analysis hangs on components.

The example of “the final answer has no citations” can make the causal chain of layered diagnosis clear. Lack of citations is only a symptom; upstream there are at least four possibilities: the retrieval layer did not retrieve the clause; the context was truncated before entering generation; the prompt did not require item-by-item citation; and the rendering layer dropped the citation id when assembling the page. These four causes fall at different positions in the chain, and the repair actions are completely different—fix recall, fix truncation, fix prompt, fix rendering. Only by recording the intermediate outputs of each layer can the vague “the model is not good enough” be rewritten into an executable repair instruction.

Therefore, the input to application evaluation is the versioned configuration of each layer—input processing, retrieval strategy, generation strategy, tool strategy, and interface chain. Versioning ensures that every evaluation can correspond to a specific object under test; the output is two things: component diagnosis and end-to-end business results. Component diagnosis answers “which link did the first deviation occur in,” and end-to-end results answer “whether the complete task was accomplished.”

This division of labor also draws two types of boundaries that must not be confused. First, local improvement of a component does not equal improvement of the complete task: an increase in retrieval recall does not mean a higher final refund success rate, because downstream may still truncate and generation may still omit clauses. Second, diagnosis cannot replace final acceptance: component metrics can locate failures to a layer, but “whether it can be released” is always determined by end-to-end results. The evaluation target is a bounded chain—within the boundary, diagnose layer by layer; outside the boundary, only look at end-to-end.

Why do ten carefully written “normal questions” create a false sense of security? Because these questions come from the reviewers’ imagination rather than from real users. In real traffic you will hardly find a question with standard wording, complete information, and pure intent: users make typos, use colloquial speech, omit key information, present mutually conflicting policies together, add conditions over multiple turns, upload very long attachments, make unauthorized requests, and even directly attempt prompt injection. A handwritten question bank filters all of these out, so the system performs excellently on the bank and is shattered by real traffic on the first day of launch. The problem with samples is not quantity but source: samples must come from the task distribution, not from an inspiration question bank.

To build sample data, draw from five buckets. High-frequency tasks ensure the most common workloads are covered; high-loss tasks include the scenarios with the greatest cost of error, such as large refunds or compliance-sensitive operations; historical incidents freeze failures that actually occurred online to prevent regressions; boundary combinations cover edge cases produced by the combination of inputs, policies, and tool states; real sampling directly captures production traffic within a time window, ensuring the data reflects the actual distribution. After the five buckets are combined, each sample must also be tagged with slice labels: language, customer group, channel, length, tool, and risk. The purpose of the labels is to analyze by slice after evaluation—differences hidden by the overall score will become visible in the slices.

A sample set is not “a single dataset” but four sets with different purposes, and their weighting interpretations must not be mixed.

The development set is used for day-to-day prompt tuning and may be viewed frequently: its value lies in giving fast feedback, and the slight overfitting caused by repeated viewing is an acceptable cost. The frozen gating set runs only after a candidate version has matured: the team must not repeatedly inspect it in daily iteration precisely to reduce test overfitting—if the gating set has been overused, a passing version may have merely memorized the answers. The challenge set deliberately concentrates long-tail and adversarial cases: its mission is to expose low-frequency, high-loss risks, so the proportion of the challenge set must not be used to estimate the overall success rate. The online sampling set is the one responsible for estimating the true distribution: it requires anonymization, permission review, and a clear time window, because real user data entering the evaluation process itself carries privacy and compliance costs.

Each of the four sets manages one segment of the causal chain: the development set gives daily iteration feedback, the frozen set keeps the release threshold from being polluted by overfitting, the challenge set keeps long-tail risks from being drowned out by average scores, and the online sampling set keeps the overall estimate faithful to the true distribution. If you verify this logic in reverse it becomes clearer: taking the attack samples that account for 30% of the challenge set and averaging them with real-traffic weights would underestimate normal experience—because online attack samples are nowhere near 30%; conversely, ignoring the challenge set entirely would mask low-frequency, high-loss risks—because such samples almost never appear in random sampling. Therefore the two must be reported separately, not merged into a single overall score.

From this we can obtain the complete form of sample design: inputs are real traffic, high-loss tasks, historical incidents, boundary combinations, and adversarial scenarios; outputs are datasets labeled with language, group, length, tool, and risk. The boundaries for use are equally clear: the challenge set’s proportion is not equal to the production incidence rate—it measures the system’s exposure under stress, not the probability of online risk; the online sampling set’s overall estimate also cannot replace the challenge set’s risk-exposure testing. Each has its own role, and mixing their weights only causes both conclusions to be distorted at the same time.

If an LLM judge says “qualified,” is the true quality necessarily qualified? The answer to this question is negative, and the reason is not that the judge is occasionally careless, but that scorers are essentially a set of measuring instruments. Any instrument reading contains bias and noise; treating the instrument reading as the true value of the measured object is the most hidden type of error in evaluation.

Different attributes suit different scorers; the choice basis is the attribute's degree of determinism and validation cost. For determinable attributes such as amounts and dates, prioritize programmatic assertions: compare the amount in the output with the true amount in the order system exactly. It is deterministic, cheap, and reproducible, but the blind spot is that the input truth value itself may be wrong—if the order amount the system receives is already wrong, a programmatic assertion will only confirm an erroneous value. Tool side effects are suited to evaluation by sandbox state differences: execute actions in a controlled sandbox and directly check whether the real result occurs, such as whether the account balance actually changed after a refund action; the blind spot is the difference between the simulated environment and production—operations that pass in the sandbox may not hold under production permissions or network conditions. Evidence-support attributes are suited to claim–evidence verification: for each policy claim in the answer, check whether it can be located to a specific span in the source text to prevent “citation without support”; the blind spot is that the source itself may be outdated—consistency between the citation and the original text does not mean the clause is still valid. Open semantic attributes such as helpfulness and tone are suited to a blinded LLM plus human combination: the LLM handles the scale of open semantics, and humans backstop the final judgment; the blind spot is order, length, and cultural bias—the judge may prefer answers that are placed earlier or written longer, or may have systematic preferences for certain expression styles.

Treat scoring as measurement, and the observed score has a clear error decomposition: observed score = true quality + scorer systematic bias + sample random error. Written in symbolic form: Score_obs = Q_true + B_judge + E_sample. The system under test itself has a latent true quality Q_true; the scorer has its own systematic bias B_judge, such as position preference, style preference, cultural preference, which does not fluctuate across samples but exists fixed according to scorer characteristics; sample random error E_sample comes from accidental fluctuations in this particular sampling and annotation. Only by superimposing the three do we obtain the observed score, so any change in score cannot be directly attributed to “the system getting better or worse”—it could also be changes in judge bias or sample noise.

Since the judge has systematic bias, we need to calibrate it with gold-standard samples. The method is to take a batch of gold-standard samples that have been annotated by two people and arbitrated—two annotators score independently, disagreements are resolved by arbitration, and the arbitration result serves as the baseline answer for that sample—then use the gold standard to calculate the judge's precision, recall, and consistency on each slice. Precision answers “how many of those judged qualified by the judge are truly qualified”; recall answers “how many of the truly qualified did the judge find”; consistency answers “whether repeated scoring results are stable”. There are also specific checks for bias types: swap candidate order and see whether scores flip with position to test position bias; unify candidate length or clarify rubric and observe score changes to reduce style bias. In addition, there is a hard discipline: the model judge cannot read instructional content in the candidate text to change the scoring rules; otherwise, the candidate under test could directly “persuade” the judge to give itself extra points, and the instrument would be manipulated by the object under test.

This calibration framework gives the boundaries for using scorers. The measurement model's inputs are latent quality Q_true, scorer systematic bias B_judge, and sample random error E_sample; the output is observed score Score_obs; because the score is the sum of the three, any approach that directly treats the judge's output as truth will mix B_judge and E_sample into the conclusion. Calibration can only make bias measurable, comparable, and correctable; it cannot turn the judge into the ground truth. This yields a selection principle: for high-risk, determinable attributes, prioritize programmatic assertions or state checks, because these instruments do not have the semantic bias of a judge; LLM judges should be reserved for truly open semantic attributes, and always used together with precision, recall, and bias data.

The new version's weighted pass rate increased from 80.3% to 83.1%, but the pass rate for unauthorized requests also dropped significantly. Should it be released? Working through this question makes the real relationship between average improvement and release decisions clear.

First, lay out the data for three slices. Ordinary eligibility Q&A accounts for 70% of traffic, with an old-version pass rate of 84%, a new-version pass rate of 90%, and a failure cost of 1; amount calculation accounts for 20%, with old 75%, new 78%, failure cost 3; unauthorized requests account for 10%, with old 65%, new 45%, failure cost 12. First look at the weighted pass rate: old version 0.7×84 + 0.2×75 + 0.1×65 = 80.3%, new version 0.7×90 + 0.2×78 + 0.1×45 = 83.1%, seemingly an improvement of 2.8 percentage points. Looking only at this table, the new version improves significantly on the largest-traffic slice, while the regression on the unauthorized slice is diluted by its 10% weight.

Now look at risk loss, i.e., multiply each slice's failure probability by its failure severity: old version 0.7×0.16×1 + 0.2×0.25×3 + 0.1×0.35×12 = 0.682; new version 0.7×0.10×1 + 0.2×0.22×3 + 0.1×0.55×12 = 0.862. Here each 1−pass rate is that slice's failure probability: the unauthorized slice worsens from 0.35 to 0.55, and multiplied by the failure cost of 12, this single term rises from 0.42 to 0.66. Overall risk loss rises from 0.682 to 0.862, worsening by about 26%. The 2.8-point improvement in average pass rate is a net regression in the risk dimension.

Write these two calculations in general form. The gating case takes slice weights wi, pass rates pi, and failure severities ci as inputs, and outputs two quantities: weighted pass rate PassWeighted and risk loss RiskLoss. The former is Σwi×pi, measuring overall pass proportion; the latter is Σwi×(1−pi)×ci, measuring expected loss after weighting failure probability by severity. What this example shows is exactly: total pass rate improves, while RiskLoss rises from 0.682 to 0.862, and the regression in the high-risk slice is not offset by averaging.

But in practice, gating should not rely on the RiskLoss number itself. The reason is that ci is a set of utility weights—converting one unauthorized failure into 12 ordinary units—and weights are inherently value judgments, full of controversy. The practical approach is to first set hard thresholds: the unauthorized slice “must not be lower than the old version and at least 60%.” Under this threshold, the new version's 45% fails outright, without any need to argue whether the number 12 is reasonable. Cost weights are used only to prioritize fixes: the slice with the highest risk loss is fixed first; hard thresholds protect non-negotiable constraints that no average score has the authority to override.

There is also an organizational-level causal factor hidden here: failure costs are determined jointly by business, legal, and affected people, not a technical constant filled in by an evaluation engineer alone. Hard-coding cost weights into the evaluation script amounts to disguising a value judgment as a value consensus—the number looks objective, but it is actually just one person's estimate. What release decisions need is not a more refined weighting formula, but two disciplines: hard thresholds are executed first, and disputed weights are used only for prioritization.

After an end-to-end score drop, how do you tell whether the problem lies in the model, retrieval, or prompt? Simply observing each component's metrics yields only correlation—retrieval scores fell and end-to-end scores fell too, but their simultaneous occurrence does not mean one caused the other. Component ablation turns correlation into repair clues: keep the same batch of inputs, freeze other variables, replace only one component, and observe how the end-to-end results change.

For different suspected components, ablation experiments have corresponding designs and supportable conclusions. When the generator is suspected, use oracle-evidence ablation: feed the correct gold-standard clauses directly to the generator, bypassing the retrieval stage. If it still answers incorrectly with correct evidence, the problem leans toward the generation stage or rule design; if it answers correctly with correct evidence, the problem is the recall ceiling—retrieval did not find the needed clauses, rather than the generator not knowing how to use them. This experiment separates the two causal factors of 'recall ceiling' and 'generation use.' When the index is suspected, keep the same model and replace only the old retrieval with the new retrieval, with prompts and sampling parameters unchanged; the end-to-end change can estimate the index version's impact. When the tool stage is suspected, use tool-replay ablation: replay the previously recorded tool return results as-is, making every evaluation face exactly the same tool responses; external service fluctuation is isolated, so end-to-end differences can no longer come from tool instability. When rendering or rules are suspected, use rule on/off ablation: run the same sample set in pairs—rules on once, rules off once—the comparison can estimate the guardrail's benefit and whether it caused over-refusal.

Here is an easy-to-miss boundary: component scores themselves are not the final goal. A higher Recall@5 for retrieval may just stuff in more distractors and reduce generation faithfulness—the higher the recall, the less faithful the answer, and such component 'progress' is harmful to the task. High tool-call accuracy may also manifest as excessive action when it should not be called—successful execution of the tool itself does not mean the action was necessary. Therefore, the value of ablation lies in narrowing the causal candidate set, not in proving that a component independently determines the result.

The input to an ablation experiment is the same batch of samples, the other frozen variables, and one component to be replaced; the output is a causal clue about which link—retrieval, generation, tool, or rendering—caused the end-to-end difference. Each design corresponds to a discipline: oracle evidence removes recall limits, tool replay isolates external fluctuations, and rule on/off estimates guardrail effects. Conversely, changing multiple factors at once makes attribution completely impossible—if you change the model, retrieval, and prompt at the same time and the end-to-end result changes, who is responsible? So the bottom line of controlled ablation is: change only one variable per round.

Causal clues ultimately must tie back to acceptance: ablation can only narrow the 'suspect scope' to a certain layer; whether the fix ultimately succeeds still has to return to the overall acceptance of the business task. If a layer's metrics are made to look good but end-to-end has not recovered, it means the causal candidate was guessed incorrectly, or there is a second cause that was not surfaced by ablation. Ablation is a diagnostic tool, not a release basis.

After all offline evaluation sets have passed, why can't we switch directly to full traffic? Because everything that offline replay can see comes from old data and simulated environments. It is fast, safe, and repeatable, but it cannot see how real users react, nor what changes occur in external services in the production environment. A perfect offline score answers 'whether it is correct on fixed samples', not 'what will happen in real traffic'. Between offline and full rollout, we need a release ladder that gradually increases realism.

The first level is the offline gate: all hard slices pass, and the difference interval of the primary metric meets the requirement. This level answers the qualification question—unqualified candidates never proceed to the next step. The second level is shadow traffic: let the new version process real online requests, but the results are not shown to users. Because they are not shown, the risk is almost zero; but it can measure things that offline cannot—the distribution of real inputs, capacity, latency, version records, and the execution of tool read operations. The boundary of the shadow stage is to never execute irreversible tools; read operations can be allowed, write operations must be forbidden. The third level is small traffic release (canary): only at this point do we first observe real interactions. Canary must be randomly assigned according to stable user units, to prevent the same session from jumping between versions—users seeing the new version in one turn and reverting to the old version in the next will have a distorted experience and confused attribution. This level must also monitor harm, completion rate, and manual takeover situations.

Every step of expansion must come with real-time hard guardrails, stop rules, and rollback capability. When expanding, maintain an observation window at each level: expanding without an observation window is equivalent to treating an experiment as a release. If any of unauthorized behavior, p95 latency, or error budget exceeds the threshold, roll back immediately—this stop action should be automatic, not waiting for a review meeting. Rollback capability must exist before expansion; otherwise the so-called 'small traffic' is just full rollout under a different name.

The inputs to this entire process are the offline gate, shadow results, canary metrics, and rollback thresholds; the output is a three-way decision: continue expanding, stop, or roll back. The causal division of labor among the levels is: offline first proves that hard slices are qualified, shadow verifies real inputs and capacity but does not touch irreversible actions, and canary observes real interactions; each level relies on the observation window to decide whether to proceed to the next level.

Finally, there is one more boundary regarding online signals: user likes are a weak signal. Silence does not mean correctness—most users will not report a mild error; satisfaction may even reward over-promising—the more boldly the system promises, the more satisfied users are at the moment, but the loss from unfulfilled promises is borne by the backend. Therefore, online behavioral metrics must be used in combination with sampled human review and deterministic business outcomes: behavioral metrics are responsible for detecting anomalies, human review and business outcomes are responsible for judging authenticity. Making release decisions based solely on like rate is equivalent to handing risk over to the silent majority.

Why might continuously adding every live failure to the test set still make it increasingly untrustworthy the more you test? Because the lifecycle of the test set is overlooked. After a failed sample is added to the fixed set, the team immediately tunes parameters for that question, and the next evaluation passes. If this process repeats enough times, the set is no longer a "sample of the real task" but gradually becomes training signal itself: the system learns these specific questions rather than the task. At the same time, two aging mechanisms compound: duplicate neighbors overcount certain accidents—the same failure appears in ten similar variants, and this accident is weighted ten times; outdated policies also make answers invalid—policy clauses have changed, but samples still judge right and wrong according to old rules, so passing or failing no longer carries meaning.

To make the evaluation set renew itself in a controlled way, each sample needs to record metadata: source, creation time, applicable policy, personal information handling method, deduplication cluster, and retirement condition. Source and creation time answer "why is this sample here"; applicable policy binds the sample to a specific policy version so that when policies change, you can locate which samples need review; personal information handling marks whether the sample contains privacy data and its processing permission; deduplication cluster prevents near-duplicate variants from being over-weighted; retirement condition states when this sample should exit, rather than remaining in the set forever.

Metadata is only a prerequisite; real governance lies in the versioning process. Failed samples do not go directly into the fixed set, but follow the path "discovery pool → review → development set → next version frozen set": newly discovered failures first enter the discovery pool; after review confirms they are real, non-duplicate, and do not contain invalid policies, they enter the development set for daily iteration; only in the next version do they enter the frozen gate set. Once the current release gate is frozen, you cannot delete questions or change the rubric because a candidate version fails—deleting a question that makes the candidate fail is equivalent to changing the passing line on the spot. Necessary changes can only be completed by upgrading the version, and the results of the old version must be retained to ensure comparability across versions. The responsibility of data drift monitoring is to signal when to resample—automatically retraining upon seeing distribution changes is actually the wrong response, because changes may be temporary; first judge, then act.

The inputs of this governance chain are the sample's source, time, policy version, privacy status, neighbor cluster, and retirement condition; the outputs are the discovery pool, review records, development set, frozen set, and migration records for the next version. Causally, adding failed samples directly and repeatedly tuning parameters turns the gate into a training set; the frozen set cannot be modified due to candidate failure; updates to the set must go through versioned migration rather than in-place patching.

Finally, there is the boundary of evaluation itself. Evaluation can only reduce risks that have been modeled—the failures you write into the set are the directions in which the system becomes reliable; it cannot prove that the system is absolutely safe in the open world. For those low-frequency but irreversible actions—a transfer that cannot be recovered, an external commitment that cannot be withdrawn—even if you put one thousand samples in the evaluation set, the remaining risk still must be controlled by permission constraints and human-in-the-loop. However good the evaluation set is, it does not replace these two lines of defense.

The starting point of this evaluation methodology is a specific problem: when reviewers disagree on what constitutes a "good answer," scores cannot guide release. From this problem, the entire causal chain can be connected step by step to verifiable practices, and each step is a response to the shortcomings of the previous step.

First, break down business success into decidable attributes. The overall "refund success" cannot be scored; atomic attributes such as eligibility, amount, evidence, permission, follow-up, structure, latency, and cost can be judged one by one. Decomposition solves the problem that "good" has no common baseline: with attributes and judgment rules, two reviewers can share the same ruler.

Second, construct versioned samples from the real distribution. Having a ruler is not enough; you also need a tested object that represents real tasks. Handwritten question banks create a false sense of security; typos, colloquial speech, conflicting policies, unauthorized requests, and prompt injection in real traffic are the distribution the system will face. Five buckets—high frequency, high loss, historical incidents, boundary combinations, and online sampling—provide material, and the development set, frozen gate set, challenge set, and online sampling set are separated by purpose, each with versions and labels. This step solves the problem of "what to test."

Third, combine and calibrate scorers. Having samples is not enough; you also need a reliable measurement method. Use programmatic assertions for amounts and dates, sandbox state differences for tool side effects, claim–evidence verification for evidential support, and blinded Large Language Model (LLM) plus human review for tone and helpfulness; any scorer has systematic bias, so use gold-standard samples to measure precision, recall, position bias, and style bias. Observed score = true quality + scorer bias + sample error. Calibration makes instrument error measurable rather than ignorable.

Fourth, run end-to-end and component ablation. End-to-end results answer "can it go live?"; component metrics answer "why?". When the end-to-end score drops, ablation experiments such as oracle evidence, swapping the index while using the same model, tool replay, and rule toggles turn correlation into causal clues and rewrite "the model is bad" into actionable fix instructions.

Fifth, decide by hard gates, slices, and cost. Once the data is complete, decision rules determine everything. Hard gates such as "must be no lower than the old version and at least 60%" on the unauthorized-access slice are enforced first; cost weights are used only to rank repair priority. Slice-weighted pass rates and risk losses are reported separately, so average improvement does not offset high-risk degradation. This step solves the problem of "how scores become decisions."

Sixth, bring production failures back to the next version through review. The chain must not break at release: real online failures enter the discovery pool, then after review enter the development set, and only in the next version enter the frozen gate set. Adding failure samples directly and repeatedly tuning hyperparameters will cause the gate to degenerate into a training set; the backflow must be supported by metadata such as source, time, policy version, privacy status, deduplication cluster, and retirement conditions, and old version results must be retained.

These six steps form a closed loop: attribute decomposition makes goals decidable, versioned samples make goals correspond to the real distribution, calibrated scorers make measurement trustworthy, end-to-end plus ablation makes results interpretable, hard gates make decisions executable, and failure backflow keeps the evaluation set updated with the world. A break anywhere in the loop will show up at another point: distorted samples will render even the best scorers useless, and missing gates will strip even the most accurate measurement of its binding force. Ultimately, evaluation delivers not a score, but a causal chain that starts from business success, goes through measurement, diagnosis, and decision-making, and returns to sample updates.