Video Analytics, Manufacturing, AI Live Insight

Defect Detection: What a Fine-Tuned Model Needs From You

The most useful thing a quality leader can know before an AI defect-detection project is that its success is decided months before any model runs, in a conversation that sounds bureaucratic and is actually the entire ballgame: what examples can you provide, and who will label them. Vendors do not lead with this conversation, for understandable commercial reasons, and buyers do not press for it, because the demo made detection look like a property of the software. It is not. A fine-tuned defect model is a property of the data it learned from, which means it is substantially a property of your plant's discipline in collecting and labeling that data, and this article is the conversation in full, so a project can be scoped on its real determinants. It accompanies our broader article on visual quality inspection with fine-tuned models and extends the pillar guide to AI-powered video analytics for manufacturing.

Your defects are unique to your plant

A scratch, to start with the simplest example, is not a universal object. On anodized housing it is a bright line against dark; on brushed steel it hides in the grain until the light rakes; on a molded part the same physical insult reads as a stress mark that may or may not matter. Whether any of them constitutes a defect is not a visual fact at all but a specification fact, this depth on this surface for this customer fails, that one ships, and the boundary lives in your quality standard, your inspectors' trained judgment, and sometimes in the accumulated case law of customer complaints. The same is true of contamination, whose appearance depends on what contaminates what, of cracks, whose visibility depends on substrate and finish, and of missing-part defects, which are defined entirely by what your assembly was supposed to contain, ground our assembly verification article covers on its own.

This specificity is why the generic tools disappoint and why fine-tuning works: the model learns your boundary, from your examples, under your cameras and lighting. But it learns only that. The model that masters scratches on the black housing knows nothing of the white variant introduced next quarter, and treating that as a defect of the technology rather than its nature leads to the disillusionment cycle this field is unfortunately known for. Scoped correctly, the specificity is an asset, and it comes with a governance property worth naming for any plant whose defect patterns are competitively sensitive: models trained on your data are isolated to your deployment, your taxonomy teaching no one else's line.

The five dataset questions

What follows is the sequence a well-run engagement walks through, and a buyer can use it as a script for vendor qualification, because a vendor unwilling to walk it is planning to discover these facts during your pilot at your expense.

The sequence opens with the taxonomy, which quietly decides everything downstream. Which defect types, enumerated and defined, with the acceptance boundary stated per type. This is quality-team work, not vendor work, and it surfaces the disagreements that would otherwise surface as label noise: two senior inspectors who draw the scratch boundary differently are a fact to resolve before labeling begins, because a model trained on their combined labels learns their disagreement as blur. Plants are routinely surprised by how much internal alignment this step forces, and the alignment is valuable independent of any AI.

Second in the sequence comes the honest inventory of examples. Real defect samples, physical or photographic, per type, and the honest census of how many exist. Here the project meets its structural irony: the defects that matter most are rarest, and the rarest are hardest to train for. The workable responses are practical rather than magical, collecting across a longer runway before go-live, photographing the reject bin's history where one exists, staging physical defect samples under the production cameras, and prioritizing the taxonomy toward types with defensible sample counts while the rare types accumulate. What does not work is pretending: a type with five examples is a watchlist entry for human inspectors, not a training candidate, and an engagement that says so early is one being run honestly.

Third comes the negative space of the training set. The model needs compliant examples as much as defective ones, across the real range of acceptable variation, shifts, lighting, material lots, the stock-keeping unit's (SKU) cosmetic diversity, because the alternative is a model that flags every departure from the narrow normal it saw, which is the false-positive machine that kills adoption. This is usually the easiest data to collect, the line produces it all day, and the most commonly under-collected.

Fourth comes the labeling protocol that turns examples into training data. Who labels, against what written standard, with what arbitration when labelers disagree, and label quality is worth paying for in inspector time rather than delegating to whoever is free, because every ambiguous label is noise the model must learn around. The protocol document, definitions, boundary examples, disagreement procedure, becomes a quality asset in its own right, and more than one plant has found it improved their human inspection consistency before any model shipped.

