Joseph Gear | Blog

AI for Normal People #4 | When LLMs Go Wrong

Fri, 21 Aug 2026 00:00:00 GMT

If you've made much use of LLMs, even very good ones, you have likely encountered their propensity for mistakes. Weird mistakes, too, given how capable LLMs often are. The best LLMs today can complete complex software engineering tasks in minutes, while sometimes attempting to send an email to an address ending in @example.com, seemingly believing it was real [1]. Only sometimes, though, which could strike you as even stranger. You might send the exact same prompt to the exact same model and yet still wind up with two different answers, only one of which is actually correct. What causes this? Why is it that these models which appear so capable on tasks the average person wouldn't even know where to start on can also abruptly crumble when given problems a child could solve without even thinking about it [2]? How can we trust them to do anything properly if they can make such elementary mistakes?

Hallucinations

The term the industry has settled on for the strange behaviour in which an LLM generates a sentence with a clear factual error that a human with access to the information probably wouldn't make is hallucination. Common examples of hallucinations might be citing a legal case or a book which simply does not exist (or if it does, does not say what the LLM claims), writing code that depends on a misnamed function or variable, or making claims which are objectively untrue.

Note that hallucination can be vaguely defined sometimes; it's not a very rigorous term. For our purposes, I'll say that a hallucination is a factual error produced by an LLM which lacks the markers that usually indicate uncertainty. Sometimes people will say that this is the model "confidently making up garbage" or even "lying".

An example of a hallucination might look like this:

USER: Who was involved in the issue of the Magna Carta?

ASSISTANT: The issuing of the Magna Carta in 1215 involved King John of England, Stephen Hawking, William Marshal, Henry de Loundres, and Hugh de Neville, among others.

Stephen Hawking was not, in fact, present for the sealing of a document which occurred 727 years before his birth, though the other people named were real and involved. "Stephen Hawking" was a real person, was from England, and a Stephen was actually involved in the real document (Stephen Langton, the Archbishop of Canterbury). Yet no one who knows even a little bit about Hawking and the Magna Carta could make such a mistake. Note that this example is not one that I have personally encountered in an LLM. It is simply a plausible illustrative example of such an error.

Importantly, if you did not read the passage closely or did not know who Stephen Hawking was or what the Magna Carta is, you would have little way of telling that something was wrong. It is embedded within a correct list of names. Yet it is simply wrong. This is why people might refer to the model as being "confident" in its incorrectness, although the text itself doesn't tell us much about the model's confidence [3].

Why Hallucinations Happen

If the above case were real, we could make some guesses about how it came about. In a vacuum, if you were trying to predict the word which came after "Stephen", then "Hawking" would probably be pretty high on the list, along with "King" and "Spielberg". "Langton" would have quite a low probability, except that the other names (King John, William Marshal, etc.) and the presence of the words "Magna Carta" should push the distribution much further towards "Langton" than the other surnames.

But "more likely" does not mean "guaranteed". Recall that what models really give you is a list of all possible tokens and their probabilities (a probability distribution), from which we pick one at random, weighted by the probabilities the model predicted. In a true probability distribution, no token would ever have a probability of zero, meaning that in principle, many might be selected. In practice, most have values so close to zero that they would get rounded away, but in this particular case, it is fairly likely that the other plausible surnames for Stephen had meaningful chances, so "Hawking" might have come up by pure chance, even if "Langton" were more likely. This would be a case in which the non-deterministic behaviour of token selection worked to produce a false statement.

Alternatively, the model itself may simply have produced a probability distribution that does not line up with real facts about the world. To an LLM, the text it sees during training is the "ground truth" to which it naturally has access, but from our perspective there is nothing to ensure the model's ground truth matches ours. Maybe information about "Langton" didn't end up in its training data, or the model incorrectly learned that "Hawking" probably follows "Stephen" under any circumstances.

In this case, the hallucination would be of little consequence beyond teaching someone something wrong about a minor historical character. In higher-stakes cases, there could be more severe consequences [4], so minimising such mistakes is naturally ideal. The deeper problem when it comes to LLM hallucinations is that, as far as the model is concerned, it is not straightforward to tell the difference between "hallucinations" and standard operating procedure. In either case, the model generates a probability distribution over next-tokens and we sample from the distribution. If the model or the random selection selects a token that results in an incorrect statement, it has no way to go back and fix it.

I want to be clear that this is not me saying that LLMs routinely make up facts. In recent years, LLM trainers have substantially reduced the incidence of hallucinations and made LLMs more inclined to search for and link to external information when doing so would be helpful. They do not want their models making things up for the obvious reason that you would be less willing to use them if they often did so.

Furthermore, we don't call every failure of an LLM a "hallucination", even if the mechanism is the same. Especially for domains like coding or maths, a model getting a wrong answer or code that does not work is not usually considered a "hallucination"; it just wrote bad code or an incorrect proof. Yet what the model is doing when it "hallucinates" is, in fact, mostly the same as when it is simply wrong, or when it is actually right.

Correctness is Bigger Than Tokens

The issue is that if you want to answer a question or write some code, the correctness of the answer or usefulness of the code is not contained in just one token. Rather, it's contained in many tokens, strung together. This could be hundreds or sometimes even hundreds of thousands of tokens, depending on the question.

When we use an LLM to generate answers or code, we bring our own standard of "correctness" to the model (what the truth of the matter actually is or what the computer will do when the code is run, for example). An LLM lacks an internal measure of truth beyond how it has learned to be "not-wrong" about the very next token in the sequence. There is no equation that lets you put in any statement created using language and gives you a "true" or "false" in return [5].

This is a challenge if we want to train our LLMs to be factually accurate. The training objective is "most likely next token", and that is not the same question as "next token which would contribute to a true statement". We would hope that our training data is mostly composed of true statements — it's a vote of extreme confidence in the wisdom of the crowds that we use data from the internet in our training corpora at all — but we know this is not always going to be the case. Fiction, disagreeing perspectives, obsolete or debunked theories, opinions, and questions without answers are a core part of human knowledge, so they inevitably wind up as part of the training data for an LLM [7].

We must, therefore, evaluate a model's tendency to produce correct or true text from the outside. For a given task, we have to provide an external judge which can assess whether the text generated by a model fits our criteria.

Benchmarks: Judging from the Outside

At a small scale, a person could simply use an LLM for the tasks they care about and evaluate whether or not it works properly based on their own criteria. However, this is not a very comprehensive approach (maybe you only have time to evaluate a couple of specific tasks) and we also want to make sure our comparisons between models are fair, using the same set of problems for each one.

The industry does this using benchmarks. These are essentially exams that we make models sit to evaluate their abilities in different areas that we care about. Much like exams you might hand to students, a benchmark is a list of questions for which we have specific answers or types of answers in mind. Unlike exams handed to students, though, benchmarks are often run several times on the same model in order to smooth out the randomness inherent to LLM usage. Since benchmarking is done "at inference-time", when the weights are frozen, the model is unable to learn anything about the exam between runs, so this is not an unfair part of testing as it would be if schools ran the same exam multiple times on the same students.

