Does Fine-Tuning Buy Reliability?

The question this picks up

My previous study found that an AI writing database queries often disagrees with itself: ask the same question ten times and you get a mix of right and wrong answers. The obvious next move is the one every team reaches for — train the model on your own correct examples. Everyone expects that to make it steadier.

Nobody seems to have measured whether it does. So I did.

What I did

I took a free 3-billion-parameter AI model and trained it on 5,851 real question-and-query pairs on my own home graphics card. Then I asked it 496 questions, ten times each — and asked an untrained copy of the same model exactly the same questions the same way.

That untrained copy matters more than anything else here. Without it, any change I measured could have come from the training or from a dozen invisible things in my own setup. (Halfway through the study the serving software updated itself. That alone could have faked a result.)

What I found

Two numbers, from the same ten answers per question:

• Can it? — did at least one of ten tries get it right
• Can I depend on it? — did all ten get it right

	Can it?	Can I depend on it?	The gap
Before training	41.7%	19.0%	22.8
After training	46.2%	23.4%	22.8

Training worked. It just lifted both numbers by the same amount — 4.4 points each — leaving the distance between them untouched. The model learned more. It did not become more dependable. The honest version of that claim: a change smaller than about 4.5 points would have been too small for a study this size to see, so this is no change detected, not proof of no change.

The part that should worry you

Scoring answers right or wrong hides something important. A wrong answer arrives in one of two ways. Either the database rejects the query — your program gets an error it can catch and retry. Or the query runs perfectly and hands back a tidy table of the wrong numbers, with no error, no warning, and nothing for your code to notice.

Training cut crashes almost in half — from 38% of attempts to 18%. That looks like a clear win, and on any error dashboard it would be one.

But only a quarter of those rescued attempts became correct answers. The rest became queries that run fine and return the wrong rows, which went from 32% to 47%.

Training taught the model what a valid query looks like — real column names, sensible joins, the house style of the examples — much faster than it taught the model to answer the question. It became fluent before it became right. For a team, that is a trade of failures you can see for failures you cannot, at roughly three to one.

Where the unsteadiness actually lives

Most questions are settled: the model either always gets them or never does. The wobble comes from a middle band — and that band is the thing training was supposed to fix.

113 questions were unsteady before training and 113 after — not roughly, exactly. Training shuffled the deck thoroughly (190 of the 496 questions changed category) without shrinking the unsteady pile at all.

The bigger model, with no training whatsoever, has only 68. On this evidence, steadiness is something you get from a larger model, not from more examples.

The decision this actually informs

A 7-billion model costs about twice as much to run as a 3-billion one, so "train the small one instead" is a real budget proposal. I could test it directly, because my earlier study had already measured that exact 7B on these exact questions.

	Can it?	Can I depend on it?
Bigger 7B, prompted	49.8%	36.1%
Trained 3B	46.2%	23.4%

On the benchmark score they are a tie — the difference is within chance. That is the number a team comparing models would see, and on its own it justifies switching to the cheaper model.

On dependability they are nowhere near equal. There are 92 questions the 7B gets right all ten times that the trained 3B does not, against 29 the other way.

So the swap that looks free on a leaderboard costs a fifth of the answers you could actually rely on, and no ordinary evaluation would have told you.

What this means if you build with AI

• Training on your own data raises scores. Do not assume it raises consistency. Measure it.
• Watch what your errors turn into. A falling error rate can mean failures went quiet, not away.
• Keep an untrained copy and measure it too. It is the only way to know the improvement came from your training and not from something else that changed.
• If you need the same answer every time, try a bigger model before more examples.

How the numbers were made trustworthy

• The untrained comparison is provably the same model. I rebuilt it through my own pipeline and checked it byte-for-byte against the published original — every internal block and every setting. That check caught four differences first, each of which would otherwise have looked like an effect of training.
• The model was never trained on the test. Training and test share no databases and no questions, checked automatically, with the build refusing to run otherwise.
• Correctness is decided by running the query, not by an AI grading an AI.
• Every difference is checked against chance by reshuffling the questions 10,000 times.
• All 9,920 attempts are published, so anyone can recompute every number without a GPU.
• The prediction was written down before the result. It was wrong, and it is published as written.

Where it fits

"Right every time" comes from τ-bench, a benchmark for customer-service agents, and researchers have applied it to text-to-SQL. Fine-tuning small models for this task is a crowded field — measured on capability. This adds the missing half: what fine-tuning does to reliability, with an untrained control, and what it does to the visibility of the failures that remain.

The full plain-language write-up, the technical method, the training run and every raw attempt are in the repository.