Yield Prediction in Production Lines

Yield losses are usually explained after the fact

Every production manager has a theory about bad batches. It was the new resin supplier. It was the humid week. It was the night shift. Sometimes the theory is right. Often it is half right, and the real cause is an interaction nobody could see by eye, such as a particular material lot running on a particular extruder at a particular temperature.

Yield prediction replaces those theories with a model that has looked at every batch. It does two jobs: it tells you which factors genuinely move yield, and it warns you during a run that this one is heading for trouble.

What goes into a yield model

The outcome row is where projects stall. Scrap is often recorded per shift rather than per batch, or with a generic reason code. If you cannot tie a quality result to the specific inputs that produced it, there is nothing to learn from. Traceability comes before modelling.

Two uses: explaining and predicting

1. Root cause analysis. Train a model on historical batches and use feature importance and partial dependence plots to show which inputs matter and in what range. This is often the most valuable output and it needs no live integration.
2. In-process prediction. Score a batch while it runs using data available so far, and alert when predicted yield drops below a threshold. This is where money is saved, but it needs live data and a clear action for operators.

Start with the first. It is cheaper, it tests whether the data supports a model at all, and it gives process engineers something to argue with, which is healthy. If the analysis shows yield is mostly explained by a single material property, the fix might be a tighter goods-in specification rather than any live model.

A worked example from food manufacturing

Consider a bakery producing 40 batches a day across three lines, with yield losses from underweight, misshapen or overbaked product. Flour protein content, dough temperature, proving time, oven zone temperatures and ambient humidity are all recorded somewhere, mostly in different systems.

Joining a year of that data by batch and training a gradient-boosted model typically shows a handful of drivers. Dough temperature at the end of mixing, combined with proving room humidity, may explain much of the misshapen product, for instance. The in-process version then predicts at the end of mixing whether the batch is likely to fall short, and suggests a proving time adjustment within a range the process engineer has approved.

The figures here are illustrative and every site differs, but that shape of result is common: a few interacting factors, one early intervention point, and an adjustment operators can make without stopping the line.

Getting operators to act on predictions

A prediction that arrives on a dashboard nobody on the floor watches changes nothing. A prediction that tells an operator what to do, within limits engineering has signed off, does.

• Show the prediction at the machine or on the line HMI, not only in an office report
• Pair every alert with a recommended action and the reason for it
• Keep recommended adjustments inside validated process windows
• Log what the operator did, so the effect of interventions can be measured
• Review false alarms weekly with the shift leads during the first months

In regulated industries such as pharmaceuticals or food with strict HACCP controls, any model that influences process settings needs change control and validation. Build that into the plan from the start rather than discovering it at go-live.

When yield prediction is the wrong project

If most of your scrap comes from a few obvious causes, such as changeovers or a known faulty machine, fix those first. A model is for losses that are spread across many small interacting factors.

• Batches are not traceable to materials and settings, and cannot be made so soon
• You produce too few batches to learn from, perhaps a few dozen a year per product
• Process settings never vary, so the model has nothing to compare
• The line is being replaced within a year

Low batch counts deserve a note. With fewer than a few hundred comparable batches, classical design of experiments run by a process engineer will often teach you more than machine learning.

How SpiderHunts would approach it

SpiderHunts would start with a data audit: can every batch be linked to its materials, settings and quality result? Where it cannot, we help close the gaps, usually by adding batch IDs to existing records. Then a root cause analysis on history, presented to production and quality leads.

Only if that analysis finds real, actionable drivers do we build the live model, served close to the line and connected to the MES or SCADA historian. Our machine learning team handles the modelling and the model deployment side, which for shop-floor systems needs particular care around reliability and what happens when the model is unavailable. The answer there is simple: the line runs as it always did.

Frequently asked questions