Skip to the lesson
FixTheRobot Explore Robotics / LLM / LM1 Understanding Large Language Models / LM1-T5

LLM · Theory · LM1

LM1-T5 — What LLMs Can and Cannot Do, and the Build Plan

A language model is a strong pattern learner over text. Knowing exactly what that gives you, and what it does not, is the first engineering skill.

  • Lesson 5 of 5
  • Module 1: Understanding Large Language Models
  • Theory
  • Difficulty: Beginner
  • About 9 minutes to read
  • Prerequisite: LM1-T4

Before building something it helps to know what it is for and where it fails. Large language models write fluent text, follow examples in a prompt, summarise, translate and write code. They also state falsehoods in a confident voice, cannot know what happened after training, are sensitive to wording, and can be steered by malicious text. This lesson lists both sides without hype, explains why the failures follow from how the models are built, and then lays out the plan for the rest of the track: the stages in which you will build, train, adapt, evaluate and apply a GPT-style model. It closes Module 1.

Learning objectives

After this lesson, you should be able to:

  • List the main capabilities of LLMs and explain why they arise from next-token prediction.
  • Name the main failure modes (hallucination, stale knowledge, brittle reasoning, prompt sensitivity, injection) and explain their causes.
  • Decide whether a task is a good fit for an LLM and what checks it needs.
  • Describe the stages of building a GPT-style model and where each is taught in this track.

The idea: very good at text, no built-in truth

A language model is trained to predict the next token of an enormous amount of text. To do that well it has to learn a lot about how text works: grammar, style, facts that are repeated often, the structure of code, the shape of an argument. Those are the source of its capabilities. The training signal never asks whether a statement is true, whether the model knows it, or whether an action it describes is safe. Those are the source of its failures.

What they do well

  1. Fluent, adaptable text. Drafting, rewriting, translating, changing tone and format.
  2. In-context learning. Large models can pick up a task from a few examples placed in the prompt, without any change of parameters (shown for GPT-3 by Brown et al.).
  3. Summarising and extracting. Condensing a document or pulling out fields, especially when the answer is in the prompt.
  4. Code and structured text. Programs, queries and JSON follow regular patterns the model has seen many times.
  5. Flexible interfaces. Natural-language commands for software, including robots, when wrapped in validation.

Where they fail, and why

  1. Hallucination. The model produces plausible text that is false or unsupported. Plausibility is exactly what it was trained for; truth is not a training target. Fluent errors are harder to spot than clumsy ones.
  2. Stale and missing knowledge. What the model knows is frozen at training time. It cannot know recent events or your private documents unless they are placed in the prompt (retrieval, Module 11).
  3. Brittle reasoning and arithmetic. Multi-step reasoning and exact calculation can fail in ways that depend on small changes of wording or number. Capability varies sharply with model size and task.
  4. Prompt sensitivity. Rephrasing a question can change the answer. Evaluation has to test variations (Module 9).
  5. Context limits. Only the context window is visible, and use of very long contexts can be uneven (Lesson LM1-T4).
  6. Prompt injection and misuse. The model treats all text in its context as input to continue. Instructions hidden in a retrieved web page or an email can steer it (Module 11).
  7. Cost and latency. Large models are expensive to run and slow to produce long outputs.

Why robots need extra care

An LLM that writes a plan for a robot produces text about actions, with no knowledge of the robot’s state, the physical world or what is safe. Its confidence in the wording says nothing about whether the action is possible or harmless. A sound design keeps a deterministic safety layer and validation between the model and the robot: the model proposes, the system checks, and only validated actions run. Module 11 shows structured outputs and tool calling with validation, and the Physical AI and VLA tracks show robot-specific designs.

