What is a large language model, in one sentence an engineer would accept?

A large language model is a function that, given a sequence of text (the context), predicts a probability distribution over the next token and samples from it — repeated one token at a time to produce output. It is trained on a large text corpus to make those predictions useful, but at its core it is next-token prediction, not a database lookup, a search engine, or a reasoning agent with beliefs.

Why do LLMs hallucinate?

Hallucination is intrinsic to how the model works, not a bug to be fully patched. The model is optimized to produce a plausible continuation of the text, and a fluent, confident-sounding wrong answer is often more probable than an honest "I do not know." Its confidence is not calibrated to correctness — it has no separate mechanism that checks whether a generated fact is true. That is why load-bearing facts (spec numbers, API signatures, citations) must be verified against an authoritative source rather than trusted because they sound right.

What is a context window and why does it matter?

The context window is the maximum amount of text — measured in tokens — the model can attend to at once: your prompt, any documents you paste, the conversation so far, and the output it is generating all share that budget. It is the model's working memory, and it is finite. When the input exceeds the window, earlier content is dropped or must be truncated, so the model can appear to "forget" instructions given far back. Managing what goes into the context is one of the highest-leverage skills in using LLMs well.

Do I need to understand the underlying math to use LLMs effectively as an engineer?

No. Using LLMs well requires a correct mental model — next-token prediction over a finite context, with uncalibrated confidence — and the discipline to verify and to manage context. The deeper mathematics (the transformer architecture, attention, training objectives) matters when you build or fine-tune models or need to reason precisely about their behavior. This page covers the working model; the mechanism is in /topics/transformer-architecture and the math foundations in /topics/math-for-machine-learning.

What are tokens, and why do they matter in practice?

Models do not see characters or words; they see tokens — sub-word chunks produced by a tokenizer. "Tokenization" is why an LLM struggles with tasks like counting the letters in a word or doing exact string manipulation: the characters are hidden inside tokens it never decomposes. Tokens also define cost and the context budget (you pay and plan per token, not per word). Knowing that the model reasons over tokens explains a whole class of otherwise-baffling failures.

Where are LLMs reliable versus unreliable?

They are most reliable when transforming or summarizing text you provide, drafting boilerplate, explaining well-established concepts, and generating candidates you will verify. They are least reliable for precise recall (exact figures, niche facts, citations), exact arithmetic or character counting, and anything after their training cutoff. The engineering judgment is matching the task to the tool: lean on the model for transformation and drafting over given material, and supply or verify facts rather than asking it to be the source of record.

What is the difference between training and inference?

Training is the expensive, one-time process that sets the model's weights from a large corpus; inference is what happens every time you send a prompt and get a response. Crucially, asking the model a question at inference does not teach it — the weights are frozen, and anything you want it to "know" for this request must be in the context. This is why retrieval (putting relevant documents in the prompt) updates behavior without retraining, and why a chat does not permanently change the model.

LLM Fundamentals for Engineers

How large language models actually work, for engineers: tokens, context windows, training vs inference, why they hallucinate, and where they are reliable.

Quick answer

LLM fundamentals for engineers are the working concepts you need to use large language models with sound judgment — without becoming a machine-learning researcher.

As AI tools become standard, engineering teams increasingly expect people to use them with a correct mental model rather than as a magic box, and that expectation shows up directly in interviews.

Editorial review

Written by

CompoundLearn editorial team

Wireless / RF / hardware engineering

Reviewed by

CompoundLearn editorial team

Wireless / RF / hardware engineering

Last reviewed

June 25, 2026

Built from curated topic maps, editorial validation, and subject-matter review so the page stays aligned with the interview intent and the current content pipeline.

Key points

An LLM predicts the next token from the context it is given and samples one at a time — it is a probabilistic text model, not a fact database, a person, or a calculator.
Three ideas explain most behavior: tokens (how text is chunked), the context window (its finite working memory), and next-token prediction (how it generates).
Hallucination is intrinsic: the model optimizes for plausible continuations and its confidence is not calibrated to correctness, so verify any load-bearing fact.
Behavior is steered at inference by the context you provide (prompt, examples, retrieved documents), not by retraining — the weights are frozen when you use it.
The core engineering judgment is matching task to tool: strong at transforming and drafting over provided text, weak at precise recall, fresh data, and exact arithmetic.

What it is

