Here is the honest truth most courses won’t tell you: the vast majority of builders never need to train or fine-tune a model. Good prompting plus retrieval (RAG) solves almost every real problem. Fine-tuning is a narrow tool for a narrow job — a specific style or task, backed by a real dataset. This page shows you the difference, when fine-tuning is genuinely worth it, and how it works — so you don’t burn time and Naira on training you didn’t need.
If you only remember one thing from this page: before you even think about fine-tuning, exhaust prompting and retrieval. Most people who think they need a custom model actually need to (1) write a sharper prompt and (2) feed the model their own documents at question time with RAG. Both are cheaper, faster, easier to change, and you can do them today on a basic laptop. Fine-tuning is the last lever, not the first.
“Training,” “fine-tuning,” and “RAG” get used interchangeably and they are not the same. Climb this ladder from cheapest to most expensive — and stop as soon as something works.
Cheapest · instant · try this first
You tell a model what to do in plain words — a clear instruction, a few examples, the format you want back. No training, no dataset, no GPU. Modern models are strong enough that good prompting solves most problems on its own. If you have not exhausted prompting, you are not ready to fine-tune.
Cheap · gives the model your facts
RAG means Retrieval-Augmented Generation: you store your own documents, search them at question time, and paste the most relevant chunks into the prompt. This is how you make a model answer from your handbook, your prices, your policies — without changing the model at all. It is the right fix for “the model doesn’t know my data.”
More effort · changes the model’s behaviour
You take an existing model and continue training it on a focused dataset of your own examples — usually a few hundred to a few thousand input/output pairs. It nudges style, tone, and format, and can teach a narrow, repeatable task. It does not reliably teach the model new facts; that is what RAG is for.
Almost certainly not you
Building a model from scratch on trillions of words. This costs millions of dollars and needs huge clusters of GPUs. Effectively no individual builder or small startup does this — you build on top of models that big labs already pretrained. We mention it only so the words don’t confuse you.
All of these should be true — not just one. If they are not, stay on prompting and RAG.
If any of these is your reason, fine-tuning is the wrong tool. Here is what to do instead.
Two real routes — a hosted fine-tuning API (no GPU of your own) or local LoRA-style fine-tuning on an open model. The steps are the same; the heavy work is the dataset, not the training.
Collect real input/output pairs that look exactly like the job. Quality and consistency beat quantity — a few hundred clean, well-formatted examples beat thousands of messy ones. Most of the work of fine-tuning is here, not in the training.
// Most hosted APIs want JSONL — one example per line:
{"messages":[{"role":"user","content":"Rewrite this for our house voice: ..."},{"role":"assistant","content":"..."}]}
{"messages":[{"role":"user","content":"Rewrite this for our house voice: ..."},{"role":"assistant","content":"..."}]}Split off a slice of your data the model never trains on. After fine-tuning, you test against that held-out slice to see if it actually improved — instead of fooling yourself. If you cannot measure better, you cannot claim better.
A hosted fine-tuning API uploads your dataset, runs the training on the provider’s GPUs, and gives you a private model to call — no GPU of your own needed. Or, with an open model, you fine-tune locally using a LoRA / QLoRA approach, which only trains a small set of extra weights so it fits on a single consumer GPU.
# Local LoRA path uses the open-source ecosystem, roughly: pip install transformers peft trl bitsandbytes datasets # then a small training script loads a base model + your JSONL, # trains a LoRA adapter, and saves it next to the base weights.
Run the job, then compare the fine-tuned model against your held-out examples — and against a plain prompt baseline. If a good prompt already matches it, you did not need to fine-tune. Keep the result only if it clearly wins.
Call your fine-tuned model the same way you call any model — from your backend, with the key kept server-side. Watch quality in the real world, and be ready to re-do the dataset as the task drifts.
Prompt first. Add RAG when the model needs your facts. Run a model locally if you want privacy or to work offline. Fine-tune only when you have a narrow task, a real dataset, and you have proven prompting and RAG fall short. That order saves you money, time, and a lot of frustration — and it is how serious builders actually work.