Fifth, the validation split, agreed before training: a held-out set of labeled examples the model never sees, on which the confusion matrix is computed, what it catches, what it misses, what it falsely flags, per type. This is the only accuracy number that means anything, measured on your parts under your cameras, and it is the number thresholds get set from, per the silent-validation pattern the visual inspection article describes.

Inside the taxonomy workshop

The taxonomy step earns a closer look, because plants consistently underestimate what it surfaces. The working format is a half-day with the senior inspectors, the quality engineer, and the reject bin's greatest hits physically on the table. Each defect type gets named, defined in a sentence, and bounded with examples: the worst acceptable and the mildest rejectable, photographed under the production cameras, not the lab bench. The friction arrives on schedule at the boundaries. One inspector's cosmetic scratch is another's reject; the definition that has lived comfortably in two heads for a decade turns out to be two definitions; and the customer-specific overlays, what ships to buyer A but not buyer B, emerge from tribal memory into writing, some for the first time. Every one of these resolutions improves the plant's human inspection consistency immediately, before any model exists, which is why the workshop is worth running even where the AI project stalls. Its outputs are the label standard, the boundary example set, and a list of unresolved disputes for the quality manager to settle, and the discipline of settling them is the project's first real test: an organization that cannot converge on what a defect is cannot teach a model what a defect is, and it is far cheaper to learn that in a conference room than in a confusion matrix.

Using staged and augmented samples

When real examples of a rare defect are scarce, two supplements are legitimate and one temptation is not. Staging is legitimate: physically creating representative defects on sacrificial parts and imaging them under the production cameras, in production lighting, which produces authentic pixels at the cost of some engineering of realism, and works best for mechanical damage types like scratches, dents, and missing components. Augmentation is legitimate within its lane: systematic variation of real samples, orientation, exposure, position, stretches a thin set further, and is standard practice rather than a trick. The temptation to refuse is borrowing: samples from another plant, another product, or a public dataset, whose defects resemble yours the way a stock photo resembles your factory. Borrowed data teaches the model a boundary that is not yours, inflates validation scores against equally borrowed test data, and delivers the disappointment at production time, where it is most expensive. The rule that keeps supplements honest is simple: everything in the training set was imaged by your cameras on your parts, staged or real, and the held-out validation set contains only the real thing.

Maintaining the model over time

The dataset conversation does not end at go-live, because the plant the model learned is a moving target. New SKUs arrive, suppliers change materials, seasons change ambient light on the floor, and each shift can move the boundary between the normal the model knows and the anomalies it flags. Mature deployments therefore treat labeled-sample refresh as a standing activity with an owner, a cadence, and a budget line, feeding two loops. The retraining loop folds new variants and newly collected rare defects into the taxonomy on a schedule. The correction loop feeds the model's operational mistakes back as training signal: the false positives inspectors clear and the escapes that surface downstream are exactly the examples the next training round needs most, and a workflow that captures them at the moment of adjudication costs little and compounds.

Two structural aids round out the honest picture. Detection corrections, the adjusted boxes and relabeled events reviewers produce in normal operation, are themselves a labeling stream when the tooling preserves them. And for anomalies outside every trained detection type, the open-question layer described across this series, a cached clip put to a multimodal model, catches some of what the taxonomy has not yet learned to name, feeding candidates into the very refresh loop that will eventually formalize them, with the usual caveats about cadence and unquantifiable accuracy stated plainly in our behavior-beyond-the-preset-list article.

Costs and returns

