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 50 of 67

We Tested Someone Else's Prediction

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. A paper published this year asks why models pick up on things that cannot possibly help the answer they are currently being asked for. It offers three explanations, all of them about how the training signal travels through the model, and it makes a prediction about models built the way ours are: they read one word at a time rather than looking at everything at once, so they should barely do this at all. We had already measured ours doing it heavily -- about half of what our model's prediction leans on is words that carry no information about the answer.

What we found. So we tested the explanation the paper leans on hardest. It blames information flowing backwards from later words, and we can cut that: train the model so the signal is only allowed to reach back a limited distance, and shrink that distance step by step until it is almost nothing. It made no difference whatsoever. At every distance from sixteen words down to one, the model leans about half its attention on words that cannot help.

Why it matters. The part we want to be careful about is what this does and does not settle. It rules out one of the three explanations, not the paper's argument. The other two are untouched, and one of them -- the fact that the same internal machinery is reused for every word -- cannot be switched off in a model built like ours without rebuilding it differently. That is now the next experiment on our list. What makes the result readable at all is a check on the side: the models given only one or two words of reach never learn the task properly, exactly as the task's structure says they should not, which tells us the cut was genuine rather than cosmetic. Running someone else's prediction against your own measurements is cheap and it is worth doing -- this took an afternoon on a laptop.

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, 25 training runs, no GPU, no cost.

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

The question, and why it comes from outside

Understanding the Emergence of Seemingly Useless Features in Next-Token Predictors (arXiv 2603.14087) identifies three gradient pathways that let a model represent features which do not help the prediction being scored:

**How much the prediction leans on words that cannot help it.** A recent paper argues that models pick up on things that cannot help their current prediction because of a specific route the training signal takes -- information flowing backwards from later words -- and predicts that models built like ours, which read one word at a time, should barely do this. We had already measured ours doing it heavily. So we cut that route, progressively: each bar allows the training signal to reach back a different distance, and the leftmost cuts it off almost entirely. Cutting the route makes no difference at all. Whether the training signal can reach back sixteen words or only one, the model leans about half its attention on words that carry no information about the answer. So that route is not the explanation, though two others the paper describes remain untested here. The check that makes this readable is on the horizontal axis: models allowed only one or two words of reach never learn the task properly, exactly as the task's structure predicts, which confirms the cut was real and not cosmetic.

direct learning, the ordinary gradient from the current position;
pre-caching, gradient from later positions flowing back into an earlier representation;
circuit sharing, gradient arriving at shared parameters from every position at once.

It tests these on transformers and OthelloGPT, and makes an explicit prediction about an architecture it does not run: recurrent models, "lacking multi-position attention, would show severely impaired learning of NTP-useless features", with direct influence dominating.

M3 measured a GRU spending about half its dependence on exactly such tokens. On synthetic-delayed-copy-v1 the answer at position t sits at offsets 3 and 7; a solved model's dependence on the other six offsets was 0.479 [0.450, 0.508] of the total. Either the prediction does not hold for recurrent networks, which do have pre-caching, through backpropagation through time, or "useless" means something narrower than M3 measured.

Kill test, fixed in advance: the useless-offset dependence is unchanged under truncation.

Design

The paper's own test is myopic training, which blocks the pre-caching gradient. Its recurrent analogue is truncated backpropagation through time: run the recurrence in segments and detach the hidden state between them, so gradient from any position reaches back at most window steps. window = 1 blocks pre-caching completely; window = 16 is the sequence length and is ordinary training.

The measurement is M3's probe, imported rather than reimplemented, corrupt one input token k places before a scored position and see how far accuracy there falls, with corruptions drawn once per seed and reused at every reading.

Two guards, both in code before any arm ran.

Truncation must be a no-op at full window. The segmented forward is asserted equal to the model's own forward before the sweep. Measured gap: 0.0 exactly. An implementation that quietly changed the forward pass would have made every arm incomparable and the sweep would have measured the bug.
A window that cannot do the task has no dependence to report. Any window failing to clear 0.20 above measured chance is reported as failed rather than as having low useless-token dependence: a model that learned nothing depends on nothing, which is a different finding.

Anchor: the full-window arm must reproduce M3's valid share and accuracy midpoint by interval overlap.

Result: the dependence does not move

Five windows, five seeds each, 400 steps, everything else identical to M3.

