Evaluation Pipelines for Foundation Models

Imagine a hospital network that wants an assistant able to read and summarize clinical notes written in a regional language and in one specialized medical vocabulary. Before anyone thinks about which model design to pick, a more basic question appears: what has the model seen? A model can only become good at patterns that appear in the material it learned from. For foundation models, that material is the training data, and it is one of the most important factors in how a model performs.

This article follows the chain of decisions that starts with training data. Data feeds into design choices such as the size of the model, the way the model is refined after its first training phase, and the way it produces output. Each of these choices connects back to the data question, so keep the hospital scenario in mind as you read.

Large models need large amounts of training data. Collecting that data is expensive and slow, so providers often use whatever data is available. That choice can leave gaps for specific tasks. The data a model learned from sets the boundary of what it can reliably do, because the model's abilities come from patterns present in that material.

Model scale is described with three numbers. Each one answers a different question, and they must be read together rather than one at a time.

The three numbers are not independent. Two factors in particular shape how much compute training requires: the size of the model and the size of the dataset. A bigger model or a larger dataset generally means more training work. So a statement like this model is large tells you little until you also know how many tokens it was trained on and how much compute that took.

Suppose the total compute budget is fixed. Model size and data size both draw on that same budget, so increasing one leaves less room for the other. A scaling law is the rule that reads the budget and suggests a balanced allocation between parameters and tokens. It helps find the best balance of parameters and tokens for a given compute budget.

Pretraining produces a model whose outputs may not match what users want. Post-training comes after pretraining to address this. It is made of two steps: supervised finetuning and preference finetuning. Post-training narrows the gap between what a pretrained model produces and what people want.

The order matters because each step builds on the model produced before it. Supervised finetuning is the first post-training step, and preference finetuning is the second. Both exist because the pretrained model alone does not reliably produce outputs aligned with user expectations.

A model that produces text does not simply output one fixed answer. Its outputs are probabilistic. Generation can be pictured as a sequence of decisions: for each position, the model produces probability scores over candidate next tokens, and a sampling step picks one token from that distribution. The chosen token is then part of what comes next.

Because sampling makes outputs probabilistic, the model can produce varied wording for the same request. That variety can be useful when a user wants alternatives. The same property creates risk. Output that is not fixed can be harder to predict and harder to reproduce, so a reviewer who checks one response cannot assume the next response will match it.