How to Interpret Training Results Without a Model Expert

Most Factories Don’t Have Model Experts

Factories that have adopted inspection models typically have equipment engineers and quality engineers. Both know the product inside out. They know which scratches are defects and which marks can be ignored, and they know which production lines tend to have more problems than others.

But when they open a training results screen, neither knows what the numbers on it actually mean. There is no model expert who knows how to set up training and interpret the results. The person who knows the product and the person who knows the model are not the same person at the same factory.

This is not a problem unique to a particular factory. When the Korea Federation of SMEs surveyed 502 companies participating in the Win-Win Smart Factory Program in September 2025 (Korea Federation of SMEs, Survey on SMEs’ Opinions on AI Adoption in Smart Factory Implementation, published October 17, 2025), 20.5% cited a lack of specialized personnel as a reason for hesitating to adopt AI. Among companies already operating AI, that figure rose to 43.8%, and it reached its highest level, 50.4%, at the stage of working with manufacturing data. The lack of people becomes more apparent after AI is put into use than at the point of adoption.

The same applies when an MLOps platform is introduced. Without someone who can interpret the results, factories cannot get to the point where they continuously build and use the models they need. And hiring someone specifically to interpret those results is not easy either.

AIVEX provides inspection models and MLOps platforms, and we have been the ones most often asked, “Is this model performing well?” So we decided to move the task of interpreting results itself into the platform.

Fortunately, the data used for training, intermediate results, and final results are already stored in predefined formats. If we separate out the step of interpreting those numbers and explaining them in human language, it aligns almost perfectly with what LLMs are good at today.

[Figure 1] Companies using AI perceive a greater shortage of specialized personnel (Korea Federation of SMEs, 2025)

Handing It to an LLM Created a New Set of Problems

As a first step, we built a feature that reads the result JSON generated after training is complete. It evaluates the model’s quality in three levels—green, yellow, and red—and provides the reasoning behind the assessment, along with recommendations on what to change in the next training run, all in human-readable language.

There is no need for document retrieval or conversational memory. The only input is the model result that we already have. It seemed like something we could solve simply by writing a good system prompt. That was true—until we actually fed it real training results.

The first problem was the amount of data. The values passed for analysis contain up to 16 decimal places, so a single value like 0.9994897842407227 can take up six or seven tokens. When hundreds of these values accumulate, they become a cost in themselves.

Once the number of classes exceeds fifty, a 50×50 confusion matrix makes the prompt exceed the context limit, and the LLM starts forgetting information in the middle or making things up. Giving the model more data can actually make it less capable of reading the data.

So the key question in the design was not what to include, but what we could leave out without changing the assessment.

The next problem was the output format. To display the explanation on screen, we need the result in a predefined JSON structure. The LLM usually follows the format, but occasionally breaks it. It might add a sentence like, “Here is the JSON you requested,” wrap the response in a Markdown code block, or add an extra bracket.

Even a single extra character can cause parsing to fail, leaving nothing on the screen. So instead of discarding failed responses, we built guardrails that could repair and parse them. But one problem remained that code alone could not solve.

The remaining issue was what the LLM explained and how it explained it. Parsing could succeed and the numbers could be correct, yet the explanation might still not make sense to someone on the factory floor. Code is fixed when it is wrong, but prompts often need to be revised even when they are technically correct.

The most common reason was terminology. The input passed to the LLM contains names created for use in the code, and because those are the terms the LLM sees, it carries them directly into its explanations. But the people on the factory floor have never seen those terms.

So we had to define, one by one, how each item should be referred to in language that makes sense to the people using it.

The assessment criteria presented a similar problem. A model that has used its validation data for training is a good example. If data that should be used only for evaluation is included in training, it is like taking an exam after seeing the questions in advance. The score may be high, but it does not necessarily represent actual performance.

So even when the performance metrics look excellent, we decided to classify such models as requiring caution before deployment. We were not fixing a defect; we were defining a quality policy. And when the policy changes, the wording of the explanation changes as well.

What made things even more difficult was that these terminology and assessment criteria were not something we could define once and leave alone. Different types of models—such as detection, segmentation, and classification—have different configuration parameters. When the training engine is upgraded, even the same parameter can have a different name or a different range of values.

As the number of models and versions grows, the prompts have to evolve with them.

[Figure 2] Only after passing through these three layers does a training result become an explanation people can actually understand

A System Prompt Is Not Code. It’s an Operational Asset.

A system prompt is not something you revise because it is wrong. You revise it because the situation changes.

