Generic AI vision models are trained on public photos of everyday objects, so they struggle with your product, your faults and your plant’s lighting, and they raise too many false alarms. A custom-trained model learns from images captured on your own line, so its confidence means something and its rejects match what your quality team would reject. Generic models still make a sensible starting point for common objects and quick trials.
On this page
An off-the-shelf AI vision system comes with a model trained on someone else's data. In industrial applications, the gap between that training data and real site conditions decides whether operators trust the system or switch it off in the first week.
What generic models are trained on
Most computer vision models start with large public datasets. ImageNet, COCO, Open Images and similar benchmarks contain millions of images that are excellent for teaching a model to recognise cats, cars, furniture and everyday objects photographed in good light.
None of those datasets contain your product. They have never seen how your packaging seal looks when it is correctly formed versus slightly deformed, how condensation sits on your bottles on a cold morning, how dust settles on a production line at 2am, or what your loader looks like mid-cycle at a quarry face.
Generic models are trained for a different problem.
Limitations in industrial settings
1. High false alarm rates
In a consumer app, a model that is wrong one time in twenty is a minor annoyance. In an industrial system, the same error rate (an illustrative 5%) can mean a supervisor getting several alerts an hour for things that are not problems, or good product being rejected all shift. Within a week, the team stops looking at alerts. Within a month, the system is switched off.
A custom-trained model learns what a real fault looks like in your environment, not what a public dataset decided was suspicious. On a production line, that means catching defects without creating false rejects.
2. Environmental conditions
Food production has steam, wet surfaces and strong reflections. FMCG packaging lines run at speeds and under lighting that look nothing like the clean product photos in training datasets. Quarries have dust that obscures camera feeds, and night shifts on construction sites change the look of everything in the frame.
Generic models were not trained on those conditions. Their confidence drops, thresholds become unreliable, and performance degrades in exactly the situations where accurate checking matters most.
3. Missing industry-specific classes
The specific seal defect on your container format, the difference between a correctly labelled product and a mislabelled one in your label design, a cap that is on but not fully tightened: none of these exist in generic training data. The same goes for site work, where a haul truck at a quarry is a different problem from a car on a road, and the posture that means a worker has entered an exclusion zone is specific to your site.
Light fine-tuning does not close a gap that large. The model has to be trained on the classes and conditions that matter to the operation.
4. Confidence thresholds
A model's confidence threshold is calibrated on its validation dataset. Put that model in a completely different visual environment and its confidence scores stop meaning what they did. As an illustration, a detection the model rates at 70% in your plant might have rated 95% in the conditions it was tested on, or the other way round.
Custom training on representative samples from your own environment lets you set thresholds against real operating conditions, so the model's confidence scores are meaningful. What counts as a reject is then agreed with your quality team, not guessed.
What custom training involves
For some applications, collecting and labelling the data is straightforward. For others, it takes careful thought about edge cases, class definitions and representative conditions. Custom-trained AI vision models.
Data collection
Training data usually comes from the cameras that will do the checking. On a production line, that means images captured by the inspection camera, under its own lighting, triggered as each item passes, so the model learns from exactly what it will see in service. For site monitoring, it can be recordings from existing camera feeds or a structured capture session covering different operators, lighting, shifts and scenarios.
How much data you need depends on the task. Tasks with strong visual contrast between classes can work well with a few hundred labelled examples per class. Harder tasks, such as subtle defect detection, multi-state equipment classification or partly hidden objects, need larger and more carefully chosen datasets.
Annotation and class definition
This is where domain knowledge matters most. The person labelling images needs to understand what a valid detection means operationally, not only visually. A correctly formed seal has specific characteristics that your quality team has defined. A "partially loaded" truck means something specific to a quarry operator. Those definitions have to be captured accurately in the labelling.
Inconsistent class definitions are one of the most common causes of poor performance in custom training. If labellers treat edge cases differently, the model learns inconsistent behaviour.
Architecture choice and training
Many industrial computer vision applications use variants of YOLO (You Only Look Once) for real-time detection, or EfficientNet, ResNet and similar backbones for classification. The choice depends on speed requirements, hardware limits and the complexity of the task.
For edge deployment, where the model runs within your facility without depending on the cloud, the architecture is constrained by the computing power available. A single modern detection model runs comfortably on a capable on-site PC. A large ensemble of models may need different hardware or a hybrid edge and cloud approach.
Validation and iteration
Testing only on images from the same camera, under the same conditions as the training data, makes a model look good on paper and underperform in service. Validation data should include hard cases, different lighting, partial occlusion and the edge cases that will appear in real operation.
Iteration is normal. The first version of a custom model usually reveals gaps in the training data that only show up once it starts making real predictions. That is why every model is validated on your own production footage, and commissioned on the line with your team, before go-live. Those edge cases become the next round of labelling and retraining, and each new model is tested before it goes live, with the option to go back to the previous one.
When a generic model is enough
Custom training is not always necessary. For some applications, a well-generalised model with suitable fine-tuning is enough, particularly when:
- The visual domain is reasonably close to public training data (standard PPE like hard hats and high-vis vests in decent lighting)
- The application can tolerate a moderate false alarm rate (perimeter security on a large site)
- The task involves common object classes that public datasets cover well
- A quick proof of concept is needed before committing to a full custom training program
The practical path is often to start from a strong pretrained model and measure it against your own data. If performance is acceptable, use it. If it is not, the gap shows you exactly what a custom training run needs to focus on.
Model ownership
A model trained on your data for your operation can be owned by you. That has several practical consequences:
- No vendor lock-in. You are not paying per-image fees to a cloud provider or depending on one vendor's service continuing to exist.
- On-site operation is possible. The model can run on hardware you control, without sending production footage to an outside service.
- The model improves over time. Edge cases from the line can be captured, labelled and folded into retraining, so the model gets sharper the longer it runs.
- Your data stays private. Where footage has security or commercial sensitivity, keeping the checking on your premises is a meaningful advantage.
On a production line, ownership goes hand in hand with integration. The model's results go to the line's own controls, which reject, divert, stop or flag items, and every decision is saved with its photo. How plant integration works.
Australian industrial context
Australian operations have characteristics that make the case for custom training particularly strong. Regional plants and remote sites with patchy connectivity make on-site processing a requirement, not an option. Harsh conditions such as Queensland summer heat and humidity, dust and coastal air affecting camera optics degrade generic model performance in predictable ways.
The products and equipment on Australian lines and sites also differ from what dominates public datasets, which lean heavily towards North American and European contexts. A regional food plant running local packaging formats, or a quarry running a mix of loaders and older CCTV, is not well represented in any public dataset, which is the argument for training on your own data.
Industrial AI develops these product-specific models in the Industrial AI Vision Lab (VLab), its model-training environment, and validates each one on the customer’s own production footage before release. To see how a model trained on your product fits into a full inspection system, read how AI vision inspection works, or see the checks most asked for on packaging lines and in general manufacturing.