The plan for building a GPT-style modelFour stages in a row with the modules that implement them: stage 1 prepare data (text, tokenizer, input-target pairs, modules 2); stage 2 build the model (embeddings, attention, GPT, modules 3 and 4); stage 3 train and adapt (pretraining, classification and instruction fine-tuning, efficient adaptation, modules 5 to 8); stage 4 evaluate and apply (evaluation, modern architecture, applications, capstone, modules 9 to 12).1 DataModules 2text → tokens → batches2 ModelModules 3, 4attention → GPT3 Train and adaptModules 5 to 8pretrain → fine-tune → LoRA4 Evaluate and applyModules 9 to 12metrics → apps → capstone Understand → implement → train → evaluate → improve → apply Module 1 (this one) explains what we are building; Module 10 shows how modern models differ from the minimal GPT built in Modules 3 to 5. The models you build are small teaching models; they show the mechanisms, not the capabilities of production systems.
The plan for the track: prepare data, build the model, train and adapt it, then evaluate and apply it.

The build plan: stages, shapes and the reference book

The track follows the structure of Sebastian Raschka’s Build a Large Language Model (From Scratch), adding evaluation, modern architecture, applications and a capstone. The stages and the quantities that flow through them are:

StageWhat you buildData shape at the endModuleBook chapter
Text to tokenstokenizer, vocabulary, byte-pair encodinglist of integer token IDs2Chapter 2
Training examplesinput-target pairs, sliding windows, batchestensors (batch, context length)2Chapter 2
Embeddings and attentiontoken and position embeddings, causal multi-head attentiontensors (batch, tokens, embedding width)3Chapter 3
The GPT modelTransformer blocks, normalisation, output headlogits (batch, tokens, vocabulary)4Chapter 4
Pretraining and generationloss, training loop, samplinga trained base model, generated text5Chapter 5
Classification fine-tuningclassification head on a pretrained modelclass predictions6Chapter 6
Instruction fine-tuninginstruction data, masked lossan instruction-following model7Chapter 7
Efficient adaptationLoRA, quantisation, memory budgetssmall trainable adapters8Appendix E
Evaluation and reliabilitymetrics, harnesses, latencytrustworthy comparisons9Chapter 7 (evaluation)
Modern architectureRoPE, grouped-query attention, KV cacheefficient inference10beyond the book
Applicationsretrieval, tools, validation, securityworking prototypes11beyond the book
Capstonean evaluated LLM system and reporta reproducible project12whole book

Two scale facts frame the whole plan. First, the architecture you build in Module 4 (token and position embeddings, a stack of Transformer blocks, a final normalisation and an output head) is the same family as GPT-2 and, with modifications (Module 10), of current open models. Second, the size is different by many orders of magnitude: your pretraining runs are a few minutes on a CPU, a production run is millions of accelerator-hours.

To make the arithmetic concrete, recall Lesson LM1-T4: the 124-million-parameter GPT-2 small is about 1,400 times smaller than GPT-3’s 175 billion parameters,

size ratio of GPT-3 to GPT-2 small
175×109124×106≈1, 411\frac{175\times 10^{9}}{124\times 10^{6}}\approx 1,\,411

and the tiny models of the notebooks are about a hundred times smaller again.

A worked example: deciding whether a task fits

Three requests to a language model attached to a warehouse robot, and how to judge them.

RequestFitWhyNeeded checks
“Summarise today’s inspection notes in three bullet points.”goodThe answer is in the prompt; errors are visible to a reader.spot-check summaries; keep the original notes
“What is the maximum payload of arm 7?”poor without retrievalThe fact is not in the model; it will produce a plausible number.retrieve the datasheet text and answer only from it; cite the source
“Move the pallet to bay 12, avoiding the wet floor.”only as a proposalA fluent plan says nothing about whether the route is clear or safe.parse into a schema, validate against the map and the safety layer, then execute

The pattern is general. The more a task depends on facts or actions outside the prompt, the more the design must supply them from trusted sources, and the more the model’s role shrinks to proposing and phrasing.

An honest summary of what you will build

By the end of Module 5 you will have trained a small GPT that writes text in the style of a small corpus. It will not answer questions, will make mistakes a person would find absurd, and will fit on a laptop. That is the point: you will have seen every part, with nothing hidden in an API, and you will understand why larger systems behave as they do and where they remain limited.

