What Is a Large Language Model?

What is a large language model?

A large language model, usually shortened to LLM, is an AI model trained to process and generate language. It receives text as tokens, uses patterns learned during training, and predicts likely continuations. That simple description covers many behaviors: answering questions, summarizing documents, drafting emails, translating text, classifying messages, generating code, extracting fields, and helping agents decide what to do next.

"Large" usually refers to the scale of training data, parameters, and computation. Bigger is not automatically better for every task. The right model depends on latency, cost, accuracy, data sensitivity, language support, tool access, and whether the answer must be explainable or auditable.

What LLMs do well

LLMs are strong at language-shaped work. They can turn a rough question into a coherent answer, compress long documents into summaries, generate examples, rewrite copy for a different audience, and help non-specialists interact with technical systems. They are especially useful when paired with retrieval, where the application supplies documents or records for the model to use as context.

LLMs also make automation more adaptive. An agent using an LLM can inspect a page, infer the next action, call a tool, evaluate the result, and try another path. That can be helpful for internal workflows. It can also make scraping, reconnaissance, and abuse less predictable. Instead of following a fixed script, an automated system can vary its route, wording, timing, and strategy based on the responses it sees.

How an LLM application works

The model is only one part of the system. A typical application includes system instructions, user prompts, retrieved context, safety rules, tool definitions, output parsers, and logging. The model sees a context window containing some combination of those inputs and generates output. The application then decides whether to show the output, validate it, call another service, or ask for human approval.

This architecture creates a key distinction: an LLM can suggest, but the application grants authority. If the application lets model output call APIs, change records, send messages, or enforce policy, then the model sits inside an authority boundary. That boundary needs the same care as any other software component that can affect users or systems.

Failure modes

The best-known LLM failure is hallucination: a fluent answer that is false or unsupported. Other failures are just as important. The model may miss context, misunderstand policy, produce insecure code, expose sensitive data, follow malicious instructions, overfit to the prompt wording, or give inconsistent answers to similar questions.

Prompt injection is especially relevant for systems that read external content. A malicious document or web page can contain instructions telling the model to ignore its rules, reveal hidden prompts, or misuse tools. The dangerous part is not that the model read hostile text. The dangerous part is an application that cannot separate untrusted content from trusted instructions.

LLMs can also fail operationally. Costs may spike when prompts grow. Latency may become unacceptable during peak traffic. Retrieval indexes may become stale. A vendor model update may change behavior. A model may answer confidently when the source system is unavailable. These failures are ordinary production risks and should be managed as such.

Security checks for LLM deployments

Start with access. Identify who can use the feature, which data sources it can retrieve, which tools it can call, and which actions require approval. Apply least privilege. A support assistant that summarizes policy articles should not have the same access as a workflow that edits customer records.

Next, test hostile and messy inputs. Include prompt injection, conflicting instructions, sensitive records, missing sources, malformed files, copied web pages, and attempts to extract hidden instructions. If the system uses tools, test whether the model can be tricked into unsafe calls. If it generates code, scan and review the output before using it in production.

Logging needs careful design. Teams often need prompt template versions, retrieved source identifiers, tool calls, model version, and final output to investigate failures. They may not need to retain every raw user input forever. Privacy, compliance, and incident response all need to be balanced before launch.

LLMs and web traffic

LLMs affect websites even when the site does not run an LLM feature. Crawlers gather content for training, retrieval indexes, competitive analysis, and agent workflows. LLM-powered agents may interact with product pages, search endpoints, forms, and APIs in ways that resemble a curious user at small scale and automated extraction at large scale.

Operators should watch for route patterns, repeated high-value page access, unusual timing, residential proxy rotation, missing browser signals, and sessions that behave consistently across changing identities. The goal is not to block all automated access by default. It is to distinguish acceptable indexing or assistance from behavior that drains capacity, copies protected content, or probes sensitive routes.

Governance and review

LLM governance should define approved use cases, allowed data, prohibited actions, review requirements, and fallback behavior. It should also define accountability. If an LLM drafts a response, who owns the final answer? If it recommends a security action, who approves enforcement? If it uses retrieved content, how are sources maintained and removed?

For high-impact workflows, the model should not be the final decision-maker. Use deterministic checks, source grounding, schema validation, rate limits, and human review where mistakes would affect customers, money, access, compliance, or security. Keep model and prompt versions tied to evaluation results so changes can be reviewed like other releases.

Key takeaway

A large language model is a language engine, not an independent source of truth. It can make interfaces easier, analysis faster, and automation more capable. It can also create confident errors and new abuse paths if it is given unchecked authority. The practical discipline is to know what the LLM can read, what it can do, how it is evaluated, and what evidence remains when its output matters.