Large Language Model (LLM)

Large language model (LLM) is a type of deep-learning model trained on large collections of language data to learn statistical patterns in sequences of tokens and perform a wide range of language-related tasks. Depending on its architecture and training, an LLM can generate text, answer questions, summarize documents, translate languages, classify information, produce computer code, and work with structured inputs. Modern generative LLMs commonly use the transformer architecture and generate responses by predicting tokens in context. Other large language models, including encoder-based systems, are designed primarily for language representation or analysis rather than open-ended text generation.

LLMs are an important technology within artificial intelligence, machine learning, and natural language processing. They power many applications of generative artificial intelligence, but an LLM is the underlying model rather than the complete chatbot, search service, or automated workflow. An application may add document retrieval, software tools, identity controls, business rules, and human approval around the model. The term large describes scale in training data, model capacity, or computational resources; there is no universally agreed minimum parameter count that makes a language model an LLM.

An LLM's ability to produce fluent output does not by itself establish that the output is accurate, current, authorized, or suitable for a consequential decision. These properties have to be evaluated in the context of the complete application and its intended use.

Purpose and scope

The purpose of a large language model is to learn reusable representations of language that can support many tasks instead of requiring a separate language-processing system to be built and trained for every task. The same model may draft a report, interpret a question, classify an email, extract fields from a contract, or explain a programming error when supplied with appropriate instructions and context. Whether it performs any particular task reliably depends on its training, adaptation, input quality, and evaluation.

The scope of the term includes models that analyze language as well as models that generate it. Some systems marketed as LLMs also accept images, audio, or video. In those cases, language remains an important part of the model's design, but the deployed system may be better described as a multimodal model. An LLM is not necessarily an autonomous system, a search engine, a verified knowledge base, or a substitute for an accountable decision-maker.

How large language models work

Tokens and representations

An LLM processes input as tokens: units that may represent whole words, parts of words, characters, punctuation, or other symbols. A tokenizer converts text into token identifiers; the model maps these identifiers into numerical representations called embeddings. Processing tokens rather than entire sentences allows the model to work with combinations it did not encounter exactly during training. Token boundaries vary by model, so the number of tokens in a document is not the same as its word count.

The model learns patterns across these representations. It can use the surrounding sequence to interpret an ambiguous word or infer an appropriate continuation. For example, the meaning of bank in a discussion of finance differs from its meaning in a description of a river. This contextual capability is one reason modern LLMs are useful across multiple language tasks.

Transformers and attention

Most widely deployed modern LLMs use transformer neural networks. Transformers employ attention mechanisms that allow the model to weigh relationships between elements of an input sequence. The original transformer architecture, described in the 2017 research paper Attention Is All You Need, was designed to process sequence data more efficiently than earlier architectures built around recurrence.

Different transformer arrangements serve different purposes. Encoder-focused models produce representations useful for classification and information extraction. Decoder-focused models are widely used for open-ended generation. Encoder-decoder models can transform one input sequence into another, as in translation or summarization. These distinctions are architectural tendencies, not an exhaustive taxonomy of every contemporary language model.

Generating a response

For a typical autoregressive, generative LLM, the application supplies a prompt and any additional context. The model estimates a probability distribution over possible next tokens, selects a token using a decoding method, adds that token to the sequence, and repeats until the response is complete or a stopping condition is reached. This process is known as inference.

Generation can vary with the prompt, model version, decoding settings, and available context. Sampling settings affect how outputs are selected, but setting them to be less variable does not create a guarantee of factual accuracy. Models can produce useful analyses and solutions using learned representations and inference-time computation; nonetheless, a plausible response is not the same as an independently verified answer.

Context windows and external information

The context window is the bounded amount of tokenized information the model can use in a particular invocation. It may include user instructions, earlier conversation, selected documents, and tool results. A larger context window permits more material to be considered, but neither guarantees attention to every relevant detail nor creates permanent memory of that material.

A model's trained parameters are different from the information provided in a prompt. Updating an external document, adding a message to a conversation, or retrieving a source does not automatically retrain the model. If an application offers persistent memory, database access, web search, or file retrieval, those are additional system functions rather than inherent properties of every LLM.