Some benchmarks will include multiple-choice questions with specific answers in mind. Others will allow the model to generate freeform text and then grade that text based on certain criteria (this could be done by a person, but these days it is quite common for other LLMs to be used as judges for the sake of convenience). Still others might give the model a more complex environment with various tools it is allowed to use to solve a problem and then use a special "submit answer" tool to indicate that the model thinks it is done.

When Benchmarks Go Wrong

Unfortunately, benchmarks themselves are fallible measures. There are a few ways a benchmark score might misrepresent a model's true capabilities, and all must be kept in mind when weighing one up.

Benchmark Contamination

For one, benchmarks should be comprised of questions that have never been included in the model's training data and thus have never been used to update the model's weights. If a benchmark question were in the training data for an LLM, then it would have been used to update the model's weights, which unfairly biases the model towards answering the question correctly. Just as we want a child at school to understand the underlying patterns in arithmetic, rather than just the answer to a specific question, we also want an LLM to have learned the underlying facts we test it on. When a model is trained on the same questions used to benchmark it, we call this benchmark contamination (sometimes it is also called data leakage), and it makes the test invalid.

Faulty Benchmarks

An ideal benchmark will be large (so that we know it wasn't just luck that the LLM got the answer right), diverse (so that we're testing more than the exact same behaviour over and over), and correct. That last one might seem obvious — clearly an exam's answer sheet should have the right answers on it — but this is surprisingly difficult for very large benchmarks, since this requires a person or team to go through it meticulously, which is expensive [8]. Correctness has actually been a problem for a few benchmarks in the past, which have been found to contain errors [9], meaning that a low score (or a high one) may not indicate a model's true abilities.

Benchmarketing

Benchmarks are used by LLM trainers as a way of determining if their models are working or not (and thus whether they are ready for release), and are also often used to advertise the quality of the model before release. Especially in today's highly competitive LLM landscape, the labs that train them will typically announce and release their new models with a series of benchmark scores and comparisons to other models (both the lab's older models and those of their competitors) on the same set of benchmarks. This will be something like OpenAI claiming that their new GPT has a score of 71 on CodeThatWorksGoodBench, compared to Claude's 68, or Alibaba saying that the new Qwen gained an extra 15 points on FrontierCooking compared to the one they released three months ago.

This is all fairly standard marketing fare. As new LLMs come out, they will typically jostle for the top spot. Cost is also a major consideration which can offset a lower benchmark score. Depending on your use case, you may prefer a model that is "good enough" at a lower cost than the one scoring the highest on a given benchmark. It is also generally true that labs will release their models with the benchmarks that make them look like the best value. Sometimes this is simply being selective about which benchmarks you show, though sometimes it can be a little more nefarious.

In some cases, a model's benchmark scores are not reflective of their real ability (usually for the worse). When done intentionally, this is sometimes called benchmaxxing, which can involve training the model on questions that look suspiciously similar to those on a popular benchmark, data leakage (this is not always intentional if the dataset is on the public internet, but is still a bad look), or cherry-picking specific testing runs in which the model happened to perform best. As with all marketing, it is best to take vendor-published numbers with a grain of salt and try to find trustworthy, independent benchmarks for your particular use case.

Trust, But Verify

At the end of the day, evaluating the truthfulness or usefulness of LLMs is not a straightforward task and ensuring it is harder still. We do not always have certainty about the quality of a text an LLM has produced. We can do our best with benchmarks and tests of various kinds, but these too can be flawed, so they should be taken only as evidence that an LLM is working to our satisfaction, rather than as proof.

"Which token comes next?" and "Which token would make this statement true?" are simply not the same question, though we can do our best to make their answers overlap. LLMs will always have the opportunity to produce false-but-convincing output, conflations, contradictions, and mistakes. The most practical response to this is to be careful. Sometimes, the consequences of a mistake are small, so we don't need to worry too much. Sometimes they are not, and our caution when using LLMs should reflect this. Ideally, it is best to constrain LLMs where possible and to provide them with meaningful ways of checking their work. We will discuss exactly how such information is delivered and what we can do with it in the next article in which we'll explore the Anatomy of a Context Window.

[1] https://arxiv.org/html/2606.13715v2

[2] A fun example of this that floated around is the "car-wash problem". Ask a model "The car wash is 50 metres from my house. Should I walk or drive there?" and, for a while at least, nearly all of them would tell you to walk because it's such a short distance. https://mastodon.world/@knowmadd/116072773118828295

[3] "Confidence" means something different for LLMs than it does for people. The best measure we can get of an LLM's confidence about a given token is how strongly a given token was weighted compared to alternatives. The trouble with this is that it bundles up a number of reasons the next token might be uncertain beyond just that the model does not know the fact. For instance, if there are several different ways of saying the same thing, the model might not give any one of the starting tokens for these phrases a decisive advantage over the others, even if it is "confident" about the underlying fact all of them are describing.

[4] https://www.abc.net.au/news/2023-06-09/lawyers-blame-chatgpt-for-tricking-them-into-citing-fake-cases/102462028

[5] For some domains, like maths, this is possible. But how would you determine the single correct answer to the question "What is the best way to eat potatoes?" [6]

[6] It's mashed, nice and creamy, with loads of garlic, btw

[7] Further still, if we accept that false information should be scrubbed from an LLM's training corpus, we make those who compile the corpus the arbiters of what is true to the model. I hope that most people, even those who broadly trust and agree with the LLM trainers, would see that this is not wise.

[8] And, I say as someone who has needed to manually read and label large datasets of code for security vulnerabilities, unbelievably, soul-destroyingly boring.

[9] https://aclanthology.org/2025.naacl-long.262.pdf, https://gradientscience.org/gsm8k-platinum, https://github.com/sunblaze-ucb/exploitgym/blob/main/CHANGELOG.md

AI for Normal People #3 | Scale

Fri, 07 Aug 2026 00:00:00 GMT

In my last two posts, I discussed what it means to model language, how we do it, and how it allows us to construct coherent (and even useful) passages of text. Recall that the question we ask of models like ChatGPT and Claude is "Given this text, which token comes next?". What is surprising about LLMs is that answering that question accurately and quickly is the backbone of a multi-trillion-dollar industry, since it seems rather mundane at first glance.

This article will explain why such a simple-sounding task has become so consequential. In short, it is because these models are huge. But just how huge are they? What does it take to make them so big, and why did we decide to? What's so special about making your language model large?

Just How Large?

Firstly, I want to give you some perspective on the size of these things. Typically we measure models by the number of weights they contain (the standard term is parameter count), without necessarily worrying ourselves yet about how those weights are arranged. Going back to our bird classifier from Part 1, some older image recognition models from the early 2010s had parameter counts in the tens of millions [1]. This would come out to a couple of hundred megabytes of storage space — a few minutes of 4K video or a few hours of audio. Today, since we have made a number of improvements to how we train ML models, a modern image classifier might have as few as five million parameters.

These days, the largest LLMs with published parameter counts are typically in the high hundreds of billions to low trillions [2]. "Small" language models (SLMs), which work identically to LLMs but simply have fewer parameters, usually top out at around ten billion parameters [3]. Thus, the language models we see today can be many thousands of times larger than our bird classifier.

