Tailspin Beverages Inline Quality Inspection

Object detection is the right starting point, for three reasons tied to the scenario:

1. Multiple defect types can co-occur on one bottle. Classification assigns one label per image, forcing a choice; detection returns zero or more labelled boxes per image.
2. Location and geometry are the defect. 'Misaligned by more than 3 mm' is a spatial measurement. A detection box gives you coordinates and hence an offset you can compare against a threshold; a whole-image class label just says 'bad'.
3. The object is 4% of the frame. Classification networks downsample the image aggressively, and a small region that carries the entire signal is easily washed out by the 96% of background. Detection architectures are trained specifically to localise small regions and are far more sample-efficient for this shape of problem.

One caveat worth stating: if a bottle can only ever exhibit a single defect type and the label set is mutually exclusive, multilabel classification becomes viable and cheaper. The team should verify that assumption before committing - label the 250 images first and count co-occurrences.

The lot code is a different problem: it is text, so use the Read OCR capability rather than a custom detector.

Data. 250 images per line per class is thin for three defect types, and a custom model will overfit. Practical responses in order of value: (a) capture more - the line runs at 60 units/minute so negatives are free and only positives need inspection effort; (b) deliberately collect hard negatives, e.g. correctly aligned labels at the tolerance boundary, because the boundary is where the model will fail; (c) augment with rotation, brightness and small translations to mimic lighting drift. Budget the labelling labour, and hold back a per-line validation set - do not evaluate line 1's model on line 1's training images.

Latency and network. A cloud round-trip with an unreliable link cannot meet 200 ms. Deploy the vision model as a container at the edge (custom model exported as an ONNX or Docker container, or the OCR/vision containers) on hardware next to the line. That also means designing for the offline case: queue frames locally, and define what the line does when the model is unavailable - the safe default is to divert, and the plant should say so explicitly rather than discover it.

One threshold for the whole model is wrong. Tune each defect class separately, because the costs are not comparable:

• Missing cap is a safety and leakage issue and a recall problem, not a precision problem. Set the threshold low so almost nothing escapes, and accept diverting a noticeable share of good bottles for re-inspection. Compute the actual divert rate so production knows the throughput cost.
• Misaligned label is rework, cheap to fix and cheap to miss on a sample. Set a higher threshold so you do not flood the line with false stops, and rely on the geometric offset measurement rather than a bare class probability.

Measure per class. Report precision and recall per defect type, not one blended accuracy. A model that is excellent at caps and useless at labels might still show 90% overall if caps dominate the sample.

Sanity check on the operating point. Reconcile the threshold policy with the inspectors' current sampling results: if the model's reported defect base rate differs wildly from what inspectors see by eye, either the labels or the data collection is wrong, and no threshold choice will fix that.