Main technical components

The following elements explain the structure and behavior of a typical LLM. Not every model implements them in precisely the same way.

Element	Function	Why it matters
Tokenizer and vocabulary	Convert text into units the model can process and generate.	Affect token counts, language handling, input limits, and usage costs.
Embedding representations	Turn token identifiers into vectors that the network can process.	Help represent relationships used in language processing; they are distinct from a separate application's search-index embeddings.
Neural-network architecture	Organizes layers and computation; transformers commonly use attention and feed-forward layers.	Influences the kinds of inputs and outputs the model supports and the resources needed to operate it.
Parameters or model weights	Store numerical values learned during training.	Affect learned capabilities but are not a database of individually verified facts.
Attention and positional information	Use contextual relationships and sequence information when processing inputs.	Help the model respond differently to the same word in different contexts.
Context window	Sets the amount of input and generated context handled within a model invocation.	Limits the documents, history, and instructions available for a particular response.
Decoding and inference configuration	Determine how output tokens are selected and when generation stops.	Influence response variation, latency, and length.

The model is only one component of an enterprise LLM application. Interfaces, permissions, retrieval indexes, monitoring systems, workflow integrations, and approval gates belong to the larger application architecture.

Training and adaptation

Pretraining

An LLM is typically pretrained on a broad collection of data using learning objectives that derive training signals from the data itself. Autoregressive models often learn by predicting the next token; other model types may predict masked or missing tokens. Training adjusts model parameters to reduce prediction error over many examples. Data selection, quality, permissions, and filtering affect what the model can learn and what risks may be inherited from its training corpus.

Pretraining produces general capabilities, but a base generative model may continue text without responding consistently to instructions. Training at large scale requires significant data and computation; the costs and resources vary considerably across model designs.

Post-training and instruction following

Additional supervised training can teach a model to respond to instructions, follow dialogue conventions, or meet specific response-format expectations. Preference optimization and reinforcement-learning methods may further shape its behavior based on chosen objectives and feedback. These methods can improve usefulness and alignment with desired behavior, but do not prove that every output is correct or safe.

Ways to adapt an LLM

Organizations can adapt a model to a particular task without necessarily undertaking new pretraining. These methods have different mechanisms and should not be treated as interchangeable.

Adaptation method	What changes	Appropriate use and limitation
Prompting and in-context examples	Supplies instructions, constraints, examples, and task data within the model's input.	Often sufficient for drafting or classification; does not permanently alter trained parameters.
Retrieval-augmented generation (RAG)	Retrieves external material and adds relevant passages to the input context.	Useful for organization-specific or changing information; output still needs grounding and access-control checks.
Fine-tuning	Updates model parameters using additional training data and objectives.	Can improve domain behavior, formats, or specialized tasks; requires governed training data, testing, and ongoing evaluation.
Tool and application integration	Gives the surrounding application controlled access to search, calculations, records, or business functions.	Allows actions and verification beyond text generation, but introduces permission and security risks.

RAG is particularly important in enterprise applications because a foundation model's training data may not include current internal policies, customer records, or changing operational information. A retrieval system can provide relevant, access-controlled source material to the model. It can also return citations if the application preserves and presents source metadata; RAG alone does not guarantee that the answer faithfully follows those sources.

Types and variants of large language models

There is no single classification system that captures all LLM designs. The following distinctions describe different characteristics and can overlap within one model.

• Generative and representation-oriented: Generative models produce sequences of text or other tokens. Representation-oriented models are often adapted for classification, extraction, search relevance, or other analytic tasks.
• Base and instruction-tuned: A base model has broad pretrained capabilities; an instruction-tuned model has additional training intended to improve responsiveness to user requests.
• General-purpose and domain-adapted: A general model supports a wide task range, while a domain-adapted version may prioritize a field such as software development, finance, or scientific language.
• Text-centered and multimodal: Text-centered models work primarily with language. Multimodal models may accept images, audio, and other data while retaining substantial language capability.
• Dense and mixture-of-experts: Some models use the same main parameter set for a given computation; others route parts of the computation through selected expert components. An architecture label by itself does not determine performance.
• Hosted, open-weight, or locally deployed: Models can be accessed through hosted services or operated under different distribution and licensing arrangements. Open weights does not necessarily mean that source code, training data, or commercial usage rights are fully open.

