The Gap Between a Computer Vision PoC and Production
Computer vision quality inspection demos are impressive under controlled conditions: curated image datasets, consistent lighting, and pre-labelled defects. Real manufacturing environments are chaotic — variable lighting, surface reflections, vibration from machinery, and defect types that evolve as production processes drift. Bridging this gap requires a structured approach from day one.
Stage 1: Data Collection Strategy
The most common failure we see is collecting images under ideal conditions and then wondering why the model fails on the floor. From the start, collect images across the full distribution of real conditions:
- Multiple shifts (lighting changes dramatically at different times of day)
- Different machines and production lines (each has subtly different characteristics)
- Both defective and non-defective examples in a class-balanced ratio
- Edge cases and ambiguous samples — these are often where models fail most catastrophically
For a typical surface inspection system, we target a minimum of 1,000 images per defect class before training, and 10,000+ for a production-ready model.
Stage 2: Model Architecture Selection
The right architecture depends on your latency requirements and defect type. For standard surface defect detection, YOLOv8 or RT-DETR provide an excellent accuracy/latency tradeoff. For anomaly detection (detecting "anything unusual" without labelling every defect type), PatchCore or EfficientAD on a pre-trained backbone is our standard approach. For pixel-level segmentation of defect regions, a lightweight U-Net variant is usually sufficient.
Edge deployment typically requires quantisation (INT8 or FP16) to meet the sub-50ms inference requirements of high-speed production lines.
Stage 3: Edge vs. Cloud Deployment
For quality inspection, edge deployment is almost always the right choice. Production lines can't tolerate the 100–300ms round-trip latency of cloud inference, and network reliability in manufacturing environments is often poor. We deploy on NVIDIA Jetson Orin or Intel Core AI PC hardware depending on power and footprint requirements, with a lightweight FastAPI inference server and a local SQLite database for anomaly logging.
Stage 4: The Continuous Improvement Loop
A deployed vision model is not a finished product — it's the beginning of a continuous improvement process. After deployment, we implement: active learning to flag low-confidence predictions for human review and labelling, weekly model retraining on newly labelled examples, automated performance monitoring with alerts when accuracy drops below threshold, and a feedback mechanism for production operators to flag missed defects directly from the inspection dashboard.
Common Pitfalls to Avoid
- Training only on "clean" images — models must see the difficult examples
- Evaluating on the same distribution you trained on — always hold out a production-representative test set
- Ignoring class imbalance — defects are rare; use oversampling, weighted loss, or synthetic data augmentation
- Deploying without operator trust — involve the production team from day one; their domain expertise catches model errors before they cause problems
Conclusion
Computer vision quality inspection delivers transformative ROI when implemented with production-readiness in mind from the start. The key is treating it as an ongoing system — not a one-time model deployment. Invest in data infrastructure, continuous labelling, and edge deployment, and you'll have a system that gets better every week rather than degrading over time.