gradient horizon	learned	final accuracy	dependence on useless tokens	effective context	transition
1	5/5	`0.3118` `[0.2962, 0.3275]`	`0.5322` `[0.4642, 0.6003]`	`4.26`	`80.0`
2	5/5	`0.2918` `[0.2786, 0.3050]`	`0.5270` `[0.4500, 0.6039]`	`3.92`	`62.0`
4	5/5	`0.8805` `[0.8488, 0.9121]`	`0.4765` `[0.4535, 0.4996]`	`3.61`	`92.0`
8	5/5	`0.9874` `[0.9837, 0.9911]`	`0.4742` `[0.4346, 0.5138]`	`3.18`	`88.0`
16 (ordinary)	5/5	`0.9840` `[0.9816, 0.9863]`	`0.4929` `[0.4700, 0.5157]`	`3.24`	`90.0`

The kill test fires. Every interval overlaps every other. Cutting the gradient horizon from 16 steps to 1, blocking pre-caching entirely, leaves the dependence on tokens that cannot help the prediction at about half the total, exactly where M3 found it.

The anchor reproduced: the full-window arm's valid share 0.5071 [0.4843, 0.5300] and midpoint 90.0 overlap M3's [0.450, 0.508] and [82.4, 91.0].

Truncation is doing what it should, which is the positive control this needed. Final accuracy tracks the horizon exactly as the task's structure predicts: the answer sits 3 places back, so a horizon of 1 or 2 cannot teach the recurrence to carry it and those arms stall around 0.30, while a horizon of 4 reaches 0.88 and 8 reaches 0.99. The manipulation is real and its size is calibrated by the task.

What this does and does not establish

It rules out one pathway of three, and that is the honest statement. Truncation blocks pre-caching. It does not block circuit sharing, the recurrent weights are still shared across every timestep, and every position still contributes gradient to them, and it does not touch direct learning. So the finding is that pre-caching is not the source of the useless-token dependence in this model, not that the paper's framework is wrong.

Two readings survive, and this record cannot separate them:

the prediction fails for recurrent networks, because circuit sharing supplies what pre-caching supplies in a transformer; or
M3's quantity is not an NTP-useless feature in the paper's sense: it may be sensitivity to the task's periodic structure arising from direct learning, which would make the two measurements about different things despite looking alike.

Separating them needs a circuit-sharing ablation, which in a recurrent network means untying the weights across time: a different architecture, not a different training run. That is written into the backlog as N10.

The stalled arms are informative rather than a confound. Windows 1 and 2 reach only 0.29–0.31 accuracy, so their rows compare a barely-working model against a solved one. They still show the same useless-token share. A model that has barely learned the task spends the same fraction of its dependence on tokens that cannot help it as one that has solved it.

Verdict

The kill test fires. Useless-token dependence is 0.47–0.53 at every gradient horizon from 1 to 16, with every interval overlapping.
The anchor reproduced, so this is M3's measurement on M3's configuration.
The manipulation is real and calibrated: accuracy tracks the horizon in the way the task's 3-step dependency predicts, and the segmented forward is bit-identical to the ordinary one at full window.
One pathway of three is ruled out. Pre-caching does not explain the dependence.

Limits

This blocks pre-caching only. Circuit sharing is untouched and is the obvious remaining candidate; direct learning is untouched and is the other. A negative on one pathway is not a negative on the framework.
Five seeds, one task, one width, one lag, one learning rate. The periodic structure that makes offsets 3 and 7 both valid is a property of this task's construction, and the useless-token dependence may be too.
Windows 1 and 2 do not solve the task. Their shares are measured on models at 0.29–0.31 accuracy. The clean comparison is windows 4, 8 and 16, and it agrees.
"Useless" is defined by the scored position only. A token at offset 4 is the answer for a different scored position, so a model that is correct everywhere has a reason to represent it, which is precisely the ambiguity the paper's own framework is about, and precisely why this record does not claim to have refuted it.
Truncated BPTT is not myopic training. It is the closest recurrent analogue, and the analogy is an argument rather than an equivalence.

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.
gradient: The direction and amount by which each of a model's internal numbers should change to do slightly better. Training is repeatedly following it.
GRU: Gated Recurrent Unit. A compact design for processing sequences one item at a time, with internal switches controlling what it keeps in memory.
hidden state: The model's working memory: the internal numbers it carries from one step of a sequence to the next.
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.
parameters: The adjustable numbers inside a model. Training is the process of setting them. Model size is usually quoted as a count of these.
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.