Reading Per-Class Evaluation Results

Imagine a delivery team reporting that their model passes some kinds of cases and fails others. The natural first reaction is to suspect the model itself. Maybe it needs more training, a different architecture, or more tuning. That reaction is understandable, but it skips a question that matters just as much. The scores come from an evaluation set, and the evaluation set was built by people choosing which cases to include and how each case was labeled. If that set is flawed, the scores can point in the wrong direction.

This article is about that second question. Before deciding what is wrong with a model, you need to ask whether the eval set is an honest measuring instrument. The sections below follow one line of reasoning: first what an eval set does, then how to tell a labeling problem from a model problem, then how to calibrate the eval set, and finally how to read the report's criteria and judge readiness.

An eval set stands in for the real workload. The model is run on its cases, and the scores it produces describe how the model behaves on those cases. That makes the score only as meaningful as the set's contents. A high score on a set that does not resemble real traffic says little about production behavior. A low score on a set that over-represents hard, rare, or mislabeled cases can say even less.

Two things in the eval set shape the number you see. The first is composition: how many cases come from each case class. The second is labels: the correct answer recorded for each case. If composition under-represents a class, the score says little about that class. If labels are wrong for a class, the model can be graded incorrectly on exactly the cases where it is trying to be right.

The source gives a concrete picture of how this goes wrong. The eval set in that project was built from early data, and that early data under-represented two of the four case classes. Those under-represented classes were the ones where the model later struggled. The team's reading was that the eval set and the model's performance were tangled together, and the eval set was not a neutral ruler.

When performance is uneven across case classes, there are two broad diagnoses, and they lead to different actions. A model problem suggests changing the model. A labeling problem suggests fixing the eval data first. Because the actions differ, the diagnosis has to come before the fix. The flow below shows the order in which the checks are worth running.

The first check is the eval set itself: does its mix of cases and its labels represent the work the model is supposed to do? Only when the set passes that check does it make sense to ask whether the model is at fault. In the source case, the failing classes shared language patterns that the eval set had underweighted. The team re-labeled forty cases with the customer's lead reviewer, and the model's pass rate on those re-labeled cases reached seventy-eight percent. That result is the evidence the team used to argue the problem lay in the labeling rather than in the model.

Eval set calibration means making the eval set represent the distribution of case classes accurately. A stratified eval set is built against the case-class distribution from the start, rather than from whatever early data happens to be available. The source admits that the team in its project should have done exactly this: stratified the eval set against the customer's case-class distribution from the beginning. Their proposed fix is to run validation against a corrected, stratified eval set rather than the original one.

The before and after panels show the mechanism. In the original mix, the common class fills most of the set and so most of the headline number. A calibrated set gives each class its real share of the workload, and the aggregate is then recomputed from a mix that reflects production. The point of calibration is not to make the number higher or lower; it is to make the number answer the question you actually care about.

An evaluation report often mixes two kinds of measurement. Some criteria are reported as a count of cases that cleared the criterion, out of the total number of cases. Other criteria are reported as an average percentage across the cases. The source report uses both forms in the same run, so reading the report correctly means first noticing which form each criterion uses.

A missed case and a hard fail are different outcomes. In the source run, six cases missed a clause under C1. Those six misses are not all equally serious. Two of the missed cases involved material clauses, and those two were classed as hard fails. The other four are recorded as misses without the hard-fail label. The distinction matters because hard fails must be fixed before production rollout.

The question an evaluation has to answer is not whether the report contains good numbers, but whether the model as a whole is ready to be used. The aggregate pass rate is compared against the validation threshold, which is a whole-model check. Individual criteria cannot replace it. Each criterion can look acceptable while the aggregate still falls short. The reverse is also worth noticing: the aggregate is a single number, so the criteria beneath it are where you find out why it is low.