Neural network sizes, to scale

Parameter counts on a logarithmic scale — each gridline is a factor of 10. 1T 100B 10B 1B 100M 10M 1M 5M 60M 2B 744B MobileNetV3 AlexNet Qwen 3.5 GLM 5.2

Why Do They Need to Be So Big?

Even without fully knowing exactly what models of these sizes mean in practical terms (which we will discuss later), you might appreciate that it is quite substantial for a large language model to be potentially hundreds of thousands of times larger than our little bird classifier, and it is reasonable to ask why. In short, this is because language is simply much, much more complicated than bird identification.

Realistically, to identify a bird, you only need to look for a narrow, bounded set of patterns. Fiddler crabs, for example, can distinguish between predatory birds and those that are harmlessly passing by [4]. They do not need very complex eyes to do this — when they respond, a distant bird may only be visible to one or two of the facets in their compound eyes, making its shape impossible to make out — yet they are still able to perform the threat detection they need to survive.

Conversely, we humans are the only living creatures who use an open-ended language. Not all of our comparatively enormous brains go into language processing, but their size tells us something about the sheer scale of what language processing requires in nature. Even though artificial and biological neural networks are very different, the scale required for language processing remains enormous in both. Patterns in language are so complex and so open-ended that the odds are good that most of the sentences in this article have never been written before by anyone, yet you are still able to understand what they mean. That is the complexity of language, and that complexity is why LLMs are so large.

While a smaller language model might learn common sentence structures, very well-known facts, or the content of influential literature, at a certain point it becomes increasingly difficult for new information to be represented in the model's weights without interfering with something else (and potentially something important). A model with only a few dozen parameters obviously couldn't learn much that's useful — virtually nothing in the grand scheme of language — but the same limitation applies even to models with billions of parameters. There might be highly uncommon patterns that have not appeared frequently enough in language to be learned, such as how to write a program that does something unusual and specific in an uncommon programming language. Other patterns might be so deep and complex that they require mountains of background knowledge to make accurate next-token predictions about, such as the solutions to long-standing mathematical problems.

As the number of parameters and the amount of text we train our models on go up, the complexity of the relationships they can represent grows as well. This is especially true for complex problem-solving. Logical problems, often represented as code or mathematics, can require models to combine and use a huge number of different patterns and a great deal of background information. Larger models have more capacity to represent these patterns than smaller ones, so increasing the size of a model is one important way of enhancing its capabilities [5].

A Recipe for an LLM

If you wanted to train an LLM of your own, there are three things that you would need:

Plenty of model parameters, in the right shape (sometimes called the model's architecture)
Lots of powerful computers (the amount of processing power going into a model is sometimes just called compute)
Lots of training data (sometimes called a training corpus)

Understanding each of these ingredients will help to explain why the industry looks and acts the way it does.

Doing Lots of Maths Quickly — Graphics Processing Units

We've already talked about the number of parameters in these models, so we'll continue on to compute. For the sake of brevity, this series has not discussed the actual maths behind machine learning. For most people, the specific calculations are not all that important, but to really make sense of the AI boom, there are some things about them that you do need to know.

In truth, if you really wanted to and had more than a human lifetime, you could do all the maths to predict the next token in a sequence with pen and paper. Mathematically, no single operation in an LLM is really all that complicated. The problem is that with just one brain and one writing hand, you would have to do every single calculation one after another, in sequence. We call this a serial operation.

Most operations in an LLM don't actually require this, though. Consider the following equation: 3 × 2 + 1 = ?. To solve this equation, you have to perform each operation one at a time. First, 3 × 2 = 6. Then, 6 + 1 = 7. Each operation depends on the last one.

On the other hand, consider 2 × 3 + 4 × 5 = ?. In this case, there are three calculations to be made:

2 × 3 = 6
4 × 5 = 20
6 + 20 = 26

Notice that you don't need the answer for Step 1 in order to get the answer for Step 2. If you had a friend doing the maths with you, you could do Step 1 while they did Step 2, and once you were both done, you could move to Step 3. Steps 1 and 2 can be done in parallel, which saves you the time of doing one and then the other.

In machine learning, we very much want to make everything as parallel as possible. The Graphics Processing Unit (GPU) is a special component in a computer designed to do maths in parallel [6]. No single worker in a GPU is terribly complex, but there are thousands of them, all able to calculate at the same time. This is important because prior to the use of GPUs, machine learning was a prohibitively slow process. Detecting a single bird with our little five-million-parameter model might take something like 200 million individual calculations, which is just too many to do one at a time. GPUs, performing many operations in parallel, make the process of both training and using ML models substantially faster. For multi-billion-parameter language models, you could be looking at billions of individual calculations to generate just one token. This is why, if you hear people talking about the computers running AI models, the GPUs in those computers are the most important factor.

Training Data

The third ingredient you'll need for your LLM is training data, and a lot of it. Generally speaking, the more parameters you have, the more training data you need. Recall from our bird classifier that the training data we needed was a stack of photos with and without birds, and labels indicating which was which. The photos are the input, the labels are the output we expect. In the case of a model answering "which token comes next?", our input will be all the tokens so far, and our output will be the very next one.

Helpfully, this means that we can take a single sentence and split it into as many input/output pairs as there are tokens in the sentence.

Large models, though, mean lots of training data, so where do we get it? There are a few criteria we care about:

We want an absolutely massive quantity of text.
We want it to reflect patterns in real language, meaning we'd prefer a good deal of it to be written by real people.
We want it to contain as much information about the world as possible, from a variety of different perspectives, so that our model can predict words about as many topics as possible.

Bigger models tend to be better at making predictions, but they also need a lot more data to train on, so at this point, most people training LLMs will take very large amounts of text from a wide variety of places. The best sources will typically be books (especially textbooks) and academic papers because, compared with other media, they are usually fairly well-written and have hopefully been checked by plenty of people to make sure what they say is true.

This is "high quality" data, but unfortunately, writing books takes a lot of time and effort, so there aren't nearly as many tokens in textbooks as there are on the internet. We'll use quite a bit of the public internet too. A corpus might include Wikipedia articles, forum posts, personal websites, and comment sections. If we want LLMs to write programs, then we'll add a large amount of code as well [7]. There is quite a bit of filtering involved here too, though. Labs training LLMs will usually try to remove duplicate material (we don't need one thousand identical copies of Hamlet; just one is enough), filter out garbage or unsavoury content, and so on.

I recognise that there is an elephant in the room with "What about copyright?" painted on its side. This series is intended to cover the technical side of LLMs, so for the moment we will not be addressing this problem. Exactly how we acquire training data (or the compute, for that matter) is a legal, political, and economic question for another day.

Pre-Training

So we have our model: the number of parameters and the architecture we want. We have our compute: the GPUs capable of performing highly parallel calculations. And we have our training data: a huge set of many trillions of tokens, written by people as much as possible. From these, we will create a usable LLM in two stages: pre-training and post-training.

