Few-Shot Prompting vs. Fine-Tuning vs. Training: Which Fix Do You Need?

Start with few-shot prompting

Few-shot prompting places a small number of worked examples inside the model context at runtime. It is useful for response style, output format, intent classification, tool selection, dialect, terminology, and recurring edge cases. You can change the examples immediately, route different examples by context, and test the effect without creating a new model.

Fine-tuning and few-shot prompting solve different problems, not the same problem at different intensities. Fine-tuning mostly changes form: consistent style, tone, and output shape across a large volume of calls. Few-shot prompting mostly changes behavior in the moment: tool selection, reasoning through a specific edge case, and getting the answer right on a class of input the base model handles poorly. If a model keeps calling the wrong tool or its reasoning breaks on a known edge case, more style consistency from fine-tuning will not fix that. More relevant examples usually will.

Use fine-tuning for repeated behavior at scale

Fine-tuning updates a model using a curated dataset. It becomes attractive when the behavior is stable, you have enough high quality examples, runtime prompts are too large, or the base model repeatedly misses a pattern even with clear context. It can improve consistency and reduce prompt length. It also creates a dataset, training, validation, versioning, and monitoring responsibility.

OpenAI supports supervised, preference, and reinforcement fine-tuning methods on selected models. That does not mean every available method belongs in your project. Start with a measurable failure and choose the method that targets it.

Model training is a different category

Training or continued pretraining changes model weights using much larger datasets and far more compute. It may make sense for a model provider, a research program, strict deployment constraints, or a domain with enough proprietary data to justify the investment. It is rarely the first answer for a customer support chatbot that needs better tone, terminology, or tool use.

My decision order

I fix the prompt, tool contracts, examples, and routing first. Then I run the same benchmark against the candidate setup. If the system still fails in a stable and repeatable way, fine-tuning becomes a real option. This order is less exciting than announcing a custom model, but it is faster to debug and gives you evidence for the next step. I never start with fine-tuning, even when a client asks for a custom model on day one.

A document-processing project made the same discipline concrete outside language work. A translation agency needed to quote jobs by counting words in whatever a customer uploaded: scanned pages, embedded images, tables, several languages and dialects sometimes inside one file. My first attempt tried to solve the whole problem with OCR before producing a single reliable count, every document type and every edge case in one pass. It never worked well, and the cost of running a strong enough model against every document type got expensive fast. The fix was not a better OCR model. It was accepting a pipeline that automated the roughly 20% of cases that covered 80% of real documents well, and routed everything else to a short human review step instead of forcing full automation from the start. That 20% keeps expanding as more edge cases get handled, but trying to hit 100% automated on day one is what kept it broken.