Splitting the Dataset into Training, Validation, and Test Sets

Before a model can be trained and judged, the data it works with has to be divided. In the workflow this article belongs to, the spam dataset has already been downloaded and balanced, and the next step is to separate it into parts that serve different purposes. Splitting a dataset into training, validation, and testing subsets is a common practice in machine learning. The goal of this article is to make that split concrete in code, and to store the result on disk so it can be reused.

The split is not arbitrary. Each part exists so that the model can be trained, adjusted, and then evaluated on data it was not trained on. Keeping those jobs separate is what makes the final evaluation meaningful. Before you read the code in this article, keep a question in mind: when the data is divided three ways and each part is saved to its own file, how can you be sure that each file holds the rows you intended?

The training subset is the portion the model learns from. The validation subset is used to adjust the model while it is being developed. The testing subset is held back to evaluate the model at the end. The source describes these three uses as training, adjusting, and evaluating the model, and these are the roles the ratios are meant to support.

The diagram shows the order of use. The validation subset is the one that feeds back into development, because it is used to adjust the model while it is being built. The testing subset does not feed back: it is kept out of the adjustment loop so that it can judge the finished model on data the model has not been shaped around.

The source introduces a function named random_split to perform the split. It takes the DataFrame and two fractions, one for training and one for validation. Notice what it does not take: a fraction for testing. The testing share is whatever remains after the training and validation shares are removed, which is why the test size is implied to be 0.2 when the other two fractions are 0.7 and 0.1.

Read the function as a sequence of steps. The first step is a shuffle. The call df.sample with frac=1 returns every row in a new order, and random_state=123 fixes that order so that running the code again produces the same split. The reset_index call with drop=True gives the shuffled rows fresh positional numbering. The second and third steps compute where the cuts go. The fourth step slices the DataFrame at those cuts. The function returns the three pieces as a tuple, and the final line unpacks that tuple into three named variables.

The three pieces never overlap. Each slice begins where the previous one ended, so every row lands in exactly one subset. The shuffle is what makes the assignment of rows to subsets unrelated to the original order of the file, and random_state is what makes that assignment repeatable.

The easiest way to see the mechanism is to picture the shuffled rows as a row of numbered positions. The boundaries are cut into that row. Positions before the training boundary belong to the training subset, positions between the two boundaries belong to the validation subset, and everything after belongs to the testing subset.

In this picture, the training boundary falls after position 6 and the validation boundary falls after position 7. The row at position 7 is the only validation row, and the last two positions form the testing subset. The positions are the order after the shuffle, not the order in the original file, which is why the shuffle matters.

Once the split is made, the subsets can be saved as CSV files, where CSV stands for comma-separated value. A DataFrame is the object that holds the data while your program runs. A CSV file is a plain text file on disk. The to_csv method is the bridge between the two: the DataFrame stays in memory, and the method produces a file that holds the same data in a form that other programs and later sessions can read. Because the method is called on the DataFrame itself, the DataFrame variable name appears before the dot.

Read each line from left to right. The DataFrame name tells you what is being saved, the method name tells you what happens to it, the string tells you where it goes, and the index argument tells you how the save is configured. A wrong name in any one position produces a file that does not match what you intended, so the reading habit is the main skill here.

The diagram shows the pattern for this section. Each DataFrame has its own call to to_csv, and each call writes to its own file. Nothing is combined: the training data goes to train.csv, the validation data goes to validation.csv, and the test data goes to test.csv. Together, the three files hold the complete dataset in the three parts produced by the split.