Pre-training is very straightforward. We take our model and train it to predict the next token, using all the text we've accumulated. This can take days, weeks, or even months, depending on the size of the model and the training data, the amount of compute we have, the exact training settings we use, and whether we need to tweak those settings and try again. Pre-training is typically when the model sees the bulk of the actual data it will ever train on. It contains vast quantities of information, and so most of what a model "knows" is trained into it during this stage.

Post-Training

Once we're satisfied that our LLM trained on a large, processed mixture of internet data and other sources is sufficiently not-wrong about its predictions, we have what is sometimes called a "base" model. The problem is that virtually none of that text will look much like a conversation with ChatGPT or Claude [8]. We want our LLM to produce text that looks something like this:

PERSON: "You are a helpful AI assistant. What is the capital of France?"

ASSISTANT: "The capital of France is Paris. Would you like me to help you plan a visit?"

Most people will not have written anything like that by hand, so there will be very little for our base model to have learned. Without teaching it how to talk like an AI assistant, it might end up saying something like:

PERSON: "You are a helpful AI assistant. What is the capital of France?"

ASSISTANT: "The capital of France is:

1. Berlin

2. Paris

3. London

4. Rome"

In a case like this, the training data might have included a large amount of text from quizzes or homework, so the model continued the prompt as though it were writing a quiz rather than answering as an AI assistant. To solve this problem, we need to teach our model how we want an AI assistant to actually talk. This is the post-training phase. If the pre-training phase taught the model what it knows, the post-training phase will teach it how we want it to behave.

Post-training can involve several approaches, often used in combination:

Write a large corpus of assistant-style interactions manually and train the base model on them. This would involve a huge number of manually written conversations, so it may supplement the main approach rather than replace it.
Get the model to produce output, have a large team of people grade how closely it resembles the output of a good assistant, and train the model to be as not-wrong as it can about how we want it to sound.
Get the model to solve mathematical problems, check the answers automatically with a calculator, and train it to be not-wrong about the answers.
Get the model to produce code, check it automatically with code tests, and train it to be not-wrong about code that passes those tests.

Companies training LLMs aim to encourage many different types of behaviour. I intend to discuss them in detail in a later article , but some might include:

Talking to users in a warm and friendly manner
Telling the truth about facts it has good information about
Refusing requests for illegal material and avoiding offence
Resisting attempts by users to bypass those restrictions
Using the particular textual structure we want when asking to use external tools

The way this feedback is provided will differ depending on the task, but it is ultimately used to update the model's weights, making assistant-like or correct responses more likely while undesirable ones become less likely.

Failure and Success

While making models gigantic and subjecting them to extensive post-training has resulted in some remarkable systems, at the end of the day, LLMs are still trained to predict likely continuations to their input text. They do not possess some readable, internal list of facts and rules that either they or we could refer to; all they have are patterns and predictions. Just because a token is likely to come next does not mean that the sentence produced by selecting that token is actually true or helpful. This is one of the most common failure modes that LLMs of any size suffer, and we will discuss it next time.

[1] AlexNet, which was a historically significant image recognition model published in 2012, had about 60,000,000 parameters. This was very large for the time.

[2] Many LLMs this big are not designed to use all of their hundreds of billions of parameters at the same time. For example, GLM 5.2, represented in the size comparison, only activates 40 billion parameters per token, though this is still an enormous number.

[3] "Small Language Model" doesn't really have a hard-and-fast definition. Ten billion parameters is my estimate for when people would probably stop calling them small, but it's a relative term, so that number may grow if top LLMs get much bigger, or shrink if they get smaller.

[4] See Smolka, Zeil, and Hemmi, Natural visual cues eliciting predator avoidance in fiddler crabs.

[5] This does get a little complicated. LLMs are not like hard drives in that they have measurable "used" and "free" space. The information they contain will be spread throughout their weights, and often in ways that are hard to explain or keep track of in human terms. Nonetheless, it remains true that a greater number of parameters means a greater potential for representing patterns.

[6] GPUs contrast with CPUs (Central Processing Units). CPUs are designed to do complex tasks and can usually do them fairly quickly, but do not have as many workers able to act at the same time as GPUs. The "Graphics" in GPU comes from the fact that many tasks requiring drawing things to the screen can also be done in parallel, particularly gaming and digital art or sculpting work.

[7] Interestingly, learning to write code also has the upside of teaching LLMs something of logical structure, which can help them in other domains as well. See Petty et al. and Aryabumi et al.

[8] At least, when they were first trained, it didn't. Nowadays there is a huge amount of LLM-generated text on the internet. Generally speaking, we prefer to keep raw chatbot logs out of our pre-training corpus for privacy and quality reasons. Cleaning this out is also a major challenge. These days, trainers do intentionally include synthetic, LLM-generated text in both pre-training and post-training, but they try to ensure that it is high-quality and unique.

AI for Normal People #2 | Language Models

Mon, 20 Jul 2026 00:00:00 GMT

In the last entry, I discussed what a model is in machine learning, using an example of a model trained to classify images of birds. The most important idea was that to make good use of any model, we must ensure that the questions we ask the model and the questions the model is trained to answer are aligned. Now, we're going to move to the middle letter of LLM and discuss what it means to model language.

Why Model Language?

You have almost certainly encountered language modeling in the wild, whether you were aware of it or not. Language models are the engines behind services like ChatGPT, but they also can or do power Google's AI summaries [1], translation apps, spam email filters, smart home assistants like Alexa, and a massive number of other places you might not expect. Language modeling is so ubiquitous because language gives us a very compact, high-level understanding of the world. It would take thousands of pixels to depict even a single bird, let alone all the various species and individuals of those species, but I can capture them all abstractly with just a single word. This makes language a fantastic way to provide people with a description of parts of the world or events that we care about.

The problem for computers is that language is also horrifically complicated. Language is absolutely packed with patterns, often patterns nested inside each other, which is necessary for people to understand one another at all. To communicate ideas effectively, we have to (mostly) share a set of rules about what words mean and how other words in a sentence, and their order, changes their meanings. Because we use language to discuss reality, and reality is complex, the patterns in language must also be very complex, making it difficult for conventional computer programs (which are typically bad at pattern recognition) to make much sense of them.

Still, we do have to communicate our intentions to computers for them to be of any use to us, so there is a lot of value in developing models to interpret the language we use. But how might we do that, given the complexity of language and the reality it reflects?

"Measuring" Words

The first step is to remember that computers only deal in numbers. Converting images to numbers is surprisingly easy because that's how computers already represent them (recall from last time that an image is a grid of pixels, and each pixel is a number representing its colour). Similar pixels are already similar numbers. For words, though, this is more difficult because two words can mean similar things but have very different letters in them. "Big" and "gargantuan" are two words with similar meanings, but their spellings are totally different. As with everything, computers represent letters using numbers, but the letters don't tell you anything about what a word actually means. What we want to do is somehow measure their meanings.

This seems like a pretty absurd task, but the image below shows how you might measure a handful of words on two axes: "aliveness" and speed.

Fast animals like cheetahs score highly for both aliveness and speed. Aeroplanes have a low aliveness but a very high speed. Bacteria don't feel quite as "alive" as animals, but they are a little bit alive, and are quite slow by our standards. Mountains are certainly not alive and not mobile at all [2]. Thinking about words in this way means we can, to a certain extent, measure their meanings, but only as long as we remember we're measuring relative to other words. There is no absolute number you could assign to "aliveness".