The scale gap in numbers. A production-scale pretraining run of the GPT-3 kind needs about 3 × 1023 FLOPs (Lesson LM1-T4). The tiny pretraining run in Lab LM5-L3 uses a few times 1012 to 1013: about ten billion times less.

Engineering implications and limitations

Write down what you will check. For each use, list the failure modes that matter and the test for each: factual accuracy, format validity, refusal behaviour, injection resistance, latency. An LLM feature without such a list is a demo.

Give the model what it needs, not what it must remember. Put facts and documents in the prompt through retrieval rather than hoping they are in the weights.

Constrain the output. Ask for structured output, validate it against a schema, and reject anything that does not parse (Module 11). A rejected output costs a retry; an unvalidated one can cost a collision.

Measure rather than impress. A few good examples prove little. Use held-out sets, several wordings and confidence intervals (Module 9).

Keep humans and safety layers in the loop where it matters. The model’s fluent explanation of its action is not evidence that the action is right.

Plan the learning path. Follow the modules in order: each depends on the previous. The notebook labs need PyTorch; the browser labs need nothing installed.

Common misconceptions

“An LLM knows facts the way a database does.”

It encodes statistical patterns of text. It can reproduce common facts and also invent plausible ones, with the same fluency.

“If it explains its reasoning, the reasoning is what produced the answer.”

The explanation is more generated text. It may or may not reflect the computation that produced the answer.

“A bigger model will not hallucinate.”

Larger models are more accurate on many tasks but still produce confident falsehoods; the problem is reduced, not removed.

“We can trust the model on a robot if it passes a few demos.”

A few demos test a few cases. Reliability needs systematic evaluation under variation, and a safety layer that does not depend on the model being right.

Engineering takeaways

  1. Capabilities (fluent text, in-context learning, summarising, code) come from next-token prediction on huge text; failures (hallucination, stale knowledge, brittle reasoning, prompt sensitivity, injection) come from the same source.
  2. The training objective rewards plausible text, not truth; give the model facts through the prompt and check its outputs.
  3. For robots, an LLM proposes and a validation and safety layer decides; fluent confidence is not evidence of safety.
  4. The track builds data → model → training and adaptation → evaluation and application, following the book and extending it.
  5. The models you build are millions of times smaller than production systems and show the mechanisms, not the full capabilities.

References and further reading

Chapter 1 of the book gives the overview and the plan; the papers are optional extensions on capabilities and security.

Knowledge check

Three conceptual questions. Write an answer, then reveal the explanation. Your answers stay in your browser.

Question 1

A model answers “Who won last week’s match?” with a confident, specific, wrong answer. Which failure is this, and what is the fix at the system level?

Explanation

Stale/missing knowledge leading to hallucination: the model cannot know recent events but is trained to produce plausible text. The system-level fix is to retrieve current information and put it into the prompt, answer only from it, and say when it is missing.

Question 2

Why is a fluent, confident explanation from an LLM not evidence that its plan for a robot is safe?

Explanation

The model produces text that is likely given its training, with no model of the robot’s state or the environment. Confidence in the wording reflects fluency, not correctness. Safety needs checks outside the model: schema validation, state-aware verification and a safety layer.

Question 3

By roughly what factor is GPT-3 (175 billion parameters) larger than GPT-2 small (124 million)?

Explanation

175 × 10⁹ / 124 × 10⁶ ≈ 1,411, about 1,400 times.

What’s next

Next, Module 2: how raw text becomes the integers a model can read: tokenization and training data.

Practice this lesson

Trace Text to Generated Output

Follow a prompt through tokens, context, probabilities and a generated continuation, and see how context changes predictions.

Next lesson

LM2-T1 — Text Normalization and Preprocessing

Decide what cleaning a text corpus needs and what each choice removes or keeps.

Nothing below is required to finish this lesson.