Model size is also a variable, not a quality grade. Smaller models may perform well on narrow tasks at lower latency and cost, while larger models may be preferable for a broader or more demanding workload. Selection requires testing against the actual task, operating environment, and constraints.

Capabilities and enterprise applications

Large language models support a variety of enterprise applications. The value of an LLM depends on how the model is connected to authoritative data, integrated into work, and supervised where errors would matter.

Application	Typical LLM contribution	Required surrounding capability or check
Knowledge assistance	Summarize policies, answer questions, and explain technical documentation.	Authoritative retrieval, permissions, source citations, and escalation of unsupported answers.
Service and customer support	Draft responses, interpret requests, and suggest next actions.	Accurate customer context, service rules, privacy controls, and human escalation.
Software engineering	Explain code, generate tests, suggest changes, and translate technical requirements.	Code review, automated testing, dependency scanning, and secure development controls.
Document processing	Extract fields, classify documents, and draft structured summaries.	Defined schemas, validation, exception handling, and comparison with original documents.
Research and analysis support	Organize evidence, generate candidate explanations, and prepare summaries.	Source verification, quantitative checking, and separation of facts from model-generated hypotheses.
Communication and localization	Draft, revise, or translate text for different audiences.	Terminology control, review of consequential wording, and appropriate disclosure.
Workflow assistance	Interpret user intent and prepare or initiate approved actions through tools.	Explicit authorization, least-privilege tool access, transaction validation, and audit records.

A common implementation error is to measure only how fast an answer is generated. A useful organizational assessment also considers whether the output is accepted, the amount of correction required, downstream errors, and the effect on the complete business process.

LLMs in application architecture

An LLM and an LLM-powered application are separate architectural objects. A basic application may send a prompt to a hosted model and display the response. A more complex enterprise system may enforce identity and access rules, retrieve information, apply instructions, call services, verify outputs, route exceptions, and maintain audit records.

For example, an enterprise knowledge assistant might follow this sequence:

1. Authenticate the user and determine which information sources they are authorized to access.
2. Retrieve relevant policy documents and preserve the source identifiers and effective dates.
3. Construct a prompt from the user's question, the retrieved passages, and operating instructions.
4. Invoke the LLM to formulate an answer using the supplied context.
5. Check citations, required fields, sensitive-information exposure, and other application rules.
6. Return the answer, with a route to human review or authoritative source inspection when needed.

This arrangement is one form of RAG. If software additionally permits the application to choose and execute tools or take steps toward a goal, it may form part of an AI-agent system. The language model supplies capabilities to these architectures; it does not, merely by being an LLM, provide the surrounding security, retrieval, transaction, and approval functions.

Limitations and failure modes

LLMs can be effective across many tasks while remaining subject to significant reliability limits. These limits vary with the model, application, language, use case, and evaluation design.

Factual errors and unsupported claims

An LLM may generate information that sounds credible but is false, unverifiable, or inconsistent with supplied documents. This phenomenon is commonly called hallucination or confabulation. Fluency, confidence of wording, or a plausible-looking reference is not proof that a claim is supported. Even answers built with RAG may cite an irrelevant passage or misinterpret a source.

Incomplete or outdated information

A model may lack information about events after its training data cutoff or about private organizational facts. It may also fail to notice an important exception within a long input. External retrieval and tools can address some information gaps, but their existence and quality must be established for the particular application.

Inconsistent and context-sensitive behavior

Different prompts, source order, settings, and model versions can change output quality. An LLM can perform well on common examples but fail on edge cases, ambiguous instructions, non-dominant languages, or unfamiliar document formats. Broad benchmark scores do not replace testing with representative organizational tasks.

Bias, privacy, and intellectual-property concerns

Training data and deployment conditions can produce uneven behavior across users, populations, or contexts. Sensitive information may be exposed through prompts, retrieval systems, logs, or outputs if application controls are inadequate. Training-data rights, contractual restrictions, and ownership of generated outputs can also matter; treatment varies by jurisdiction and applicable agreement.

