How do you know a fine-tuned AI model is actually better?

You measure it. Hold out a portion of the client's real examples so the model never sees them during training, score the plain base model on those held-out questions first, fine-tune, then score again on the identical questions with identical scoring. The difference is the lift. Because the only thing that changed is the fine-tune, the improvement is attributable to it.

Does fine-tuning actually improve accuracy, or is the base model already good enough?

It depends on the task and, critically, on how much data you have. On a public benchmark of 510 lawyer-annotated commercial contracts, a base Qwen3-4B extracted short contract fields at 62.2% accuracy. Fine-tuned on 396 examples it reached 83.5-85.4%, a lift of 21.3 to 23.2 points across three runs. The same model trained on only 48 examples produced a lift inside the noise floor, so the amount of data was the deciding factor rather than the model's ceiling.

How much of our own data do we need to fine-tune a model?

Fewer examples than most people expect, but more than a handful. In our contract-extraction measurements, 48 training examples produced no measurable improvement while roughly 400 produced a 22-point gain. The honest answer for any specific case is that it depends on how varied and how consistent the examples are, which is what a paid readiness assessment measures on the client's own corpus.

Why can't you just use a public AI benchmark score?

Public benchmarks measure general ability on standardised tests, not your work. A model that scores well in the abstract can still be mediocre at reading your contracts or following your policies. Public benchmarks are also increasingly targeted during training, so a high score can reflect test preparation as much as capability. The only benchmark that answers your question is built from your own tasks.

Research record 43 of 69

Looking Is Not Using

By Joshua Bolick, Awareness Software Group ~14 min read August 2026

Ongoing research. This is an experimental result from active work, not a settled conclusion. The numbers are what we measured and the method is described so you can judge it, but the programme is still running and later experiments may revise what it means. More about this programme.

In plain English

What we asked. One of our exercises has an unusual property: three quite different approaches score three quite different ways on it. A hand-written rule gets every answer right, our recurrent model gets about six in ten, and a model built the way modern language models are built gets about two in ten. The attention model doing worse than the simpler one is backwards from what most people would guess, and we had never looked into why.

What we found. The exercise works like this: the first word of each sequence tells you how far back to look for the answer, and that distance changes every time. We measured two things in the same runs. How often each model is right, and how much each one actually relies on the word that holds the answer, which we find by changing that word and seeing how much worse the prediction gets. The attention model relies on the right word genuinely and from the very first check we make, just as early as the recurrent model does. It simply never turns that into correct answers.

Why it matters. Watching what its answers resemble over the course of training shows what it does instead. It settles into always copying from a fixed distance -- and different runs settle on different distances -- on an exercise built specifically to punish that. So its problem is not finding the right place to look; it is doing anything useful with what it finds. Two notes on how we checked ourselves. Our measurement could easily have been reading nothing on this kind of model, and that has happened to us before with a different tool, so we ran every measurement a second time deliberately misaligned by one position: it goes flat, which tells us the aligned version is reading something real. And the way we normally identify the moment a model improves gives a confident answer even for a model that never improves at all, which we only noticed because a consistency check half-disagreed. Both versions are reported on the page.

The rest of this page is the technical record: the design, every number, and the limits. It is written for a reviewer, and you do not need it to have understood the result above.

New here? How to read a research record

Start at the verdict. Every record states, before the experiment was run, what result would have made us abandon the idea. That is the "kill test". Then it says whether the test fired. Nothing gets reinterpreted after the fact.
Numbers in square brackets are uncertainty. 23.4 [18.1, 28.7] means our best estimate is 23.4 and the true value is probably somewhere in that range. If a range includes zero, we cannot claim an effect.
Negative results are kept. Roughly half of what is published here says an idea did not work, including several of our own. Those pages are not failures, they are the output. Work that only publishes what worked is not measuring anything.
Read the Limits section. Every record ends with what it does not show. It is the most honest part of any experiment and usually the shortest.
Pro tip: the figures near the top are designed to carry the result on their own. If you read nothing else, read the caption under each one, which says what it shows and what to take from it.