LLM fundamentals for engineers are the working concepts you need to use large language models with sound judgment — without becoming a machine-learning researcher. A large language model is, at its core, a function that takes a sequence of text and predicts a probability distribution over the next token, then samples one and repeats. Trained on a large corpus to make those predictions useful, it produces fluent output that can look like knowledge and reasoning, but the mechanism underneath is next-token prediction, not a lookup in a fact database. Three concepts carry most of the practical weight. Tokens are the sub-word chunks the model actually operates on — it does not see characters or words directly, which explains a whole class of failures like miscounting letters. The context window is the finite token budget the model attends to at once: prompt, pasted documents, conversation, and the output it is generating all share it, and overflowing it makes the model appear to forget. And the split between training and inference matters: training sets the weights once, while every prompt you send is inference over frozen weights, so anything the model should "know" for your request must be in the context. For engineers — people who already reason about systems and failure modes — the payoff of this model is predictive power. It tells you why the tool hallucinates, why more context is not always better, and where the reliable uses are. The deeper mechanism lives in /topics/transformer-architecture and the math in /topics/math-for-machine-learning; this page is the foundation the rest of the AI-upskilling cluster builds on.

Why interviewers ask

As AI tools become standard, engineering teams increasingly expect people to use them with a correct mental model rather than as a magic box, and that expectation shows up directly in interviews. The question behind the question is whether you understand what an LLM is doing well enough to predict where it will fail and to use it safely on real work. The strongest signals are specific. Can you explain, in one or two sentences, that the model predicts tokens over a finite context and that its confidence is not calibrated to truth? Do you know why it hallucinates, and can you name the categories of task where verification is non-negotiable? Do you understand that pasting more text is not free — that the context window is a budget with real consequences? Candidates who can articulate these reason about the tool the way they would reason about any unreliable component in a system: with bounds, verification, and a clear sense of where it is safe. For hiring teams, this also separates durable judgment from hype on both sides. Someone who dismisses LLMs entirely is as much a concern as someone who trusts every output; the engineer who can say precisely where the tool helps and where it must be checked is the one who will get reliable leverage from it without shipping confident-but-wrong results.

Common mistakes

The most common mistake is treating an LLM as a database or a search engine — asking it for precise facts, figures, or citations and trusting the answer because it sounds authoritative. The model generates plausible text, and a fabricated but specific-looking fact is a natural output; precise recall is exactly where it is least reliable. A second mistake is assuming more context is always better. The context window is finite and shared, and stuffing it with marginally relevant material can crowd out the parts that matter, dilute attention, and increase cost. Curating what goes into the context usually beats dumping everything in. A third is anthropomorphizing the model's "reasoning." It does not hold beliefs or follow logical rules in a separate engine; any chain of reasoning is itself generated text and can be confidently incoherent. Treating its self-explanations as authoritative — "it said it checked, so it must have" — leads to misplaced trust. A fourth is ignoring tokenization and determinism. Tasks that depend on individual characters or exact arithmetic fail because the model works over tokens, and output varies run to run because generation samples from a probability distribution (at temperature 0 / greedy decoding it is near-deterministic). Engineers who internalize the fundamentals route those tasks to code and verification instead of expecting the model to be a precise, deterministic calculator.

Where LLMs are reliable vs risky — and what to do about it

Task	Reliability	What to do
Summarize or transform text you provide	High	Works over the given context; still spot-check
Draft boilerplate or explain an established concept	High	Verify the specifics before relying on them
Recall a precise fact, spec number, or citation	Low	Verify against the source; it may confabulate confidently
Exact arithmetic or counting characters	Low	Use a tool or code; tokenization hides the characters
Anything after the training cutoff	Low	Supply the data via context (retrieval), do not ask from memory
Multi-step reasoning	Mixed	Improves with step-by-step prompting plus verification

Sample interview questions