Cost and operational constraints

Model inference consumes computing resources. Input length, generated output, repeated tool calls, service throughput, and deployment design affect cost and latency. Reliability also depends on provider availability, version changes, integration quality, and fallback arrangements.

Security and governance

An enterprise should treat an LLM deployment as a governed information system rather than assuming that controls built into a model are sufficient. NIST's Generative AI Profile identifies risks that require management across the development and use of generative AI. The OWASP Top 10 for LLM Applications 2025 identifies application-security risks such as prompt injection, sensitive-information disclosure, supply-chain weaknesses, improper output handling, excessive agency, and misinformation.

Governance concern	Practical control or evidence
Authorized use and accountability	Register the application, name a business owner, record its purpose and risk classification, and define approved uses.
Data access and confidentiality	Apply access controls before retrieval; set rules for prompt, output, and log retention; test for sensitive-information disclosure.
Prompt injection and untrusted content	Treat retrieved documents and external tool responses as data, not instructions; constrain what tools can do and test adversarial inputs.
Model and supplier management	Document model/provider/version, licence and contract terms, data-handling assurances, service dependencies, and change notifications.
Output assurance	Require source checks, schema validation, human review, or independent calculations in proportion to the consequence of error.
Operational monitoring	Record suitable logs, incidents, version changes, quality drift, security exceptions, and evaluation results within privacy requirements.
Action permissions	Restrict tool and transaction access to the minimum required, with explicit approval for sensitive or irreversible actions.

AI governance standards and frameworks can organize these controls without replacing legal analysis or task-specific assurance. For example, ISO/IEC 42001:2023 specifies requirements for an organizational AI management system; it does not certify that a particular LLM output is correct.

Responsibility typically crosses several functions: the CIO or IT leadership may oversee technology integration and service operation; a chief AI officer or equivalent executive may coordinate AI policy and adoption; the chief data officer may govern data assets; and the CISO may lead information-security controls. Business owners remain responsible for their operational decisions within the organization's governance arrangements. Titles and reporting lines vary.

Evaluation and performance measurement

LLM evaluation should use tasks and reference standards appropriate to the intended application. No single test score proves general reliability, and a strong generic model may perform poorly with a specific organization's terminology, workflows, or source material.

Evaluation dimension	What to examine	Example evidence
Task effectiveness	Whether outputs meet the intended task requirements.	Correct field extraction against reviewed records; accepted service-response drafts.
Factual grounding	Whether each material claim follows accessible, authoritative evidence.	Claim-to-source verification; citation accuracy; unsupported-claim rate.
Safety and security	Whether the system respects prohibited behaviors, authorization boundaries, and sensitive data controls.	Prompt-injection exercises; access-control tests; adverse-content review.
Consistency and robustness	Behavior across paraphrases, edge cases, languages, context lengths, and model versions.	Repeated test runs and documented failure classifications.
Operational performance	Response time, availability, throughput, and resource consumption.	Latency distribution, error rate, token expenditure, and unit cost.
Business impact	Effects on the complete task and its downstream outcomes.	Time to completion, rework, user acceptance, exception rate, and quality-adjusted savings.

Evaluation cases should preserve their test inputs, expected results, model and application versions, assessor judgments, and known limitations. They should include normal work, difficult edge cases, and adversarial conditions. Results obtained on one task, population, language, or provider should not be treated as universal evidence of performance.

Deployment and sourcing options

Organizations may use an external model through an API, consume it within a managed cloud or software product, deploy permitted model weights in a controlled environment, or combine multiple models and services. These choices affect cost, customization, availability, control over data, model updates, and operational responsibility.

A hosted service may simplify infrastructure management while creating supplier, contract, data-processing, and service-continuity dependencies. A locally deployed model may offer greater control over some processing and integration decisions but requires computing resources, engineering, patching, model governance, and security operations. A hybrid design may route different tasks to different models based on sensitivity or capability needs.

Model selection should be based on evidence of fitness for the actual workload: accuracy, allowed data uses, security, supportability, language coverage, output formats, latency, and total operating cost. Model parameter count, benchmark position, or popularity is an incomplete basis for a sourcing decision.

