LLMs & Generative AI in Practice

From transformer to assistant

You know the engine (transformers, next-token prediction). An assistant like ChatGPT or Claude is that engine plus a production line:

1. Pretraining — predict the next token over trillions of words. Yields a base model: a brilliant, amoral autocomplete containing compressed world knowledge.
2. Instruction tuning — fine-tune (supervised!) on curated examples of instructions and good responses, teaching the format of helpfulness.
3. Preference alignment — humans (and increasingly AI judges guided by written principles) rank candidate responses; RLHF-style optimization (RL path!) pushes the model toward preferred behavior: helpful, honest, harmless.

Sampling settings matter downstream: temperature scales the randomness of token choice — low = focused and repeatable (extraction, code), high = varied (brainstorming).

Working with LLMs: the new engineering stack

• Prompting — the model completes patterns, so shape the pattern: clear instructions, explicit output format, worked examples in the prompt (few-shot), and "think step by step" (chain-of-thought) which improves multi-step reasoning by making the model generate intermediate steps before answers.
• RAG (retrieval-augmented generation) — the antidote to stale knowledge and hallucinated facts: embed your documents (embeddings — ML path), vector-search the relevant passages for each query (k-NN at scale!), and stuff them into the prompt so answers are grounded in sources the model can cite. This is how "chat with your company's docs" products actually work.
• Tool use & agents — let the model emit structured calls (search, calculator, code execution, APIs), feed results back, and loop: plan → act → observe → replan. This turns a text predictor into a system that does things — the agent framework from lesson one, with an LLM as the policy. Multi-step autonomy amplifies both usefulness and error compounding; production agents need guardrails, budgets and human checkpoints.
• Fine-tuning — for specialized domains/styles, efficient methods (LoRA adapters) retrain a sliver of weights on your data. Rule of thumb: try prompting, then RAG, then fine-tuning — in that order of cost.

Failure modes you must design around

• Hallucination — fluent, confident fabrication (citations, APIs, case law). Mitigate with RAG + citation checking, never eliminate. Treat unverified LLM facts as drafts.
• Jailbreaks & prompt injection — adversarial text that overrides instructions; especially dangerous when agents read untrusted web content that may command them.
• Bias — internet-scale training data imports internet-scale stereotypes (next lesson).
• Cutoffs & context limits — models know nothing after training and forget beyond their context window; both are system-design constraints, not bugs to be surprised by.

The professional stance: LLMs are extraordinary components — probabilistic, fallible, improving fast — to be engineered around with evaluation, grounding and oversight, exactly like any other component with a failure rate.

Key takeaways

• Assistant = pretraining + instruction tuning + preference alignment; each stage shapes different behavior.
• The applied stack in cost order: prompting → RAG → tools/agents → fine-tuning.
• Design for hallucination, injection and drift the way engineers design for component failure.