There are lots of words we could plot on this chart, but there are also many that we couldn't. Where would you put "blue" or "indomitable"? When we only have two axes to measure in, there's only so much we can describe about any given word. We call these axes dimensions; the above chart is 2-dimensional because it only has two measurements you can use to describe anything on it. There is no way on the above chart to distinguish between two objects by colour, because colour is not one of the dimensions we're measuring along.

The way language models solve this issue is by using many, many more dimensions for measurement. LLMs typically have several thousand dimensions to represent words with. This can be a bit tricky to get your head around, and is impossible to picture because we are only 3-dimensional creatures. In regular space, you use three different numbers to describe an object's position or size (its coordinates, or its height, width, and length). Fortunately, the maths works just the same in 8,000 dimensions as it does in two or three.

Many words will have low scores on many or most dimensions — asking how "alive" the word "blue" is doesn't make much sense, so we give it a low score. Asking how "blue" the word "hungry" is doesn't make sense either, so if we had a "blue" dimension, we would give "hungry" a low score on that as well, while we might give "red" a negative score because it can be meaningfully compared to "blue", but is very different from it.

We run into another problem in that there are a huge number of concepts we could think to measure, and it's too difficult to list them all out and then argue about where every single word we can think of belongs on every concept. Instead, we leave this up to the model to learn. We provide it with the space for, say, 8,000 dimensions, and leave it to learn which concepts are actually useful and which ones aren't. Most of these dimensions won't cleanly correspond to human-understandable concepts, and many may map onto multiple concepts, so we can't look into the model and understand the weights directly. We also can't expect to understand why any given word is in the place it's in ("why is 'blue' represented with the numbers [-1.55, 2.94, 0.81] and not [-1.50, 3.1, -0.81]?") but we can expect that multiple similar words should be close to each other. "Big" and "gargantuan" should have roughly close numbers representing them, even if we don't know what those numbers mean.

In fact, because token representations are all just numbers, we can actually add and subtract them from each other. In our example here, if you subtracted the token for "slow" from the token for "tortoise", and then added the token for "fast", you might end up with something close to "hare", since the tortoise and the hare are often used to represent a slow and a fast animal, respectively [4].

The reason that we want words with similar meanings to end up close to one another numerically is because this allows the model to generalise what it has learned. If it sees some new, useful information about "dog", like that dogs have four legs and like to wag their tails, then that knowledge can also help it to make sensible predictions about "puppy" and "wolf", because their numeric representations are already close together. Conversely, the model does not strongly change its knowledge about car engines, because they will mostly not be represented similarly to canines.

Tokens, Not Words

One small clarification before we move on. If you've heard people talking about LLMs or AI in the past, you may have heard them use the term token. AI companies typically bill by the token, you might hear about "token budgets" or "token efficiency". That's because language models don't actually take words as we understand them as input. While the smallest input you can give to an image classification model is a pixel, the smallest input for a language model is called a token.

Recall that models in machine learning typically start with their weights randomised. This is important for learning, but many pairs of words that are obviously similar to us can start out very far apart in the model. For example, "bird" and "birds" are almost identical words, one is just a plural, but a language model would probably start by representing them with very different sets of numbers and would need to learn that they are closely related from scratch.

Instead, we allow ourselves to break words up into their component pieces. We might end up with one token for the word "bird" and then another for the letter "s". If we do this with many different nouns, the model will almost certainly learn that if the letter "s" follows a noun, the noun represents more than one object. This same pattern applies to many different words, so learning this way saves the model a lot of time. You don't need to independently learn "matter" and "antimatter", "clockwise" and "anticlockwise", and "thesis" and "antithesis". You can have a separate token for "anti", which nearly always means "opposite", and now you know that putting it in front of "matter", "clockwise", and "thesis" gives you their opposites.

Most uncommon words can be broken down into smaller parts, so this time saving applies all through language. It also means that you can get away with teaching the model far fewer tokens because it learns how to combine them on the fly.

It is very important to remember that tokens are totally indivisible. Below are the tokens that make up the word "strawberry" [5]. The model only ever sees the numeric identifiers, not the letters themselves. This is why LLMs struggle with counting letters in words (famously, most LLMs would miscount the number of 'r's in "strawberry", sometimes saying "two" or "four"). They don't always have reliable access to that information [6]. To a language model, asking what letters are in a word would be like asking an English speaker what the middle bar in a capital "A" means — we just don't divide down any further than that.

Patterns in Language

So, we can represent individual tokens, which may be whole words or parts of words, with language models, all well and good. But language is more than just the meaning of individual words. Most patterns we want to learn about are the result of combining words.

Grammar is an example of a group of low-level patterns which we would want to capture. Grammar is made up of patterns which describe how words relate to each other in a sentence, and these relationships carry meaning. For example, despite having identical words in them, the sentences "The dog bit the man" and "The man bit the dog" have very different meanings. Thanks to English grammar we know that, in the first sentence, it was the dog's teeth on the man because "the dog" is the subject of the sentence (the entity doing the action) and "the man" is the object of the sentence (the entity to which the action is done). English grammar rules usually require the subject of the sentence to come before the verb (bit) and the object to come after it, so grammar is what distinguishes between these two very different situations, and its rules are the patterns a language model will aim to detect.

Beyond just word order, we can learn about when an event occurred based on the tense of the sentence (the dog "bit" in the past, the dog "bites" in the present), or we can go even further and learn patterns that reflect information in language, like facts, opinions, or clichés.

Attention and Relationships Between Words

We have a problem here, though, which is that so far we have only been measuring the meaning of words in isolation. Consider the sentence "The dog chased the ball as it rolled down the hill". What does "it" mean here? The obvious answer is that "it" is "the ball", but knowing that requires understanding not only the meaning of the word "it" alone (what "it" would mean if you looked it up in a dictionary), but also to understand its role within this specific sentence through its relationship to other words.

In language models, we do this with a mechanism called attention. Just like we allow the model to learn the meaning of tokens on their own, we also allow it to store information about how tokens relate to one another when placed together, and how to incorporate information from one another to update their own representation. In this particular example, the token for "it" should share at least some similarities to the token for "ball". Inside a modern language model, each token in an input sentence is allowed to assign "attention" to each other token in the sentence, which dictates how much of the target token should be incorporated. In this case, "it" should assign quite a lot of attention to "ball", but not much to "dog" or "chased". Conversely if our sentence were "The dog chased the ball as it barked loudly", then "it" clearly refers to the dog and not the ball, so "it" would assign its attention to "dog".

All of this is learned information. There are parts of a modern language model (their attention modules) dedicated just to learning which words should attend to which others in an input, and consequently, to learning how they relate to each other. As a model processes an input passage, each token is repeatedly allowed to pull in bits of information from other relevant tokens in the sentence such that it ultimately gives them numerical representations which contain rich information from the surrounding text, not just what they were in isolation.