At the most fundamental level, what is a large language model doing when it answers your question?
- A. Looking the answer up in a stored database of facts it memorized during training.
- B. Predicting a probability distribution over the next token given the context, then sampling from it, repeated one token at a time. ✓
- C. Executing a symbolic reasoning engine that derives the answer from logical rules.
- D. Searching the live internet for the most relevant page.
Option B is correct. An LLM is fundamentally a next-token predictor: given the context so far, it produces a probability distribution over the next token and samples one, then repeats. Everything else — apparent knowledge, apparent reasoning — emerges from that objective applied at scale. Option A is wrong. The model has no addressable fact database; "knowledge" is diffused in weights as statistical regularities, which is exactly why recall can be confidently wrong. Option C is wrong. There is no separate symbolic rule engine; any reasoning is itself produced as text via next-token prediction. Option D is wrong. A bare model does not browse; it only sees its context. Tools or retrieval can add live data, but that is a layer on top, not the model itself. Production reality: holding the "next-token predictor over a finite context" model in mind predicts most LLM behavior, including its failure modes.
An LLM confidently cites a specification number that turns out not to exist. What is the correct way to understand and handle this?
- A. The model is broken and should not be used at all.
- B. Hallucination is intrinsic — the model optimizes for plausible text and its confidence is not calibrated to truth — so verify load-bearing facts against an authoritative source. ✓
- C. The model needs a bigger context window to stop hallucinating.
- D. Asking more politely will make it tell the truth.
Option B is correct. The model produces the most plausible continuation, and a confident, specific-sounding citation is often more probable than an admission of ignorance. Confidence does not track correctness, so any fact you will rely on must be checked against the source. Option A is wrong. Discarding a useful tool over a known, manageable failure mode is an overreaction; engineers manage unreliable components with verification. Option C is wrong. A larger window helps with long inputs but does not fix fabrication of facts not in the context. Option D is wrong. Tone does not change the model's lack of a truth-checking mechanism. Production reality: treat the model as a fast first-pass partner whose factual claims are hypotheses to verify, not citations of record.
You paste a very long document plus instructions, and the model seems to ignore an instruction you gave near the top. What is the most likely cause?
- A. The model is deliberately disobeying.
- B. The input exceeded or strained the context window, so earlier content was truncated or attended to weakly — the model has finite working memory, not perfect recall of everything pasted. ✓
- C. The instruction was grammatically incorrect.
- D. The model permanently learned to ignore that instruction.
Option B is correct. The context window is a finite token budget shared by the prompt, documents, history, and output. When you overflow or crowd it, earlier instructions get truncated or weakly weighted, which looks like "forgetting." Option A is wrong. There is no intent; it is a capacity and attention effect. Option C is wrong. Minor grammar rarely causes wholesale instruction loss; position and length do. Option D is wrong. Nothing in a single request changes the frozen weights — the next request starts fresh. Production reality: keep instructions close to the relevant content, trim irrelevant context, and restate critical constraints rather than assuming everything pasted is equally "remembered."
An LLM insists the word "strawberry" has two r's. Why does this kind of character-level task fail so often?
- A. The model was trained on incorrect spellings.
- B. The model reasons over tokens (sub-word chunks), not individual characters, so the letters are hidden inside tokens it does not decompose. ✓
- C. The word is too long for the context window.
- D. Spelling is fundamentally impossible for any AI.
Option B is correct. Tokenizers split text into sub-word units, and the model operates on those tokens. Individual characters are not directly visible, so counting letters or doing exact character manipulation is unreliable. Option A is wrong. The failure is structural (tokenization), not a training-data spelling problem. Option C is wrong. A single short word is nowhere near the context limit. Option D is wrong. With a tool (or by spelling the word out token-by-token) the task becomes reliable; the limitation is the representation, not impossibility. Production reality: for exact character or arithmetic work, hand the task to code or a tool rather than the model's token-level intuition.
You correct an LLM in a chat, and it agrees. Does that correction persist so the model "knows" it next week for everyone?
- A. Yes — chatting with the model retrains it in real time.
- B. No — weights are frozen at inference; your correction lives only in the current context and is gone once it falls out of the window or the session ends. ✓
- C. Yes, but only if you say "remember this."
- D. Only if the answer was about code.
Option B is correct. Inference does not update the model. Anything you want it to use must be present in the context for that request; a correction does not change the underlying weights or affect other users. Option A is wrong. Training and inference are separate; a chat is inference. Option C is wrong. A "remember this" phrase may persist within a product's memory feature (which re-injects it into context), but that is the application storing text and re-prompting — not the model retraining. Option D is wrong. The topic is irrelevant; the weights are frozen regardless. Production reality: to make a model reliably "know" something, put it in the context (retrieval) or fine-tune deliberately — do not rely on in-chat corrections to stick. See /topics/rag-retrieval-augmented-generation.
Which task best fits what an LLM is reliably good at, with the least verification burden?
- A. Stating the exact value of a niche engineering constant from memory.
- B. Rewriting a paragraph you provide into a clearer, shorter version while preserving its meaning. ✓
- C. Computing a 12-digit multiplication exactly.
- D. Reporting this morning's breaking news without any tool access.
Option B is correct. Transforming text you supply — summarizing, rephrasing, restructuring — plays to the model's strength: it operates over given context rather than recalling external facts, so the failure surface is small. Option A is wrong. Precise recall of niche values is a low-reliability use; verify against a source. Option C is wrong. Exact large arithmetic is unreliable due to token-level processing; use code. Option D is wrong. A bare model cannot access post-cutoff or live information. Production reality: match the task to the tool — lean on LLMs for transformation and drafting over provided material, and supply or verify any external fact.

