What Are Large Language Models (LLMs)? The Complete Guide

What is a large language model?

A large language model (LLM) is an artificial-intelligence system trained on enormous amounts of text to predict language — and, through that prediction, to answer questions, write, summarise, translate, reason through problems, and hold a conversation. When you type a message into ChatGPT, Claude, or Gemini, an LLM is the engine that reads what you wrote and produces a reply, one small piece of text at a time.

The name describes the thing precisely. It is large — trained on a substantial fraction of the public internet, books, code, and other writing, using models with billions of internal parameters. It is a language model — its native task is understanding and generating human language. And it is a model — a mathematical system that has learned statistical patterns in how language works, rather than a database that stores and looks up facts.

That last point is the one most people miss, and it explains almost everything an LLM does well and everything it gets wrong. An LLM does not "know" facts the way an encyclopaedia does. It has learned, from examples, which words tend to follow which other words in which contexts. That sounds trivially simple. It is not: at sufficient scale, learning to predict the next word forces a model to absorb grammar, facts, reasoning patterns, tone, and a working model of the world — because all of those things shape what word comes next.

This guide explains how that works, from the ground up. You will not need any maths. By the end you will understand what an LLM actually is, how it is built, why it behaves the way it does, which models matter in 2026, how to get better results from them, and how they are quietly rewiring the way people find information — including the large language model that may be reading this page right now.

The short version: how an LLM actually works

Before the detail, here is the whole idea in one paragraph. An LLM is a next-word-prediction machine. You give it some text — a question, an instruction, a half-finished sentence. It converts that text into numbers, runs those numbers through a very large network of learned weights, and produces a probability for every possible next word. It picks one, adds it to the text, and repeats the whole process — now predicting the word after that. Do this a few hundred times and you have a paragraph. That is genuinely all an LLM does at the moment it answers you: predict the next piece of text, over and over, extremely fast.

Everything else — the apparent intelligence, the reasoning, the code, the poetry — is an emergent consequence of doing that one task well, at a scale that was not computationally possible until recently. The model is not planning a whole answer in advance. It is choosing the most plausible continuation at each step, guided by everything it learned in training and everything you put in your prompt.

Three ideas do the heavy lifting, and the rest of this guide unpacks each one:

• Tokens — the pieces of text a model reads and writes, which are usually chunks of words rather than whole words.
• The transformer — the neural-network architecture, built around a mechanism called attention, that lets a model weigh how every word relates to every other word.
• Training — the multi-stage process that turns a blank network into something that can follow instructions helpfully and safely.

Tokens: how a model reads and writes

An LLM does not see letters or words the way you do. It sees tokens — the atomic units of text it was built to process. A token is often a whole short word, but longer or rarer words get split into pieces. As a rough rule of thumb, one token is about four characters of English, and 100 tokens is roughly 75 words.

For example, the word "cat" is a single token. The word "unbelievable" might be split into "un", "believ", and "able" — three tokens. A space usually belongs to the token that follows it, and punctuation is its own token. This is why an LLM can confidently handle words it has never seen: it reassembles them from familiar fragments, the same way you can read a made-up word like "flurgle" by sounding out its parts.

Tokens matter for practical reasons far beyond theory. You are almost always billed by the token — both the tokens you send (your prompt) and the tokens the model generates (its answer). The model's memory limit, its context window, is measured in tokens. And because the model reads token by token, it can occasionally stumble on tasks that require seeing individual letters — famously, counting how many times the letter "r" appears in "strawberry," because it sees the word as a couple of tokens, not a string of letters.

Turning text into tokens is called tokenisation, and every model family has its own tokeniser. That is a small but real reason the same prompt can cost slightly different amounts, or fit differently, across ChatGPT, Claude, and Gemini. When you hear that a model has a "200,000-token context window," that is the tokeniser's units — roughly 150,000 words, or a decent-sized book, that the model can hold in view at once.

Embeddings: turning words into numbers

A neural network cannot do arithmetic on the word "dog." So the first thing an LLM does with each token is convert it into an embedding — a long list of numbers (a vector) that represents the token's meaning as a point in a high-dimensional space.

