Evaluating Model Output Against a Labeled Evaluation Set

Imagine a team reviewing the first results of an automated inspection reporting model. The model turns the audio recording of an inspector into a structured record, and the first numbers look encouraging: nearly every required field is filled in. It is tempting to read that result as a sign the model is ready. This article examines why that conclusion is premature, and how a team in an aerospace quality setting found a remedy that made the record trustworthy enough to pass an audit.

The belief at the center of this article is intuitive: if every field in a report is present, the report is good. Completeness feels like a proxy for quality. Pause and reason about it before reading on. The rest of the article traces what the team measured, what went wrong, and what they changed.

The team evaluated the model against a rubric with three criteria. The evaluation set was forty real inspections, each labeled by the customer's quality manager. The labels give the team a reference point: for each inspection, they know what the correct record should contain, so they can check the model's output against it.

The three criteria ask different questions. Structural completeness asks whether the required fields are present at all. Factual accuracy asks whether the values in those fields match what the inspection actually contains. Audit-readiness asks whether the finished record is trustworthy enough to pass an audit. Because these questions are different, a model can do well on one criterion and poorly on another.

The first run cleared the completeness criterion at ninety-six percent, which means the model was usually filling in the required fields. It missed the accuracy criterion at eighty-one percent. Read together, the two numbers show the gap: the record looked finished far more often than it was correct.

The quality manager traced the gap to a specific behavior. The model was inferring fields the inspector had not said aloud. The quality manager flagged this as a serious risk, because an inferred value can look like a legitimate entry while having no basis in the inspection itself.

The lesson is that a field being present says nothing about where its value came from. A reviewer reading the finished report cannot easily tell a value that was spoken from one that was guessed. This is exactly why the failure mattered for audit purposes: an audit asks whether the record can be trusted, and a record that mixes spoken and guessed values cannot be verified from its contents alone.

The remedy was explicit and simple to state. The model could only fill fields the inspector had spoken. Any field the inspector did not address had to remain missing, and it had to be flagged so that the inspector could complete it manually. The model was no longer allowed to fill gaps with its own inference.

The effect on the scores was a trade-off, and the source reports both sides of it. The constraint reduced the completeness score, since fields the model would previously have guessed now stayed empty. At the same time, it raised the audit-readiness score to one hundred percent. The customer signed the validation milestone after this result.