Frequently asked questions

What is a large language model, in one sentence an engineer would accept?: A large language model is a function that, given a sequence of text (the context), predicts a probability distribution over the next token and samples from it — repeated one token at a time to produce output. It is trained on a large text corpus to make those predictions useful, but at its core it is next-token prediction, not a database lookup, a search engine, or a reasoning agent with beliefs.
Why do LLMs hallucinate?: Hallucination is intrinsic to how the model works, not a bug to be fully patched. The model is optimized to produce a plausible continuation of the text, and a fluent, confident-sounding wrong answer is often more probable than an honest "I do not know." Its confidence is not calibrated to correctness — it has no separate mechanism that checks whether a generated fact is true. That is why load-bearing facts (spec numbers, API signatures, citations) must be verified against an authoritative source rather than trusted because they sound right.
What is a context window and why does it matter?: The context window is the maximum amount of text — measured in tokens — the model can attend to at once: your prompt, any documents you paste, the conversation so far, and the output it is generating all share that budget. It is the model's working memory, and it is finite. When the input exceeds the window, earlier content is dropped or must be truncated, so the model can appear to "forget" instructions given far back. Managing what goes into the context is one of the highest-leverage skills in using LLMs well.
Do I need to understand the underlying math to use LLMs effectively as an engineer?: No. Using LLMs well requires a correct mental model — next-token prediction over a finite context, with uncalibrated confidence — and the discipline to verify and to manage context. The deeper mathematics (the transformer architecture, attention, training objectives) matters when you build or fine-tune models or need to reason precisely about their behavior. This page covers the working model; the mechanism is in /topics/transformer-architecture and the math foundations in /topics/math-for-machine-learning.
What are tokens, and why do they matter in practice?: Models do not see characters or words; they see tokens — sub-word chunks produced by a tokenizer. "Tokenization" is why an LLM struggles with tasks like counting the letters in a word or doing exact string manipulation: the characters are hidden inside tokens it never decomposes. Tokens also define cost and the context budget (you pay and plan per token, not per word). Knowing that the model reasons over tokens explains a whole class of otherwise-baffling failures.
Where are LLMs reliable versus unreliable?: They are most reliable when transforming or summarizing text you provide, drafting boilerplate, explaining well-established concepts, and generating candidates you will verify. They are least reliable for precise recall (exact figures, niche facts, citations), exact arithmetic or character counting, and anything after their training cutoff. The engineering judgment is matching the task to the tool: lean on the model for transformation and drafting over given material, and supply or verify facts rather than asking it to be the source of record.
What is the difference between training and inference?: Training is the expensive, one-time process that sets the model's weights from a large corpus; inference is what happens every time you send a prompt and get a response. Crucially, asking the model a question at inference does not teach it — the weights are frozen, and anything you want it to "know" for this request must be in the context. This is why retrieval (putting relevant documents in the prompt) updates behavior without retraining, and why a chat does not permanently change the model.

Essential AI-Native Skills for LLM Fundamentals for Engineers

Modern engineering work increasingly uses AI tools for design and code review, debugging, documentation, test and testbench generation, and workflow automation. The goal is not to let AI replace engineering judgment — it is to move faster while keeping verification discipline.

Use AI to explain unfamiliar code, logs, waveforms, datasheets, or test failures.
Break large problems into small, reviewable steps you can verify independently.
Ask AI for hypotheses, then validate them against tests, measurements, simulations, or lab data.
Version-control your analysis scripts, testbenches, and configs — keep changes small and reviewable.
Document your assumptions, design tradeoffs, and debugging decisions.
Verify AI output before trusting it: run the checks that fit the domain — unit tests, linters, simulations, or bench/lab measurements.
Review AI output for correctness, edge cases, and real-world consequences.

Next up: LLM Fundamentals for Engineers practice

The adaptive practice engine is already live for core wireless, RF, and ML domains. LLM Fundamentals for Engineers questions — covering production realities, not just framework syntax — are in active development. Join the early-access list to get them first.