The magic of embeddings is that meaning becomes geometry. Tokens with similar meanings end up near each other in this space. "King" sits close to "queen," "monarch," and "throne," and far from "carburettor." Relationships become directions you can move along: the step from "king" to "queen" is roughly the same step as from "man" to "woman." The model is not told any of this. It discovers these relationships on its own, because representing meaning geometrically is what lets it predict the next word accurately.

Embeddings are also the foundation of much of the AI tooling built around LLMs. When a system needs to find documents relevant to your question — the retrieval step in retrieval-augmented generation — it usually converts both your question and every candidate document into embeddings and looks for the ones closest together in vector space. This is semantic search: matching on meaning rather than exact keywords, which is why it can connect "how do I make my site load faster" to a page titled "improving Core Web Vitals" even though they share almost no words.

So the pipeline so far: your text becomes tokens, and each token becomes an embedding — a vector the network can actually compute with. Now the real work begins.

The transformer: attention is the breakthrough

The architecture behind every modern LLM is the transformer, introduced by Google researchers in a 2017 paper memorably titled "Attention Is All You Need." Before the transformer, models processed text word by word in sequence, which made them slow to train and forgetful over long passages. The transformer changed that by letting a model look at all the words at once and learn how they relate.

Its central mechanism is attention. For every token it processes, the model asks: which other tokens in this text should I pay attention to, and how much? Consider the sentence "The trophy would not fit in the suitcase because it was too big." What does "it" refer to — the trophy or the suitcase? To predict well, the model must attend strongly to "trophy." Change "big" to "small" and the correct reference flips to "suitcase." Attention is the mechanism that lets the model resolve exactly this kind of dependency, across a whole document, for every word simultaneously.

A transformer stacks many layers of attention on top of each other — dozens, sometimes over a hundred. Early layers tend to capture surface patterns like grammar; later layers capture abstract structure like intent, logic, and style. Between the attention layers sit ordinary neural-network layers that transform the information further. The numbers that control all of this — how strongly each connection fires — are the model's parameters, and the largest models have hundreds of billions of them. "Training a model" means finding good values for every one of those parameters.

Crucially, the transformer is parallel: it can process an entire passage in one pass rather than crawling through it word by word. That parallelism is what made it possible to train models on internet-scale text using thousands of specialised chips (GPUs and TPUs) at once. The transformer did not just improve language models; it made today's LLMs economically feasible to build.

Training a model: pretraining, fine-tuning, and alignment

A newly created model is useless — its billions of parameters are random numbers, and it produces gibberish. Turning it into something helpful happens in stages.

Stage one: pretraining. The model is shown a vast corpus of text — web pages, books, articles, code, reference material — and given one relentless task: predict the next token. Over trillions of tokens and weeks or months of computation on enormous clusters of chips, it gradually adjusts its parameters to get better at that prediction. This is where the model absorbs grammar, facts, reasoning patterns, and a rough model of the world. Pretraining is by far the most expensive stage, costing millions to hundreds of millions of dollars in compute. The result is a base model: fluent, knowledgeable, but undirected — it will happily continue your text without any sense that it is supposed to be helpful.

Stage two: fine-tuning. The base model is then trained further on carefully curated examples of the behaviour you want — questions paired with good answers, instructions paired with correct responses. This instruction tuning teaches the model to behave like an assistant: to answer the question you asked rather than, say, generate ten more questions like it.

Stage three: alignment. Finally, the model is shaped by human (and increasingly AI) feedback, most commonly through a technique called reinforcement learning from human feedback (RLHF). Reviewers compare pairs of model responses and indicate which is better; the model learns to produce answers people prefer — more helpful, more honest, less harmful. This stage is why modern assistants feel polite, cautious, and generally on-task. It is also where a model's "personality" and safety behaviour are largely set. Anthropic's approach, Constitutional AI, is a well-known variant that uses a written set of principles to guide this feedback.

Two consequences fall out of this process and matter constantly in practice. First, a model has a knowledge cutoff: it only knows about the world up to when its training data was collected. Anything after that — recent news, this week's prices — it has not learned, which is one reason retrieval and web access matter so much. Second, the model's helpfulness is trained in, not innate. The same underlying network could be tuned to behave very differently; the assistant you talk to is a deliberately shaped product, not a raw intelligence.

Inference: what happens when you hit enter

