What is few-shot learning, and how does it work in computer vision?
Few-shot learning attempts to recognise a target class from a small number of labelled examples. In computer vision, a shot usually means an image belonging to a particular class. An experiment with five examples per class is different from one with five images in total. The model may already have been trained on a large dataset; few-shot learning does not mean that all its learning took place using only those few target images.
The Prototypical Networks paper recognises classes unseen during training by measuring distances to class prototypes in a learned feature space. A simple classifier built on pretrained features can also provide a starting point for a small-data application. However, not every small-data training exercise uses the experimental setup of that paper. State how many classes, how many independent images per class and which pretraining your own experiment uses.
Anomaly detection using only normal parts addresses a different problem. Instead of learning a known defect's name, it looks for departures from normal appearance. The PatchCore paper investigates that normal-image starting point. Two defective images and hundreds of normal images do not automatically constitute the same task as two-shot defect classification. You may need a defect name, a suspicious region or a review decision, each requiring a different data plan.
Which experiment fits the available labels?
Inventory images by product, defect type, camera, shift and batch. Twenty similar frames of one physical part are not twenty independent defect examples. The counts below are illustrative data situations for planning a pilot, rather than success thresholds for a method. Diversity and a clear acceptance rule matter alongside image count, and none of these rows removes the need for an independent evaluation.
| Available labels | Starting experiment | Output and check |
|---|---|---|
| No defect labels; normal images available | Normal-trained anomaly model | Review score; independent defect test |
| 1–5 defects per class | Feature similarity or class prototypes | Suggested class; more independent examples |
| 5–20 defects per class | Small classifier on frozen features | Defect class; held-out validation |
| Some defect types have no examples | Known classes with an unknown route | Review routing; new-type test |
| Defect location or area required | Separate experiment with location labels | Boxes or masks; regional evaluation |
A correct part-level class does not establish that the model located a hairline scratch. If localisation matters, annotate test examples with boxes or masks. If physical area matters, validate the image geometry too. Adding more image labels does not automatically solve that measurement requirement. Choose what the operator must see and what the downstream system must do before extending the annotation budget.
How to build a small-data image recognition experiment
First write the class definitions: acceptable appearance, defect types, confusing cosmetic marks and uncertain cases. Show annotators examples near the decision boundary. Markings on defect photographs, different backgrounds or a different capture setup must not become the class cue. Capture acceptable and defective parts at the same station where possible, so the model does not learn the collection process instead of the defect.
Keep the part ID, batch, camera, product variant, capture time, defect label and review decision for each image. Split independent parts into training, validation and test groups first, then create augmented images from training only. A rotated or recoloured copy of the same image is not a new physical defect. A derivative of an original test image must not appear in training, even when its filename or pixels have changed.
Compare three starting points: the existing camera rule, normal-only anomaly detection and a small classifier where the labels support it. PyTorch's computer vision transfer learning tutorial distinguishes adapting a pretrained network from keeping the network as a fixed feature extractor. With limited data, you can first try an experiment with fewer learned parameters, then measure whether broader adaptation adds value on the validation group.
For a few-shot prototype approach, record which images form the reference set. An image may be closest to one class while still being very different from every known class. Select the review boundary using separate validation data. Do not treat a classifier's requirement to assign a known class to every input as an operational decision. The unknown route needs its own acceptance test; it does not emerge automatically from having a confidence score.
Plan annotation effort and public data use
Do not allocate the entire budget to training examples. Expert checking, independent testing and review of incorrect decisions require work too. If a class has only one example, learning and independent performance measurement cannot both depend on that same image. Collecting new images can be more useful than trying many model settings. Use the error log to decide which missing class or camera slice should receive the next collection budget.
MVTec AD 2 offers a comparison resource with challenging lighting conditions and public and private tests. Its dataset licence restricts commercial use, so check the conditions before copying it into a business project. You can investigate a method with this resource, but the results do not guarantee performance for your camera, product mix or physical removal system. Keep benchmark evidence separate from evidence gathered at your own inspection station.
Hypothetical example: 400 normal and 18 defective images
All numbers in this scenario are hypothetical and illustrate a plan. Suppose a packaging line has 400 normal images and six images for each of three defect types. Allocate the normal images as 240 training, 80 validation and 80 test examples. For each defect type, allocate three images to classifier learning or references, one to validation and two to testing. The total defect split is therefore nine, three and six images.
Split by physical part and batch; do not share the same object between groups just to meet those counts. Train the anomaly model using only the 240 normal images. The classifier can use the same normal history and nine defective examples. Choose both candidates' thresholds on validation data. Open the six test defects only for the final comparison. Do not turn those images into repeated tuning data because the first result is disappointing.
If annotation takes one minute per normal image and three minutes per defective image, the initial work requires 400 + 54 = 454 minutes, or approximately 7.6 hours. Expert checking and new captures are additional. Suppose one candidate flags five of the six test defects and sends four of the 80 normal parts for review. Detection on the available defect sample is 83.3%, and the false-alert rate is 5%. Under similar conditions, the latter corresponds to 50 alerts per thousand normal parts. Six defects do not make this strong evidence for automatic rejection: one miss changes the percentage by approximately 16.7 percentage points.
A test plan: what to report with few examples
Overall accuracy can look strong because acceptable parts dominate the sample. For every defect type, show counts for detected, missed and incorrectly classified images. Calculate false alerts against the number of normal parts. Before selecting the model, agree with the production team which error carries the greater cost and how uncertain outcomes will be handled.
- Data separation: Audit physical part IDs and confirm that augmented copies appear only in training. Inspect related frames as well as exact duplicate files, since both can make an evaluation optimistic.
- Reference sensitivity: Use validation data to measure how results change when the few-shot reference selection changes. A favourable choice of three reference images should not be confused with a stable system.
- Difficult slices: Report tiny defects, different shifts, later batches and camera conditions separately. Include sample counts to show where a percentage rests on just one or two examples.
- Operation: Measure total latency on the intended hardware, false alerts and operator review time. A small image dataset says nothing by itself about whether the whole station can meet line timing.
- Unknown cases: Test that new defects, missing images and uncertain classes reach review. Verify the action rather than accepting a displayed uncertainty score as proof that routing works.
Accumulate data from later independent batches. Match false alerts and misses to the quality decision, and also inspect a sample of low-scoring parts. Repeat acceptance testing after camera moves, material changes or new lighting. Additional labels should fill missing conditions rather than merely increase the total count. Keep model, reference set and threshold versions with the results so a later improvement can be compared on the same basis.
Common mistakes
- Presenting the total image count as the number of independent examples for each class.
- Treating anomaly detection with normal references and labelled defect classification as the same experiment.
- Spreading augmented copies across evaluation sets and inflating performance with related frames.
- Interpreting a percentage from six test defects as broad assurance for production.
- Using a classification score as evidence of localisation, measurement or detection of unknown defects.
How Hatson Tech builds this
In our computer vision services, we combine the data inventory, annotation budget and final action in one pilot plan. Our guide to image processing and quality control in production covers the wider line setup; our article on anomaly detection without defect labels helps when normal data dominates; and our segmentation or detection selection guide addresses location and area requirements. The first goal is to demonstrate, through independent measurement, which decision the available data can support.