Why everyone's fine-tuning now (and most people shouldn't)

Why everyone's fine-tuning now (and most people shouldn't)

Last issue was about why fine-tuning suddenly got cheap — LoRA turned a multi-GPU, multi-day research project into an afternoon on a single rented GPU. The predictable result: fine-tuning is now on almost every product roadmap, usually as the answer to "the model isn't doing what we want."

Here's the catch. For a large share of those projects, fine-tuning isn't the fix. It's an expensive, slow way to discover that the actual problem was somewhere else entirely.

Two different problems, one wrong solution

Almost every "the model isn't doing what we want" complaint is one of two very different problems, and they need opposite fixes:

Problem one: the model doesn't know something. It's missing facts — your product details, your latest pricing, a customer's history, last week's policy change. No amount of fine-tuning reliably fixes this. Fine-tuning bakes patterns into weights; it doesn't give a model a reliable lookup table, and it definitely doesn't help with information that changes weekly. This is a retrieval problem — the territory Issue 002 covered.

Problem two: the model knows the answer but won't deliver it the way you need. Wrong tone, wrong format, ignoring your output schema, refusing when it shouldn't, being verbose when you need terse. This is a behavior problem — and it's the one fine-tuning is actually good at.

The expensive mistake is running a fine-tuning project to solve problem one. Teams collect thousands of examples, spend a weekend training, deploy the new model — and the hallucination rate on "what's our refund policy" barely moves, because the model still doesn't have the current policy. It just learned to sound more confident while being wrong in a more specific way.

The minimum viable fine-tune

If you've genuinely got a behavior problem, the next mistake is over-collecting. The instinct is "more data = better model," so teams spend weeks scraping together tens of thousands of loosely-related examples before training anything.

In practice, a few hundred carefully chosen, carefully checked examples that look exactly like your real production inputs and outputs will get you further than ten thousand examples scraped from old logs with inconsistent quality. The model is learning a narrow pattern — formatting, tone, a specific task shape — and a small, clean dataset teaches that pattern more reliably than a large, noisy one. More on why this works in this issue's Paper Trail.

The practical version: write (or curate) 100-300 input/output pairs that represent exactly what you want, by hand if necessary. That's a few days of focused work, not a data engineering project — and it's the highest-leverage few days you can spend before touching a training run.

The eval you can't skip

A fine-tuned model can get better at your target task and quietly get worse at everything else — a well-known failure mode sometimes called catastrophic forgetting. A model fine-tuned hard on "respond in this JSON schema" can lose some of its general reasoning sharpness on tasks outside that schema.

This is where the eval-set generator from Issue 004 earns its keep twice: once on your target task (did fine-tuning actually help?) and once on a broader sample of your other production tasks (did it quietly hurt anything else?). Run both, before and after, through the same harness from Issue 005's Tool Drop so the comparison is apples-to-apples. If you only check the metric you were optimizing for, you'll miss regressions until a user finds them.

When to skip fine-tuning entirely

Before committing to a training run, try the cheap version first: put 3-5 of your best examples directly into the prompt as few-shot demonstrations. Few-shot prompting solves a surprising fraction of "behavior" problems with zero training, zero infrastructure, and the ability to change your mind in the next deploy instead of the next training run.

If few-shot gets you to "good enough," ship that. Fine-tuning is for when you've outgrown what fits in a prompt — a behavior that needs to be consistent across thousands of calls, or a format too rigid for occasional drift. It's a real tool. It's just not the first one to reach for.

• 01 Hosted fine-tuning platforms now let teams skip GPU infrastructure entirely — upload a dataset, kick off a LoRA run, and get back a serving endpoint, no cluster management required.
• 02 A few hundred carefully curated examples routinely outperform tens of thousands of noisy ones — for narrow behavior changes, dataset quality dominates dataset size.
• 03 Catastrophic forgetting is real and easy to miss — a model fine-tuned hard on one task can quietly regress on others; broad before/after evals catch what narrow ones don't.
• 04 Data curation, not compute, is now the bottleneck — the GPU bill for a LoRA run is often smaller than the cost of the engineer-days spent building the training set.
• 05 If 3-5 few-shot examples in your prompt solve the problem, you don't need a training run — few-shot is the cheapest fine-tuning alternative, and the right default first move.

This week's prompt is a readiness check — it forces the knowledge-vs-behavior diagnosis from this issue before you commit to a training run, and gives you a curation and eval plan if fine-tuning is actually the right call.

You are helping me decide whether fine-tuning is the
right fix for a problem I'm having with an LLM-based
feature, or whether I should look elsewhere first.

I will give you:
1. A description of what's going wrong
2. Example(s) of a bad output vs. what I wanted instead
3. Whether the issue involves missing/outdated information
   or a wrong format, tone, or behavior
4. What I've already tried (better prompting, few-shot
   examples, retrieval, none of the above)

Based on this, do the following:

1. DIAGNOSIS
   Classify the problem as primarily a KNOWLEDGE issue
   (the model lacks information) or a BEHAVIOR issue
   (the model has the information but won't deliver it
   the way I need). Explain your reasoning.

2. RECOMMENDATION
   - If KNOWLEDGE: explain why fine-tuning won't reliably
     fix this and recommend retrieval/context-based fixes
     instead.
   - If BEHAVIOR: check whether few-shot prompting (3-5
     examples in-context) could plausibly solve it before
     recommending fine-tuning.
   - Only recommend fine-tuning if the behavior is narrow,
     needs to be consistent at scale, and few-shot is
     impractical (e.g. too many examples needed, or
     latency/cost-sensitive).

3. IF FINE-TUNING IS RECOMMENDED
   - Describe the minimum viable dataset: how many examples,
     what they should look like, and how to keep them
     high-quality rather than high-volume.
   - Describe an eval plan that checks both the target
     behavior AND a broader sample of unrelated tasks, to
     catch regressions.

Be direct — if the honest answer is "don't fine-tune,
do X instead," say so clearly.

What's going wrong:
[DESCRIBE THE PROBLEM]

Bad output vs. desired output:
[PASTE EXAMPLE(S)]

Knowledge issue or behavior issue (if known):
[DESCRIBE OR SAY "NOT SURE"]

What I've already tried:
[PROMPTING / FEW-SHOT / RETRIEVAL / NONE]

If the diagnosis comes back "behavior, and few-shot won't cut it," the eval plan it gives you plugs straight into Issue 004's eval-set generator and Issue 005's OpenRouter setup — diagnosis to dataset to verdict, without a wasted training run.