Could we prototype with an assistant and deploy something purpose-built?

That is a sensible and common path. Use the general assistant to establish that the task is possible and what good looks like, gathering examples as you go, then build the narrow system on those examples. The prototype has then produced both the confidence and the training material.

What accuracy should we expect?

Ask instead about the two directions separately: how often a real problem is missed and how often a good item is flagged. Those have different costs in your process and one number hides both. Any vendor able to discuss the trade rather than quote a figure is a better sign than the figure itself.

Does the video have to leave our premises?

Not necessarily, and this is one of the field's practical advantages. Narrow models run on hardware at or beside the camera, so the footage need never be transmitted and only the result travels. Where a vendor requires video to be uploaded, that is a design choice worth asking about rather than a requirement of the technology.

Glossary

Computer vision

Computer vision is the field concerned with getting software to interpret what is in an image or a video, such as which objects are present, whether a part is faulty, or whether something moved.

In plain terms

Older and narrower than the assistants that now accept photographs. This is the discipline behind a camera that counts vehicles, a production line that spots a cracked casing, and a phone that finds the faces in your pictures. The systems are usually built for one job and are very good at it, which is the opposite arrangement from a general assistant that will attempt anything.

Why it matters

Anywhere one of your people looks at something repeatedly and makes the same judgement, this is the technology in question, and it is mature. Counting, checking, sorting and spotting differences at volume have been solved well for years, at costs that surprise people who assume anything involving AI is expensive. The mistake worth avoiding is reaching for a general assistant because it is easier to try, on a task you know will run ten thousand times a day.

How it works

A model is trained on labelled examples of the specific thing it must recognise, which is why the examples matter more than the algorithm. A defect detector needs photographs of your defects, including the awkward ones, and gathering those is usually the bulk of the project rather than a preliminary to it.

The common jobs are distinct and worth naming. Classification says what this is, detection says what is present and where, segmentation says which pixels belong to what, and tracking follows something across frames. Products differ in which they do, and a vendor offering one will happily discuss a problem needing another.

It runs comfortably on modest hardware, which is why it appears in cameras, phones and machinery rather than only in data centres. A model built for one narrow job is small enough to sit beside the thing it is watching, which is also why it can react in the time available on a production line.

Accuracy is measured in two directions and the trade between them is a business decision. Missing a real defect and flagging a good part cost you different amounts, and setting the balance between them is a judgement about your process rather than a technical setting. A vendor quoting one accuracy figure is quoting half a picture.

Why the easy option and the deployed one are two stages, not two choices

The temptation is to treat these as alternatives, and organisations that do usually pick the first because it works before lunch. That is the correct decision for finding out whether the idea has legs and the wrong one for a camera watching a line all day. What makes the sequence work is that the earlier stage produces exactly what the later one needs: every image pushed through the general assistant while establishing what a good answer looks like is a labelled example, and labelled examples were always the expensive part of building the narrow system. Used that way the two stop competing. The easy thing gathers the material, and the hard thing runs the result at a cost per look that makes ten thousand a day unremarkable.

Seen in the wild

Photograph something and ask a general assistant what is in it, which is the easy version and a useful comparison against a purpose-built system.
Google Gemini
Ask an assistant to count identical objects in a photograph and check the answer yourself, which is where the general approach is weakest.
ChatGPT
Attach an image and ask about something described rather than counted, which is where the general approach is strongest and a narrow detector has nothing to say.
Claude

Common misconceptions

People assume

A general assistant that accepts images has replaced it.

In fact

It has replaced the trying-it-out stage, which was previously the expensive part. For one visual task running thousands of times a day, a purpose-built system is usually cheaper, faster and more accurate, and it does not need a connection to somebody's servers. The general assistant is the prototype rather than the deployment.

People assume

It needs a huge quantity of examples.

In fact

Far fewer than it used to, because most projects now start from a model already trained on general images and adapt it. Hundreds of well-chosen examples, including the awkward cases, get a long way. What has not changed is that the awkward cases are the ones that matter and the ones nobody photographs.

Telling them apart

Computer vision vs Multimodal

Computer vision

Purpose-built for one visual task, trained on examples of it, cheap and fast at volume, and unable to answer a question about anything else.

Multimodal

A general system that accepts images alongside text, will attempt anything, and costs more per look while being far easier to try.

Run it once and the general one wins on effort. Run it ten thousand times a day and the purpose-built one usually wins on everything, which is why prototyping and deploying often use different technologies here.

Questions

Could we prototype with an assistant and deploy something purpose-built?: That is a sensible and common path. Use the general assistant to establish that the task is possible and what good looks like, gathering examples as you go, then build the narrow system on those examples. The prototype has then produced both the confidence and the training material.
What accuracy should we expect?: Ask instead about the two directions separately: how often a real problem is missed and how often a good item is flagged. Those have different costs in your process and one number hides both. Any vendor able to discuss the trade rather than quote a figure is a better sign than the figure itself.
Does the video have to leave our premises?: Not necessarily, and this is one of the field's practical advantages. Narrow models run on hardware at or beside the camera, so the footage need never be transmitted and only the result travels. Where a vendor requires video to be uploaded, that is a design choice worth asking about rather than a requirement of the technology.

Key takeaways

It is the older, narrower discipline for interpreting images, distinct from an assistant that accepts them.
Systems are trained for one job on labelled examples, and gathering those is most of the work.
Classification, detection, segmentation and tracking are different jobs, and products differ in which they do.
It runs on modest hardware beside the camera, so footage need not travel.
Accuracy has two directions, and the balance between them is a business judgement.

Tools that use this

Google Gemini
The easy version, useful as a comparison against a purpose-built system.
ChatGPT
Counting in a photograph, where the general approach is weakest.
Claude
Describing rather than counting, where a narrow detector has nothing to say.

Last checked July 2026

All glossary terms