Mastery check: connect the pieces

Complete this explanation in your own words:

1. Pretraining: Text and code are tokenized into sequences. The model predicts next tokens, receives an error signal, and adjusts many numerical weights over repeated examples.
2. Representation: Learned patterns are distributed across parameters and activations rather than stored as one tidy record per fact.
3. Request time: Instructions, examples, conversation history, and supplied sources form a bounded context. Normal prompting does not rewrite the model’s weights.
4. Generation: The model produces scores for possible next tokens. Decoding selects one, appends it to the context, and repeats.
5. Product controls: Retrieval, tools, schemas, permissions, validation, and human review can extend or constrain the base model.

A strong explanation connects these steps without overclaiming. It can say the model “learns patterns” and “performs reasoning tasks” while remaining clear that observable capability does not prove human-like thought or direct access to a source archive.

For each claim, identify the mistake and write a better version.

Claim 1: “The model downloaded a live copy of the internet.”
A pretrained model has fixed weights at inference time. A product may separately provide web search. Better: “The application can retrieve current web pages and provide selected content to the model.”

Claim 2: “The answer sounds certain, so the model is confident.”
Tone is generated text, and token likelihood is not the probability that a whole claim is true. Better: “The answer is fluent; verify important claims against authoritative evidence.”

Claim 3: “We showed it three examples, so it is permanently trained.”
Examples in a prompt cause in-context adaptation while they remain available. Better: “The examples temporarily demonstrate the task and expected format.”

Claim 4: “A bigger context window means it will use every detail correctly.”
Capacity does not guarantee retrieval or attention quality. Better: “The material fits, but long-context performance must be tested with representative documents.”

These corrections are practical. Each points toward a different system design: retrieval for freshness, verification for truth, prompt examples for temporary adaptation, and evaluation for long-context reliability.

Match the failure to the intervention:

• Missing current information: retrieve an authoritative source or call a tool.
• Inconsistent output syntax: use a schema, constrained output, and validation.
• Ambiguous category labels: improve instructions and add representative examples.
• Exact arithmetic errors: use a calculator or executable code.
• High-impact judgment: preserve qualified human review and accountability.
• Slow, expensive routine task: test a smaller model or route only difficult cases upward.
• Repeated task failure across prompts: compare stronger models, improve task data, or redesign the workflow.

Do not use one remedy for every problem. Lowering temperature can improve repeatability but cannot update stale knowledge. A larger model can improve quality but does not replace permissions. Retrieval can supply evidence but can also introduce irrelevant or malicious text.

A company wants an assistant that answers employee leave questions from an internal handbook. Design it from end to end.

Context: Retrieve a few relevant handbook passages for each question. Include passage IDs and policy dates. Instruct the model to use only those passages for policy claims.

Output: Ask for a direct answer, cited passage IDs, and needs_human_help: true when the passages conflict or do not support an answer.

Controls: Enforce access permissions before retrieval. Keep employee details out of logs where possible. Validate the output structure. Check that cited IDs were actually supplied.

Evaluation: Test ordinary questions, unusual employment types, conflicting passages, missing policy coverage, prompt injection inside documents, and requests for individualized legal advice.

Review: Route unsupported, sensitive, or consequential cases to the appropriate people team. Present the assistant as a policy navigation aid, not the final authority.

Notice how little is solved by asking for “a smart model.” Reliability comes from the model plus sources, permissions, task design, checks, and ownership.

Answer these without looking back:

1. Why can next-token prediction support translation and code generation?
2. What changes during pretraining, and what normally stays fixed during a request?
3. How does temperature affect a probability distribution?
4. Why can an early generated error influence the rest of an answer?
5. What is in-context learning, and why is it temporary?
6. Why is a fluent citation not sufficient evidence?
7. When should a deterministic tool replace or support an LLM?
8. Which dimensions would you compare when selecting a model?

Good answers should mention learned patterns, weights, context, sequential decoding, external evidence, and task-level evaluation. If your answer relies on “the AI just knows,” replace that phrase with the mechanism or evidence you mean.

This topic used tokens as the basic units of input and output, but several questions remain. How does a tokenizer split unfamiliar words? Why do languages and code consume different token counts? How do token budgets affect context, latency, and price?

It also treated training as repeated prediction and weight updates. A deeper treatment will examine loss, gradients, data mixtures, training stages, evaluation splits, and how teams distinguish memorization from generalization.

Carry two bridge questions forward:

• Token question: What exactly did the model receive, and what fit inside its context window?
• Training question: Which behavior came from fixed weights, which came from current context, and which came from an external system?

Those questions prevent many category errors. They separate the model from the product around it and turn vague claims about “AI intelligence” into components you can inspect.