When you send a message, the model runs in inference mode — using its trained parameters to generate a response. Understanding this moment demystifies a lot of LLM behaviour.

Your entire conversation so far — the system instructions, your earlier messages, and your latest one — is fed in as tokens. The model processes all of it and produces a probability distribution over its whole vocabulary for the very next token. Then it samples one token from that distribution, appends it, and repeats. Each new token is chosen with the full preceding text in view. This is why answers stream out word by word: you are watching the model think in real time, one token per step.

A setting called temperature controls how adventurous the sampling is. At low temperature, the model almost always picks the single most probable next token — output is focused, consistent, and repetitive, which is what you want for code or factual answers. At high temperature, it samples more freely from less-likely options — output is more varied and creative, but also more prone to wandering. This one dial is much of the difference between an LLM that feels robotic and one that feels imaginative.

Two facts about inference explain behaviour people find puzzling. First, because generation involves sampling, the same prompt can give different answers each time — the model is not broken; it is drawing from a distribution. Set temperature to zero and outputs become nearly deterministic. Second, the model has no memory between separate conversations unless the application deliberately stores and re-feeds earlier context. Within a single chat it "remembers" only because the whole transcript is re-sent with every message. The intelligence lives in the fixed parameters; the conversation lives in the context you supply.

The context window: a model's working memory

The context window is the maximum amount of text — measured in tokens — that a model can consider at once. It is the single most important practical limit to understand, because it governs how much the model can actually pay attention to when it answers.

Everything competes for space in that window: the system prompt that defines the assistant's behaviour, any documents or data you have supplied, the entire back-and-forth of your conversation, and the answer being generated. When a conversation grows longer than the window, the oldest content has to be dropped or summarised — which is why a very long chat can seem to "forget" what you said at the start.

Context windows have grown dramatically. Early models handled a couple of thousand tokens — a few pages. Leading 2026 models handle hundreds of thousands, and some reach into the millions — enough to hold entire books, large codebases, or long document sets in view at once. This has quietly transformed what LLMs are useful for: you can now paste in a full contract, a research paper, or a sprawling codebase and ask questions grounded in the actual material rather than the model's general training.

But a bigger window is not a free lunch. Models can suffer from a "lost in the middle" effect, attending most reliably to information at the very start and very end of a long context and skimming what sits in between. Processing more tokens also costs more and runs slower. And a large context window is not the same as long-term memory — close the chat, and unless the product saved it, the model retains nothing. Managing the context window well — deciding what to include, in what order, and how to keep it focused — is one of the core skills of working effectively with LLMs, and the discipline behind it is often called context engineering.

Why models hallucinate — and what it means

The most important limitation to internalise is that LLMs hallucinate: they sometimes produce statements that are fluent, confident, and completely false. A model will invent a citation, a statistic, a court case, or an API that does not exist, and present it with exactly the same assurance as a true fact.

This is not a bug that a patch will one day fully remove. It is a direct consequence of how the technology works. The model is a next-token predictor optimised to produce plausible text, not true text. It has no built-in fact-checker and no internal flag that distinguishes "I know this" from "this sounds right." When it lacks the information to answer, generating a confident, well-formed guess is often more probable — given its training — than admitting uncertainty. Fluency and truth are correlated in its training data, but they are not the same thing, and the model optimises for the former.

Understanding this reframes how you should use LLMs. They are extraordinary at tasks where plausibility is the goal — drafting, rephrasing, brainstorming, explaining familiar concepts, transforming text from one form to another. They are riskier for tasks where a specific fact must be exactly right — names, numbers, dates, quotes, legal or medical specifics — especially anything obscure or recent. For those, you verify, or you use a system that grounds the model in real sources.

That grounding is precisely what the next technique provides, and it is the single most effective way to reduce hallucination in practice.

Retrieval-augmented generation: giving models fresh facts

Retrieval-augmented generation (RAG) is a technique that connects an LLM to an external source of information — a search index, a document library, a company knowledge base — so that instead of answering purely from memory, the model answers using relevant material fetched at the moment you ask.

The flow is straightforward. When you ask a question, the system first retrieves the most relevant documents — usually via the semantic (embedding-based) search described earlier — then places those documents into the model's context window alongside your question, with an instruction like "answer using the information below." The model now generates its response grounded in real, current, specific text rather than its general training. You can read a fuller definition in the RAG glossary entry.

