What is Few-Shot Learning?
Few-Shot Learning is a family of machine-learning settings in which a system must generalize to a new task or class from a small labeled support set relative to the problem, prior data, or conventional training requirement.
Quick Facts
| Created | Concept from 2000s, LLM context from 2020 |
|---|---|
| Specification | Official Specification |
How It Works
N-way K-shot defines an episodic task
An N-way K-shot classification episode presents N labels and K support examples for each label, then evaluates predictions on a disjoint query set from those labels. K describes the episode, not a universal definition of few. Regression, generation, and detection use different task structures. Report class balance, support construction, query size, prior data, and whether adaptation is transductive.
Methods transfer different kinds of prior knowledge
Matching Networks compare queries with support representations; Prototypical Networks classify by distance to class prototypes; optimization-based methods such as MAML learn an initialization that can adapt with a small update. Other approaches use pretrained embeddings, data augmentation, Bayesian inference, or parameter-efficient adaptation. None removes the need to validate the representation and distance or update rule on the target domain.
LLM few-shot prompting is an inference technique
In an LLM prompt, a few input-output demonstrations specify labels, format, or behavior inside the current context. This is usually a form of in-context learning rather than classical episodic training: no optimizer step occurs and the examples consume context on every request. Use the phrase few-shot prompting when that narrower behavior is intended, and state whether retrieval chooses demonstrations dynamically.
Evaluation must prevent hidden data reuse
Split by task, class, entity, source, or time according to the claimed generalization target; a random row split can leak near-duplicates or the same entity into support and query. Evaluate many sampled episodes or representative production tasks, publish the sampling procedure and uncertainty, and compare against zero-shot, nearest-neighbor, linear-probe, full-supervision, and fine-tuning baselines where relevant.
Key Characteristics
- Uses a small support set relative to the target task and available prior knowledge
- Often evaluates N-way K-shot episodes with a separate query set
- Transfers representations, similarity metrics, priors, or adaptation procedures
- Includes metric-based, optimization-based, probabilistic, and augmentation approaches
- Is distinct from LLM few-shot prompting even though both use limited examples
- Requires leakage-safe splits and repeated evaluation to support generalization claims
Common Use Cases
- Recognizing newly introduced product or defect classes with few reviewed examples
- Adapting perception or document models where expert labels are expensive
- Bootstrapping intent classification before a large labeled set exists
- Comparing pretrained representations under controlled support-query episodes
- Providing LLM demonstrations for temporary labels or output formats without weight updates
Example
Loading code...Frequently Asked Questions
What do N-way and K-shot mean?
In an N-way K-shot classification episode, the support set contains N classes and K labeled examples per class. A separate query set measures predictions for those episode classes. The notation does not specify how much prior training the model received, how queries were sampled, or whether the method uses query-set information jointly.
Is few-shot learning the same as few-shot prompting?
No. Classical few-shot learning often trains or evaluates a system over support-query episodes and may adapt parameters. Few-shot prompting places demonstrations in an LLM's current context without an optimizer step. Both use limited examples, but their mechanisms, persistence, compute, leakage risks, and evaluation protocols differ.
How many examples count as few-shot learning?
There is no universal cutoff. K is meaningful only relative to the task, class complexity, prior data, annotation cost, and baseline. Report the exact support size and construction instead of saying merely few-shot. For LLM prompts, also report demonstration tokens because context cost can matter more than example count.
How can few-shot evaluation leak test information?
Near-duplicate samples, the same user or object, shared acquisition sessions, pretraining overlap, label-description leakage, or tuning repeatedly on the final test episodes can inflate results. Split on the entity, source, class, or time boundary implied by deployment, deduplicate support and query, and keep a final untouched evaluation set.
When should I use prototypes, prompting, or fine-tuning?
Prototype methods suit stable embeddings and class-based tasks with small support sets. Prompting suits temporary natural-language tasks when a capable LLM already understands the domain. Fine-tuning is worth testing when behavior must persist, request-time context is costly, or enough governed data exists. Compare all viable baselines on quality and operations.