Training and Fine-Tuning FMs
How foundation models get their knowledge: pre-training, fine-tuning methods, and the data preparation that decides whether tuning succeeds.
The customization ladder told you when to fine-tune. This topic shows you what fine-tuning actually is. It opens up the base model you have been calling in Bedrock, traces the three stages that built it, and then walks through the customization methods you can run yourself and the data those methods live or die on.
What This Topic Covers
- How pre-training works: self-supervised next-token prediction on massive unlabeled text, and why it costs providers so much
- The three stages that turn raw text into an assistant: pre-training, fine-tuning and instruction tuning, and alignment with RLHF
- The fine-tuning methods AWS offers: supervised fine-tuning, continued pre-training, reinforcement fine-tuning, and distillation
- The boundary the exam tests most: labeled task examples (fine-tuning) versus an unlabeled domain corpus (continued pre-training)
- What creating a custom model on Bedrock produces, and how training and storage are billed
- The JSONL formats Bedrock expects, and what makes a dataset representative, balanced, clean, and safe to train on
Why It Matters
Fine-tuning is one of the more expensive and error-prone things you can do with a foundation model, and the exam knows it. Questions here are rarely about definitions. They hand you a goal and a dataset and ask which method fits, or they describe a messy training set and ask what will go wrong. Both come down to the same skill: matching the method to the data you have and the outcome you need, then preparing that data so the model learns the real task instead of your noise. Get this right and fine-tuning delivers; get it wrong and you pay for a custom model that does not solve your problem.
