Unsupervised inspection
Anomaly detection
Train on good parts. Flag whatever does not belong.
For the inspection that never got built because nobody could produce the defect images. Twenty good parts is a coffee break, and the data already exists on your line right now.
What is anomaly detection?
Inspection that learns the normal appearance of a good part and flags anything that deviates from it. Because it never needs a defect example, it catches the failure mode nobody anticipated, which a model trained on a fixed list of defects cannot do.
Where it fits
Six situations where it is the right call
No defect images exist
The failure happens monthly, the parts were scrapped without photographs, and nobody can describe the next one. The most common reason an inspection never gets built, and the case this is designed for.
The defect list is open ended
Contamination, foreign objects and cosmetic damage do not come from a finite catalogue. A model trained on the eight defects you know about misses the ninth by construction.
Textured or patterned surfaces
Where no two good parts look the same, describing defects by appearance breaks down. Describing the boundary of normal does not.
Low volume, high mix
A part number running a few hundred times a year will never accumulate a labelled defect set. Twenty good parts you can get on the first run.
A safety net over known defects
Running alongside a supervised model that handles the named failures, catching whatever nobody predicted. Both models inspect the same capture.
Early production and NPI
Before the failure modes are understood well enough to name them, which is exactly when the process is least stable and inspection is most valuable.
What it returns
Four outputs, and the one that makes it usable
An anomaly model does not return a class and a confidence. Understanding the shape of what it does return is what stops the sensitivity setting becoming an argument.
Anomaly map
A heatmap showing where the part deviated. This is what an operator sees, and it is why the tool is defensible on the floor: the camera points at the spot rather than only announcing a fail.
Anomaly score
One number for how unusual the part is overall. Most useful as a trend, because a slow climb across a shift is a process drifting rather than a bad part.
Blob statistics
The deviating regions grouped and measured, with area and position. This is what makes a usable rule: not any deviation, but a deviation larger than an agreed area.
Runtime sensitivity
Tuned after training rather than baked into it, so the trip point can be adjusted against real production without collecting anything new or retraining.
The honest limit
Anomaly detection has one characteristic weakness, and it is better named than discovered. The model defines normal from the good parts it was given. If that set does not span the full range of acceptable variation, everything outside the range reads as an anomaly.
In practice a station commissioned on one material lot will flag the next when the finish shifts. That is not a defect in the model, it is an accurate report that the part looks different, which is precisely what was asked of it. Two things prevent it becoming a problem: include real variation in the good set from the start, and keep a straightforward path for adding genuinely good production images back into training as the process legitimately moves. Lighting stability matters more here than for a supervised model, because an illumination change looks exactly like an abnormal part. Our guide to machine vision lighting covers that half.
Manufacturers running Overview AI in production
Manufacturers running Overview AI in production
FAQ
Frequently asked questions
Can I inspect without any defect images?
Yes, and this is the main reason anomaly detection exists. The model trains only on good parts, builds a representation of what normal looks like, and flags regions that depart from it. That solves the most common blocker on inspection projects, which is that the failure happens rarely and nobody photographed it before the parts were scrapped. The trade is that the model tells you a region is abnormal without naming which defect it is.
How many good parts does it need?
It depends which model type suits the surface. A high sensitivity pixel-wise model needs at least twenty good images. Models aimed at textured surfaces, or at simple presence and absence checks, need only a few. The count matters less than the coverage: the good set should span the variation the line genuinely produces, including different material lots and shifts, because the model defines normal from what it is given and will flag legitimate variation that was left out.
When should I use a trained defect model instead?
When the disposition depends on which defect it is, because one goes to rework and another to scrap. When you need the defect name to feed a Pareto chart back to the process. Or when you already have a good labelled set, in which case a supervised model will usually be more accurate and easier to defend in a capability study. These are not exclusive: running a supervised model for the known defects alongside an unsupervised one as a safety net for the unexpected is a common and sensible pattern.
Does it work on textured or patterned surfaces?
Textured surfaces are one of its strongest applications, and there is a model type specifically for them. On woven textile, a machined finish, a casting or a moulded grain, no two good parts look identical, which makes describing defects by appearance close to impossible. Describing the boundary of normal appearance is far more tractable, so the unsupervised approach often outperforms a trained defect model here.
How do I stop it rejecting good parts?
Use the minimum blob area filter rather than the sensitivity slider alone. Every real surface deviates slightly everywhere, so a rule that fails on any deviation will reject continuously. A rule that fails only when a deviating region exceeds a defined area behaves predictably. Setting that area means agreeing with the quality team what size of mark is genuinely a reject, which is a conversation worth having regardless.
What happens when the process legitimately changes?
The model reports the new parts as abnormal, which is accurate rather than a fault: they do look different from what it was trained on. A new material lot with a slightly different finish is the usual trigger. The fix is a retraining path, feeding genuinely good but flagged production images back into the good set. Being able to find those images in production history and add them without a data science exercise is what separates a station that survives a year from one switched off in month three.
Related
Anomaly Detection From Good Samples Only
The three model types, what each returns, and how to keep it from rejecting everything.
Read more →Surface Inspection
Scratches, overspray and contaminants where the defect list is known.
Read more →Escape vs Overkill
How to set the sensitivity by cost rather than by preference.
Read more →No defect images? Start anyway
Describe the part and what a good one looks like. You get an honest answer on whether this is the right approach, before anyone talks to you about hardware.