Chapter 11: Key Takeaways
-
An LLM is a decoder-only transformer trained on next-token prediction — nothing more, nothing less. The architecture is the same transformer from Chapter 10: causal self-attention, feed-forward networks, residual connections. What makes LLMs remarkable is not architectural novelty but scale: billions of parameters trained on trillions of tokens. Emergent capabilities — in-context learning, chain-of-thought reasoning, few-shot generalization — arise from scale, not from special design choices. Understanding the architecture means understanding that there is no secret ingredient.
-
The three-stage training pipeline transforms a text completer into an aligned assistant. Pretraining (massive data, next-token prediction) builds general language understanding. Supervised fine-tuning (curated instruction pairs, loss on response tokens only) teaches the model to follow instructions. Alignment via RLHF or DPO (preference data) steers the model toward helpful, truthful, harmless outputs. Each stage uses different data, different objectives, and different compute budgets — and each is essential. DPO has emerged as the practical default for alignment because it eliminates the reward model and RL loop that make RLHF engineering-intensive.
-
LoRA makes fine-tuning accessible by exploiting the low-rank structure of weight updates. When fine-tuning a pretrained model on a domain-specific task, the weight change $\Delta W$ is empirically low-rank — most of the model's knowledge is preserved, and only a small task-specific adjustment is needed. LoRA trains $\Delta W = BA$ with $r \ll d$, reducing trainable parameters by 100x+ and enabling fine-tuning on a single GPU. Combined with 4-bit quantization (QLoRA), a 65B model can be fine-tuned on consumer hardware. At inference time, the LoRA weights merge into the base model with zero latency overhead.
-
RAG grounds LLM responses in retrieved evidence, but retrieval quality bounds generation quality. The RAG pipeline — chunk, embed, retrieve, augment, generate — extends an LLM's knowledge beyond its training data. But if the retrieval stage misses the relevant document, the generation stage cannot compensate. This makes embedding model selection, chunking strategy, and retrieval evaluation (precision@$k$, NDCG) as important as the LLM itself. Hybrid search (dense vectors + sparse keywords) and cross-encoder reranking consistently outperform single-method retrieval.
-
Hallucination is a fundamental property of probabilistic generation, not a bug to be fixed. LLMs are trained to produce plausible text, and plausibility and truthfulness are different properties. The model assigns nonzero probability to incorrect continuations because the training data contains ambiguity, contradiction, and insufficiency. RAG reduces hallucination by providing factual context; validation pipelines catch it after the fact; but no method eliminates it. Production systems must be designed with this limitation as an architectural constraint — not an edge case to be patched.
-
LLM evaluation is an unsolved problem, and honest evaluation requires multiple methods. No single metric captures the quality of free-form text generation. BLEU and ROUGE measure lexical overlap and miss semantic equivalence. BERTScore captures semantics but requires reference texts. LLM-as-judge is flexible but introduces biases (self-preference, verbosity, position). Human evaluation is the gold standard but does not scale. The practical answer is layered evaluation: unit tests for regressions, automated metrics for drift detection, LLM-as-judge for nuanced quality, and human evaluation on a calibration sample.
-
The gap between demo and production is where most LLM projects fail. Building a working LLM demo takes hours. Building a reliable, monitored, cost-effective production system takes months. The production challenges are engineering, not ML: stale vector indexes, inconsistent extraction across runs, context window management, latency budgets, cost optimization, and regulatory compliance. The MediCore case study illustrates this clearly: the LLM extraction works impressively on individual notes, but deploying it across 340,000 notes requires a validation pipeline, error monitoring, human review workflows, and regulatory documentation — all of which cost more engineering effort than the LLM integration itself.