Guide

How large language models work, and what that means for research. Read it straight through, or jump to a section from the contents.

What we mean by “AI”

AI is not one thing, and most of what people call AI today is one narrow kind of it.

Three distinctions narrow it down to what this guide covers.

What it works on. Text, images, audio, video. This guide is about text. Much of it transfers to images and code, but it doesn’t assume that it does. Two uses are worth naming on the way through. Images are the one place journals nearly agree. In the journal policy lookup, 57 of 92 journals prohibit AI-generated images and figures, the only activity where prohibition is the most common rule. Transcription is audio in and text out, and many researchers use it every week without thinking of it as AI.

What you ask it to do. A discriminative model picks from categories you defined. A generative model makes something new. Say you have 500 earnings call transcripts. Hand-code 200 for a construct, train a classifier on your coding, and apply it to the rest, and you’re using a discriminative model. Ask a model to summarize the themes across all 500, and you’re using a generative one. This guide is about generative models. The distinction here is about the task, not the architecture. A topic model is generative under the hood and produces something that looks like a classification.

It’s worth noticing what we call these things. Most researchers don’t call their classifiers or topic models “AI.” They call them methods. What has established norms gets called a method, and what has none gets called AI.

What you’re touching. ChatGPT, Claude, Gemini, and Copilot are products, and each can run several models underneath. Copilot runs models made by OpenAI and Anthropic.

The model is the part that takes text in and gives text out. The product is everything built around it: search, code execution, memory, your files, a system prompt, and a safety layer. This guide is about the model, because everything the product does is built on it. Some of what follows stops being true once the product is doing the work, and the guide flags where.

So the subject is generative models that work on text, taken apart at the level of the model itself. These are large language models, or LLMs.

Last verified September 2026.

What the models are

A model is a very large set of numbers, built by predicting text and then tuned toward the answers people prefer.

Most people picture a library or a database. The model is neither. It is a set of numbers, called weights, and there are hundreds of billions to trillions of them. Here is how those numbers get made, in two stages.

Pre-training: how it’s built

1. Take an enormous pile of text. Books, articles, websites, code.
2. Cover the next word. The model gives every word it could say, tens of thousands of them, a probability of being the one that comes next.
3. Uncover it. You can see exactly what probability the model gave the real word. If that probability was low, shift the weights so it would have been higher. Move along one word and do it again.
4. Do this trillions of times. What the weights settle into is the model.

Post-training: how it’s tuned

A smaller pass over the finished model. The best-known method is reinforcement learning from human feedback, usually shortened to RLHF. The model is shown examples of good answers, then writes several answers to the same prompt, and people rank them. The weights are nudged toward what the raters preferred. It’s the same nudging as pre-training. Only the teacher changed, from “the word that came next” to “the answer a person preferred.”

Post-training shapes behavior far more than knowledge. It’s why the model:

• answers your question, rather than continuing your text,
• holds a confident, helpful tone,
• and refuses some requests.

Not a list of facts

There is no table, nothing to look up, and no record of where anything came from. The model is weights, predicting what comes next.

Last verified September 2026.

Open-weight models

Some companies publish the weights themselves, so anyone can download a model and run it on their own computer.

ChatGPT, Claude, and Gemini run on models you can only reach through the company. You send text, you get text back, and the company decides which version you’re using. An open-weight model is different. The weights are published, so you can download them and run the model on your own hardware. Llama from Meta, Mistral, Qwen, DeepSeek, and gpt-oss from OpenAI are examples.

For research, that matters in three ways.

• Your data never leaves your machine. That can make a model usable for data you couldn’t send to a company.
• The model can’t change under you. The weights you downloaded stay the same, so an analysis can be rerun a year later on exactly the same model. See Reproducibility and reporting.
• You can see the probabilities and set the temperature. Everything the companies’ newest models hide is available.

