What Is a Large Language Model? Capabilities, Context and Limits

A large language model (LLM) generates text one piece at a time. Given the conversation so far, it predicts the most likely next piece, a token, which is a fragment of a word or a symbol. It repeats that step until the response is complete. That is the entire mechanism. Everything else people attribute to AI (knowing facts, judging intent, acting on the world) comes from the software wrapped around the model, not from the model itself.

This distinction explains most of the confusion about AI products. A chatbot that sounds knowledgeable is not necessarily knowledgeable. It is fluent. Fluency and accuracy are different properties, and the product you buy needs to bridge them.

TL;DR: An LLM is a statistical text generator, not a database of verified facts. It predicts the next token from patterns in its training data and the context you supply. On its own, it cannot verify claims, look things up, or perform actions. Useful AI systems add a retrieval layer that feeds it evidence and a policy layer that controls what the text may do. Judge a product by how it behaves when the source is missing or stale, not by how smoothly it answers happy-path questions.

What a model does: tokens and probability

A token is the unit an LLM works with. The text you type is split into tokens: whole words ("return"), parts of words ("ing"), punctuation, and other fragments. The model reads a sequence of tokens and assigns a probability to every possible token that could come next. Then it picks one, usually the most likely, sometimes a sampled alternative for variety, appends it, and repeats.

During training, the model's internal parameters (numerical weights) are adjusted so these predictions agree with real text. After training, those parameters encode statistical regularities of language: grammar, common knowledge, reasoning patterns, even tone. This is the "learned parameters" part, and it's where answers get their polish.

But calling the result knowledge is generous. The model stores compressed statistics, not verified propositions. It has never checked a fact or consulted a source. It reproduces patterns that look like facts. Many of those patterns happen to reflect real facts because the training data contained them. Many others don't.

Training versus retrieval: where a fact actually comes from

There are two ways a fact enters an answer: either it was baked into the model's parameters during training, or it was handed to the model at query time. Retrieval is the second path.

Retrieval-augmented generation searches your knowledge base, selects relevant passages, and inserts them into the model's context window before it generates. The model then writes an answer informed by those passages. This is how support bots correctly cite your return policy or how research tools quote a paper.

If nothing is retrieved, the model improvises from its latent statistics. Ask a support bot about your return window while its context lacks the policy, and it will generate a plausible window anyway, statistically plausible retail language like "within 30 days." It isn't lying in any intentional sense; it's completing the pattern. The failure belongs to the system that sent the model into the conversation without evidence.

Inference: how a response is actually produced

Inference is the term for using a trained model. The process is humble:

1. Your question, along with system instructions, retrieved documents, and message history, is tokenized.
2. All those tokens become the context.
3. The model computes a probability distribution over the next token.
4. It samples one token, adds it to the context, and repeats until an end-of-response token appears.

Every step conditions on everything that came before. That makes the context the single most important input. Good context means relevant, recent, well-organized tokens. Bad context means noise, outdated documents, or a flooded window.

Context is also finite. Anthropic's context engineering guidance describes an "attention budget": every additional token depletes focus, and as context grows, models become less precise at recalling earlier information, a phenomenon the researchers call context rot. Performance degrades gradually, not at a hard limit; but longer is not better. Smart systems curate aggressively, retrieving just what matters and dropping what doesn't.

A support answer, traced end to end

Put the pieces together for a realistic exchange. A customer asks: "What's your return window?"

1. Routing. A classifier, often the model itself, identifies the intent as a returns question.
2. Retrieval. The system searches the knowledge base and places the return-policy article into the context.
3. Generation. The model reads the policy and writes: "We accept returns within 30 days of delivery, unopened."
4. Policy check. A guardrail layer validates the draft against display rules: correct tone, no invented details, appropriate refusal if needed. It also keeps credential collection out of the chat: passwords, admin tokens, and one-time codes belong in a secure login or verification screen, never in a request to the model.
5. Action. Any follow-up, such as sending a prepaid label or opening a return case, is executed by program code, not by the model. If the action touches a customer account, the software first confirms an authenticated session and object-level permission. An email address or order number typed into chat is a lookup key, not proof of identity. For a guest, the system can send a secure link to the stored contact address instead of exposing records in chat. After the call, the software verifies the result against the authoritative record: a 200 or 202 response means the request was accepted, not that the case exists. If a timeout occurs, inspect the operation state before retrying, and use an idempotency key to avoid duplicate actions.

