Why few-shot prompting breaks on real data
On a demo dataset, few-shot prompting looks reliable: a dozen labeled examples in the system message, and the model confidently assigns requests to classes.
In a production stream, input data comes from different channels, wording changes, and the example set stops covering reality. Let's break down where exactly it breaks — the same set behaves differently on OpenAI and on a local model, but the failure classes are the same.
We have collected four modes that occur in almost every implementation — from blurred category boundaries to response format drift.
| Failure class | How it manifests | What it results in |
|---|---|---|
| Blurred class boundaries | The model assigns a borderline request either to one category or to a neighboring one | Part of the stream goes to the wrong route, and the share of manual edits grows |
| Contradictory example labeling | Two similar examples are labeled with different labels | Unstable model output: the same text gets different labels on a repeat run |
| Wording drift | Wording appears in the stream that was not in the examples | Accuracy falls gradually, without an obvious error on a specific request |
| Format drift | The model adds explanations, changes keys, wraps the response in text | Control over the response format is lost, and the parser receives empty fields |
The cost of these failures is measured not in "overall response quality" but in the share of requests that went to manual review and in the percentage of requests where none of the required fields arrived.
Classification failures are dangerous because they do not show up immediately: for a week the metrics are steady, then the share of edits grows — and it is unclear what exactly broke.
Next, we look at how this is addressed: with robust example sets, labeling for conflict cases, and format validation on the service side.
What controlled generation with examples provides
A well-tuned example set works as a specification of model behavior: thirty to fifty "input — correct answer" pairs collected from real requests define class boundaries more precisely than a long instruction.
The model sees where the line runs between a "quality complaint" and a "warranty question" and does not guess from the category name. On a held-out validation set, classification accuracy rises from 0.7 to 0.9 and above — on the same data, without fine-tuning.
Examples also define the response shape. If in the set every answer has the same set of fields, the model returns it on new inputs too: the same input gives the same result on a repeat run, not a "similar in meaning" one.
This is what removes manual editing — the response is already parsed into fields and goes to the accounting system without being rewritten by an operator, and the share of records that a human edits by hand falls from a third to single-digit percentages.
Resistance to new data is a consequence of how the set is assembled. We keep examples and the validation set in Hugging Face with versioning, so a new request class or a change in wording is addressed by adding two or three examples rather than rebuilding the solution.
Every change to the set is run through measurement on a held-out set: if accuracy does not improve, the example is removed from the set.
Tuning approaches: examples, instructions, fine-tuning
The tuning mode is chosen not by a general recommendation but by the properties of the stream: how many categories are in the task, how often the labeling changes, and whether examples of the required quality exist.
The same request behaves differently on ten classes and on two hundred — we compare approaches by applicability and limits, not by average quality.
Instructions in the request and few-shot prompting do not compete: rules fix the response format, field order, and prohibitions, while examples show the boundary between close classes.
Fine-tuning is brought in when the taxonomy is stable and the accumulated examples are enough for robust separation.
Comparison of approaches
| Approach | When it fits | Limitations |
|---|---|---|
| Examples in the request | 5–20 categories, labeling changes, launch needed without rebuilding | request size grows, quality drops on 30+ categories and on rare classes |
| Instructions in the request | rules are expressed in words: format, tone, what counts as an error | handles implicit features poorly, a conflict of rules breaks the response |
| Fine-tuning | stable taxonomy, hundreds of homogeneous examples per class | requires labeling, a taxonomy change entails rebuilding and a newly assembled set |
We select the size of the example set by the worst class, not the average: 5–15 examples per class for the request, from a hundred for fine-tuning.
If there are more categories, we first test a hierarchy or a two-stage scheme — a flat list of 50+ classes loses accuracy regardless of the chosen mode.
Implementation stages: from data audit to handover
Before writing wording, we analyze the corpus: how many labeled examples fall to each class, how they are distributed, and whether there are duplicates and overlapping wordings.
This determines whether few-shot will work at all — if a rare class has two or three samples, no instruction will give a robust result. The workflow below is the same for both classification and field extraction.
- Data corpus audit. We assess volume, labeling quality, the share of rare classes, and discrepancies between annotators. The output is a data map: which categories are actually distinguishable by text, and which will have to be merged.
- Solution design. We fix where exactly few-shot works — classification, entity extraction, or bringing text to the corporate style. We define the response format, required fields, and model behavior under uncertainty.
- Example assembly. We select samples for each class: short, unambiguous, without intersections between categories. We balance composition and order — the model is sensitive both to the number of examples and to the order in which they are presented.
- Validation bench. We form a held-out set that does not participate in tuning and run every version of the example set on it. This shows where the improvement is real and where it is overfitting to the data we have seen.
- Metric alignment. We agree in advance on what counts as success: per-class accuracy, extraction recall, the share of failures, and disputed cases for manual review. We fix the acceptance threshold before measurements, not after.
- Documentation handover. We provide a description of the example set and selection rules, instructions for expanding the corpus, the run scheme, and the retraining procedure when new categories appear. The client's team can handle further tuning on its own.
Example library, request templates, and procedures
After the solution launches, the team has a kit that determines whether it will maintain quality without us: an example library, templates for calls to the model, and the procedure by which all of this is updated. We hand it over in your code repository — with change history, not as an archive of documents.
- Example library — labeled "request — reference answer" pairs for each class, with complex and borderline cases that the model most often got wrong kept on a separate shelf.
- Request templates — templates for classification, field extraction, and bringing text to the corporate style: fixed structure, a place for examples, and rules for ambiguous input.
- Versioning rules — every edit to examples or a template goes as a separate change with an explanation of what was changed and why; the previous version remains for comparing results.
- Validation procedure — a set of test cases with expected answers and the run order: what counts as degradation and at what discrepancy an edit is rolled back.
- Solution documentation — the request processing scheme, input requirements, known limitations, and a list of cases where a human is required.
- Escalation procedure — who owns the example library on your side and how to hand the task over to us if edits stop producing quality gains.
The kit is designed for an engineer who has not worked with this before: it lets you add a new request class without rebuilding the entire solution.
Case study: request classification on a ticket stream
A support service with a stream of several thousand requests per day: each ticket must be assigned to one of 40 categories in order to forward it to the right group and trigger a standard response.
Labeling was done manually by operators, and this step became the bottleneck — at peak, the queue could not be processed fast enough, and a routing error came back to the second line.
What it was like before implementation
Four operators labeled the queue and diverged in interpretation: agreement between them stayed at 80%, meaning every fifth request, when re-labeled, went to a different category.
The average time from ticket arrival to assigning an owner reached 6–8 minutes, and disputed categories were discussed at a general meeting — which consumed part of the shift.
What was changed and what the result was
We set up few-shot prompting: the request included 5–8 reference examples per category plus a low-confidence rule — the model does not decide on its own but flags the request for an operator.
The category directory and procedures remained the same, no fine-tuning was required, and quality was additionally verified on the public Banking77 set.
Disputed cases stopped being reviewed en masse: the model sends only the low-confidence layer to an operator — about 6% of the queue — and the rest goes automatically.
A new category is added with a couple of reference examples, without rebuilding the directory or re-labeling the archive.
How does few-shot differ from fine-tuning?
The few-shot approach does not change the model weights: you describe the task in words and attach several labeled examples directly in the request. Behavior changes on the very next call — editing wording or replacing one example gives a new result without rebuilding the model.
Fine-tuning works differently: examples go into a dataset, the weights are updated from it, and the output is a separate artifact that must be versioned and maintained.
The labeling requirements here are an order of magnitude higher — hundreds and thousands of agreed examples, a separate validation set, and control of discrepancies between annotators. A labeling error is not visible immediately: it surfaces in the behavior of the finished model.
Support effort diverges at the very first change in the problem statement. In few-shot, it is enough to fix the examples and run the same set of checks to make sure neighboring scenarios have not broken.
In fine-tuning, every class change is a new pass: data collection, training, comparison with the previous version, and regression testing.
Transfer to new categories is also structured differently. Few-shot introduces a new category with two or three examples and immediately shows where the model gets confused — this is a quick way to test the problem statement itself.
Fine-tuning gives more stable behavior when there are many classes and the requirements for style and format are strict.
The boundary lies in the frequency of changes. If rules and categories live for weeks, few-shot wins; if the task is stable and the stream of similar requests is large, fine-tuning pays off.
Often both tools are used: fine-tuning covers baseline quality on mass classes, while few-shot covers rare cases and quick overrides on top.
Technical concerns: quality, volume, support
Engineers and tech leads usually raise the same objections: how many examples are really needed, what to do with rare classes, and how to update the solution without stopping the service. We answer point by point — with the specifics we see in projects.
How many labeled examples are needed per class?
For classification and entity extraction, a robust result is usually achieved with 8–30 examples per class — provided they cover different wordings, lengths, and edge cases rather than paraphrasing a single template.
Increasing the volume further is pointless: the request grows while accuracy stays flat. Therefore we select the required number experimentally — we run variants on a held-out set and fix where the metrics stop improving.
What to do with rare categories where there are almost no examples?
A rare class cannot be carried by examples alone, so we assemble it from several sources: accumulated request logs, analyst labeling of borderline cases, a hierarchy — first a broad group, then refinement within it.
While there is little data, such cases go to manual review with an explicit "needs clarification" label: overall accuracy does not drop, and we get material for the next iteration.
How to change wording and example sets without downtime?
Prompts, example sets, and rules are versioned like regular code. A new version first goes through a shadow run on live traffic: we calculate discrepancies with the current one and look at behavior on the golden set.
Switching is controlled, and the previous version remains deployed, so rolling back to it takes minutes rather than hours of approvals.
Let's discuss the task and come back with a work plan
To make the conversation substantive rather than general, a few inputs are enough for us — they show where few-shot prompting truly solves the task and where it is cheaper to get by with rules or fine-tuning.
Send what has already been accumulated: prompt drafts, disputed examples, and current filtering rules.
What helps at the input:
- 30–50 anonymized input examples with the expected answer indicated — a few-shot set is assembled from them.
- A list of target classes or extraction fields and a decision on ambiguous cases: assign to a class or send for review.
- The current prompt or rules, if you have already tried, and exactly what went wrong — repeated errors show where a different approach is needed.
- Data constraints: where it resides, whether it can be sent to external services, and who has access.
- Load profile: how many requests per hour, what the peak load is, and the average text length.
- Response format requirements — schema, required fields, and what counts as a critical error.
- Acceptance criterion: what share of correct answers on your set is considered workable.
In response, we send a task analysis and solution design: which examples will go into the prompt, how labeling is built, and where human review remains.
As a separate block — stages and timelines, including a pilot on your data: on it we fix the quality metric before implementation into the production loop.
Describe the task in two or three paragraphs — we will come back with an estimate and a work plan.