The trade-offs are real. The largest open-weight models need serious hardware, the ones that run on a laptop are usually weaker than the companies’ best, and setting them up takes some technical work. “Open weight” also isn’t the same as open source. The weights are shared, but the training data and methods usually aren’t, and the licenses vary.

Last verified September 2026.

How the models work

Prediction

When you ask a question, the model does what it did trillions of times in training. It takes all the text in front of it and gives every possible next word a probability. Then one word is chosen, added to the text, and the whole thing runs again for the word after. An answer is that loop, repeated until it stops.

When the model gets a fact right, it’s because the right word was the likely one. A passage seen often enough in training becomes a very sharp distribution and can come back word for word. That looks like looking something up, but it’s the same prediction. Fill in the blank, narrow shows what that looks like.

Last verified September 2026.

Tokens

Models don’t read words. They read tokens, pieces of text that are often a whole word and sometimes only part of one.

This guide talks about words to keep things simple, but what the model actually predicts is the next token. Common words are usually a single token. Longer or rarer words, names, and numbers get split into pieces. In Fill in the blank, the model’s raw candidates weren’t “complexity” and “predictive” but “complex” and “predict,” the first pieces of those words. In English, a token averages a bit less than a word.

Tokens explain some behavior that otherwise seems strange.

• Counting letters and characters is unreliable. The model never sees the individual letters of a word that arrived as one token.
• Arithmetic on long numbers is unreliable. A long number is split into chunks that don’t line up with its digits. For anything numerical, ask the model to write and run code instead of doing the math in text.
• Limits and prices are counted in tokens. How much a model can take in at once, and what you pay through an API, are both measured in tokens, not words or pages.
• Other languages often cost more tokens. Text in many languages other than English is split into more pieces, so the same content uses more of the model’s limit.

Last verified September 2026.

Sampling

The weights don’t change when you ask a question. Give the model the same text and it computes the same probabilities every time. What varies is the draw. The software that turns probabilities into text picks the next word at random, in proportion to its probability, then does it again for the word after, all the way to the end of the answer.

That’s why the same question can come back differently. In Fill in the blank, the favorite word had about half the probability and came out 13 times in 20 runs. The other seven runs drew something less likely, from exactly the same probabilities.

The precise way to say it: the model is a fixed distribution, and you sample from the model. It’s tempting to say “the model is random,” but that puts the randomness in the wrong place, and it matters. If the model were random, a result that changes after you push back would just be noise. It isn’t. “Are you sure?” moved the answer from 80 to 92 because the conversation changed the distribution.

You can’t see these probabilities anymore. The demos on this site show the probability the model gave each word. You can’t get that from ChatGPT, Claude, or Gemini, and you can’t get it from the newest models even through their APIs. The newest models from OpenAI and Google refuse the request, and Anthropic has never offered it. That’s why the probability demos here run on gpt-4o, a model that still returns them. There are two reasons worth knowing.

Probabilities make a model easier to copy. A full set of probabilities teaches a small model to imitate a large one far more cheaply than plain text does. Researchers have also shown that access to a production model’s probabilities can reveal real facts about its internals. That work was followed by visible restrictions at more than one company. This reason has evidence behind it.

The cost falls on anyone trying to check the model. You can no longer measure how uncertain a model is, compare how well calibrated different models are, or see what probability it gave the answer it handed you. The defensive reasons are genuine. It’s just worth noticing that what has been withdrawn is the thing that would let a researcher check the model’s own confidence, which is part of why verification has to come from outside.

Last verified September 2026.

Temperature

Temperature controls how the draw is made, not what the model knows.

Temperature reshapes the probabilities just before the draw. Lower temperature sharpens them toward the favorite, so the most likely word wins more often. Higher temperature flattens them, so less likely words come out more often. The demos here use a temperature of 1.0, which draws in proportion to the model’s own probabilities.

