Zero-shot, few-shot or fine-tuning?

Zero-shot means telling the model what you want without showing it. Few-shot means putting two or three correct examples inside the same prompt. Fine-tuning means updating the model's weights with your data — you are no longer running a general model but one that has learned your task.

The difference is not only accuracy. With zero-shot, fixing a mistake takes as long as rewriting a sentence. With fine-tuning, the same fix means collecting data, retraining and re-measuring. So the decision is less about accuracy than about how fast you need to be able to change your mind.

We start zero-shot because setup takes half a day and it answers the question that matters: can the model already do this from what it knows, or not. Going straight to fine-tuning without that answer is prescribing before diagnosing.

If zero-shot falls short, the next step is usually fixing the prompt, and only then adding examples. What we see in practice: most tasks people assume need fine-tuning are solved once the prompt makes the format and the boundaries explicit. The model does not lack the skill; it lacks the instruction.

Examples have a ceiling too. Each one lengthens the prompt, every request pays for that length, and past a point new examples stop improving accuracy. Reaching that point is what makes fine-tuning worth discussing.

Four situations where it wins clearly. First, when the output format is rigid and must be identical every time. Second, when the task speaks a language specific to the organisation — terms, product codes and internal abbreviations that never appeared in training data.

Third, when latency or cost is under pressure: a fine-tuned small model runs faster and cheaper than a large model carrying a long prompt, and the gap shows up on the monthly bill rather than per request. Fourth, when you already hold a few thousand well-labelled examples.

Without any of those four, fine-tuning usually slows a project down. Training a model is not the hard part; being able to update it three months later is.

None of this is argued without a comparable measurement. We build a set of fifty to two hundred real cases with hand-written correct answers, then run all three approaches against the same set.

Three numbers matter: accuracy, cost per request and response time. If fine-tuning does not beat few-shot by a meaningful margin, the decision is made — the other two approaches cost far less to maintain.

Building that set takes a day and it is usually the highest-return day of the project. A choice without a measurement is not a choice; it is a preference.