Computer Vision Implementation

Before training a model, we agree with your technologists on what counts as a defect: a scratch on the housing, a shift in packaging color, or a seam offset of two millimeters. The rule must be readable in a photo, not live only in an operator's head. A mismatch in describing a defect costs more than all the training stages.

A model errs in two directions: it misses a defect or raises a false alarm. Tighten the trigger threshold, and a stream of faulty housings keeps moving down the line. Loosen it, and the line starts stopping for a harmless reflection. Both mistakes cost money, so we convert both into rubles before the pilot starts.

Before launch we price each kind of error: a client claim for a missed defect, or a rework of a batch caused by extra stops. On a food conveyor the claim money decides, while at checkout areas it matters more not to stop the flow. We set the trigger threshold against whichever hits the budget harder.

We report with metrics, not pictures full of green checkmarks: recall shows what share of defects the model found out of all of them, and precision says how many alarms were real. Target values go into the brief before work starts. A missing recall rate shows up in numbers at the very first validation, and we track it over iterations.

Frames where the model hesitates are neither scrapped nor silently passed: an operator reviews them on a separate screen. In practice this clears most borderline cases at the cost of a few seconds of attention per hour. No automation where the outcome affects a customer claim runs without a human check.

We never promise that one hundred percent of defects will be caught, that is fairy-tale talk from vendor decks. On a line with forty thousand parts per shift, even 99.9% recall leaves a tail of misses. We name beforehand where that tail stays across the whole flow and how often an operator will pick it up by hand after the shift.

The real effort in a project is not the models but the data: a labeled set takes weeks to collect and gets corrected after the first runs. We budget for that from week one instead of remembering it at the pilot. A model without solid labeled data is a nice hypothesis, not a working tool.

We run labeling together with your technologists, since they know defects better than any outside contractor. An employee who labels a couple of hours a day gives a clear gain in recall within a month, and their notes on unusual cases end up in the test set. So the knowledge base grows inside the plant.

Before buying expensive cameras, we stabilize the light: lamps and diffusers on the line are often cheaper than a pair of GPUs and remove half of recognition errors. Light, not the model, makes most frames readable. A shadow from an operator cast on the conveyor causes more false alarms than the weakest model.

You can run the model right on a camera or on a server with a GPU. Edge devices are cheap on a flow and do not depend on the network, but they fall short on complex scenes. A server setup is easier to update and scale, though it brings a steady cost line for rent, electricity, cooling, and maintenance.

We put retraining in the budget from the very start: once a month the model is retrained on new examples that operators added over that period. The reserve for this is tiny, yet without it accuracy quietly slips down. Light, assortment, and packaging change faster than you would like.

Vision needs constant care: someone has to add examples, answer operators' questions, and watch the metrics. If the team has no half-time engineer for support, it is more honest to discuss that before we start than to catch a drop in accuracy later and blame the system. Missing support is what most often kills a project within six months.