LLM Fundamentals

LLM Fundamentals accounts for 5.2 percent of the blueprint, close to three scored questions, in a domain where the fundamentals outweigh the selection material. The questions do not ask you to describe transformer internals. They give you a behaviour and ask why it happens, or hand you a task and ask whether a language model is a sensible way to do it.

Everything traces back to one mechanism. The model produces text one token at a time, each conditioned on everything before it, choosing what is likely rather than looking anything up. Four consequences follow directly, and between them they explain most of what candidates find surprising.

Output is sequential, so a long answer takes proportionally longer to produce and is priced above the input it was conditioned on. Plausibility is the objective, so a confident, well-formed, wrong answer is a normal output rather than a malfunction. Nothing persists between calls, so anything the model appears to remember was resent. And the parameters were fixed at training time, so the model's world has a horizon and anything past it must arrive in the request.

Read each scenario by asking which of those four is being illustrated.

What the exam tests here

• •Explaining an observed behaviour by the way text is generated rather than by a bug
• •Why a fluent answer can be entirely wrong, and what actually reduces that risk
• •The absence of memory between calls, and what that implies about anything the model appears to recall
• •Why sub-word tokenisation makes character-level and exact-arithmetic tasks unreliable
• •What reasoning tokens buy, what they cost, and the task types where they change the answer
• •Recognising the task shapes a language model is structurally poor at

Generation is sequential, and that explains the economics

Each token is produced with the whole preceding sequence available, which means input can be processed in one pass while output has to be produced step by step.

That asymmetry is why output is billed at a multiple of input across every tier, and why a request asking for a long answer is slow in proportion to the length of that answer rather than to the difficulty of the question. It also explains why the first token of a streamed response arrives long before the last: the model is not withholding a finished answer, it is composing one.

Design conclusions follow. Asking for a concise answer is a real cost lever, and a task producing a large artefact belongs on a path that can stream.

Plausibility is the objective, so confident errors are normal

The model is not consulting a store of facts and reporting what it finds. It is continuing a sequence the way the training distribution suggests, which produces text that is well formed and appropriate in register whether or not it is true. A fabricated citation, a plausible but nonexistent function, an invented field name: each is the mechanism working as designed rather than failing.

The practical implication is that fluency carries no information about accuracy, so confidence expressed in the text is not a signal you can act on. What reduces the risk is structural: supply the facts in the request instead of relying on recall, give the model a tool that can look something up, and verify anything consequential against a source outside the generation.

Nothing persists between calls

A model holds no state of its own between requests. Anything it appears to remember from earlier in a conversation is present because it was included in the request that just arrived, and anything omitted is genuinely gone.

That is the mechanical basis for several behaviours which otherwise look inconsistent. A detail mentioned twenty turns ago is recalled reliably while a session lasts and forgotten completely once a new one begins. Two users of the same deployment cannot see each other's conversations unless your code puts them in the same request. And an instruction given once is followed for exactly as long as it keeps being sent.

Memory in a product is a feature your system implements, deliberately, by choosing what to include.

Tokenisation explains a specific class of weakness

Text is split into sub-word units before the model sees it, so the model does not perceive individual characters unless a token happens to be one.

That is why counting the letters in a word, reversing a string, judging whether two words rhyme, and performing exact arithmetic on long numbers are all unreliable in a way that feels out of keeping with the model's other abilities. The lesson is not that the model is bad at these tasks; it is that they are structurally awkward given the representation.

Route them to code. A model that writes a short program to count the characters gets the right answer every time, which is why giving it an executable tool converts a whole class of unreliable behaviour into a reliable one.

Where candidates go wrong

Common questions