Generative AI & LLM Foundations

1.1 Why this chapter exists

Most AI tutorials start by throwing words at you: transformer, embedding, token, inference, temperature. You nod along, and three paragraphs later you realise you have not actually understood a single thing — you have just learned which words go next to which other words.

This chapter does the opposite. We introduce one idea at a time, and every new term gets defined before it is used. Nothing here assumes you have trained a model, studied statistics, or read a research paper.

There is one running example throughout the whole course: an online retail store. Not because retail is special, but because it is concrete. Every abstract idea ("what is a token?") lands better when it is attached to something real ("how many tokens does a product description cost me, and what is the bill?").

1.2 Step zero: what a "model" actually is

Before generative AI, before neural networks, before anything — what is a model?

A model is a function that turns an input into an output, where the rules were learned from examples rather than written by a programmer.

That distinction is the whole game. Consider a store that wants to flag orders as fraudulent. The traditional way is to write the rules by hand:

function isFraud(order) {
  if (order.amount > 5000) return true;
  if (order.billingCountry !== order.shippingCountry) return true;
  if (order.accountAgeDays < 1) return true;
  return false;
}

A human decided the number 5000. A human decided that a country mismatch matters. Every rule is traceable to a person's judgement. This works, and for many problems it is still the right answer — it is fast, free, and completely explainable.

It also breaks down fast. Real fraud depends on hundreds of interacting signals with no clean thresholds. A $50 order can be fraud; a $9,000 order can be a loyal customer buying a sofa. Nobody can hand-write that.

So instead you show a program 100,000 past orders, each labelled "fraud" or "fine", and let it discover the pattern itself. The output of that process — the learned rules, frozen and reusable — is the model.

1.3 Generative AI, defined

The fraud model above answers a closed question: fraud, or not? It picks from a fixed list of possible answers. That is discriminative AI — it discriminates between categories.

Now imagine asking instead: "write a product description for this waterproof hiking boot." There is no list to pick from. The answer is a sentence that has quite possibly never been written before. The model must produce new content, not select from options.

The difference is easiest to feel with a concrete pair:

1.4 Untangling AI vs ML vs NLP vs GenAI

These four terms get used interchangeably in job ads and press releases, which is unhelpful, because they are not synonyms — they are nested categories that partially overlap.

1.5 A short history: how we got here

You cannot judge whether a technique is good without knowing what it replaced. This timeline is not trivia — each entry exists because the previous approach hit a wall, and knowing which wall tells you when the old approach is still perfectly fine.

• 1950s-80s Rule-based language systems. Linguists hand-wrote grammar rules. ELIZA (1966) simulated a therapist using pattern matching alone. Wall hit: human language has endless exceptions. Every rule added broke two others.
• 1990s Statistical NLP. Instead of rules, count things. If "New York" appears together far more often than chance would predict, treat it as a unit. This powered early machine translation. Wall hit: counting words ignores meaning. "Bank" by a river and "bank" with money were the same token.
• 2003-2013 Neural language models and word embeddings. Represent each word as a list of numbers, positioned so similar words sit close together. Word2Vec (2013) made this famous. Wall hit: each word got exactly one vector regardless of context.
• 2014-2016 RNNs, LSTMs and sequence-to-sequence. Networks that read text one word at a time, carrying a memory forward. Powered Google Translate from 2016. Wall hit: strictly sequential, so training could not be parallelised, and memory of early words faded across long inputs.
• 2017 The Transformer. The paper Attention Is All You Need (Vaswani et al., Google) dropped recurrence entirely in favour of attention. Training could now parallelise across a whole sequence. This is the architecture under every modern LLM, and Chapter 2 takes it apart piece by piece.
• 2018 Pre-training becomes the recipe. BERT (Google) and GPT-1 (OpenAI) showed you could pre-train once on enormous unlabelled text, then adapt cheaply to specific tasks. This is the birth of the foundation model idea.
• 2020 Scale as a strategy. GPT-3, at 175 billion parameters, could perform tasks it was never explicitly trained on, purely from instructions written in the prompt. "Prompting" became a skill worth having.
• 2022 Instruction tuning and RLHF. InstructGPT, and then ChatGPT in November 2022, showed that teaching a model to follow instructions helpfully mattered more to users than raw size did.
• 2023-present The production era. Long context windows, multimodality, tool calling, strong open-weight models, and a shift in the interesting problems — from "can it do this?" to "can it do this reliably, cheaply and safely at scale?" Most of this course lives here.