EXPLORATORY. Not a preregistered study. Local CPU, 10 training runs, no GPU, no cost.

Program v2 Bucket N, item N8. Decisive computation: analysis/three_way_separation.py. Output: analysis/three_way_separation.json. Reproduce with python analysis/three_way_separation.py, or re-derive every endpoint with --reuse.

The question

dispatch-copy-8lag is the one substrate here with a three-way separation, and no record had used it. M1 showed a hand-built cache-dispatch scores 1.0000; E1 measured a GRU at 0.62 and a transformer at 0.24, the attention model does far worse than the recurrent one on a task a lookup solves outright.

**Finding the right word, and doing anything with it, are separate abilities.** In this exercise the first word of each sequence says how far back to look, and the distance changes every time. Two models are compared. The first pair of bars is how often each gets the answer right. The second pair measures something different: how much each one actually relies on the word that holds the answer, found by changing that word and seeing how much worse the prediction gets. The attention model relies on the right word -- genuinely, and from the very first check we make -- and still answers correctly less than half as often. It is not failing to look in the right place. Watching what its answers resemble over time shows what it does instead: it settles into always copying from a fixed distance, which is what this exercise is built to punish, and different runs settle on different distances. The recurrent model finds the correct varying rule and stays with it in every run.

Kill test, fixed in advance: the transformer's behavioural trajectory is the GRU's.

Two instruments, both imported rather than rebuilt: N5's dependence probe re-keyed to each example's announced lag, and M2's algorithm agreement.

The instrument check came first, because it has failed here before

This programme's most repeated failure is a null that turns out to be a statement about the instrument. It has already happened on this exact comparison: E3 found F2's decode probe gives a transformer +1.3 steps with 0/5 runs resolvable, a constant offset wearing a lead's clothes. So every architecture carries N5's mis-keyed arm.

architecture	aligned peak at the true source	mis-keyed	verdict
GRU	`+0.4926`	`+0.0453`	reads the model
transformer	`+0.2223`	`+0.0324`	reads the model

The dependence probe works on the transformer. A flat result here would have been a finding rather than a broken instrument, and it is not flat.

Result: they look alike where you would expect them to differ, and differ where you would expect them to agree

	GRU	transformer
final accuracy	`0.580` `[0.566, 0.594]`	`0.246` `[0.236, 0.257]`
runs that transitioned	5/5	0/5
true source ranked first from	step `10` (5/5)	step `10` (4/5), `20` (1/5)
peak dependence on the true source	`+0.493` `[+0.468, +0.518]`	`+0.222` `[+0.209, +0.236]`

The transformer finds where to look exactly as early as the GRU: the first evaluation, in essentially every run, and its dependence on the correct, per-example source is real and survives the mis-keyed control. It then never converts that into accuracy. It does not transition in any run, and finishes at 0.246.

The algorithm it comes to resemble is the difference.

stage	GRU	transformer
10%	`cache-dispatch`	`cache-4`, `cache-dispatch`
25%	`cache-dispatch`	`cache-2`, `cache-3`, `cache-dispatch`
50%	`cache-dispatch`	`cache-2`, `cache-dispatch`
100%	`cache-dispatch` (5/5)	`cache-2`, `cache-3`

The GRU resembles the correct dispatching algorithm at every stage, in every seed. The transformer converges on fixed-lag caches instead, and the seeds do not even agree on which one. It ends up looking like "always copy from two back" or "three back" on a task whose whole point is that the distance changes per example.

The kill test does not fire. The two trajectories are not the same.

What this says

The transformer's failure here is not a failure to attend to the right position. It attends there from the first evaluation, measurably, with a validated instrument. The failure is downstream: it does not turn a correct, varying pointer into a correct, varying read, and settles into a fixed habit instead.

That is a more specific claim than "transformers do poorly on this task", and it is the kind of statement the three-way separation was there to buy. It also fits M1 from the other side: the task is solved outright by a lookup that is told where to look, and the transformer's difficulty is precisely in the "told where to look" step being something it must do per example.

The endpoint definition, which had to be split in two

