Preparing data for supervised fine-tuning Part 1: Formatting and quality

AWS’s new guide makes a blunt case: if supervised fine-tuning is going to help, the data has to be excellent before anything else happens. The post is the first half of a two-part series and focuses on the basics — quality checks, formatting, and train/evaluation splits — with examples drawn from Amazon Bedrock documentation but meant to apply to any model.

The central argument is simple. Continued pre-training expands what a model knows. Supervised fine-tuning changes how it behaves. Reinforcement fine-tuning pushes that behavior with rewards. AWS says those steps can be combined, but in practice the company sees a common pattern of CPT first, then SFT, then RFT. For many foundation models, though, the advice is to skip straight to SFT and RFT unless the base model is missing key domain knowledge.

Before anyone formats a single file, AWS says to audit the raw data. Every example should be deployment-ready. Bad examples are not harmless noise; they can teach the model habits that stick. The post points to research showing that 1,000 carefully curated examples can compete with models trained on much larger datasets, and that pruning an instruction set down to its cleanest 20 percent can outperform the full set. If humans are labeling the data, AWS recommends multi-review before examples enter training.

Diversity matters just as much as cleanliness. A good SFT set needs semantic coverage, meaning different task domains and prompt phrasings, plus enough information depth in each example. It also needs edge cases: ambiguous inputs, incomplete information, and requests that should be refused. AWS suggests clustering examples by embedding similarity to find gaps — the kind of missing refund cluster that would leave a support model weak on refund conversations.

Then comes consistency. Similar tasks need similar answers. If one example uses bullets and another uses paragraphs, the model learns confusion instead of structure. AWS also warns about duplicate or near-duplicate samples, which can make the model overweight repeated patterns, and about toxicity screening, since harmful content can leak into unexpected outputs. On formatting, the message is equally strict: match the chat template your model will use at inference, include system prompts when you plan to use them, keep JSONL to one object per line, and preserve the right turn order. The post also covers reasoning traces, tool calling, and multimodal examples, all of which have to be formatted carefully if you want the model to learn the right behavior instead of just the wrong syntax.