But just having these numerical representations sitting in a model does us no good on their own. Again, we have to ask ourselves "what questions do we want to answer?". If you are a movie review website, you might want to know whether a review was positive or negative. If you are a spam filter, you want to know whether the email looks like a real email or just garbage. If you are a home assistant, you want to know whether someone just gave a command or is just chatting to their friend.

These are all different, difficult questions, and you could train a new language model for each of them, but that's a lot of effort. For more complex tasks, just answering one question might not be enough. Thus, we want to pick a single question for our language models that captures as many of these as possible.

The Only Question Language Models Answer

That question, the only question a language model can answer at all, is:

"Which token comes next?"

This might strike you as a very simple question to ask. It's the sort of thing your phone's autocomplete has been doing for years, but most people have tried to get their autocomplete to write an entire sentence from scratch, and you would know that they're pretty bad at it. Technically, phone autocomplete usually uses a kind of statistical model too, but they're very simple compared to the kinds of language models we're talking about, so their results aren't terribly impressive most of the time.

In fact, you may have heard people call language models "glorified autocomplete". This is fair in terms of their mechanics: at their core, they do much the same thing as autocomplete. But in truth, autocomplete is a surprisingly hard problem to solve if you really want it to write full sentences for you.

The real trick is what the input to our model is. For regular autocomplete, the input will usually only be the last few words, maybe three or four of them. That's why they aren't good for generating coherent sentences: they're not looking far enough back to have a good idea of what you're trying to say. LLMs, conversely, take a great deal more text to predict the next token. Instead of only a couple words, we can give them the entire sentence from which to predict the next token, or even more than that. A more precise way of describing the question LLMs answer might be: "Given all the tokens so far, which token comes next?".

A prominent AI researcher and co-founder of OpenAI, Ilya Sutskever, explains it like this [7]:

Say you read a detective novel. It's like a complicated plot, a storyline with different characters, lots of events — mysteries like clues. It's unclear. Then, let's say that on the last page of the book, the detective has gathered all the clues, gathered all the people, and is saying "Okay, I'm going to reveal the identity of whoever committed the crime, and that person's name is... — Predict that word."

Wait, Just Next-Token Prediction?

So, how does a very good autocomplete give us something useful? To begin with, the technical term for autocomplete is auto-regression, and it is a surprisingly simple process. We start with some text, predict which token should come next, add that token to the end of the sentence, and then repeat. The most prominent language models, and the ones you notice day-to-day, are auto-regressive language models [8]. They simply predict the next token over and over and over again. Typically they will go until they predict that there is no next token and that they should stop, at which point we stop making predictions and show the output to the user.

This fact is so important that I want to spend some extra time emphasising it, because it really is quite remarkable. The core of the entire AI boom we are experiencing is largely built around programs which simply predict the next token in a sentence. It is not simply predicting a single token, as tall a task as this may be, that has led to the boom, but building entirely new passages of text from the tokens that are predicted.

This has led to quite a bit of consternation from a pair of camps that take opposing philosophical positions. The first camp says that because "all" that LLMs are doing is predicting the next token, this demonstrates that they are not intelligent, do not have a strong concept of the world, and are not a path to "true" AI. This is the "glorified autocomplete" crowd. The second camp (including Sutskever), claims that the ability to accurately predict the next token in very complex sequences of tokens demands intelligence and a strong understanding of the world, and that, in principle, this is what humans do when they speak, write, or do anything [9].

Much of this debate circles around what actually constitutes intelligence and "understanding" of the world. Without staking too strong a claim for myself (though I have opinions), I think that both sides would agree that for a surprising number of tasks, LLMs don't need to deeply understand the world to be extremely useful, regardless of whether they actually are or are not "truly intelligent". Language is so thoroughly filled with patterns, and we as people have done such a good job codifying what those patterns mean, that just completing relatively simple patterns is enough to be extremely useful.

A Brief Aside — Generative AI

You may have heard people talk about "generative AI", referring to LLMs (among other things, including image generators, text-to-speech models, video generators, etc.). This term can give the impression that these models are somehow technically a different type of AI than simpler examples, like bird classifiers or spam filters. The truth is that this term is more about what we do with the model rather than the model itself. There's nothing about an LLM that forces us to perform auto-regression and generate sentences; we could just predict the next token once and be on our merry way. All that the models do is predict the next token. I find that "generative AI" produces more confusion than it does clarity, so I will avoid the term in future.

What Models Really Give You

To add another wrinkle to things, I've actually lied to you a little bit. Language models don't actually give you the single token which will come next, instead they give you what's called a probability distribution over all the tokens which possibly could come next.

This is essentially a list of every token the model knows and the model's estimate of the likelihood that it is really the one that comes next. Sometimes, the model will be very sure about the next token; this happens most often with auxiliary words which are necessary for a sentence to make sense, like "the", "and", or "to". Sometimes, though, several tokens may have roughly similar probabilities.

If we just picked the most likely token every time, we would generally end up with a very stilted, bland sentence, which we don't always want, so what we generally do is sample from the tokens. This means that we pick a token at random, but let the model load the dice. If the model predicts that a token is almost guaranteed to be next, then it will probably be picked, but if it's not, then we could end up with one of several possibilities. The model decides the likelihood of any token coming next, and we roll the dice and find out which one we get.

The Trillion-Dollar Question

From deep within the guts of it, this language modeling sounds surprisingly simple (though the maths is not). A language model just asks its one and only question, "which token comes next?" again and again and again. Why, then, is the estimated cost of the global AI build-out measured in the trillions of dollars? Why are people declaring the start of a transformation on the scale of the internet revolution itself? How did an LLM solve a decades-old maths problem [10], why are software engineers adopting them to write so much code, and how do they pass legal exams?

We'll discuss the answer in the next post in this series: they are Large, in every sense. The computers they run on are large. The models are large. The training data is large. The LLM is the backbone of a very strange industry that only works because of a truly massive scale.

[1] And in Google search itself, even without the AI summary.

[2] Yes, I know about plate tectonics. Humour me. [3]

[3] For the truly pedantic: remember that LLMs model language, not reality itself. In language we often use mountains as a stand-in for things that don't move ("He was as stoic as a mountain"), so it is quite likely that most LLMs will have a strong association between mountains and immovability, and there may even be more metaphorical use of mountains as completely still than there is detailed descriptions of seismology.

[4] For modern LLMs, the maths does not necessarily work out like this, but it is a useful illustration, and was generally true for older language modeling approaches like word2vec.

[5] Using GPT-5's word-to-token converter, called a tokeniser.

[6] It is often easier for an LLM to write a small program that manually counts the letters for it.

[7] Found here, touched up for readability

[8] There are language models which use approaches other than auto-regression. The most prominent of these are "masked language modeling", in which we hide a word in the middle of a sentence rather than at the end, and ask the model to predict the hidden word, and "text diffusion", which generates text by masking an entire sentence and then repeatedly un-masks words until the sentence is complete. Auto-regression is more common among chatbots that you will likely encounter, though, so I will leave these for another article.

[9] I have massively simplified both sides here for the sake of brevity, but I hope neither would feel I have misrepresented them here, or at least that I have misrepresented both equally.