The GRU's midpoint first read 178.0 [167.6, 188.4] against N5's published 158.3 [146.1, 170.6], overlapping only at the margin. The cause was not the runs. N5's probe was imported but its midpoint definition was not, and the two differ: N5 takes floor and ceiling as the run's min and max with no eligibility gate; this pilot took them as the mean of the first and last three readings, and refuses to report anything unless accuracy gained 0.3.

Recomputed on N5's own definition the GRU reads 158.0 [141.8, 174.2], reproducing N5 almost exactly.

And the gate is not optional, because of the other arm. On N5's definition the transformer, which never learns anything, returns a confident midpoint of 40.0 in every single seed, because a noisy flat curve has a min and a max like any other.

So both are computed and both are reported: the anchor is checked on N5's definition, the only like-for-like comparison available, and every substantive statement uses the gated one.

An endpoint that behaves well on runs which all learn can become actively misleading the moment one arm does not. N5 had no non-learning arm, so it never needed the gate. This is the same class of error as K3's, importing a record's prose instead of its code, caught here by an anchor that only half-agreed.

Verdict

The kill test does not fire. The architectures differ: 5/5 against 0/5 transitions, and different terminal algorithms.
The instrument is valid on both, against the mis-keyed control, so the transformer's readings are readings.
The transformer locates the true source as early as the GRU (step 10) and with real dependence (+0.222), then fails to use it, converging on fixed-lag caches that the seeds do not agree on.
The anchor reproduced on N5's own definition (158.0 against 158.3), and the definitional split is documented rather than smoothed over.

Limits

Five seeds, one task, one width, one learning rate, one transformer configuration: E1's, with n_head=4, n_layers=1, dim_feedforward=96. A different head count or depth might dispatch perfectly well, and nothing here says otherwise.
1,200 steps. E1 ran 2,000 and measured 0.24; this measures 0.246 at 1,200, so the transformer is not obviously still climbing, but it is not run to exhaustion either.
"Never transitions" is relative to a 0.3 gain. The transformer improves from chance to 0.246, which is real learning: it is a failure to reach the regime the rest of this programme studies, not a failure to learn at all.
Peak dependence is less than half the GRU's (+0.222 against +0.493). The instrument says this is not noise; it does not say the two dependences are the same kind of thing.
The agreement candidates are hand-chosen. A model resembling none of them still reports a best match, and the shuffled control bounds how much of that is structural without supplying a missing candidate.
This does not separate architecture from objective. Both arms train on the same loss, and the standing confound recorded as I5 is untouched.

Terms on this page

Every piece of vocabulary this record uses, in plain language. Generated from the text above, so it cannot drift out of step with it.

accuracy: The fraction of answers a model gets right on questions it was not trained on.
architecture: The blueprint of a model: what components it has and how they connect. Two models can be the same size and completely different architectures.
confound: A second explanation you did not control for. If bigger models both learn faster and score higher, then 'fast learners score higher' may be entirely about size and not about speed.
gated: A design where the model has explicit internal switches deciding what to remember and what to discard at each step. GRUs and LSTMs are gated; plain recurrent networks are not.
GRU: Gated Recurrent Unit. A compact design for processing sequences one item at a time, with internal switches controlling what it keeps in memory.
kill test: A condition written down before running the experiment that says what result would make us abandon the idea. Fixing it in advance is what stops a disappointing result being reinterpreted as an encouraging one.
learning rate: How big a step training takes each time it updates the model. Too small and nothing happens; too big and it never settles.
probe: A small separate model trained to read information out of a bigger model's internals, used as a measuring instrument rather than as a product.
recurrent: A design that reads a sequence one item at a time, carrying memory forward. The main alternative is attention, which looks at everything at once.
seed: The number that fixes all the randomness in a training run. Same seed, same run. Running several seeds is how you tell a real effect from a lucky one.
transformer: The architecture behind most modern large language models. It uses attention to look at every part of the input at once, rather than reading in order.
width: How many internal numbers a model uses at each layer. The usual way we vary model size in these experiments.