1.6 Foundation models

Before 2018, each task meant its own model. Want sentiment analysis? Collect labelled reviews and train a sentiment model. Want product categorisation? Start again from scratch with a new labelled dataset. Every task paid the full cost of data collection and training.

The foundation model flipped that economic structure on its head.

1.7 Parameters and weights: what is actually inside

We keep saying a model is "a big pile of learned numbers". Let us be precise, because two terms — parameters and weights — get used loosely and you should know the difference.

Here is the smallest honest example. Predict a shipment's cost from weight and distance:

# w1 and w2 are weights; b is a bias. Three parameters total.
def shipping_cost(weight_kg, distance_km, w1, w2, b):
    return w1 * weight_kg + w2 * distance_km + b

# "Training" means finding good values for w1, w2 and b
# by looking at thousands of past shipments.
shipping_cost(weight_kg=2.0, distance_km=300,
              w1=1.20, w2=0.008, b=2.50)
# -> 1.20*2.0 + 0.008*300 + 2.50 = 7.30

That is genuinely all a parameter is: a number that gets multiplied or added, whose value was tuned so predictions match reality. A large language model is the same idea at a different quantity — billions of them, arranged in layers. There is no extra magic ingredient, only scale and structure.

The arithmetic worth memorising: parameters times 2 bytes equals gigabytes of memory at 16-bit precision. An 8B model needs roughly 16 GB just to hold the weights, before any working memory for the actual conversation. This one calculation decides whether you can self-host or must rent an API.

1.8 Large vs small language models

There is no official parameter count at which "small" becomes "large" — the boundary moves every year. What stays constant is the shape of the trade-off.

1.9 Pre-trained vs fine-tuned models

Training a modern LLM happens in stages. Knowing the stages tells you which lever to pull when the model is not doing what you want.

1. Pre-training: learning language itself The model reads an enormous amount of text and repeatedly plays one game: predict the next word. No human labels are needed, because the text supplies its own answers — hide the next word, guess it, check, adjust. Do this trillions of times and grammar, facts, reasoning patterns and style all get absorbed. This costs millions of dollars and takes months.
2. Supervised fine-tuning: learning to be useful A raw pre-trained model only continues text. Ask it a question and it might reply with a list of more questions, because that is a plausible continuation of a document. So it is trained further on curated pairs of instruction and good response. Now it answers rather than continues.
3. Alignment (RLHF and successors): learning to be preferred Humans compare pairs of model outputs and pick the better one. The model is tuned toward the preferred style: helpful, honest, willing to say "I don't know", and declining harmful requests. Reinforcement Learning from Human Feedback is what separated ChatGPT from GPT-3 in users' eyes, despite similar underlying capability.
4. Your fine-tuning: optional, and usually skipped You can continue training on your own examples to teach a consistent output format or house style. Modern practice uses parameter-efficient methods such as LoRA (2021), which trains a small add-on adapter instead of all the weights, cutting cost by orders of magnitude.

1.10 Tokens and tokenization

Here is a fact that surprises people: a language model has never seen a word. It works entirely with numbers. Tokenization is the translation layer between the text you write and the numbers the model consumes.

Why not just use words?

The obvious design is one token per word. It was tried, and it fails in three ways.

1. The vocabulary explodes English has millions of word forms once you include names, plurals, typos and product codes. Every distinct word needs its own row in a lookup table, and that table becomes enormous.
2. Unknown words break everything Your catalogue contains "Hydroflask", "size-12EE" and "Ryobi". A word-level model that never saw them in training has literally no representation, and must fall back to a useless placeholder.
3. Obvious relationships are lost "Walk", "walking" and "walked" become three unrelated entries. The model has to learn each independently instead of sharing what it knows about "walk".