A quality leader budgeting this honestly should count four line items: inspector hours for taxonomy, labeling, and adjudication, concentrated up front and recurring at refresh; camera and lighting adjustments where the feasibility arithmetic demands them; Graphics Processing Unit (GPU) capacity sized to the inspection cadence the stations actually need; and the vendor engagement itself. Against it sits what per-unit inspection displaces, sampling risk on every uninspected unit, escape costs that scale with customer consequence, and the review-queue labor that generic tools would have added, plus the audit value of an evidence-backed inspection record, which the visual inspection article covers. Deployments that clear this arithmetic tend to share a profile: meaningful escape costs, defect types in the macro-to-middle visual tier, and a quality organization willing to own the data discipline. Deployments that lack the third element fail regardless of the first two, which is the theme of this entire article, restated once more as a selection criterion.

One planning heuristic compresses everything above into a number a project sponsor can use: count the labeled examples, not the promised features. An engagement entering training with a written taxonomy, a few hundred well-labeled examples of the common defect types, staged coverage of the mechanical rare ones, and thousands of compliant frames across real production variation has the raw material success is made from. An engagement entering with a feature list and a promise to gather data during the pilot is scheduled to discover this article's contents at production prices. The difference between the two is not vendor capability but plant preparation, which is simultaneously sobering and encouraging, because preparation is the input the quality leader controls completely.

How VIDIZMO runs the engagement

VIDIZMO's fine-tuned defect detection is delivered per engagement on the plant's own labeled footage, with the taxonomy, sample inventory, labeling protocol, and held-out validation walked in the order above, and the resulting detection types deployed into AI Live Insight like any other, per-camera thresholds, severity, events with clips preserved in the Nexus portal the deployment works alongside. Models are customer-isolated, processing runs on the plant's own hardware on site, and detection corrections captured during review feed the refresh loop the engagement establishes. Inspection events flow to the Quality Management System (QMS) through the REST API and webhooks for the closed-loop responses, holds, rework routing, that our plant-systems integration article details.

The qualifying question for your own organization is the one this article opened with, and it deserves a real answer before any vendor call: for the three defects that cost you most, how many labeled examples could you produce next month, and who would you trust to label them? The project's timeline, budget, and probability of success are all hiding inside that answer.

FAQ

Frequently Asked Questions

How many labeled examples does defect detection training need?

Enough per defect type to represent its real variation, and the honest census comes before any commitment: a few hundred well-labeled examples of common types is workable raw material, while a type with five examples is a human watchlist entry rather than a training class. Compliant examples matter as much as defective ones, across real production variation, and they are the most commonly under-collected.

Who should label defect training data?

Senior inspectors working against a written standard with an arbitration path for disagreements, because every ambiguous label is noise the model must learn around. The labeling protocol itself becomes a quality asset, and plants regularly find it improves human inspection consistency before any model ships.

Can staged or synthetic defect samples be used?

Staging is legitimate: physically creating defects on sacrificial parts and imaging them under production cameras and lighting. Augmentation of real samples is standard practice. What fails is borrowing samples from other plants, products or public datasets, which teaches the model a boundary that is not yours and delivers the disappointment at production time. Validation sets contain only the real thing.

Is our defect data shared with other customers?

No. Models trained on a plant's data are isolated to that customer's deployment, which matters when the defect taxonomy itself is competitively sensitive, and processing runs on the plant's own hardware on site for the same reasons of control and residency.

What ongoing work does a deployed inspection model need?

Labeled-sample refresh as a standing activity with an owner and a cadence, feeding two loops: retraining that folds in new variants and newly collected rare defects, and correction that returns the model's operational mistakes, cleared false positives and downstream escapes, as training signal. Products change and defects drift, so the refresh is permanent rather than a project phase.

TopicsVideo AnalyticsManufacturingAI Live Insight

You may also like

Fire and Smoke Detection as a Second Set of Eyes in Schools

Let the first sentence of this article do the compliance work: nothing described here replaces, modifies, or competes ...

Weapon Detection in Schools: Detection, Verification, Response

No school safety technology carries more emotional weight than weapon detection, and no school safety technology is ...

School Safety Grants: What the Money Can Buy

School safety improvements have a funding problem that is really a sequencing problem: the need is continuous, the ...

See all posts

See it on your own content

Tell us what you are trying to solve and we will show you how it works on your infrastructure.