At the extreme, always taking the single most likely word is called greedy decoding, and in principle it returns the same output from the same model every time. That’s the clearest sign that the randomness is in the draw, not in the model. A lower temperature makes answers more repeatable. It doesn’t make them more correct. It just gives you the favorite every time, and the favorite can be wrong.

On the newest models, you often can’t set it. Temperature is fixed at one value or can’t be changed at all, especially on reasoning models. Reasoning models are trained at a particular setting, and their long chains of reasoning tend to stall or wander when it changes. Fixing it keeps the model behaving the way it was tested. This is inference, not something the companies state plainly.

Last verified September 2026.

Why fluency tells you nothing

Training rewarded the model for predicting the next word well, and post-training rewarded answers people preferred. Correctness was shaped along the way, strongly for things like math and code and unevenly elsewhere. But nothing checks correctness at the moment the words come out. What comes out is text that reads like a good answer, word after word, because each word is predicted from everything before it.

So a wrong answer and a right one look the same. A fabricated citation had real authors, the right journal, and a real volume, and the paper didn’t exist. One word, then one sentence shows two runs of the same question landing on two different research gaps, each reading like a confident claim.

There’s no answering step where a lookup could fail, which is why the model rarely says “I don’t know.” There is only what comes next, and something always comes next. The model can’t tell you when to trust it. That’s the problem the rest of this guide is about.

Last verified September 2026.

Reasoning models

A reasoning model writes out intermediate steps before it answers. The steps are produced the same way as everything else.

Reasoning models, sometimes called “thinking” modes, generate a working-out before the final answer: breaking the problem down, trying an approach, checking it, and trying again. They’re trained, in part, by rewarding correct final answers on problems that can be checked automatically, like math and code. That makes them noticeably better at multi-step problems where a right answer exists.

Three things stay the same.

• It’s still prediction. Every step of the reasoning is predicted word by word, just like the answer. The two principles still hold.
• The shown reasoning isn’t guaranteed to be how the answer was reached. It reads like an explanation, and it’s fluent for the same reason everything else is. Treat it as more output, not as a record of the model’s process.
• The answer still needs checking. Reasoning helps most where a right answer exists and could be checked anyway. It helps least on questions with no right answer, where the reasoning can make a default answer look considered.

Reasoning models are also slower and cost more, and they’re the ones that usually don’t let you set temperature. See Temperature.

Last verified September 2026.

Agents

An agent is a model in a loop. It decides on a step, uses a tool, reads the result, and decides the next step.

The tools can be a web search, running code, reading and writing files, or acting in other software. An agent asked to “find recent papers on X and summarize them” might search, open several results, write notes, search again, and then write the summary, without you seeing each step.

Everything in this guide still applies, with three additions.

• Every tool result becomes context. Search results, pages, and files the agent reads all shape what it predicts next, and you may never see them.
• Errors compound. A wrong step early on becomes the starting point for every step after it, and the final output reads just as fluently.
• The blast radius grows. An agent that edits files or runs analyses can change a lot before anyone checks. Check intermediate results, not just the final one.

Agents are covered hands-on in Lab 3.

Last verified September 2026.

What this means for research

There are two places you get to intervene. What you put in, and what you do with what comes back.

Context

Context doesn’t make the model smarter. It changes which words have a real chance of being drawn.

Context is everything the model sees before it predicts, and it’s much more than what you typed.

• The prompt. What you typed this turn.
• Attachments. Files you uploaded, a PDF, a spreadsheet, a codebase.
• The conversation. Everything said earlier in the thread, yours and its own.
• Project files and standing instructions. Materials and directions the tool brings in on every turn.
• Memory. What the tool has saved about you across sessions.
• Retrieval. Whatever came back when it searched, read a link, or called a tool.

The model can’t tell these apart. Attachments aren’t consulted and the conversation isn’t remembered. All of it is put together into one block of text, and the model predicts what comes next from the whole thing. That’s the first principle again, with the input in view instead of the output.