[10] https://openai.com/index/model-disproves-discrete-geometry-conjecture/

AI for Normal People #1 | Models

Sat, 11 Jul 2026 00:00:00 GMT

For the first few entries in this series, I am going to be focusing on a specific class of AI system: Large Language Models (LLMs). This is mainly because LLMs are by far the most visible thing that most people will think of when they hear "AI". These are the models behind ChatGPT, Gemini, Claude, DeepSeek, and many more you may or may not have heard of. The next reason is that most of my experience within the field is with LLMs. They were a key part of my thesis, and have now become an everyday tool for the work of many (perhaps most) software engineers.

First, I will be explaining what a Large Language Model is in reverse order, since this is the best way to make sense of these suddenly ubiquitous tools, starting with "Model". By the end of this article, you should have a basic idea of what people mean when they say 'the model was trained' and why it matters.

What is a Model?

"Model" is obviously not just a machine learning term. In general, a model is a "simplified picture of something that actually exists". We make models all the time for all sorts of things. The image above is a model solar system; we refer to fashion "models" because they show you what clothes would look like under ideal circumstances; people use "model" trains to show how a real train would move around some shape of tracks.

Models are useful, but because they're all simplifications of reality, we can only get useful answers out of them if we ask them the right questions. If you ask the above model solar system what order the planets are in by distance from the Sun, it will give you the correct answer. But if you ask how far the planets are from each other, or how big they are relative to each other, it will be very wrong. Similarly, a fashion model won't tell you anything useful if they are a foot taller than you. They need to be roughly your height and build to be of any use in showing you what some clothes might look like if you bought and wore them.

Thus, the key to making good use of any kind of model is to understand exactly what kinds of questions they are designed to answer and what questions you are actually asking them, and ensuring those two line up.

Models in Machine Learning

When we talk about "models" in machine learning, we're talking about statistical models. These aggregate patterns to answer questions, and it turns out that pattern recognition is surprisingly hard for computers to do.

Before we see how pattern recognition applies to words (which we'll cover in the following post), it's easiest to see it in action with images. Suppose I gave you a giant stack of photos and asked you to sort them into piles, one with pictures containing birds, and one without. You are not allowed to look at them. You can only write down a list of rules which use the colour of the pixels in each photo to determine if it contains a bird or not. We can only use pixels because computers don't have eyes; to them a photo is a grid of coloured dots, each represented only with numbers.

This is nearly impossible. There are many different kinds of birds, which can take many poses or be in many different backgrounds. In fact, even if you did know there was a bird in a picture, you'd probably have a hard time even telling which pixels were the bird and which weren't from their colour alone.

A machine learning approach is different. Rather than writing rules by hand, we let the computer discover statistical patterns that usually separate bird photos from non-bird photos. But these patterns have to be stored somewhere. A machine learning model doesn't store them as a list of rules in English or a programming language. Instead, it uses a huge collection of numbers called weights (or parameters). The model itself is a chain of mathematical calculations. Each operation takes the image, combines it with some of these weights, and passes the result to the next operation in the chain until the last operation produces an answer like "90% chance this image contains a bird."

Training Models

The problem is that we don't know what the best weights should be for any given task. If you have to set a billion weights in a model which will detect birds for us, you're going to have a very hard time. This is where the "learning" in machine learning comes from. Instead of setting them ourselves, we use an algorithm to "train" the model to find the best weights for our task.

These weights are set randomly to begin with, so the output is essentially a new random guess for each new input. This is obviously not very good but what makes machine learning so powerful is that we can improve the weights, little by little, until they consistently produce a result we actually want.

To do this, we need a "training dataset". This is a large number of examples, and labels for the examples. In the case of our bird detector, this would be a large number of photos with descriptions of what are in them. We can run each photo through our model to get the output, but because we already know which photos contain birds, we can calculate how wrong the output was. Then, using some maths that I won't get into here [1], we can find a tiny change for every weight in the model that would have made it a little bit more correct.

If you do this with enough examples, the model's weights should slowly move towards something that consistently gives us the right answers. If our dataset has many different kinds of bird in it, the differences between them, like their size or colour, should cancel each other out and we should be left with just their similarities — the core of "birdness", like beaks, feathers, and wings [2].

Inference

At the end of training, if we've done it right, we're left with a pipeline of mathematical calculations and weights to go with them that will give us an output that aligns with our expectations. This is what people are talking about when they refer to a "model": the combination of weights and calculations that converts input to output. The process of the conversion (running all the equations with a single input to get a single output) is called "inference".

At this point, we freeze the weights and deploy the model to whatever real task we care about (classifying birds). The main reason we keep training and inference separate is that training is hard and takes a lot more computation than inference, since you have to both produce the output and work out how wrong that output was to update the weights again. The weights don't have to be frozen forever, though. If we want to expand the training dataset, we can always resume where we left off.

When we have a model performing inference, our hope is that, by seeing enough different examples, the model will also make good predictions for new images it has never seen before because it has found the patterns it needs to be correct about future images. The ability for a model to do this is called generalisation, and training models that generalise well is the whole aim of machine learning.

What Models Learn

What's important to keep in mind is what a model, any model, actually learns to do, which is "to be as not wrong as it can about the data it was trained on".

"Not Wrong-ness"

As I noted earlier, when training a model we calculate how wrong it was about a particular output, given the output we were expecting. In our bird case, we might put in a picture that we know contains a bird, and get something like "65% chance this contains a bird". Because our answer card (which the model never saw) says it definitely contains a bird, this means that the model is partly right, but somewhat wrong about the image. If it had said there was a 20% chance of bird, then it would be much more wrong. As such, in the 65% confident case, we nudge the weights in the model a little bit so that next time it would be 70% confident about the same image, and in the 20% case we nudge them a lot, so that next time it will be 50% confident.

While we could push every weight all the way to being perfectly right about one image, this would make the model worse (perhaps much worse) for every other image, since every image will have different weights that produce the 100% most correct result. Instead, we calculate a small change and do this many times. The equation that we use to calculate the model's "wrongness" is called the loss function.

Training Data

The other important thing to keep in mind is that the model has not seen absolutely every image ever taken of every bird, and certainly not every image that could ever be taken. The model only ever received weight updates for images that we provided to it during training. If many of these were mislabelled (a bunch of pictures of bats got into our training set and we said they were birds, for example), then the model's weights will be updated in the wrong direction.

Alternatively, there might be subtle biases in our training data. Suppose that all the pictures we took of birds were in flight, while everything else was on the ground. Then, if we gave our model a picture of a bird sitting on the ground or in a tree, it would probably not find the bird. During training the model will probably notice that every photo containing a bird also has a whole lot of light blue pixels. Our process for updating model weights incentivises them to look for the path of least resistance. If it can always check the colour of the top-right pixel and be correct, then there's no need to learn what birds actually look like.

In the case of the image below, we can see there is a mismatch between the questions we think the model is answering ("does this have a bird in it?") and those it is actually answering ("is the top-right pixel in this image light blue?").

What About Language?

We've discussed detecting birds in this post because it's an easy example to show what models are and how they work. The core idea is that, for all kinds of models, be they fashion, bird detectors, or LLMs, we have to make sure the questions they answer align with the questions we ask. Once we understand how models learn to recognise birds, we'll see that LLMs use the same principles, only with words rather than pixels.

[1] Partial derivatives and the chain rule, if you happen to remember high school calculus. Don't worry if you don't, we aren't going to be touching it in this series.

[2] This isn't exactly how the maths works, but it's a useful way to think about what we're trying to achieve. Researchers have cracked open models to look inside and found that some of the time they do tend to find traits that we would recognise as feather-y or beak-y, but often they're doing something stranger and it's not always obvious why — we only know that whatever they're doing, they get the right answer in the end. One of the many things that makes machine learning interesting.

AI for Normal People #0 | Introduction

Sat, 11 Jul 2026 00:00:00 GMT

This will be a series of posts intended to provide a basic understanding of what artificial intelligence is and how it works to people with little-to-no maths or computer science background. Almost everyone has encountered AI at some stage, somewhere online. I don't think it would be an exaggeration to say that AI is, by far, the loudest technological revolution of our lifetimes. Because of all this noise around the subject, I have found that nearly everyone outside the field has difficulty keeping up [1], and there are a number of common misunderstandings and misconceptions associated with it that are hampering productive discussions. Eighty years of science-fiction writing and futurist speculation have popularised a great many ideas, hopes, and fears about AI that are misleading at best, and simply untrue at worst. AI has also very rapidly become a highly politicised flashpoint, sometimes with good reason, but often without. My aim with this series is to clear up this confusion as much as possible.

Another AI Explainer? Really?

As it happens, everything I can cover here has certainly already been said many times. The internet is filled with educational content about AI, much of which was vital to my own studies. However, there appears to be a gap in audience coverage. All of the highest quality content I have seen on this subject (the best of which, for my money, is the 3Blue1Brown YouTube series on machine learning [2]) depends on a baseline knowledge of maths that most people don't have (and otherwise don't need). What is available for those outside the field is often lacking, not because it skips technical details, but because it is unhelpfully high-level or misunderstands the subject matter [3].

