2 How to do model adaptation

This chapter frames model adaptation as a set of practical choices rather than a single “best” technique. It warns that teams often pick a method that is too heavy for the task, as in the opening example where full fine-tuning was used when retrieval over fresh documents was the real need. The central idea is an adaptation continuum: prompting, RAG, LoRA, full supervised fine-tuning, distillation, and preference optimization each add capability, but they also increase data needs, hardware requirements, timeline, cost, and operational complexity.

Most of the chapter is about matching the method to the problem. It explains that RAG is best when knowledge changes frequently, LoRA is often enough for voice, format, or domain behavior, full fine-tuning is reserved for harder reasoning or when LoRA plateaus, distillation helps when you want frontier-model quality at lower serving cost, and preference optimization is useful for refusal behavior, safety, and tone. The chapter also emphasizes that real production systems usually stack methods: a common pattern is a base model plus fine-tuning, retrieval, and guardrails, with telemetry and logging on top. It then walks through the buy-versus-build decision, showing when a managed API is the fastest and cheapest start and when self-hosting becomes necessary because of scale, privacy, or deeper customization needs.

The rest of the chapter gives the supporting infrastructure and operational guidance needed to make those choices work in practice. It reviews common training frameworks, the main categories of self-hosting infrastructure, and how to choose a base model based on task difficulty, latency, hardware, and ecosystem maturity. It then offers a small LoRA quickstart to show the full adaptation loop in miniature: prepare data, load a base model, train an adapter, generate outputs, and save the result. Finally, it stresses security and operations, noting that each adaptation method changes the attack surface and can weaken safety if not tested carefully, so teams should use regression checks, manifests, promotion lanes, canaries, rollback triggers, and monitoring from the start.

The hybrid production stack: each layer adds capability; requests travel down, responses come back up.

Managed-API cost scales with request volume; self-hosted cost is largely fixed.

• The continuum is a menu to combine from, not a single rung to pick. Most production systems layer RAG for knowledge access, LoRA or SFT for behavioral specialization, and alignment for tone or refusal on top of a base model.
• Half of the techniques on the continuum require fewer than a thousand examples, and the pair that is cheapest to build (prompting and RAG) ships in days and pays for its capability per call instead. Cost discipline argues for walking the continuum from cheapest to heaviest, not skipping straight to fine-tuning.
• Buy versus build is upstream of any training decision. Managed APIs win on speed-to-prototype and operational simplicity. Self-hosting wins on customization depth, data privacy, and cost at scale once the volume crosses the break-even point.
• Hard constraints decide the rung. Safety guarantees, latency budgets, data-residency requirements, and cost-per-call ceilings are what graduate a project from prompting to LoRA to full SFT, not enthusiasm for a heavier technique.
• Each adaptation technique characteristically changes the attack surface. Fine-tuning erodes safety properties even on benign data; RAG opens a retrieval pipeline that can be poisoned; distillation transfers task behavior more reliably than refusal behavior. Mitigations are mostly operational rather than algorithmic.
• A small set of operational disciplines (promotion lanes, artifact manifests, canary deployment, rollback triggers, traffic logging) belongs in the design from day one. Chapter 9 builds these out; this chapter establishes the floor.

FAQ