That’s why attaching the source works. Asked from memory, the model couldn’t back up its answer. With the paper in front of it, it gave the right number every time and quoted the sentence that reports it. The right answer became the likely continuation. Attaching the source →

Two consequences are worth keeping in mind.

• You often carry context you didn’t choose. Memory, standing instructions, and forty turns of earlier conversation all shape the answer. The same prompt in a fresh thread is a different question. This is how a long thread goes down a rabbit hole and can’t get back out.
• Retrieval puts text you didn’t write into your context. If the tool searched and read a page, that page now shapes the output as much as your own words do. You may not have read it, or even know which page it was.

When the product is doing the work

Chat products add features around the model, and each one puts text in front of it that you didn’t choose.

Everything above describes the model. The products built around it add features, and each feature works by adding to the context.

• Search. When the product searches the web, it puts the pages it found in front of the model, and the answer rests on them. You didn’t choose those pages and may not have read them. Check the sources it shows, not just its summary of them.
• Files you attach. For long files, some products don’t give the model the whole document. They pull out the passages they judge relevant, so the model can miss the part you cared about. Ask it to quote the passage it’s relying on.
• Memory and custom instructions. What the product has saved about you goes into every conversation. In Same question, different models, ChatGPT with memory on answered with topics from the asker’s own research, which were never typed into the prompt. When you want an answer that isn’t shaped by you, turn memory off or use a temporary chat.
• The company’s own instructions and safety layer. Every product adds instructions you never see. It’s one reason the same model can answer differently in the chat product and through the API.

A rule of thumb: whenever a product feature is involved, part of your context was chosen by the product.

Long documents and context limits

A model can only take in so much at once, and it doesn’t pay equal attention to all of it.

The context window is the most text a model can take in at once, counted in tokens. Current models can hold a lot, often several long papers. But what happens near and past the limit matters.

• Past the limit, something gives. Products drop or summarize text to make it fit. In a very long conversation, the earliest turns can quietly fall out of what the model sees.
• More isn’t always better. Researchers have found that models use information at the beginning and end of a long input more reliably than information in the middle (Liu et al., 2024). Newer models have improved, but the pattern is a reason not to bury the part that matters.
• Everything you add competes. Twenty attached papers don’t give the model twenty times the understanding. They give it more text to predict from, most of it beside the point.

In practice, attach the two papers that matter, not twenty. For a long document, point the model to the section you mean, and ask it to quote the passage it relied on so you can check it.

Last verified September 2026.

Verification

A wrong output looks exactly like a right one. Verification is how you go outside the output to find out.

Generating output has become cheap. Checking it hasn’t. You can produce 20 outputs in a minute and verify none of them. The output tells you nothing about its own reliability, so checking is the only thing that does.

Asking the model to check itself isn’t verification. In “Are you sure?”, pushing back produced an apology every time and a new answer that was further from the truth. The question changed the conversation, and the model continued the conversation.

Verification does one of two jobs.

Make it checkable. Turn a claim into something that can be settled outside the model.

• Ask for a DOI for each citation, then follow it, and confirm it’s the paper named. Thirty citations shows why the DOI existing isn’t enough.
• Ask for the quoted passage and the page, then find that sentence in the actual document.
• Ask it to point to where in your material it found something. The claim is grounded there, or it isn’t.
• Run the code. Redo the arithmetic. A compiler can’t be talked round.

Test whether it holds. When nothing can settle the question, you build the test yourself. These give you a signal, not a verdict.

• Run it again cold, in a fresh conversation with none of your framing.
• Run it with no context at all. If you get the same answer, you got the field’s default, not something drawn from your material.
• Try a different model. It has different probabilities and a different most likely answer.
• Ask for the strongest objection first, before you argue back.
• Ask what it left out. Summaries tend to drop the qualification that mattered.

When a right answer exists, almost everything in the first list is available. When it doesn’t, almost none of it is, which is what makes those questions hard. That difference is the next section.

Last verified September 2026.

