Working with the context window
An LLM's only working memory is its context window, the tokens it can attend to at once: from a few thousand in early models to hundreds of thousands or more today. Everything it should use must either be in its weights (learned in training, frozen at a cutoff date) or in the context.
- Prompting: clear instructions, examples of the desired output (few-shot), and relevant background all go in the context.
- Chain of thought: asking a model to work step by step before answering improves multi-step reasoning (Wei et al., 2022), because each generated token becomes context for the next: the model gets more computation per answer.
- Retrieval-augmented generation (RAG) (Lewis et al., 2020): embed documents as vectors, retrieve the ones most similar to the question (cosine similarity, module 1), and put them in the prompt. The model answers from current, citable sources instead of memory alone.
- Tool use: models can be trained to emit structured calls to calculators, code interpreters, search engines or APIs, and read the results back into their context.
Hallucination
Models sometimes state falsehoods fluently and confidently: invented citations, wrong dates, functions that don't exist. This follows from the objective: pretraining rewards plausible continuations, and a plausible-sounding citation is exactly that. Models are also better calibrated about what they know than their confident tone suggests, but not reliably so. Mitigations include retrieval with citations, training models to say "I don't know", verification with tools, and, for anything important, human checking.
Evaluating LLMs is hard
- Benchmarks saturate: tests like MMLU (multiple-choice questions across 57 subjects) went from hard to nearly solved within a few years, so new, harder ones keep appearing.
- Contamination: benchmark questions leak onto the web and into training data. A high score may reflect memorisation, the module 3 leakage problem at internet scale.
- Prompt sensitivity: small wording changes can move scores, so comparisons need identical setups.
- Human preference arenas, held-out private test sets, and evaluations of real tasks (fixing actual software bugs, for example) complement static benchmarks.
The same honesty you practised in module 3 applies here, with higher stakes: decide how you'll evaluate before you look, keep test data away from training, and be suspicious of results that look too good.
Everything a model uses must be in its weights or its context. Retrieval and tools extend the context; hallucination and benchmark contamination are reasons to verify.