Organizational example

Consider a hypothetical company that wants employees to ask questions about current internal travel and expense rules. The company has several versions of policies, departmental exceptions, and documents that users may not all be authorized to see.

The language model is chosen for its ability to interpret questions and explain policy text. A separate retrieval layer indexes approved policy documents, attaches effective dates, and restricts search results to the user's permissions. The application asks the model to answer using the retrieved passages and to report when no relevant rule can be established. It presents links to the source policies and directs uncertain or disputed cases to a human policy owner.

The organization tests the complete system with questions involving old rules, conflicting policy versions, exceptions, attempted access to restricted documents, and deliberately misleading retrieved text. It measures whether citations actually support the answers, how often humans must correct outputs, and whether employees reach the correct policy faster than through the existing search process.

This is an illustration, not a verified deployment or a claim of achieved savings. It shows why the capabilities of the LLM, the accuracy of the retrieved information, the authorization design, and the business process must be assessed separately.

History and development

Large-scale statistical language modeling predates contemporary transformers. The introduction of the transformer architecture in 2017 enabled influential new approaches to scaling neural language models. Research on large pretrained models, including the 2020 paper Language Models are Few-Shot Learners, demonstrated that a single model could perform diverse tasks using instructions and examples supplied in its context.

The expression foundation model subsequently became an important way to describe models trained broadly and adapted to many downstream uses. Language models are a prominent subset of this larger family; not all foundation models are language models.

LLM technology continues to evolve through changes in architecture, training, tool integration, multimodal processing, efficiency, and evaluation. Particular vendors, model names, capabilities, rankings, and usage terms may change rapidly; they should not be treated as permanent properties of the category.

Related concepts and distinctions

Concept	Relationship to an LLM
Generative AI	A broader category of AI that creates content in text, images, audio, video, or other forms. Generative LLMs are one important kind of generative model.
Foundation Model	A model trained broadly for reuse across many tasks. Many LLMs qualify as foundation models; the foundation-model category also includes non-language systems.
Natural Language Processing (NLP)	The field concerned with computational language tasks. LLMs are one family of methods used within NLP.
Transformer	A neural-network architecture used by many LLMs. The architecture and the trained language model are different objects.
RAG	An application pattern that combines retrieval with model generation. Retrieval is supplied by external components, not by the language model alone.
AI agent	A system that may use an LLM for interpretation, planning, or tool selection; actions and permissions come from the surrounding system.
Chatbot	A conversational application. A chatbot can use an LLM, but the user interface and business workflow are not themselves the model.
Small Language Model	A language model designed for a smaller operating footprint or narrower constraints. The size distinction is relative rather than a universal performance boundary.

Frequently asked questions

Is an LLM the same as a chatbot?

No. An LLM is a trained model. A chatbot is a user-facing application that may employ an LLM together with prompts, user interfaces, information retrieval, security controls, and conversation management.

Does an LLM automatically search the internet?

No. Internet access, database queries, and enterprise search require additional services or tools. Without those integrations, a model generates responses using its trained parameters and the context supplied to it.

Does an LLM learn permanently from every conversation?

Not necessarily. Information in a conversation may influence responses within the available context, while permanent changes to model weights require separate training or update processes. Whether a service stores, reuses, or trains on interaction data depends on its product configuration, contract, and privacy practices.

Is a larger model always better?

No. Capability depends on architecture, data, training, adaptation, and task. Larger models may be advantageous for some complex work, but smaller models can be more cost-effective or reliable for specific constrained tasks. Direct evaluation is required.

Can an LLM's answers be used for high-stakes decisions?

An LLM may assist with analysis or drafting, but consequential use requires evidence appropriate to the decision: independent verification, controlled data access, performance testing, human accountability, and relevant legal and professional review. Fluency or self-reported confidence is insufficient.

See also

• Artificial Intelligence (AI)
• Generative AI
• Machine Learning
• Deep Learning
• Natural Language Processing (NLP)
• Foundation Model
• Transformer (Machine Learning)
• Retrieval-Augmented Generation
• Prompt Engineering
• MLOps
• AI Governance