Large language models (LLMs) are neural sequence models trained to predict tokens—and then adapted so that token prediction becomes useful instruction following, dialogue, coding help, and tool use. Leading providers such as OpenAI and Anthropic ship widely used LLM APIs, but the mechanics on this page are provider-agnostic. They are a specialized deep architecture for language, not a synonym for all of generative AI, and not a substitute for retrieval systems of record or permissioned AI agents.
This guide owns language-modeling mechanics, tokenization, LLM training and alignment at model altitude, and LLM inference operations. Product surfaces such as AI coding assistants wrap these models under repository and security controls. Cross-modality generative product patterns stay in generative AI. Full corpus ingestion, hybrid retrieval, and ACL-grounded answers stay in RAG. Tool permission loops and kill switches stay in AI agents. Representation learning systems context sits in deep learning; unit-level nets in neural networks; decision-centric classical ML in machine learning; serving substrates in AI infrastructure.
What an LLM actually learns
Capabilities are uneven: a model may write fluent essays and fail simple counting or bind variables incorrectly. Product design should route brittle tasks to tools or deterministic code. Evaluating only happy-path chat transcripts hides these cliffs.
Stochastic decoding (temperature, nucleus sampling) changes output distributions. For tasks that need stability, prefer lower temperature and stronger constraints—and still expect residual variance across seeds.
An autoregressive LLM learns a conditional distribution over next tokens given prior tokens. “Understanding” in product language is a metaphor for useful next-token behavior across many prompts. The same models power conversational AI dialog products when the interface stays chat-centric. The training signal is local (predict the next token) yet the emergent behaviors can look global (following instructions, writing code). Do not confuse fluency with grounded truth or with authorization to act.
Base models complete text; chat/instruction models are further trained to respond as assistants. The same tokenizer and stack can yield very different products depending on post-training. Always name which checkpoint you evaluate—base vs instruct vs tool-tuned.
Scaling laws describe how loss and some capabilities improve with data, parameters, and compute—under assumptions. They do not guarantee safe behavior, domain competence, or calibrated uncertainty. Treat scaling as a planning input, not a moral warrant.
Tokenization and vocabulary effects
Compression ratios differ by language and domain. Budget tokens explicitly in product copy (“paste less”) when users hit limits. Log token counts per request class to forecast cost.
Security note: delimiter tokens and role markers must be hard to forge from user content. Naive concatenation of system and user strings is an injection footgun.
Tokenizers split text into subword units (or bytes) that the model embeds. Tokenization choices affect compression, multilingual fairness, code formatting, and the meaning of “context length” (tokens ≠ words). Rare languages and odd whitespace can explode token counts and degrade quality.
Detokenization bugs, special tokens, and chat templates are production landmines. A prompt that works in a playground can fail in an API if the chat template or role markers differ. Pin tokenizer and template versions beside model IDs.
For exact identifiers (SKU, hex, base64), token boundaries can hurt; constrained decoding and tools often beat hoping the model emits exact strings.
Context windows and long-context failure
Summarize-and-carry strategies and hierarchical memory are product patterns that sit beside raw long context. They introduce summarization error; measure end-task success, not only whether the window fit.
For multi-turn assistants, decide what enters the window: full transcript, sliding window, or structured state. Transcript dumping is the default that becomes the cost and distraction problem.
Context windows bound how many tokens the model can attend to in one forward pass. Longer windows help some tasks and create new failure modes: lost-in-the-middle effects, diluted attention, higher cost, and a temptation to dump entire corpora into the prompt instead of retrieving.
Long context does not retire RAG. Permissions, freshness, and citations still need retrieval engineering. Longer context also does not fix hallucinations; it can increase the surface for conflicting evidence.
Evaluate long-context claims with needle-style and realistic multi-document tasks at the lengths you will pay for—not only marketing maxima.
Transformer stacks for language
Context parallelism and KV-cache quantization are serving concerns that interact with architecture. When quality drops after an infra change, include numerical and cache settings in the diff—not only prompt text.
Modern LLMs are typically deep transformer stacks: self-attention, feed-forward blocks, residual paths, and normalization. Positional methods (relative, RoPE-class, etc.) encode order. Mixture-of-experts variants route tokens to sparse experts for capacity at lower average compute. Architecture details matter for infrastructure (memory, parallelism) and for quality—but this page stays at language-system altitude, not a full NN textbook (neural networks).
Decoder-only autoregressive designs dominate chat LLMs; encoder–decoder designs remain relevant for some translation and span tasks. Choose based on product needs and available checkpoints, not nostalgia.
Pretraining data and objectives
Domain midtraining (continued pretrain on specialty corpora) can lift in-domain loss before instruction tuning. It is not a replacement for RAG when documents change weekly. It is also a compliance surface: know what you midtrain on.
Pretraining consumes vast text (and sometimes code) under next-token or related objectives. Data mix—licenses, quality filters, domain coverage, toxicity filters—shapes capabilities and risks. Contamination of eval sets into training data inflates benchmarks.
Enterprises buying APIs rarely see raw mixes; they should still ask about retention, training-on-prompts policies, and domain fit. Self-hosting open weights shifts data diligence onto you for any continued pretrain or midtrain.
Compute and data curation often beat naive parameter counting. A smaller well-curated domain model can outperform a larger general model on in-domain tasks after adaptation.
Instruction tuning and preference optimization
Preference data quality dominates. Noisy or conflicted raters produce muddled assistants. Maintain preference guidelines like labeling guides in classical ML. Track over-optimization against a held-out human panel.
Instruction tuning fine-tunes base models on examples of instructions and preferred responses. Preference optimization (RLHF-class or direct preference methods) further shapes behavior using ranked feedback. These stages create the “assistant” personality and many safety behaviors—and can introduce sycophancy or overrefusal.
Alignment here means model-level preference shaping, not organizational AI governance. Keep that boundary clear. Deep RLHF theory is adjacent; product teams need to know what post-training stage they are buying and how it regresses when the base model changes.
Custom instruction tuning is a form of fine-tuning—method selection and data recipes deepen in the fine-tuning guide when published; here the ownership is how post-training sits in the LLM lifecycle.
Tool calling as an interface, not magic
Multi-tool plans require runtime budgets and idempotency—owned by agent systems. At LLM altitude, ensure the model is trained or prompted to emit valid schemas and to stop when tools fail closed.
LLMs can emit structured tool calls (functions) that external runtimes execute. The model proposes; the gateway authorizes and validates. That split is mandatory. Tool calling without permissions is how prompt injection becomes an incident—see AI agents for control loops.
Schemas, enum constraints, and server-side checks beat prose instructions like “only call safe tools.” Measure tool-argument validity and authorization denials as first-class metrics.
Prompting versus fine-tuning versus RAG boundaries
A frequent anti-pattern is fine-tuning on facts that belong in a corpus. Another is stuffing RAG with style guides that should be short system prompts or adapters. Keep responsibilities separated so updates land in the right layer.
Prompting steers a frozen model with text. Fine-tuning changes weights (or adapters) for durable behavior shifts. RAG supplies external evidence at request time. Use prompting for quick interface control; fine-tuning when style/domain must stick and prompting is unstable; RAG when facts must stay fresh and attributable. Combinations are normal; substitutes are not.
| Approach | Changes | Best for | Fails when |
|---|---|---|---|
| Prompting | Context only | Fast iteration, light style | Needs durable domain voice; long unstable prompts |
| Fine-tuning | Weights/adapters | Stable style/domain skills | Facts churn; you needed retrieval |
| RAG | External corpus | Fresh, citable facts | Corpus/ACLs weak; treated as training |
Evaluation: capability, safety, and regression suites
Release gates should combine automatic checks and sampled human review proportional to risk tier. Consumer doodle bots and medical-adjacent drafting do not share gates. Align with the risk language in artificial intelligence without turning this into a safety encyclopedia.
LLM eval is multi-axis: capability (tasks, coding, reasoning proxies), safety (policy violations, jailbreaks), and regression (your golden prompts). Public leaderboards are weakly predictive of your domain. Build private suites with versioned prompts and graders.
LLM-as-judge helps at scale but needs human calibration. Execution-based tests for code beat prose rubrics when sandboxes exist. Track sycophancy, overrefusal, and multilingual slices.
When providers silently update models, your suite is the only defense. Pin versions; alert on quality deltas.
Hallucinations as calibrated risk
Ask models to cite only from provided evidence when evidence exists; penalize fabricated citations in eval. For numeric tasks, prefer tools. For “I don’t know,” reward abstention on unanswerable sets.
Hallucination is fluent content not entailed by truth or provided evidence. It is not one bug; it includes fabrications, bad citations, and unsupported merges of retrieved snippets. Mitigation layers: RAG with faithfulness checks, tools for calculations, abstention policies, and UI that separates draft from claim.
Bigger models and longer contexts can reduce some errors and create others. Measure hallucination rates on your tasks; do not accept “solved” marketing.
Inference: batching, caching, and speculative decoding
Speculative decoding and quantization need quality regression tests—they are not free speed. Prefix cache hit rates should be monitored; sudden misses may indicate template churn.
Decoding generates tokens sequentially. Continuous batching raises utilization; KV caches store attention state; prefix caching reuses shared prompts; speculative decoding uses a draft model to accelerate. Quantization trades precision for cost. These knobs live at the intersection of LLM ops and AI infrastructure—own the LLM-facing behavior here, the substrate economics there.
Measure TTFT and TPOT at product percentiles. Admission control when KV memory is exhausted beats silent latency collapse.
Serving economics and model choice
Output tokens often dominate cost for chatty assistants. UX that encourages concise answers is a cost control. Streaming improves perceived latency without reducing total token bills.
Cost scales with input+output tokens, rate limits, and reserved capacity. Route easy tasks to smaller models; reserve frontier models for hard slices. Cache frequent prompts. Bound max output tokens in product UX.
Model choice is a portfolio: quality, latency, cost, data residency, and toolchain fit. Bake off on your suite, not on vibes.
Open weights versus API models
Exit drills matter: can you re-run golden suites on an alternate model within a week? If not, you have concentration risk. Contract for version pins and notice periods where possible.
API models optimize convenience and frequent improvement; open weights optimize control, customization, and sometimes residency—at the cost of ops burden. Hybrid is common: API for peak capability, self-host for sensitive or high-volume paths.
Open weights still need licenses, eval, safety filters, and serving expertise. “Open” is not “finished product.”
Operational change management when models update
Maintain a model registry with owners, suite links, and known defects. Hot-swapping production models without registry entries recreates shadow IT inside the AI stack.
Treat model ID changes like dependency upgrades: changelog review, golden-suite diff, canary, rollback. Prompt and tool schemas may need co-changes. Document breaking chat template shifts.
Shadow traffic and pairwise comparisons catch silent personality or formatting regressions that averages miss.
Lifecycle checklist for an LLM feature
Define the user job and risk tier. Choose base vs instruct checkpoint. Decide prompting vs adapters vs RAG vs tools. Build golden suites for quality and safety. Load-test latency and cost. Pin versions. Canary with kill criteria. Monitor regressions and jailbreak attempts. Schedule refresh when upstream models or corpora change.
Skip any step and you inherit a demo. LLM features fail operationally more often than they fail at “not enough parameters.”
Anti-patterns
Using an LLM as a database. Trusting chain-of-thought text as audit evidence. Unbounded tools. Fine-tuning away hallucination on facts that should be retrieved. Evaluating only with vibe checks. Ignoring chat templates. Mixing untrusted documents into system prompts. Celebrating leaderboard wins that do not match production prompts.
Each anti-pattern maps to a missing boundary: retrieval, permissions, eval, or change control. Restore the boundary before scaling traffic.
Where LLMs sit in the Knowledge graph
LLMs are the language-model hub. They feed agents and RAG, specialize via fine-tuning and prompting, and sit under generative AI’s broader modality umbrella without replacing discriminative ML. Keep links contextual as neighboring Batch 2 guides publish.
Until then, mention embeddings, fine-tuning deep dives, and prompt pattern libraries as concepts—and link only what is live. This page remains the mechanics and ops home for large language models.
Large language models are powerful token predictors shaped by data and post-training into product surfaces. Treat them as components with sharp interfaces—retrieval for truth, tools for actions, eval for change—rather than as omniscient oracles. That discipline is what makes LLM systems operable.
Training stack altitudes: what product teams must know
Pretraining creates general next-token competence. Midtraining specializes the distribution. Instruction tuning teaches format and helpfulness. Preference optimization shapes comparative quality and some safety behaviors. Distillation compresses teacher behavior into smaller students. Each stage has data contracts and eval gates. Skipping documentation of which stage produced your checkpoint is how teams mis-attribute regressions.
Continued pretraining on private corpora can help terminology and style, yet it can also memorize secrets. Deduplicate, scrub, and measure extraction risk. If documents change often, prefer RAG for facts and keep weight updates for stable skills.
Synthetic data pipelines—models generating training text for other models—can amplify quirks. Track lineage. Mix with human data. Evaluate on human-authored holdouts.
Decoding, determinism, and product UX
Greedy decoding and low temperature increase stability; sampling increases diversity. Beam search is less common in chat APIs but still relevant in some MT settings. Stop sequences and max tokens prevent runaway cost. Structured output modes constrain tokens to schemas—use them for anything that must parse.
Streaming changes UX and error handling: partial JSON is not JSON. Buffer until valid or use incremental parsers carefully. Cancelled streams should not leave half-applied tool side effects—another agent-runtime concern.
Seed controls, where offered, help reproducibility demos but are not cryptographic guarantees across engine versions. Document nondeterminism to stakeholders who expect bit-identical outputs.
Safety behaviors at the model boundary
Model-level refusals are one layer. They fail under jailbreaks and multi-turn coercion. Pair with input/output filters and policy engines. Red-team with your domain’s attack prompts, not only public lists. Measure attack success rate over time as models update.
Overrefusal harms adoption and pushes users to shadow tools. Tune with false-block evaluation on legitimate business prompts. Safety and usefulness are a joint objective—see also generative AI product patterns without duplicating that map.
Child safety, self-harm, and cyber-abuse categories need specialized policies and escalation paths. General helpfulness defaults are the wrong starting point for those surfaces.
Multilingual and code-centric LLM realities
Multilingual quality tracks tokenizer fertility and data mix. Evaluate per language you claim to support. Code models need execution tests and secure-coding checks; vulnerable snippets can look idiomatic. Separate “code that compiles” from “code that is safe to merge.”
Domain jargon and OCR-noisy text stress tokenizers. For document-heavy enterprises, retrieval quality often dominates generator choice—fix the pipeline, not only the LLM brand.
Procurement and diligence questions
Ask providers for: version pinning, changelog discipline, training-on-your-data defaults, residency, subprocessors, uptime history, and export of logs needed for incidents. Run your golden suite under contract before committing volume. Price out output-token heavy workflows honestly.
For open weights: license compatibility, dangerous-capability evals you will run, hosting plan, and who owns updates. “We downloaded the weights” is not an operating model.
Worked routing examples
Internal policy Q&A: instruct LLM + RAG with ACL filters + citation UI; abstain when empty; no fine-tune on weekly policy PDFs.
Brand voice email drafts: light adapter or strong system prompt; human send gate; measure edit distance and policy violations; facts from CRM tools not from parametric memory.
Analytics SQL assistant: LLM emits queries; warehouse enforces read-only roles; dry-run explain; golden question suite with execution checks; agent budgets if multi-step.
Consumer creative chat: generative altitude dominates; lighter factual grounding; stronger abuse filters; cost controls on output length.
Routing is product architecture. The LLM is shared; wrappers differ. Document the wrapper choice in the eval card.
Regression taxonomy for LLM ops
Classify failures: formatting break (template), tool-schema break, retrieval miss, faithfulness miss, safety miss, latency/cost miss, personality drift. Different classes page different owners. A single “LLM quality” ticket queue guarantees thrash.
When upstream vendors update, run a stratified sample across classes within 24 hours for high-traffic surfaces. Keep a freeze option for regulated flows.
Prompt diffs deserve the same code review culture as application code. Unsigned prompt edits in production are change-control failures.
Memory, state, and multi-turn discipline
Stateless request/response is easiest to secure and evaluate. Multi-turn state improves UX and expands attack surface. Prefer structured state (slots, tool results with provenance) over ever-growing transcripts. Summaries need provenance and expiry.
Cross-session memory should default off for high-privilege tools. When enabled, expose controls to users and enterprises. Memory poisoning is an agent/RAG concern that begins with how LLM context is assembled.
Evaluate multi-turn tasks separately from single-shot. Many suites overstate quality by testing only turn one.
Closing
LLMs earn a place in the stack when token prediction plus post-training delivers interface leverage that cheaper systems cannot. They fail when asked to be systems of record, authorization layers, or untested oracles. Keep mechanics and ops here; keep retrieval, agents, and cross-modality product maps in their guides; link outward as Batch 2 densifies.
Pin versions. Measure faithfulness and safety on your distribution. Bound tools. Prefer RAG for churning facts. Change-control prompts and models together. That operating posture outlasts any single checkpoint brand.
Capacity planning for LLM products
Forecast tokens from session length distributions, not from averages alone. Heavy users and verbose system prompts dominate bills. Separate budgets by feature. Provide graceful degradation to smaller models or retrieval-only answers under overload.
Reserved capacity lowers variance for enterprise SLAs; on-demand flexibility helps startups. Spot/preemptible GPUs for batch offline scoring differ from online chat. Match purchase mode to latency class.
Include evaluation and red-team compute in operating cost. Suites that never run because they are “expensive” are not suites—they are aspirations.
Security notes specific to LLM text channels
Untrusted content in the context window can override instructions. Isolate roles hard. Sanitize tool outputs before re-injection. Do not place secrets in prompts when a gateway can inject them at tool time. Log redaction policies must cover prompts and completions.
Model extraction and membership inference are research-active risks for some deployments. Threat-model accordingly for high-value weights and sensitive training sets.
Supply chain: validate model artifacts checksums, container bases, and tokenizer files. A tampered chat template can silently alter behavior more than a slightly different weight file.
From research demos to durable LLM services
Demos optimize surprise; services optimize predictable behavior under load and abuse. The migration adds authn/z, quotas, observability, eval gates, and on-call. If your org cannot staff those, buy a managed surface—or narrow the feature until you can.
Write a one-page “LLM service charter” per surface: allowed data classes, max autonomy, eval owner, and kill switch. Charters prevent drive-by prompt experiments from becoming undeclared production dependencies.
Keep a living glossary for your org’s LLM surfaces: model IDs, template versions, tool schema versions, and suite hashes. On-call should be able to answer “what changed since yesterday?” in minutes. Without that, every regression becomes folklore.
Educationally, learn LLMs in this order: next-token objective; tokenization; context limits; post-training stages; decoding; eval axes; then wrappers (RAG, tools). Skipping to tool demos without eval discipline produces fragile assistants. This guide is the hub for that sequence inside Brel’s Knowledge library.
As neighboring Batch 2 articles on embeddings, fine-tuning, and prompt engineering publish, refresh contextual links. Until then, treat those layers as named boundaries—not link targets—so readers never hit draft 404s.
Finally, separate research curiosity from production scope. It is fine to explore long-context tricks, speculative decoding, or new preference methods in a lab. It is not fine to hot-swap them under enterprise traffic without suite diffs and a rollback owner. Curiosity without change control is how LLM programs lose trust internally—long before customers see a public incident.
Ship small, measure hard, expand wrappers deliberately. The model is necessary; the operating system around it is what makes large language models a durable product capability rather than a rotating demo.
Grounding layers without replacing RAG
Grounding means binding claims to evidence the system can show. At LLM altitude that means: prefer tool results and retrieved snippets over parametric recall for high-stakes facts; require the model to quote or cite only from provided evidence when evidence is present; and treat unsupported assertions as failures in eval—even when fluent.
Citation UI is not faithfulness. A model can cite a document and still invent a sentence. Faithfulness checks compare answer spans to evidence spans. Build those checks for regulated answers; do not assume “sources listed” equals grounded. Full ingestion, chunking, hybrid retrieval, and ACL design remain in the RAG guide—this page only owns how the generator should behave when evidence arrives.
When evidence conflicts, teach abstention or conflict surfacing rather than silent merging. Silent merges look decisive and are often wrong. Product copy that says “based on your documents” must be backed by retrieval logs you can audit.
Offline corpora, online search tools, and structured databases are different grounding substrates. Route by data class. Do not paste an entire warehouse schema into the prompt and call it grounding; use constrained query tools with least privilege.
References and further reading
- Brown, T., et al. (2020). Language Models are Few-Shot Learners.
- Vaswani, A., et al. (2017). Attention Is All You Need.
- Ouyang, L., et al. (2022). Training language models to follow instructions with human feedback.
- Kaplan, J., et al. (2020). Scaling Laws for Neural Language Models.
- OWASP. OWASP Top 10 for LLM Applications.