Two kinds of questions

The type of question doesn’t change what context does. It changes whether verification can back you up.

One test sorts them: if two of us disagreed about the answer, is there something that would settle it?

Type 1: a right answer exists. Citations, code that has to run, arithmetic, what a paper actually says. What makes it Type 1 is that a source exists, whether or not you supply it. Context reaches that source early, by bringing it in. Verification reaches the same source late, by going out to it. Same referee, two different times. Attaching the source makes the check cheap, and without it the check still works, it just costs more. The failure here isn’t misjudging. It’s skipping the check. Attaching the source and Thirty citations show both halves.

Type 2: no right answer exists. Framing, positioning, which literature you’re in, what the contribution is. There is no source to go out to, so the standard has to come from you. You can’t judge whether the output is good if you never decided what you wanted. Context is your particulars: your paper, your data, your actual position, the two papers you’re really in conversation with. Its job is to point the model at what you intend. Curation beats volume here. Two well-chosen papers narrow the question, and ten add noise. Verification can test whether the output holds up, but it never settles it, so nothing downstream catches a weak setup. The most useful test is asking what would change the output. Where would you apply it? and Same question, different models show both halves.

The words don’t tell you which type you’re asking. “Is this a good framing?” can mean “would the field accept it?”, which the literature could settle, or “is this the right way to see it?”, which nothing settles. Both come back as a fluent paragraph naming a literature. Only what you meant tells you whether you got the field’s default answer or a failure to engage your case. Most real research questions are mixed, and the skill is spotting the parts that have a right answer inside a question that doesn’t.

Type 1 costs you discipline. Type 2 costs you judgment. These tools save the most effort on the easy questions. On the hard ones, they move your effort earlier without reducing it.

Last verified September 2026.

Blast radius

Ask how far a wrong answer would travel. Blast radius doesn’t change how much judgment you need. It changes how much it mattered that the judgment was good.

If this is wrong, what else could be wrong? One sentence, or the whole paper? The bigger the blast radius, the more it pays to set up the input and check the output.

Where a right answer exists, the judgment sits up front, in choosing what source settles it, and the check after that is mechanical. Where none exists, it sits at both ends. The bottom right is the cell to take most seriously. There’s nothing to check against and nothing downstream that will catch a mistake. Your own judgment is the only thing standing there, which is exactly where it was before these models arrived.

Blast radius isn’t fixed. An idea generated as one of six options has a small blast radius until you adopt it and build on it. The check comes due when you adopt it, not when it’s generated.

Last verified September 2026.

Reproducibility and reporting

The same prompt next month may not be the same study. Record enough that someone could tell what you actually ran.

Three things make results from these tools hard to reproduce.

• Models change under the same name. Companies update the model behind a name like “ChatGPT,” and sometimes behind an API name too. Older models are retired and stop being available at all.
• Products change around the model. The instructions a company adds behind the scenes, the tools a product can use, and the memory it keeps about you all shape the answer, and they change without notice.
• Every answer is a draw. Even with nothing else changing, the same prompt gives a different answer next time. See Sampling.

What to record whenever a model’s output feeds into your research:

• the product and the model, with the exact version where one is shown, and the date,
• the settings you controlled, such as temperature, and whether memory, search, or other tools were on,
• the full prompts and anything you attached,
• how many times you ran it, and the outputs you used, saved as they came back.

When the output is part of your analysis, not just help with writing, go further. Use an API with a dated model version where the company offers one, or an open-weight model you can keep. Run it more than once, and report how much the results varied. Put the prompts in an appendix.

What to report depends on the journal. Many ask you to disclose AI use, and what they want disclosed varies. Look up the journal in the journal policy lookup. When in doubt, say which tool you used, for what, and how you checked what it produced.

This site follows its own advice. Each demo gives its model, settings, number of runs, and date, and the probability demos may not be exactly reproducible once gpt-4o is retired.

Last verified September 2026.