The other extreme — one token per character — solves those problems but creates a worse one: sequences become very long, and the model must spend its capacity learning that "c-a-t" spells a word before it can learn anything about cats.

Tokens are the unit of billing, speed and memory

Tokens are not an implementation detail you can ignore. They are the unit in which you pay, the unit that limits how much the model can read, and the unit that determines how long a response takes.

1.11 Context and the context window

Now the single most misunderstood idea in the whole field. Get this one right and a great deal of confusing LLM behaviour suddenly makes sense.

How context windows grew, and what it cost

Context windows have expanded dramatically. This is one of the clearest capability jumps of the last few years.

Why did this take so long? Because of how attention works, doubling the context originally quadrupled the computation required. Chapter 2 explains the mechanism. Getting to a million tokens took genuine architectural innovation, not just bigger machines.

1.12 Inference: what happens when you press send

Here is the part that surprises people most. A model does not compose a sentence, or plan an answer, or decide what it is going to say. It does exactly one thing:

Generating a ten-word answer means running the model roughly thirteen separate times. Each run produces one token, which is appended to the input, and then the whole thing runs again. This is called autoregressive generation: the model's own output feeds back in as input.

1. Tokenize the input Your text becomes token IDs, as in section 1.10. "Best boots for rain" becomes something like [6435, 16512, 329, 6290].
2. Run a forward pass Those IDs travel through every layer of the network. Chapter 2 opens this box; for now treat it as a very large mathematical function.
3. Produce logits The output is one raw score per token in the vocabulary. For a 50,000-token vocabulary that is 50,000 numbers, one for every word the model could say next. These raw, unnormalised scores are called logits.
4. Convert logits to probabilities A function called softmax squeezes those raw scores into probabilities that sum to 1. Now you have a genuine probability distribution over the vocabulary.
5. Sample one token Pick a token from that distribution. How you pick is where temperature and top-p come in, which is the next section.
6. Append and repeat Add the chosen token to the sequence and go back to step 2. Stop when the model emits a special end-of-sequence token, or when you hit your maximum output length.

Why this loop shapes everything about performance

Once you understand that generation is a loop with one model run per token, several production behaviours stop being mysterious.

1.13 Temperature, top-p and top-k

Step 5 of the loop said "sample one token from the distribution". That word sample is doing a lot of work. These three settings control how the choice is made, and they are the dials you will actually touch in production.

The simplest strategy, and why it is not enough

The obvious approach is to always take the highest-probability token. This is called greedy decoding. It sounds ideal — always pick the best option — but it produces noticeably poor text.

The reason is subtle: the best word at each individual step does not add up to the best sentence. Greedy decoding gets stuck in loops ("the product is very very very good"), produces bland phrasing, and cannot recover from an early wrong turn because it never considers alternatives.

The name comes from physics, specifically the Boltzmann distribution in statistical mechanics: heat a system and its particles occupy a wider spread of states. Same mathematics, same intuition.

Top-k and top-p: trimming the candidate list

Temperature rescales probabilities but never removes a candidate. Even at a low setting, "purple" keeps a tiny chance — and across thousands of generations, tiny chances happen. Top-k and top-p solve that by cutting the list before sampling.

Why top-p generally beats top-k

The weakness of top-k is that it is rigid. A fixed k cannot adapt to how confident the model is, and confidence varies enormously between one token and the next.

1.14 Deterministic vs non-deterministic generation

Standard software is deterministic and we rely on that completely. Call calculateTax(100) a thousand times and you expect the same answer a thousand times. Language models break that expectation by default, and that has real consequences for testing, debugging and customer trust.

Where the randomness comes from

The model itself is deterministic. Feed the same tokens through the same weights and you get the same probability distribution every time, down to the last decimal. The randomness lives entirely in step 5 of the loop: sampling. Drawing from a distribution is a dice roll, and a different roll gives a different token, which changes all subsequent context, which changes everything after it.

How to get closer to reproducibility

