1 Why model adaptation?

Large language models are powerful generalists, but production enterprise use often exposes a gap between fluent answers and trustworthy, domain-specific behavior. This chapter frames model adaptation as the set of techniques that reshape a pretrained model for a particular organization, task, domain, culture, or workflow without training a new model from scratch. Instead of treating the decision as simply “fine-tune or not,” it presents adaptation as a continuum ranging from prompting and retrieval-augmented generation to LoRA, full supervised fine-tuning, distillation, and preference optimization. The central message is that teams should choose the lightest technique that solves the measured problem, rather than jumping straight to training.

The chapter explains where adaptation creates value: specialized industry knowledge, regional and cultural fit, enterprise tone and brand behavior, lower inference costs, privacy and data-sovereignty compliance, reduced latency, and protection from vendor lock-in. It also emphasizes when adaptation is the wrong choice. Commodity tasks, early-stage projects without baselines, weak or insufficient data, and cases where a frontier model already performs well should usually stay with prompting or RAG. Across all scenarios, the chapter argues that data quality and evaluation matter more than technique choice: a small, well-curated dataset and a trusted held-out evaluation set often beat much larger but noisy training data.

The chapter then outlines a practical adaptation lifecycle: start with a base model and curated data, apply an appropriate adaptation method, evaluate against a production-representative test set, run safety checks, deploy only if the adapted model improves on the baseline, and feed production failures back into the next data iteration. It introduces diagnostic questions for choosing a starting technique: whether the task is commodity or specialized, whether a prompting baseline has been measured, whether enough high-quality examples exist, and what hard constraint is driving the project. Finally, it sets up the book’s hands-on path using an accessible open-weight model, a small IT-support dataset, and a Python-based toolchain, with later chapters building progressively from prompting and RAG through LoRA, full fine-tuning, distillation, alignment, deployment, monitoring, and rollback.

The model adaptation continuum, drawn as engineering effort against influence over model behavior. The gaps are deliberately uneven: moving from prompting to LoRA is a far larger step than from prompting to RAG.

The model adaptation lifecycle

A decision flowchart for choosing your first adaptation technique.

• Off-the-shelf LLMs are generalists; enterprises need specialists. The right framing is a continuum, not “fine-tune or not.” The question is which rung of the ladder this specific problem fits.
• Four questions structure every adaptation project: do we need to fine-tune at all, how much data, open-source or frontier API, and what is the difference between fine-tuning, distillation, and alignment.
• Model adaptation is a five-stage lifecycle: base model + curated data → adaptation technique → evaluation gate → deploy and monitor → feedback to data curation. The technique is one of the five places a project can fail.
• Three scenarios drive most enterprise work: industry-specific specialization, regional and cultural adaptation, and enterprise tone and brand.
• ROI breaks down into cost (a 5-10× per-request reduction depending on the frontier tier), privacy and data sovereignty, latency, and competitive advantage. Common pain points are accuracy gaps, API cost at scale, regulatory constraints, and vendor lock-in.
• Adaptation is the wrong answer for commodity use cases, early-stage projects without baselines, projects without enough high-quality data, and cases where the frontier model is already good enough.
• The continuum runs from prompting and RAG through LoRA and full SFT to distillation and alignment. A four-question decision framework points each project to its starting technique.
• Adaptation does not fix confabulation by itself. Fine-tuning on generic instruction data can make a model’s wrong answer more confident, not more correct. Closing the gap requires training data that explicitly demonstrates the desired behavior and, often, preference optimization on top.
• Adaptation can weaken model safety properties.

FAQ