Prompting, retrieval, or fine-tuning

Sooner or later, everyone who uses AI seriously hits the same wall. The answers are close, but not right. Too formal. Missing a fact. Out of date. Wrong format, again. And somewhere online, someone says the fix is to "train your own AI."

Sometimes that is true. Most of the time it is not. This lesson lays out the three ways to change what a model does, what each one is actually good at, and how to look at a problem and tell which one it needs. It is a map of the territory, not a build guide. No code, no setup, just the ideas you need to judge a claim when you hear one.

Three levers

Picture a new hire at a St. George gutter company. Smart, well read, knows how to write. Three things you could do to make that person better at the job:

• Give clearer instructions. "Keep quotes under 150 words, friendly, and always mention the five-year warranty."
• Hand them the binder. The price sheet, the warranty terms, the service area. They look things up instead of guessing.
• Send them through months of practice. Hundreds of worked examples until the way you do things becomes second nature.

Those are the three levers, in plain clothes.

Prompting means changing the instructions: what you type in the chat, plus any standing instructions the tool reads before every chat. You already know the basics from everyday prompting, and the standing version is the whole System Prompting module. Nothing about the model changes. You change what it reads.

Retrieval means handing the model the right facts at the moment it answers. The tool searches a store of documents, or the web, pulls out the few passages that matter, and puts them in front of the model next to your question. That is RAG, covered in its own lesson, and the search underneath it runs on the embeddings from the first lesson in this module. Again, the model itself does not change. It gets a better reading packet.

Fine-tuning means extra training. You take a model that has already been through the normal training stages and train it a little more on your own examples: here is an input, here is the output we want, a few hundred or a few thousand times. This is the only lever that changes the model itself. Google's cloud docs for Gemini put it plainly as of October 2026: fine-tuning "adapts model behavior with a labeled dataset," meaning examples paired with the right answer.

One way to keep them straight: prompting changes what the model is told, retrieval changes what the model can see, and fine-tuning changes who the model is.

What each one fixes

Each lever is good at one kind of problem and weak at the others. Matching the problem to the lever is most of the skill.

Prompting fixes format, tone, and rules. Too long, too stiff, wrong structure, forgets to include the phone number, writes for the wrong reader. These are all problems of not knowing what you want, and the model learns what you want by being told. It is instant, free, and easy to undo. OpenAI's own guide to model optimization, as of October 2026, points out that good prompting "may be all you need" before you consider anything else.

Retrieval fixes missing and fresh facts. Your prices, your policies, your inventory, this week's news. The model never saw any of it during training, so no amount of clever wording will conjure it up. Retrieval puts the facts in front of the model where it can read them. And because the facts live outside the model, you can update them in seconds. Change the price sheet and the very next answer uses the new price.

Fine-tuning fixes consistency at scale. When a narrow task runs thousands of times, and you need it done the same way every time, training can bake the pattern into the model so each request can be short. OpenAI's guide lists the kinds of jobs where it helps most, as of October 2026: sorting things into categories, nuanced translation, producing a specific format, and correcting a model that keeps failing to follow instructions. Google's list is similar: classification, summarization, pulling answers out of text, and chat. Notice what is not on either list: "teach the model our facts."

Try sorting a few real-looking problems yourself. Tap a problem, then tap the lever you would pull.

The pattern you probably noticed: most problems are prompting or retrieval. Fine-tuning wins in one specific shape of situation, a narrow job, repeated at high volume, with a large pile of past examples to learn from. That shape is real, but it is rare for an individual or a small business using a chat app.

The levers also stack. A serious AI tool usually has all three at once: the maker fine-tuned the model, the tool has standing instructions, and it retrieves your files when you ask about them. The question is never "which one, forever." It is "which one fixes this particular problem."

Why fine-tuning rarely teaches facts

This is the part that surprises people, and the reason so many "train it on our documents" projects disappoint.

It seems obvious that if you train a model on your employee handbook, it will know your employee handbook. But training does not work like saving a file. During training, the model is not storing your sentences anywhere it can look them up later. It is nudging millions of internal settings so that its guesses about the next word lean a little more toward the examples it saw. What gets nudged most easily is the stuff that repeats across many examples: the tone, the structure, the vocabulary, the way answers start and end. A single fact that appears once or twice barely moves anything.

Google's docs hint at this, describing fine-tuning as especially useful where a field's "language or content" differs from what the model normally sees. Language is a habit. The model gets better at talking like your field. That is not the same as reliably remembering your field's details.

What fine-tuning costs

The price of a training run is only one of the costs, and usually not the biggest. The real costs are the ones around it.

• Examples. You need a pile of good input and output pairs, written the way you actually want answers written. As of October 2026, OpenAI's guide says the minimum it accepts is 10 examples, but it reports seeing improvements at 50 to 100 and suggests starting with 50 well-crafted ones. Gathering and cleaning even that many, consistently, is real work. Bad examples train bad habits just as efficiently as good ones.
• Testing. You have to check whether the tuned model is actually better, which means a fair test set you did not train on. OpenAI's guide is blunt about the order: build the tests first, then invest in fine-tuning. That kind of testing gets its own lesson later in this module.
• Freezing. A tuned model is a snapshot of your examples on the day you trained it. If your style or your process changes, you train again. Compare that with a prompt, which you can edit in a minute.
• Availability. Not every model can be fine-tuned, and the options change. As of October 2026, Google's Gemini API documentation says there is no model available for fine-tuning in the Gemini API or AI Studio, and points to its enterprise cloud platform instead.

None of this makes fine-tuning bad. It makes it an engineering project, with ongoing upkeep, instead of a setting you flip. That is a reasonable trade for a company running one narrow task a hundred thousand times a month. It is a poor trade for most everyone else.

Why most people never need it

Here is the honest order of operations most practitioners follow, and the one both OpenAI and Google gesture at in their own guides.

Start with prompting. It is free, instant, and reversible. A surprising share of "the AI is not good enough" complaints turn out to be "the AI was never told what good looks like." Clear instructions plus one or two examples of the output you want close most of that gap.

Add retrieval when facts are missing. If the model keeps making things up about your own business, the problem is almost never its writing. It is that it has never seen the facts. The good news is that you are probably already using retrieval without calling it that. Uploading a file to a chat, adding documents to a project, or letting the app search the web are all retrieval.

Consider fine-tuning last, and only when prompting and retrieval both work but something about scale, speed, or consistency is still not good enough. By the time you get there, you will have the examples and the tests you need anyway, because you built them while trying the first two.

Try this yourself

You can watch two of the three levers work in the chat app you already use. You cannot fine-tune anything from a chat window, and you do not need to. Start with the facts lever. Paste this:

What is the cancellation fee at Zephyr Mesa ATV Rentals in Hurricane, Utah, for a booking cancelled less than 48 hours out? If you do not know for certain, say so.

That business is made up, so watch whether the model admits it does not know, or invents a fee that sounds reasonable. Either way, then give it the fact:

Here is the policy: "Cancellations more than 48 hours before pickup get a full refund. Cancellations inside 48 hours forfeit the $75 deposit." Now answer the same question, and quote the sentence you used.

That is retrieval done by hand. You fetched the page, the model read it. Now try the instructions lever on the same answer:

Rewrite that answer as a text message to a customer: two sentences, friendly, no exclamation points, and end by asking if they want to reschedule instead.

Notice what changed each time. The second prompt changed what the model knew. The third changed how it said it. Neither one changed the model. Both took seconds. Keep that in mind the next time someone says a problem can only be fixed by training.