Now rerun the scenario with a broken retrieval step. The search returns nothing useful, but the model still generates. It produces "within 14 days" because that's a common retail pattern. The customer leaves with plausible, wrong information. Nothing about the model malfunctioned in the way a buyer would expect; the system's evidence pipeline failed silently.

This is why the useful question is never "which model?" but "what happens when the model has no source?" The answer separates a product from a demo.

Why fluency, benchmark scores, and agent success differ

A model that excels on a public benchmark can still fail at your task. The reasons are concrete:

• Task mismatch. Benchmarks measure general capability. Your task has domain-specific vocabulary, constraints, and edge cases.
• Context sensitivity. The same model performs differently depending on what fills its context. A cluttered or adversarial context drags down any model.
• Compounding errors. Agents, meaning LLMs that call tools in a loop, accumulate mistakes. A slightly wrong retrieval early in a multi-step process propagates into a wrong final action.
• Invisible uncertainty. The model assigns probabilities to every token but reports none. A fabricated detail looks as polished as a verified one.

Agents add power but also surface. Anthropic's agent guidance defines agents as LLMs autonomously using tools in a loop. That loop multiplies both usefulness and failure modes. The systems that work keep the loop narrow, the tools well-defined, and the decisions reversible.

What you're actually buying

Forget the hype about the model. You're buying three layers:

1. The model, which renders language. Heavier models cost more; some platforms meter usage through credit pools that drain faster with heavier models. Ask which model your agent runs and what that costs per interaction.
2. The retrieval layer, which decides what the model sees. If this is weak, a stronger model will merely write more convincing wrong answers.
3. The policy and action layer, which limits what the text may do: send, refuse, escalate, or trigger an order. It also decides whether a requested action is permitted for the authenticated user and whether the backend actually completed it. Without clear refusal rules, the bot answers whatever it's asked. This is where a support deployment meets its bill, because a wrong answer that gets counted as a resolution is an answer you paid for.

Security reviews reinforce this. OWASP's Top 10 for LLM applications focuses on systemic issues like prompt injection, sensitive data disclosure, insecure output handling, and excessive agency rather than the weights themselves. NIST's AI Risk Management Framework likewise treats risk as a property of the whole AI system, not the model card. The vulnerability story is a system story.

How to evaluate an LLM product

Skip the parameter count; it won't tell you how the model handles your content. Run these checks instead:

• Grounded question: Does the answer cite or quote the source?
• Missing source: Does the system refuse, or invent a pleasant fiction?
• Stale source: Update the policy; does the next answer reflect the change?
• Refusal boundary: Can a user steer the bot into violating your rules?
• Escalation: Does it hand off to a human when it can't verify?
• Outcome verification: After an action, does the system confirm the authoritative record rather than trusting a 200/202 response?

A vendor who passes all six has engineered a product. One who shows you a highlight reel has shown you a model. For more depth on the product side, see how AI agents are built, what RAG actually does, and how prompt engineering shapes behavior beyond the model.

Frequently asked questions

Does an LLM actually know facts? No. It predicts text that looks like facts based on patterns from training. Unless a retrieval layer injects a source into the context, the model can't verify anything. Treat its statements as drafts to be confirmed against evidence.

Why does my chatbot give confident wrong answers? Fluency is separate from accuracy. When the context contains no relevant source, the model extrapolates from statistical patterns, producing plausible-sounding content. Fix it by adding retrieval, requiring citations, and routing unverifiable cases to humans.

What is context, and why does it matter? Context is everything the model sees before generating: system instructions, retrieved documents, conversation history. It's a finite resource. As it grows, precision drops; researchers describe this as context rot, so systems must curate what goes in.

What's the difference between a model and an agent? A model generates text. An agent is a model plus tools and a loop, able to search, call APIs, and act. That adds leverage and risk: errors compound across steps, so agent autonomy should match your tolerance for failure.

Do bigger models mean better results? Not necessarily. Parameter counts say little about performance on your specific task with your context. A small model with clean retrieval and strict policy often beats a large model fed garbage. Test behavior, not specs.

How do I stop a bot from hallucinating? Ground it in retrieved documents, require citations, add explicit refusal rules when no source matches, and route low-confidence answers to a human. Hallucination is a system property; control it at the system level.

The practical takeaway

An LLM is a remarkable text generator with no internal grasp of truth. Its worth in a product depends entirely on the plumbing around it: retrieval that brings evidence, policy that restrains action, and humans in the loop where consequences bite. Evaluate against failures, not demos, and you'll see quickly which tools ship a system and which ship a model with a friendly interface. If you're shopping for a support deployment, use the helpdesk comparison or start from the AI agent buying guide to weigh those layers against your workflow.