RAG solves several of the LLM's deepest weaknesses at once. It supplies current information, sidestepping the knowledge-cutoff problem. It supplies private or specialised information the model was never trained on — your internal docs, your product catalogue. And because the model is working from supplied text, it can cite its sources and is far less likely to hallucinate, since the facts are right there in front of it. This is why almost every serious business application of LLMs — customer-support bots, internal assistants, AI search — is built on RAG rather than raw model calls.

RAG is also the mechanism that connects LLMs to your website. When an AI search engine answers a user's question by pulling in and citing web pages, it is doing retrieval-augmented generation across the open web. Whether your page gets retrieved and cited depends on how clearly and credibly it answers the question — which is exactly the concern of generative engine optimization, covered later in this guide.

Tool use and agents: models that do things

An LLM on its own can only produce text. But text can be an instruction — and that insight turns a language model into something that can take actions in the world. This is tool use (also called function calling), and it is one of the most consequential developments in how LLMs are deployed.

The idea is simple. You tell the model about a set of tools it can use — a web search, a calculator, a database query, a calendar, an email sender, a code interpreter — describing what each one does. When the model decides a tool would help, instead of answering directly it emits a structured request: call the weather tool with location = "Tokyo." The surrounding software runs that tool, feeds the real result back into the model's context, and the model continues, now armed with genuine data. A model that cannot reliably do arithmetic can call a calculator; a model with a knowledge cutoff can call a search engine; a model that cannot remember can call a database.

Chain several of these steps together and you get an agent — an LLM that works toward a goal over multiple steps, deciding which tools to use, observing the results, and adjusting its plan. Ask an agent to "research three competitors and draft a summary," and it might search the web, read several pages, take notes, and write a document, looping through tool calls until it is done. The model supplies the reasoning and the decisions; the tools supply the actual capabilities and the connection to real systems.

This agent pattern is the foundation of the current wave of AI products — coding assistants that read your files and run commands, research assistants that browse and synthesise, and workflow automations that string many actions together. It is also why "which model is smartest" is no longer the only question that matters. How reliably a model uses tools, follows multi-step plans, and recovers from mistakes is often what separates a useful agent from a frustrating one.

Multimodality: beyond text

Although "language model" is in the name, the leading 2026 models are multimodal — they process and, increasingly, produce more than just text. The same transformer machinery that handles tokens of text can handle tokens representing pieces of images, audio, and video, once those inputs are converted into a compatible form.

In practice this means you can show a model a photograph and ask what is in it, hand it a screenshot of an error and ask how to fix it, give it a chart and ask it to interpret the trend, or share a diagram and ask it to turn the design into code. Voice conversations work the same way — speech becomes tokens the model understands, and its reply can be turned back into speech. Some models also generate images or audio directly.

Multimodality widens the range of problems LLMs can touch, from reading documents and analysing designs to describing scenes for accessibility. But the same limitations carry over: a model can misread an image or confidently misinterpret a chart exactly as it can hallucinate text. The reasoning is more capable and more general than before; it is not more infallible.

The major models in 2026

The LLM landscape in 2026 is dominated by a handful of model families, each released as a series of successively more capable versions. The differences that matter to most users are less about raw benchmark scores — which are close at the top and change constantly — and more about strengths, ecosystem, price, and how the model behaves in daily use.

A few cross-cutting distinctions are worth understanding because they cut across every family. Open-weight versus closed is the biggest: closed models (Claude, GPT, Gemini) are accessed only through an API or app, while open-weight models (Llama, Mistral, DeepSeek) can be downloaded and run on your own infrastructure — trading some capability for control, privacy, and cost. Model size and tier is the next: every family offers a range from small, fast, cheap models to large, slow, powerful ones, and choosing the smallest model that can do the job well is one of the most effective ways to control cost and latency. Finally, reasoning models — versions tuned to "think" through a problem step by step before answering — trade speed and cost for markedly better performance on hard maths, logic, and coding, and most families now offer them.

You can explore how to get the most out of the leading assistants in the Troiana AI Hub, which has dedicated, workflow-oriented guides for Claude, ChatGPT, and Gemini.

