---
title: "Chapter 01: Why Fine-Tune"
description: "What fine-tuning is for: small, durable behavior changes — and why that is different from prompting."
type: lesson
order: 1
chapter: "01-lora-eyes-open"
---

# Chapter 01: Why Fine-Tune

## Objective

Understand what fine-tuning is *for* — small, checkable behavior changes — before you install anything or touch a training config.

This is a **concept-only** lesson: no install gates. Your tutor still uses the interactive flow — explain, then quiz one question at a time. Do not skip to Chapter 02 tooling until you can pass the checks below.

## Concept: The Job

A base model already knows a lot. Prompting steers it for one conversation. **Fine-tuning steers it for every conversation after that.**

You are not trying to upload a codebase into the weights. You are teaching a **small, stable habit** the base model does not reliably have:

| Domain | Example of a small change |
|---|---|
| **Images** | Every portrait of `TOK` has *this* face, not a random similar one |
| **Text style** | Always answer in iambic pentameter |
| **Format** | Always return `{"answer": ..., "confidence": ...}` and nothing else |
| **Agent loop** (later in this course) | Emit a well-formed tool call, read the result, stop when done |

Same idea every time: **one behavior you can verify**, repeated until the model does it by default.

If you cannot say in one sentence what “success” looks like, you are not ready to train. You are ready to write a better task definition.

## Why Not Just Prompt?

Prompting is the right tool when:

- the behavior is easy to describe once
- you can afford the tokens every time
- a slightly wrong answer is fine

Fine-tuning earns its keep when:

- you need the same behavior **every** run (format, protocol, tool-call shape)
- the prompt is already long and still unreliable
- you want a **small local model** to do something a big prompted model does only sometimes
- you will run the loop thousands of times (this course’s flywheel)

Prompting says “please do X.” Fine-tuning makes X the default.

## High Level: How It Works

You start from a frozen base model — the big pile of weights you downloaded. You do **not** retrain all of them.

You train a **small add-on** (in this course, a LoRA *adapter*): a thin set of extra parameters that nudge the base model’s behavior. Think of it as a small patch file, not a rewrite of the app.

- **Base weights stay the same.** Detach the adapter and you’re back to stock.
- **The adapter is tiny** compared to the base — megabytes, not tens of gigabytes — so you can train it on a laptop and keep many variants around.
- **You show examples of the behavior you want.** The adapter absorbs the pattern. Too few examples and too much training and it memorizes the examples instead of learning the habit. You’ll *see* that in the next chapters.

That is enough theory for now. Rank, steps, alpha, and the rest are **controls on how hard and how long you press that patch in**. You will meet them when you run real trainings — first where failure is visible (images), then on text.

## Why This Course Starts With Images

Same kind of change. Different feedback.

- **Image:** “Draw this person.” Overfit → you get the same training photo back. Underfit → face drifts. You know in one glance.
- **Text:** “Always answer in iambic pentameter.” Overfit → fluent nonsense that *looks* fine until you check carefully. Underfit → prose with occasional meter.

Part 1 uses faces and contact sheets so your eyes learn the failure modes. Parts 2–5 use the same idea on text and tools: teach a small behavior, check it mechanically, keep only what passes.

## What Fine-Tuning Is *Not*

- **Not** a substitute for context. Facts about *your* repo belong in retrieval and prompts; they go stale in weights.
- **Not** magic capability. A 1B model will not become Claude because you LoRA’d it. It can become *reliable at a narrow habit* Claude already has.
- **Not** the first step of every project. If a system prompt and good tools solve it, ship that. Fine-tune when the habit has to live in the model.

The rest of this course fine-tunes **agentic behavior** — the loop — not your source tree.

## Before You Install Anything

Pick one sentence of the form:

> After training, the model should always __________, and I can tell in under five seconds whether it did.

That sentence is your north star for Part 1 (images) and Part 2 (toy text task). Tool-calling is the same sentence with a stricter checker.

---

## Check your understanding

Answer in your own words — write it down before opening the key. Your tutor grades against the criteria and generates fresh variants on retries.

**Q1.** In one or two sentences: what kind of thing is fine-tuning good at changing, and what kind of thing should stay out of the weights?

**Q2.** Give one image example and one text example of a “small change” you could fine-tune for. What would “success” look like for each in under five seconds?

**Q3.** At a high level (no jargon required): what stays frozen when you LoRA-train, what gets trained, and why does that matter on a laptop?

**Q4.** Why does this course bother with image LoRA before the coding-agent work?

<details>
<summary>Answer key — attempt every question first</summary>

## Answer key

### Q1

**Model answer:** Fine-tuning is good at durable *behavior* or style habits (format, protocol, a consistent subject). Codebase facts and moving knowledge should stay in context/retrieval, not baked into weights.

**Pass criteria:** distinguishes behavior/habit vs. knowledge/facts; implies or states that knowledge belongs outside weights

### Q2

**Model answer:** Image — always render this person’s face when `TOK` is in the prompt; success = you recognize them at a glance across new scenes. Text — always reply in iambic pentameter (or always valid JSON with fixed keys); success = skim or parse and see the constraint held.

**Pass criteria:** one image + one text; each has a concrete, quickly checkable success condition

### Q3

**Model answer:** The base model weights stay frozen; you train a small adapter (a thin add-on). That keeps training cheap and fast enough for a laptop, and you can attach/detach the patch without replacing the whole model.

**Pass criteria:** base frozen + small trainable piece; at least one practical reason (size, speed, attach/detach, laptop)

### Q4

**Model answer:** Same kind of small behavior change, but image failure modes are obvious (same photo / wrong face). Text failure modes look fluent and waste hours. Calibrate judgment where you can see it, then apply it to text and tools.

**Pass criteria:** visible/fast feedback for images vs. hard-to-see text failures; links that intuition to later text/agent work

</details>

---

[← Part 1 Index](/fine-tune-local-agent/01-lora-eyes-open/) · [Next: Chapter 02 →](/fine-tune-local-agent/01-lora-eyes-open/02-train-an-adapter/)