Back to blog

YOLOv8 for Industrial Quality Control: Decisions That Actually Moved the Needle

A practical post-mortem on the architecture, data strategy, and deployment decisions that mattered in industrial inkjet quality control, instead of another generic YOLO tutorial.

10 min read
Computer VisionYOLOv8Industrial AIPyTorchProduction ML

This Was Not a Tutorial Project

Most YOLO posts stop at "train on a large dataset and report mAP." Industrial quality control does not work that way. The constraints are different: fewer images, harder defects, tighter latency budgets, and real-world consequences for false alarms and misses.

The First Important Decision

I did not use YOLOv8 mainly as a detector. I used it as a feature extractor. The print-quality problem involved feature types such as dots, distances, edges, and angles. Those are not always best represented as classic object-detection boxes.

Using the backbone features gave the downstream anomaly detector richer geometric information than relying on the final detection head alone.

Data Engineering Mattered More Than Hype

With a limited dataset, the biggest wins came from discipline:

  • careful fold construction
  • avoiding leakage between folds
  • realistic augmentation only
  • respecting feature-type imbalance

Heavy synthetic tricks were much less useful than simply being honest about the data regime.

Training Choices That Helped

config = {
    "lr": 1e-4,
    "batch_size": 16,
    "epochs": 150,
    "scheduler": "cosine",
}

The key was not the exact numbers by themselves. The key was matching them to a small industrial dataset and a production target. Freeze-then-unfreeze strategies, conservative optimization, and per-feature inspection mattered much more than generic defaults.

Evaluation That Meant Something

The system was evaluated with strict 5-fold cross-validation. Per-feature AUROC told a more honest story than a single overall score. Some features were highly reliable, while others were limited mostly by data scarcity rather than by architecture.

Deployment Reality

The final system had to run within edge constraints. Quantization helped latency, but reliability still came first. The practical lesson was simple: a slightly slower stable deployment is better than a faster unstable one.

What Actually Moved the Needle

  • using YOLO features instead of forcing a detector framing
  • building a disciplined evaluation loop
  • treating feature types as different sub-problems
  • optimizing for dependable inference, not just lab numbers

Frequently Asked Questions

Why use YOLO as a feature extractor and not as a detector?

Because the task was not natural object detection. The feature types behaved more like structured visual signatures than bounding-box objects, so the backbone features were more useful than the detector head.

What latency did the deployed system reach?

Around 35 ms per component in the final production-friendly configuration, which stayed within the edge constraint.

What mattered most?

Data discipline, fold design, and choosing a stable deployment path mattered more than chasing the fanciest architecture variant.