Tuning is the heavier tool and it is often the wrong one. If the job is about facts that change, or about following a document, retrieval does it without a training run and without a model that goes stale. Choosing the wrong one is the more common error than doing the tuning badly.
About 1 min of reading
Classify the job.
A changing job
Before you run it, say out loud what it will print. Then open the answer.
A stable job
Before you run it, say out loud what it will print. Then open the answer.
Read the first example one line at a time. A line that prints shows what appears on screen; the rest set things up quietly.
Write what changes in the job. If something does, that part belongs in the context, and only the stable shape belongs in the weights.
Run the same test set against the prompted base model and the tuned one. Publishing both numbers is what makes the choice reviewable rather than a preference.
Prices, versions, policies, and anything in a repository are facts that move. A tuned model carries them in weights and becomes wrong the day they change, which is retrieval's job.
A format, a tone, a fixed transformation, a classification into set labels. These do not change and they are hard to describe in words, which is exactly what examples are good for.
Write the instruction and the few examples in the prompt. If that already works, you do not need a tuned model, and you keep one model instead of a build artifact to maintain.
Each one is defined here on this site. Open the entry for the full definition and the other words it points at.