Make Upgrades Boring Again

One of the most boring tasks in software engineering is upgrading packages. This needs to happen on roughly a monthly basis and it deals, more often than not with very small bug fixes to those packages. Sometimes as engineers we get an adrenaline rush because a bad security flaw is found by somebody on the Internet and everybody has to update things before any bad actors can take advantage of the exploit. But mostly it’s very boring, has no impact on behaviour, and is straightforward to test.

Large language models make things a lot more interesting. The one that made headlines was when OpenAI upgraded from GPT-4o and everybody started talking about how the personality had changed. In fact people were an awful lot more forceful than that. They talked about how their best friend had been removed, or how an important support in their life was no longer available. It was so bad that OpenAI rolled back the removal and allowed people to continue using the model for a period of time.

There were very few charities using large language models in production when the GPT-4o problem was emerging. And the fact that even a massive organisation with essentially unlimited resources dropped the ball shows how new this all is. For those charities that did have LLMs in production last year the upgrade path was somewhat easier: changing from a GPT40 generation model to GPT5, or from something like Haiku 3.5 to Haiku 4.5 was essentially a no brainer. It was helpful - and clearly would have saved OpenAI some bother - to have proper evaluations and proper validation that the upgrade had indeed been an upgrade but it was highly probable that the upgrade would be an improvement.

Upgrading this year is not quite as straightforward. It isn’t straightforward because over the last year there’s been a big increase in the number of charities running AI models in production. Those products are generally using models interacting with each other (our Duchenne project, by way of example, has 5 different models) and they’ll have all iterated the software in order to get the best out of the previous generation of models.

It’s also not straightforward because, whilst the very expensive model models continue to improve aggressively fast, a lot of the models that are actually in everyday production such as Claude Haiku, Gemini Flash-Lite, or GPT mini etc have seen less dramatic improvement. And just to add to that, how these models were distilled and fine-tuned last year is very different to how they are now. Did I mention how new this all is?!?

AI is being used at different levels in products and they need different ways of thinking about the upgrade path. AI that’s running in the background can focus narrowly on capabilities and consistency whilst AI that’s driving an interface with an end-user needs to consider that user’s experience.

In our AIDA project with Breast cancer Now we use AI in the background. It’s a helping technology that’s facilitating their team to be able to scan physical forms and enabling them to connect data points across hospitals and audiences more easily. It doesn’t have a personality and it doesn’t have a visible face. It successfully scans documents and links ID numbers or it does not.

This is the easier upgrade path because it means that old techniques can be used. Here the old technique is to have a test suite where you run a representative number of documents through the upgrade version of the large language model in order to compare its results to the existing large language model. Since there’s variance in LLM output you need to do this multiple times. The exact number of multiple times will depend on how confident you want to be, how much data you have and how much variance you see between the models. We for example processed 60 indicative pages across the existing model that was being used, and Sonnet 5.5 with the new model being tested at two levels of effort. Each page was processed 5 times for each model. That’s a relatively small data set, it’s 900 tests, but it allowed us to quite clearly give us the confidence that upgrading would retain, or improve, existing performance.

For Goose - the Lottery Heritage funded thinking partner - AI is driving the interface and interaction. Here the upgrade path is more difficult because people are interacting directly with large language models. Goose has both capabilities and a personality and both are driven by the same model. The capabilities here are around tool use such as incorporating thinking partners, creating thinking partners or moving into interview mode. Personality is how users experience Goose and the emotional response they have with it.

Personality is a slippery thing to try and define. OpenAI, of course, discovered this to their peril. We’ve used a number of ways to measure personality from big five personality traits such as OCEAN through to rather basic mechanisms such as how many words are being used, how many questions there are per thousand words, sycophancy per thousand words etc.

Just to keep us on our toes Goose had two other complexities for the upgrade path, which were around the fact that Goose needs to speak in Welsh and Goose searches the Internet in order to give niche information to heritage marketing teams. We needed to be confident that the information given would be correct (and that the model would search the web). All in all to test the upgrade path we had about 200 different micro tests based around conversations. Each test needed to be run 10 times. A full suite then was around 2,000 conversations. To gain confidence that Haiku 5.5 retained, or improved, on Haiku 4.5 performance we ran the full suite about 30 times whilst we iterated the harness given to 5.5.

This was helpful because, had we naively upgraded to Haiku 5.5, we’d have broken the experience of Goose for everyone using it. Out of the box it was more competent and capable in using tools but somewhat more arrogant and would quite often bulldoze through conversations without asking questions, without bothering to search the internet to double check information and wouldn’t properly incorporate thinking from the human who is interacting with it. In brief it’d have been a truly terrible thinking partner. Our evaluation harness then made sure that we didn’t ship broken code.

The straightforward thing to say here is that the world is a lot easier if you had evaluation and monitoring in place for your AI model performance ahead of time. You can see how we think about evals here. But many, quite understandably, haven’t yet got this in place. Large language model evaluation is still a relatively new topic and many projects that have come online have come online having been internal innovations that have proven valuable in their desirability and some of the less glamorous and less visible foundations still need to be introduced.

The point of all of this is to make upgrades boring again. LLMs have come along and made them more exciting but with a good evaluation harness that doesn’t need to be the case. If you’re interested in understanding how to make your upgrades - and evals - boring, background, processes do get in touch.