What LLMs are genuinely good at

Cutting through the hype, LLMs have a real and specific set of strengths. They are strongest wherever the task is fundamentally about transforming or generating language, and where fluency and plausibility are close to what you actually want.

• Writing and editing. Drafting, rewriting, summarising, changing tone, fixing grammar, expanding notes into prose or compressing prose into notes. This is the model's home turf.
• Explaining and teaching. Breaking down complex topics, answering follow-up questions, adapting an explanation to a beginner or an expert — as long as the subject is well-covered enough that hallucination risk is low.
• Coding. Writing functions, explaining unfamiliar code, translating between languages, spotting bugs, and generating tests. Modern models are strong enough that AI-assisted development — including vibecoding — has become mainstream.
• Transformation and extraction. Turning messy text into structured data, reformatting, translating between languages, pulling specific fields out of documents. Reliable and enormously time-saving.
• Brainstorming and synthesis. Generating options, exploring angles, and pulling together the themes across a large body of supplied text.

The common thread is that these are tasks where a knowledgeable, fast, tireless collaborator adds value — and where you, the human, remain in the loop to judge and verify. Used this way, an LLM is less an oracle and more a force multiplier: it does not replace your judgement, it accelerates the work around it.

Where LLMs fall short

The weaknesses are as specific as the strengths, and using LLMs well means respecting both.

• Factual precision. As covered, models hallucinate. Any specific name, number, date, quote, or citation — especially obscure or recent ones — needs verification. Confidence is not evidence.
• Currency. A model's knowledge stops at its training cutoff. Without web access or retrieval, it cannot know anything recent, and it may not tell you it does not know.
• Genuine reasoning and maths. Models can simulate step-by-step reasoning impressively, but they can also fail on problems a child would get right, and they make arithmetic slips. Reasoning models and tool use help, but do not fully close the gap.
• Bias. Trained on human text, models absorb human biases — around gender, race, culture, and more. Alignment reduces the worst of it, but it cannot be assumed gone.
• Consistency and determinism. The same prompt can yield different answers, which is a problem for tasks needing repeatability unless you constrain the settings.
• Explainability. A model cannot reliably tell you why it produced an answer. Its stated "reasoning" is generated text, not a faithful trace of its internal computation.

None of these make LLMs unusable — they make them tools with a shape. The professionals who get the most from them are the ones who know exactly where that shape has edges, and design their process to keep a human in charge at those edges.

How to write a good prompt

The instruction you give a model — the prompt — is the single biggest lever you control over the quality of what you get back. Prompting is not a mystical art, but a few reliable principles make an outsized difference.

1. Be specific about what you want. Vague prompts get vague answers. Instead of "write about marketing," say "write a 200-word introduction to email marketing for small e-commerce owners, in a practical, encouraging tone." Every constraint you add — length, audience, format, tone — narrows the model toward what you actually need.
2. Give context. The model only knows what is in its training and what you tell it. Supplying the relevant background, examples, or source material up front dramatically improves relevance and accuracy — and grounds the answer in your facts rather than its guesses.
3. Show an example. If you want a particular format or style, show one. Demonstrating the pattern ("here is an example of the kind of summary I want") is often more effective than describing it. This is called few-shot prompting.
4. Ask for structure. If you want a table, a numbered list, or JSON, ask for it explicitly. Models follow format instructions well, and structured output is easier to use and to verify.
5. Let it reason before it answers. For anything involving logic or multiple steps, inviting the model to "think step by step" or work through the problem before giving a final answer measurably improves accuracy — you are giving it room to work rather than forcing an instant verdict.
6. Iterate. Treat the first answer as a draft. Tell the model what to change — "make it shorter," "more formal," "you missed the pricing section" — and it will refine. A conversation almost always beats a single perfect prompt.

The underlying mindset: you are not typing a search query, you are briefing a capable but literal-minded collaborator who cannot read your intent. The clearer the brief, the better the work. Everything else is refinement.

How LLMs are reshaping search — and why GEO matters

The most far-reaching effect of LLMs is not any single app — it is what they are doing to how people find information. For twenty-five years, searching meant typing keywords and getting a list of links to choose from. Increasingly, people ask a question in natural language and get a single, synthesised answer, assembled by an LLM from a handful of sources it decided to trust.