1. Set temperature to 0 The single largest factor. Removes deliberate randomness from sampling.
2. Pass a seed if the provider supports one A fixed seed makes the random draws repeatable. Several APIs expose this, often alongside a system fingerprint that tells you when the backend changed.
3. Pin the exact model version Use a dated or versioned model identifier rather than a moving alias. An alias like "latest" will silently change under you, and your carefully tested prompts will behave differently overnight.
4. Constrain the output format Requiring strict JSON with a fixed schema eliminates most surface variation. The prose may wobble; the structure will not.
5. Cache aggressively The most reliable way to return the same answer twice is to not ask twice. Store the result against a hash of the input.

1.15 Hallucinations

The most talked-about failure mode of language models, and the most misunderstood.

Why hallucination is not a bug

This is the crucial insight, and it changes how you design around the problem.

A language model was trained to produce plausible continuations of text. It was never trained to produce true statements. Truth and plausibility overlap heavily, which is why models are useful at all — but they are not the same thing, and when they diverge the model follows plausibility every time.

The main varieties

How to reduce hallucination, in order of effectiveness

You cannot eliminate hallucination, because it is inherent to how the model works. You can make it rare and, more importantly, make it detectable.

1. Ground the model in retrieved facts By far the biggest win. Instead of asking "what is our returns policy?", retrieve the actual policy document and ask "using only the text below, answer the question." The model shifts from recalling to reading. This is RAG, and Chapter 4 is devoted to it.
2. Give explicit permission to refuse Add to your system prompt: "If the provided context does not contain the answer, say you do not know." Models will not do this by default, because refusing is a less plausible continuation than answering. You have to make it an instruction.
3. Require citations Ask for the source of each claim. This helps in two ways: it nudges the model toward supported statements, and it makes unsupported ones visible to you and the user.
4. Lower the temperature Higher temperatures sample lower-probability tokens, and lower-probability tokens are more likely to be wrong. For factual tasks, stay near zero.
5. Never let the model produce authoritative numbers Prices, stock levels, order status and delivery dates should be inserted from your database into the response template, not generated. If a number matters, it should never pass through the sampling step.
6. Validate the output programmatically Check that any product mentioned exists in your catalogue. Check any quoted price against your database. Automated verification catches what prompting cannot.

1.16 Model bias and limitations

Bias is not a moral failing of the model, and it is not something a vendor forgot to switch off. A model trained on human text absorbs the statistical regularities of that text, including the ones we would rather it did not.

Where bias comes from

The honest limitations list

Separate from bias, these are structural limits worth knowing before you promise something to a stakeholder.

1.17 Grounded generation

Everything in this chapter has been building to this idea. It is the single most important architectural pattern in applied generative AI, and it is the bridge into the rest of the course.

The same question, two architectures

# SYSTEM
You answer customer questions about returns.
Use only the CONTEXT below.
If the context does not contain the answer, say:
"I don't have that information — let me connect you to an agent."
Cite the section for every claim you make.

# CONTEXT (retrieved from your document store)
[returns-policy 4.1] Unworn items may be returned within 30 days.
[returns-policy 4.2] Sale items are final and cannot be returned
                     unless faulty.
[returns-policy 4.3] Faulty goods are refunded in full at any time.

# USER
Can I return the discounted jacket I bought last week?

Three things are doing the work here. The instruction to use only the context constrains where answers may come from. The explicit escape hatch gives the model a plausible path other than inventing. The citation requirement makes any violation visible.

The obvious question this raises: how do you find the right documents to put in the context in the first place? With 20,000 products and hundreds of policy pages, you cannot send everything. Answering that question well requires embeddings (Chapter 3), vector search (Chapter 5), and the full retrieval pipeline (Chapter 4).

1.18 Key takeaways

1.19 Interview drills

Eighteen questions drawn from this chapter, in the form interviewers actually ask them. Try to answer before expanding. The model answers are deliberately concise: what a strong candidate would say in 30 to 60 seconds, plus the follow-up you should expect.

Expand all

1.20 Where this leads

This chapter deliberately treated the model as a black box: text in, tokens out. That was enough to reason about cost, latency, consistency and hallucination — which is most of what matters day to day.

But several answers ended with "because of how attention works". Why doubling context used to quadruple the compute. Why models read input in parallel but write output one token at a time. Why transformers displaced everything before them in 2017. Chapter 2 opens the box and answers all three from first principles.