When the terminology no longer matches what people use on the factory floor, when the policy for what to pay attention to changes, when a new type of model is introduced, or when the training engine is upgraded, the prompt needs to be updated.

It is not a file you write once and forget. It is an asset that continuously evolves as the number of models you manage grows.

When changes happen this often, no one will actually make them if every revision requires finding a developer and waiting for a deployment.

So we took the prompt out of the code and put it on a screen. Users can write it directly, distinguish between saved and deployed versions, and see at a glance which version is currently active and who deployed it last.

They can also choose what data to pass to the LLM from the same screen. Each item includes an explanation of what kind of data it contains. Simply listing the names is not enough for someone who is not a developer to know what to select.

As soon as we made the prompt editable, another problem followed. If you deploy a change just to see whether it works, that change immediately goes out to every user.

So we added a playground to the same screen. By specifying an actual model and dataset, users can run the prompt and check both the resulting JSON and how that JSON will appear on screen—all before deployment.

Input and output tokens are also displayed, making it possible to see on the spot how much the cost increases when a sentence is added.

That is what it took to make a single explanation work properly. But what the factory actually needed was more than one well-made explanation.

[Figure 3] Edit prompts on screen and check the results and cost before deployment

Analysis Alone Has No Meaning

The assessment produces one more thing: recommended settings that tell the user what to change and how to change it to improve model performance in the next training run.

But these settings have another purpose. They are not just something a person reads and refers to. The values are fed directly into the next training run as its configuration.

This is possible because what to change, what value to use, and why the change is being made are all produced in a predefined format.

But one iteration was not enough.

Even when training is run with the recommended settings, it is rare to reach the target in a single attempt. Checking the results and adjusting the settings again remained a manual task.

So we decided to hand over the repetition itself.

The system now runs the process continuously: execute training, evaluate the results, receive the next settings, and run training again.

Instead, we first had to define when to stop.

A single training run can occupy GPU resources for a long time, so without a defined stopping point, longer iterations simply mean greater waste.

Users can set only the metrics that matter for the current task—F1 score, false-positive rate, or false-negative rate—as targets. If multiple targets are specified, the process stops when all of them are met. The maximum number of attempts can also be set.

The first training run starts with the recommended settings generated by the explanation.

If the target is exceeded, the process stops there. If not, the settings and results from the current iteration are passed along with the previous iterations to generate the next settings.

Once the predefined number of attempts has been used, the process ends without reaching the target. If the newly generated settings are identical to those from any previous iteration, the process stops immediately. That means there is nothing new left to suggest.

The actual design problem, however, was somewhere else.

The existing explanation was designed around a single model. But in iterative training, what matters is whether the model has improved compared with the previous run.

Because the previous result was not included in the input, performance metrics alone were not enough to determine whether the result was meaningful. The problem was not the wording of the prompt. It was the structure of the input.

So we divided the data passed to the LLM for each iteration into two types.

The current iteration is included in full. Previous iterations are compressed into summaries that retain the key metrics and only what changed.

Even so, the input gets longer as iterations accumulate.

When we measured it in practice, including previous iterations increased the number of tokens by about 47%. Since comparison is essential to the process, this is an unavoidable cost, and we determined that it was manageable at the current scale.

[Figure 4] Set a target, and the system keeps training and evaluating until it gets there

Now, the Important Thing Is Not the Model. It’s the Data.

Now, the person in charge only needs to set the target before leaving work.

The next morning, the screen is ready with the assessment—green or yellow—along with why the model was assessed that way and what should be changed next.

Once training is complete, the assessment, reasoning, and next settings are presented together. The repeated process of training until the target is reached no longer requires human intervention.

The judgment that once required a model expert to read the results can now be handled by an AI system.

Of course, not everything becomes automatic.

If a class has only two validation images, no amount of stronger augmentation will reduce the false negatives for that class. The problem is not the parameters. It is the data.

When an iterative process ends without reaching its target, the system can tell you that it failed to reach the target. But it does not yet explain why it could not get there.

In other words, the bottleneck has moved.

The system now determines which settings to use for training. What has moved to the forefront instead is deciding which types of defects should be considered defective, collecting images for underrepresented classes, and labeling them.

How much well-labeled data you have has become a decisive factor in model performance.

[Figure 5] The iterations continue overnight. By morning, all that remains is to review the results.

Most factories do not have a model expert on staff. AIVEX’s AIVOps enables factories to build models and improve them based on the results, without the need for an expert. The remaining challenge is to secure good data—and the source of that data is already inside the factory.