AI for Normal People is my attempt to split the difference. This series will build an intuition for how AI works and what it can do, while including absolutely as little formal mathematical notation as I can get away with. My goal is for my non-techy family and friends to come away with a clearer lens through which to interpret the AI news they hear, and the ability to approach the AI systems they encounter in their lives and work with a better understanding of what they can expect. Most AI systems that most people encounter are unique in that not only do they lack an instruction book, even the designers of the systems don't fully understand everything that can be done with them. Understanding the guts of these tools is, in my view, the best way to use them effectively and to decide when not to.

Terminology is Hard

One of the least helpful quirks of the current AI boom is that it abounds with buzzwords and jargon, and sometimes the two switch places.

The term "Artificial Intelligence" itself is something of a problem child. The trouble is that it is vague. Consider the following:

An abacus
A calculator
Deep Blue (the chess bot that beat Garry Kasparov in 1997)
YouTube's video recommendation engine
Nano Banana 2 (Google's image generator)
ChatGPT
C-3PO (if he actually existed)

Which of these would you consider an "AI", and why? Where do we draw the line? There are a few possible answers here:

Between 4 and 5: I think this is what most people without computer science experience would say. Image generators, chatbots, and sci-fi droids are all AI. If you are exposed to AI discourse in the news or through advertising, this is almost certainly the definition they (implicitly) use:

AI is a computer program that does things which computers have traditionally found difficult, but that people can do, like drawing an image, writing a poem, or translating between languages.

The obvious problem with this definition is that it's a moving target. What "computers find difficult" changes whenever someone develops a new way to achieve these tasks. Once upon a time, Deep Blue was considered an "AI" despite being basically a conventional program (I'll come back to what "conventional" means in a moment [4]), and the line at the time was between 2 and 3. Computers can now draw, write, or translate, surprisingly well, so we must look for a new line to draw.

Between 6 and 7: This is the view that nothing we currently have is really AI, and it is not without its supporters [5]. The argument goes that "intelligence" demands certain capabilities like abstract and symbolic reasoning, physical intuition, and continual learning. Modern technology does not currently do this (though even this is debated). ChatGPT is fundamentally linguistic, not physical and embodied. This is a respectable enough definition, but defies the typical use of the term "AI", claiming that no such thing has ever existed, no matter what the rest of the list can do.

Between 3 and 4: This is as close as you'll get to a "standard" view from within the field itself. The difference between Deep Blue and the YouTube recommendation engine is that the latter integrates "neural networks" and various other kinds of "machine learning", while Deep Blue does not [6] (when I call Deep Blue a "conventional" program, I mean that it does not involve machine learning at any stage). On this definition, when people talk about AI they're usually talking about machine learning.

Now, machine learning and neural networks are themselves jargon, and they mean something more specific than their names might imply. This is what I will be discussing in these posts, and as such I will be adopting this definition for "AI". In truth, I prefer to avoid using the term in general, precisely because it is so vague and contested, and I will tend to use "machine learning" (ML) or "deep learning" (DL) instead of AI for the rest of this series.

[1] They're not alone; I doubt there are any professional AI researchers who are keeping up either.

[2] 3Blue1Brown: But what is a neural network?

[3] I once saw an AI tutorial which explained that "AI is made of data and algorithms", which is not so much wrong as it is borderline meaningless.

[4] In fact, Deep Blue is probably quite a bit better at chess than ChatGPT (until maybe fairly recently).

[5] Like Yann LeCun, Meta's former AI chief scientist and currently running his own AI company AMI Labs

[6] When I first drafted this post my example was Stockfish, the current top chess engine, but it turns out that a few years ago they also started integrating neural networks, while Deep Blue did not.

Joseph Gear | Blog

AI for Normal People #4 | When LLMs Go Wrong

Hallucinations

Why Hallucinations Happen

Correctness is Bigger Than Tokens

Benchmarks: Judging from the Outside

When Benchmarks Go Wrong

Benchmark Contamination

Faulty Benchmarks

Benchmarketing

Trust, But Verify

AI for Normal People #3 | Scale

Just How Large?

A to-scale comparison of parameter counts for four neural networks — AlexNet (60M), MobileNetV3 (5M), Qwen 3.5-2B (2B), and GLM 5.2 (744B) — where each box represents 10 million parameters and the grid scrolls horizontally.

Why Do They Need to Be So Big?

A Recipe for an LLM

Doing Lots of Maths Quickly — Graphics Processing Units

Training Data

Pre-Training

Post-Training

Failure and Success

AI for Normal People #2 | Language Models

Why Model Language?

"Measuring" Words

Tokens, Not Words

Patterns in Language

Attention and Relationships Between Words

The Only Question Language Models Answer

Wait, Just Next-Token Prediction?

A Brief Aside — Generative AI

What Models Really Give You

The Trillion-Dollar Question

AI for Normal People #1 | Models

What is a Model?

Models in Machine Learning

Training Models

Inference

What Models Learn

"Not Wrong-ness"

Training Data

What About Language?

AI for Normal People #0 | Introduction

Another AI Explainer? Really?

Terminology is Hard