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. (Between the earlier study and this one, the serving software moved to a new version. 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.9%	19.0%	23.0
After training	46.2%	23.4%	22.8

Training worked. It just lifted both numbers by about the same amount — 4.2 and 4.4 points — leaving the distance between them where it was: a change of −0.2 points, one question out of 496. The model learned more. It did not become detectably 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 (in net rates: 5.2 points more right answers, 14.5 more silent wrong ones).

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.

114 questions were unsteady before training and 113 after. Training shuffled the deck thoroughly (151 of the 496 questions changed category, and 191 changed how many of their ten tries were right) while the unsteady pile shrank by a single question.

The bigger model, prompted and given no fine-tuning of mine, has only 69. In this one comparison, the larger model was steadier than more examples made the small one.

The decision this actually informs

A 7-billion model has more than twice the parameters of a 3-billion one and needs more memory to serve, 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? (10 tries)	Right on one try	Can I depend on it?
Bigger 7B, prompted	50.0%	43.0%	36.1%
Trained 3B	46.2%	34.9%	23.4%

On "can it?" this study can't tell them apart: the trained 3B is 3.8 points behind, within chance. That is the comparison that makes the cheaper model look like a fair swap. But on a single try, the number a one-shot leaderboard reports, it is already 8.1 points behind, and the stricter the measure, the wider the shortfall.

On dependability they are nowhere near equal: 12.7 points apart. 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 close on a ten-try capability score costs about a third of the answers you could actually rely on (179 dependable questions against 116), and an evaluation that stops at that score would not 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, measure a bigger model alongside 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 all 434 of its weight tensors byte-for-byte against the published original, plus 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 resampling the questions 10,000 times.
• All 9,920 scored attempts are published, so anyone can recompute every number without a GPU.
• The prediction was written down before training, in the project plan, with the rule that would decide it. The result supported neither hypothesis, and that 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.