# Fine-tuning (/academy/fine-tuning)



You already have a model that can talk. **Fine-tuning** is when you keep training it on *your* examples until a habit sticks.

Not a new encyclopedia. A new reflex.

You collect pairs: this kind of ticket, this kind of reply. This kind of user message, this exact [JSON](/academy/json) shape. You run a training job. Afterward the model reaches for your format, your tone, your refusals, without you restating the house rules every turn. The [system prompt](/academy/system-prompt) is still cheaper. Fine-tuning is what you reach for when the prompt is not enough and the same shape repeats a thousand times.

Hold it next to [RAG](/academy/rag), because "make it know our stuff" is usually that fork:

* **Facts that change** — prices, inventory, last week's numbers, the FAQ you edited at 2 a.m. — do not belong in weights. Retrieval owns those. Running another training job every time a price moves is a bad weekend.
* **Shape and style** — always sound like support, always emit this schema, always refuse that class of ask — can live in a fine-tune. You are teaching habits, not today's spreadsheet.

The costs are real. You need a pile of good examples, a training run, and an [eval](/academy/eval) set so you can tell "it sounds like us" from "it broke the easy cases." A bad fact baked into the run comes back later as a confident [hallucination](/academy/hallucination) you cannot fix by editing a page. You train again.

At a hackathon, skip it. A tight system prompt plus RAG plus a few [tool calls](/academy/tool-calling) will beat a rushed fine-tune. Ship the habit in instructions first. Bake it into weights when the product *is* the habit.

**What this unlocks**

You stop treating "custom model" as the default. You pick the cheap lever: prompt for rules, retrieval for facts, fine-tune only when the *way it writes* is the product.