> For the complete documentation index, see [llms.txt](https://www.pranaypourkar.co.in/the-programmers-guide/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://www.pranaypourkar.co.in/the-programmers-guide/ai/generative-ai/large-language-models-llm/prompt-engineering/prompt-engineering-techniques/1.-input-based-techniques/few-shot-prompting.md).

# Few-Shot Prompting

## About

Few-shot prompting is a technique where the model is given **a small number of examples (demonstrations)** within the prompt to show how a task should be performed.

Unlike zero-shot prompting, where the model relies entirely on instructions, few-shot prompting provides:

* Example inputs
* Corresponding example outputs
* A pattern to imitate

Core idea:

> Demonstrate the behavior you expect, then ask the model to continue the pattern.

The model does not “learn” permanently from these examples. Instead, it performs **in-context learning**, temporarily adapting its output behavior based on the examples shown in the prompt.

## How Few-Shot Prompting Works ?

Large Language Models are extremely good at pattern continuation.

When we provide examples like:

Input: A\
Output: B

Input: C\
Output: D

The model detects:

* Structural patterns
* Formatting style
* Level of detail
* Output boundaries
* Label conventions

Then when we provide:

Input: X\
Output: ?

The model generates output consistent with the observed pattern.

This works because LLMs are trained on large corpora containing structured demonstrations, examples, Q\&A formats, and classification patterns.

Few-shot prompting effectively says:

> “Follow this pattern.”

## Strengths and Ideal Use Cases

Few-shot prompting significantly improves reliability over zero-shot when structure or format matters.

### 1. Improved Consistency

Examples reduce ambiguity in:

* Output format
* Tone
* Label choices
* Structure

The model mimics demonstrated structure.

### 2. Better Task Interpretation

If a task can be interpreted in multiple ways, examples clarify intent.

For example:

Without example:\
“Extract entities.”

With example:\
You show what “entities” means in this context.

This removes interpretation errors.

### 3. Stronger Performance on Complex Tasks

Few-shot prompting helps in:

* Classification with custom labels
* Data transformation
* Schema conversion
* Domain-specific summarization
* Code formatting patterns
* API response shaping

When the task format is non-standard, examples are critical.

### 4. Better Output Control

Few-shot implicitly enforces:

* Structure
* Formatting
* Verbosity level
* Label consistency

It acts as a soft schema.

## Limitations and Failure Modes

While powerful, few-shot prompting has trade-offs.

### 1. Increased Token Cost

Examples consume tokens.

More examples →

* Higher cost
* Higher latency
* Risk of hitting context window limits

Efficiency must be balanced with reliability.

### 2. Example Quality Sensitivity

The model imitates the examples exactly.

If examples are:

* Incorrect
* Poorly structured
* Inconsistent
* Ambiguous

The output quality degrades.

Garbage examples → garbage pattern continuation.

### 3. Overfitting to Examples

The model may:

* Copy example phrasing too closely
* Assume narrow scope
* Fail to generalize beyond examples

Examples must represent the task broadly enough.

### 4. Context Window Constraints

Since LLMs have limited context windows, too many examples can:

* Push out important instructions
* Reduce space for task-specific data

Few-shot must be efficient and intentional.

## Design Considerations

To use few-shot prompting effectively in production systems, consider the following:

#### 1. Choose Minimal but Representative Examples

We do not need many examples.

Often:

* 2–5 high-quality examples are enough.

They should:

* Cover edge cases
* Demonstrate structure clearly
* Represent variation in input

### 2. Maintain Structural Consistency

Examples should follow strict formatting patterns.

For example:

Input:\
...\
Output:\
...

Use consistent separators, indentation, and formatting.\
The model is sensitive to structural cues.

### 3. Separate Examples from the Actual Task

Clearly distinguish:

**Examples:**

Example 1\
Example 2

Now perform the task on:

This prevents blending between examples and the new task.

### 4. Combine Few-Shot with Constraints

Few-shot works best when combined with:

* Explicit output instructions
* Role definition
* Format restrictions

Example:

“You are a backend validation engine.\
Follow the examples strictly.\
Return output only in JSON format.”

This increases determinism.

## Engineering Perspective

From a backend systems viewpoint:

Zero-shot prompting = API call without reference response.\
Few-shot prompting = API call with sample request/response examples included in documentation.

Few-shot provides:

* Behavioral specification
* Soft schema guidance
* Implicit validation pattern

It is particularly useful when building:

* AI-assisted automation pipelines
* API transformation systems
* Code generation workflows
* Structured document processors

It reduces randomness without requiring fine-tuning.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://www.pranaypourkar.co.in/the-programmers-guide/ai/generative-ai/large-language-models-llm/prompt-engineering/prompt-engineering-techniques/1.-input-based-techniques/few-shot-prompting.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.