Few shot learning is a way of getting an AI model to perform a new task correctly by showing it a small number of examples, typically somewhere between two and a handful, rather than retraining it on a large labeled dataset. The examples are usually placed directly in the prompt sent to the model, showing the pattern of input and desired output, and the model uses that pattern to handle a new, similar input it has never seen before. This is different from traditional machine learning, where getting a model to do a new task usually meant collecting thousands of labeled examples and running a separate training process. Few shot learning turns that multi-week process into something that can happen inside a single prompt, tested and adjusted in the time it takes to write a good example set.
The reason few shot learning exists is that collecting and labeling large training datasets for every new task a business wants an AI model to handle is slow, expensive, and often impractical. A company that wants a model to classify support tickets into ten specific internal categories used to need hundreds or thousands of labeled examples of each category before a model could learn the pattern reliably, and building that dataset alone could take a data team weeks before any actual model training even began. Few shot learning solves this by relying on the fact that large language models already learned broad patterns of language and reasoning during their original training, so a handful of examples showing the specific task at hand is often enough to point that existing capability at the new problem.
What distinguishes few shot learning mechanically is that no weights inside the model are updated, nothing is retrained, and no separate model gets deployed. The examples are provided as part of the input text at the moment a request is made, and the model uses its existing capabilities to recognize the pattern in those examples and apply it to the new case in the same request. This is sometimes described as the model "learning" the task, but it is more precise to say the model is being shown a pattern to follow using context it already has, and that context disappears once the request ends unless it is included again next time. Nothing persists between requests unless the system explicitly resends the same examples with every new call.
By 2026, few shot learning has become one of the most common ways businesses adapt general-purpose AI models to specific internal tasks without the cost of fine-tuning or building a custom model. Teams building internal tools, from ticket routing to document classification to structured data extraction, routinely include a handful of examples in their prompts as the default first approach, reserving more expensive custom training for the cases where a handful of examples genuinely is not enough. This shift has lowered the barrier to building narrow AI features considerably, since a task that once required a data science team and weeks of labeling can now often be handled by a product manager writing a good prompt in an afternoon and iterating on it directly against real output.
This page covers how few shot learning works, how it compares to zero shot approaches and full fine-tuning, where it earns its keep and where it falls short, and how to build good few-shot examples in practice. The durable idea underneath all of it is that showing a pattern is often nearly as powerful as training on it, and understanding when that holds true lets a team ship narrow, task-specific AI behavior fast, without defaulting to expensive custom training every time a new use case comes up, and without waiting on a data science team to build a training set before shipping something that works.
A typical few-shot prompt includes a short instruction describing the task, followed by a small set of example pairs showing an input and the correct output, and finally the new input the model actually needs to handle. If a business wants a model to tag customer emails with a priority level, the prompt might show three or four example emails alongside the correct priority label for each, then present a new email and ask the model to assign a label following the same pattern. The model picks up on the structure and the criteria implied by the examples and applies similar reasoning to the new case, effectively inferring the rules of the task from demonstrations rather than from an explicit written policy.
The number of examples needed varies by task difficulty and by how much the desired behavior differs from what the model would do by default. Simple classification tasks with clear categories often need only two or three examples to lock in the right pattern, while more nuanced tasks involving tone, structure, or domain-specific judgment calls may need more examples to reliably capture the intended behavior. There is a practical ceiling here too, since every example added to the prompt increases the token count and therefore the cost and latency of every single request that includes it, and teams often discover that accuracy gains flatten out well before they run out of examples worth adding.
The quality and diversity of the examples matter more than the raw count. A set of examples that only shows the easy, obvious cases will not prepare the model for the edge cases it is actually likely to encounter in production. Good few-shot examples typically include at least one edge case or ambiguous scenario alongside the clear-cut ones, since this teaches the model how to handle the situations where the desired behavior is not obvious from a plain description of the task alone, and those ambiguous cases are usually exactly where a model left to guess on its own would go wrong.
Few shot learning is closely related to chain of thought prompting when the examples include not just an input and output but also the reasoning steps that connect them. This combination, sometimes called few-shot chain of thought, is particularly useful for tasks that involve some judgment or calculation, since it shows the model not just what the right answer looks like but how to arrive at it, which tends to produce more consistent results on cases that differ somewhat from the examples shown, at the cost of a longer prompt and a higher token bill per request.
Fine-tuning is the traditional alternative to few shot learning, and it involves actually updating a model's internal weights using a labeled dataset, typically requiring hundreds or thousands of examples and a separate training run before the adapted model can be used. Fine-tuning tends to produce more consistent and often more accurate results than few shot prompting on tasks where the pattern is subtle or where consistency across a very high volume of requests matters enormously, but it costs significantly more in data preparation time, compute, and ongoing maintenance whenever the underlying base model changes. That maintenance burden is easy to underestimate: a fine-tuned model built on top of one version of a base model often needs to be retrained again whenever the provider ships a newer version.
Zero shot learning sits at the other end of the spectrum, where a model is asked to perform a task with no examples at all, relying purely on a written description of what is wanted. This works well when the task closely resembles something the model has broad general knowledge of, such as summarizing a document or answering a general question, since the model can lean on patterns learned during its original training without needing anything to be spelled out further. See zero shot learning for more on how that approach differs and when it is the better choice.
Few shot learning is the practical middle ground, useful specifically when a task has some structure or convention that is not obvious from a description alone but also not so idiosyncratic that it requires a fully custom trained model. A company's internal categorization scheme for support tickets, for instance, is not something a general model would guess correctly from a plain description, since the categories and their boundaries are specific to that company, but a handful of labeled examples usually communicates the scheme well enough for the model to apply it correctly to new tickets, without the weeks of setup that a fully trained classifier would have required in the past.
The choice between these three approaches usually comes down to how much the task deviates from general knowledge, how much volume the task needs to handle, and how much engineering time is available to invest. A team validating an idea quickly should start with zero shot or few shot prompting, since both can be tested in minutes, and only move to fine-tuning once the task has proven valuable enough to justify the additional investment and once few shot prompting has hit a real accuracy ceiling that more examples cannot fix. Skipping straight to fine-tuning before validating that the task is even worth solving is one of the more common ways teams waste engineering time on AI features that never end up mattering.
Document and data extraction tasks are a strong fit for few shot learning, since businesses often need a model to pull specific fields out of documents that follow varied but related formats, such as invoices, contracts, or intake forms. Showing the model two or three examples of a document alongside the correctly extracted fields communicates the exact structure wanted far more precisely than a written description of the fields alone, especially when the documents have unusual layouts or industry-specific terminology that a general description would struggle to capture in full.
Content classification and tagging systems, from support ticket routing to content moderation to internal document tagging, rely heavily on few shot examples to communicate a specific taxonomy that a general model would not know on its own. This is especially useful in tools built as an AI copilot for internal teams, where the categories and priorities reflect a specific company's workflow rather than any universal standard the model might already understand, and where getting the taxonomy wrong means work gets routed to the wrong team entirely.
Structured output generation, where a model needs to produce a response in a very specific format such as a particular JSON schema or a company's standard report template, benefits from few shot examples showing exactly that format applied to a couple of sample cases. Written instructions alone often leave room for the model to interpret formatting requirements slightly differently than intended, while a concrete example removes that ambiguity directly and tends to produce far more consistent output across many separate requests.
Multi-step agent systems, the kind built around an agentic workflow, often use few shot examples at individual decision points within a longer task, showing the model how to choose between available tools or how to structure an intermediate output before passing it to the next step. This keeps each step in a longer automated process predictable, since the model has a clear pattern to follow at each individual stage rather than needing to interpret an abstract instruction fresh every time, which matters enormously when one step's output feeds directly into the next.
Few shot learning fits well when a task has a clear pattern that a small number of examples can demonstrate, when the business needs to move fast without investing in a large labeled dataset, and when the volume of requests does not make the added token cost of including examples in every prompt prohibitively expensive. It is particularly strong for narrow, well-defined tasks that differ from general knowledge only in some specific convention or taxonomy that is easy to show but hard to describe fully in words. A good rule of thumb is to ask whether the task could be explained to a new employee in a single short document with a couple of worked examples attached; if so, few shot learning is usually a strong candidate.
It fits poorly when a task requires genuinely deep domain expertise that cannot be adequately captured in a handful of examples, such as specialized medical diagnosis reasoning or highly technical engineering judgment, where the pattern is too complex and the stakes of getting it wrong are too high to rely on a prompting technique alone. In these cases, fine-tuning on a much larger dataset, or pairing the model with structured domain knowledge through retrieval, tends to produce more reliable results, since a handful of examples simply cannot encode the depth of judgment an expert brings to those decisions.
It also fits poorly at extremely high request volumes where the added cost of repeating several examples in every single prompt becomes a meaningful expense at scale. A task handled millions of times a day may be better served by a fine-tuned model that does not need examples repeated in every request, since the one-time training cost gets amortized across enormous volume, while few shot prompting keeps paying the token cost of the examples on every single call indefinitely, a difference that can add up to a real line item on a monthly infrastructure bill once volume climbs high enough.
There is also a consistency limitation worth noting. Few shot learning can produce somewhat variable results across similar inputs, since the model is applying a pattern rather than following a rigid rule, and this variability can be a problem in situations demanding strict consistency, such as regulatory reporting where two similar cases must always be treated identically. Fine-tuning, or adding explicit rule-based validation on top of the model's output, tends to close this gap better than adding more examples alone, and a well-designed system will often layer a simple validation check on top of the model's response regardless of which approach generated it.
Start by choosing examples that represent the real range of inputs the model will actually see in production, not just the clean, obvious cases. Pull the examples from real past data whenever possible rather than inventing hypothetical ones, since real data tends to include the messiness, ambiguity, and edge cases that actually determine whether the model handles production traffic well or poorly. A set of examples built entirely from hypothetical scenarios tends to look tidy but often misses the specific quirks that show up once real users start sending real requests.
Keep the examples consistent in format and clearly separated, using a repeatable structure such as a labeled input and output pair for each example, so the model can easily recognize the pattern being demonstrated. Inconsistent formatting between examples, even small differences like varying labels or inconsistent punctuation, can confuse the pattern the model is meant to pick up on and lead to less reliable results on new cases, since the model may end up picking up on the formatting inconsistency itself as part of the pattern rather than ignoring it.
Test with a held-out set of real cases that were not used as examples, and measure accuracy directly rather than relying on a subjective sense that the outputs look reasonable. If accuracy plateaus below what the task requires even after adding more or better examples, that is a signal the task may need fine-tuning or a fundamentally different approach rather than further prompt tweaking. This kind of held-out testing is also the only reliable way to catch a set of examples that happens to work well on the cases it was built from but fails on anything slightly different.
Revisit your few-shot examples periodically as the task or the underlying data changes, since examples that captured the right pattern when they were written can go stale as edge cases evolve, categories shift, or the volume and variety of real inputs grows. Treat a set of few-shot examples as a living part of the product that needs occasional maintenance, not a one-time setup step you write once and never touch again, and assign clear ownership for that maintenance the same way you would for any other piece of production configuration.
Few shot learning is a technique where an AI model is given a small number of example input-output pairs directly in a prompt, and uses the pattern shown in those examples to correctly handle a new, similar input, without any retraining or changes to the model's underlying weights. It is one of the fastest ways to adapt a general model to a narrow, specific task, and it can typically be tested and refined within a single working session rather than a multi-week project.
Most few-shot prompts use somewhere between two and ten examples, with simpler classification tasks often needing only two or three clear examples and more nuanced tasks needing a somewhat larger and more varied set to reliably capture the intended pattern. Adding examples beyond that point usually produces diminishing returns while still increasing cost.
Few shot learning includes actual example input-output pairs in the prompt, while zero shot learning relies only on a written description of the task with no examples at all, making few shot generally more reliable for tasks with a specific convention that is hard to fully describe in words. Zero shot works fine when the task closely matches general knowledge the model already has.
No, fine-tuning actually updates a model's internal weights using a labeled training dataset and a separate training process, while few shot learning provides examples as part of the prompt at request time with no changes to the model itself. Fine-tuning tends to cost more upfront but can be cheaper per request at very high volume.
Few shot learning is a good starting point for validating a new task quickly, for tasks with a clear pattern that a small number of examples can demonstrate, and for lower-volume tasks where the extra token cost of including examples is not a major expense at scale. Move to fine-tuning only once the task has proven its value and few shot accuracy has hit a real ceiling that more or better examples cannot push past.
Yes, including worked reasoning steps alongside the input and output in each example, an approach related to chain of thought, often produces more consistent results on tasks involving judgment or calculation than examples showing only the final answer. This combination costs more tokens per prompt but tends to pay for itself on harder tasks.
Once the examples already capture the core pattern and the range of cases the model will encounter, additional examples mostly add redundant information, increasing token cost and latency without teaching the model anything it had not already picked up from the earlier examples. This is why testing accuracy directly matters more than assuming more is always better.
Yes, in an agentic workflow, few shot examples are often used at specific decision points to show a model how to choose between tools or structure an output at that step, keeping individual steps in a longer automated process predictable and consistent. This matters most in longer workflows where one unpredictable step can derail everything downstream of it.
If accuracy plateaus below what a task requires even with well-chosen and varied examples, that usually signals the task needs fine-tuning on a larger labeled dataset or a different approach entirely, such as pairing the model with retrieval of structured domain knowledge. Trying to force the issue by adding still more examples rarely closes a real accuracy gap at that point, and often just adds cost without moving the needle.
