Card 10 of 38· Domain 2 · Generative AI and agents

Prompt vs RAG vs fine-tune — the most-asked decision

Matching the symptom to the fix, what fine-tuning actually involves if the answer really is fine-tuning, and the single most reliable distractor on the paper.

Prompt vs RAG vs fine-tune — the most-asked decision
Open the card in a new tab to read it at full size.

If you learn one decision properly, make it this one. It comes up more than any other, and it also happens to be the decision most often got wrong in real projects.

Match the symptom to the fix

What the requirement says The answer Why
A little extra knowledge — a couple of paragraphs Prompt engineering It fits in the prompt. Cheapest, instant.
A lot of knowledge, or knowledge that keeps changing — reams of documents Retrieval Too much for a prompt. You extend it by adding documents.
A different behaviour, tone or format Fine-tuning It optimises style, not facts.
Facts that change weekly Retrieval Fine-tuning would have to be redone every time they change.

Notice that two of the four rows resolve to retrieval, and they resolve there for different reasons — one about volume, one about change. Volume and volatility both rule out the alternatives.

If the answer really is fine-tuning

The data. The format is JSONL — one JSON object per line. Each line is one example, carrying the system, user and assistant parts of an exchange.

The three methods:

  • Supervised fine-tuning — the default. You provide labelled pairs: this input, that correct output.
  • Direct preference optimisation — you provide a preferred and a non-preferred response, teaching relative judgement rather than a single right answer.
  • Reinforcement fine-tuning — you provide graded or rated outputs.

You can stack them: supervised fine-tuning first, then preference optimisation on top.

The constraints, which are what get examined:

  • It needs a tunable model, in a region that supports tuning.
  • It is slow and costly, and must be redone whenever the underlying needs change.
  • Deploy the result on the Developer tier to test it — pay per token, no service level agreement.
  • Only Foundry Owner can both fine-tune and deploy the result. That role holds data-plane and control-plane permissions, and this job needs both.

That last constraint is a neat cross-check on card 4. If a question describes someone who can fine-tune but cannot deploy what they produced, the role is the answer.

The most reliable distractor on the paper

Fine-tuning to inject knowledge.

It is offered constantly, it sounds sensible, and it is never right. Fine-tuning changes behaviour. Retrieval supplies knowledge. When an option proposes fine-tuning as the way to make a model know something it does not know, eliminate it without further thought and spend the time on the remaining options.

The reason it is worth internalising rather than memorising: this same mistake is made in real programmes, with real budget, by people who then wonder why the model still gets the facts wrong. The exam is testing something that actually matters.