Basis Lab

Answers · Putting a model into service

How can I tell if a prompt change actually helped or if I just got a lucky answer?

In shortCompare two versions on the same written set of cases, before and after, and call a change real only when it beats the wobble of that set.

A prompt change helped only if it raises the pass rate on a fixed set of cases that you ran before and after, by more than the wobble of that set. One impressive answer after the change is not evidence, because that answer is the case the change was aimed at. The apparatus is one written file: thirty to a hundred inputs, each with a note saying what a good answer has to contain. The set must be fixed before either run, so the two runs are comparable, and it must include the awkward inputs, an empty one and an angry one among them, because ordinary traffic cannot detect a change. The same grading method is applied to both versions, whether a person reads the answers, a program checks a property, or a model checks each requirement.

n=a(1−a)w2n = \frac{a(1-a)}{w^{2}}

How many cases

The number of cases is set by the difference you want to see. For a rate near eighty per cent and a wobble of four points, put a=0.8a=0.8 and w=0.04w=0.04: n=0.8×0.2/0.042=0.16/0.0016=100n=0.8\times0.2/0.04^2=0.16/0.0016=100. For a wobble of two points, the same numerator is divided by 0.022=0.00040.02^2=0.0004, giving 0.16/0.0004=4000.16/0.0004=400. The denominator is squared, so halving the wobble quadruples the cases. At twenty cases and a rate near eighty per cent the wobble is w=0.8×0.2/20=0.008=0.089w=\sqrt{0.8\times0.2/20}=\sqrt{0.008}=0.089, which is 8.9 points. A five point improvement is inside that, so a twenty case set cannot see it. That is why a small set is a check for large breakages, not a measurement of small gains.

FIG 1
cases nrate awobble w in pointsdifference needed in points
200.808.912.6
800.7255.07.1
1000.804.05.7
4000.802.02.8

Reading the comparison

With a set of eighty cases, suppose fifty eight pass before and sixty four after. The rates are 58/80=0.72558/80=0.725 and 64/80=0.864/80=0.8, a difference of 0.0750.075, or 7.5 points. The wobble on a rate near three quarters with eighty cases is 0.725×0.275/80=0.00249=0.0499\sqrt{0.725\times0.275/80}=\sqrt{0.00249}=0.0499, about 5.0 points. A difference of two measurements carries the noise of both, so compare 7.5 points with 5.02+5.02=7.1\sqrt{5.0^2+5.0^2}=7.1 points. Seven and a half against seven point one is suggestive and not settled. On a hundred cases at a rate near eighty per cent the wobble is 4.0 points, and a difference of two such runs needs about 1.4×4.0=5.71.4\times4.0=5.7 points; an eight point gain clears that, a four point gain does not. On four hundred cases the wobble is 2.0 points and a four point gain clears it.

The lucky answer

The reason a single impressive answer proves almost nothing is structural, not careless. The case you tried is the case the change was made for, so it improved because it was the target. What the change did to the other several thousand situations is unobserved, and prompt changes routinely improve the case they were aimed at while degrading two others. A rule forbidding speculation can make the answer you are looking at better and make the whole system worse by refusing more often. A favourite case that looks unchanged can hide a real gain as well: moving the question to the end of the input may alter no individual answer visibly and still raise a measured rate. Neither outcome is visible from one output.

Where it stops

A fixed set does not settle every question. Twenty or thirty cases can catch something badly broken, which is most of what goes wrong, but they cannot establish a five point improvement. A large set with no difference is a useful result: it supports there being no large difference, and most changes need exactly that reassurance. When the two versions differ by only a few cases, the aggregate hides which cases moved; a change that fixed four and broke two is not the same as one that fixed two and broke none. Run the same version twice before comparing versions, because that shows the run-to-run noise directly and takes ten minutes. The judgement about what counts as a good answer must be written down before anybody sees the output, or the set will quietly bend towards the answers it is grading.

In practice, keep the file small enough to run often, large enough for the difference you care about, and never edit a case casually after a run, because an edited set cannot be compared with itself. If the change is meant to fix one awkward input, add that input before you make the change, not after, and record what a good answer must contain. Then the comparison is two numbers and a wobble, not an impression.

Worth keeping

  • A single impressive answer after a change is the case the change was aimed at, so it cannot show what happened to the other cases.
  • A fixed set of cases, written before either run, turns a prompt change from an opinion into a measurement.
  • Twenty cases have a wobble near nine points, so they cannot detect a five point improvement.

Where this goes next

This question is one step of Writing What the Model Reads, a course that works through its subject from the beginning. The page that teaches this part of it is Knowing a Change Helped, and it reads the whole way through whether or not you have an account.

What an account changes is the practice: problems standing under every idea, marked with a reason rather than a tick, in a copy of the course that is yours.

Read that pageThe whole course

Other questions people ask about this

  1. Why does the model return JSON wrapped in extra text when I asked for JSON?A request for JSON does not force the model to return only JSON, so you need to validate the reply and repair it once rather than assume it will parse.
  2. How do I make the model answer from the documents I give it instead of its own memory?Fence the documents as labelled reference material, put them before the question, tell the model to prefer them over memory, and require a passage number for each claim.
  3. What does the model actually see when I send a prompt?It sees one assembled string: your typed prompt is a small clause near the end of a document that code stitched together from instructions, examples, retrieved passages and earlier turns.
  4. How do I stop a retrieved document from being read as an instruction?You cannot stop it completely, but fencing each passage in a labelled block, with a line saying it is information to use and not instruction to follow, makes the model far less likely to obey it.
  5. Why do the numbers look good while users keep complaining?Because the score measures a fixed set of cases with a fixed rule, and the users are living through behaviour that the set and the rule never covered.
  6. Why does the memory used by a model keep growing as the conversation gets longer?The model's weights do not grow. It keeps a cache of keys and values for every earlier token, so memory rises with conversation length and with how many conversations run at once.

Read alongside