This shows up everywhere now: AI Overviews at the top of Google results, answer engines like Perplexity, and assistants like ChatGPT, Claude, and Gemini answering questions that used to begin with a search. The mechanism, as we have seen, is retrieval-augmented generation over the web: the engine retrieves relevant pages, reads them, and composes an answer — often citing a few of them.

For anyone who publishes online, this changes the game entirely. If the answer engine does not retrieve and cite your page, you are invisible at the exact moment a decision is being made — and there is no "page two" to climb from. Being the tenth blue link used to be worth something; being un-cited in a generated answer is worth nothing. The discipline of earning a place in those answers is called generative engine optimization (GEO) — sometimes answer engine optimization — and it is the natural successor to SEO for an AI-mediated web.

The good news is that what makes content easy for an LLM to cite is largely what makes it good for humans: a clear, direct answer near the top; self-contained, factual statements a model can lift without distorting; clean structure with descriptive headings, lists, and tables; and credibility that is corroborated elsewhere on the web. Machine-readable signals — structured data, semantic HTML, and an llms.txt file that points engines at your best content — help a model parse and trust you. If you want to go deeper, start with what generative engine optimization is, then compare it with classic search in GEO vs SEO and follow the practical playbook in how to get your brand cited by AI.

The strategic point is simple: LLMs are becoming the layer between your content and your audience. Understanding how they read, retrieve, and cite is no longer a niche technical concern — it is how you stay visible.

How to choose the right model

With several strong families and multiple tiers within each, "which model should I use?" is a genuinely practical question. A few guidelines cut through it.

Match the tier to the task. For simple, high-volume work — classification, short rewrites, extraction — a small, fast, cheap model is usually plenty, and choosing it saves money and latency. For hard reasoning, nuanced writing, or complex code, reach for a larger or reasoning-focused model. Do not pay for the flagship on tasks a lightweight model handles well.

Decide open versus closed. If you need maximum capability with the least effort, a closed model behind an API (Claude, GPT, Gemini) is simplest. If you need to keep data fully in-house, fine-tune deeply, or control costs at scale, an open-weight model (Llama, Mistral, DeepSeek) you host yourself may be the better fit — at the cost of running the infrastructure.

Weigh the ecosystem, not just the model. Integration often matters more than a benchmark point. If your work lives in Google's tools, Gemini's integration counts. If you are building software, a model's coding quality and tool-use reliability matter most. If you value a careful, steerable style for writing and analysis, that is a real differentiator.

Test on your own work. Public benchmarks are a starting point, not an answer. The only test that matters is how a model performs on your actual tasks. Run the same real prompts through two or three candidates and compare the results — the right choice is often obvious within an afternoon, and it may differ from what the leaderboards suggest.

And expect this to keep moving. The pace of releases means today's best choice may be overtaken in months. Building your process around the category of model you need — rather than a specific version — keeps you flexible as the landscape shifts.

A short glossary of LLM terms

A quick reference to the vocabulary in this guide. Each links to a fuller definition where one exists.

• Large language model (LLM) — an AI system trained on vast text to predict and generate language.
• Token — the chunk of text (roughly ¾ of a word) a model reads and writes; the unit of context limits and billing.
• Embedding — a numeric vector representing a token's meaning, so that similar meanings sit near each other in space.
• Transformer — the neural-network architecture, built on attention, behind all modern LLMs.
• Attention — the mechanism that lets a model weigh how each token relates to every other token.
• Parameters — the billions of learned weights that encode what a model knows.
• Pretraining / fine-tuning / RLHF — the stages that turn a random network into a helpful, aligned assistant.
• Inference — the model generating a response from a prompt, one token at a time.
• Temperature — the setting that controls how random versus focused generation is.
• Context window — the maximum tokens a model can consider at once; its working memory.
• Hallucination — a confident but false statement produced by a model.
• Retrieval-augmented generation (RAG) — grounding a model in retrieved documents to improve accuracy and currency.
• Tool use / agent — a model that calls external tools and works toward a goal over multiple steps.
• Generative engine — an AI system that answers questions by synthesising sources rather than listing links.
• Generative engine optimization (GEO) — the practice of structuring content so AI answer engines cite it.

Common questions