Evaluation Fundamentals › The Evaluation Lifecycle

Evaluation is not a one-time activity but a continuous process that evolves with the model development cycle. Understanding how evaluation fits into each stage of development helps you apply the right evaluation method at the right time.

During active model development, the primary evaluation goal is fast feedback. You are making many changes, and you need to know quickly whether each change improves or degrades performance. This requires cheap, automated evaluation that can run in minutes or hours rather than days.

Perplexity on a held-out validation set is the fastest signal: it is computed as a byproduct of training and requires no additional inference. For instruction-tuned models, a small set of representative prompts with automatic scoring, whether by regex matching, execution, or simple LLM-as-judge calls, provides the next layer of signal without the cost of a full benchmark evaluation.

The key discipline in this phase is not to over-index on any single signal. Improving validation perplexity is a good sign, but it does not guarantee improvement on instruction-following tasks. A small representative evaluation suite that covers the main capability areas you care about, run after each significant training change, provides far more actionable signal than perplexity alone.

Once training runs are complete and you have candidate model checkpoints, the evaluation focus shifts to comparison and selection. This is the stage where you need evaluation that is both broad and statistically reliable.

Best practice is to maintain a fixed, versioned evaluation suite for this purpose. Running all candidate checkpoints against exactly the same evaluation suite, in exactly the same conditions, ensures that score differences reflect model differences rather than evaluation variability. Any change to the evaluation suite, including updates to prompts or test sets, should be versioned and tracked so that comparisons across time remain valid.

For major checkpoints, supplement automatic evaluation with targeted human evaluation on a sample of outputs. Human evaluation is expensive, so focus it on the dimensions where automatic metrics are least reliable: instruction-following fidelity, response style, tone, and subjective quality. Human evaluation at this stage is used to validate that the automatic metrics are tracking what you care about, and to catch regressions that the automatic suite might miss.

Before deploying a model to users, evaluation must expand to cover dimensions that are irrelevant during training but critical in production: safety, reliability under adversarial inputs, behavior at the edges of the intended use case, and consistency across multiple runs.

Safety evaluation requires red-teaming: deliberately attempting to elicit harmful outputs through adversarial prompts, jailbreaks, and edge cases. This is a specialized form of evaluation that goes beyond standard benchmarks and requires domain expertise in the safety risks relevant to the deployment context. A customer service chatbot requires different safety evaluation than a medical information assistant, because the harmful outputs and the adversarial techniques differ.

Reliability evaluation checks whether the model behaves consistently under small variations in prompt wording, order of information, or irrelevant context. A model that gives a correct answer to a question stated one way but an incorrect answer to the same question stated differently is less reliable than its benchmark scores suggest. Measuring this variance requires prompt perturbation experiments that go beyond standard evaluation.

After deployment, evaluation must track how the model performs in the wild, on the actual distribution of user inputs rather than the evaluation distribution. This requires logging a representative sample of production inputs and outputs, and applying evaluation metrics to this production sample on a regular cadence.

Production evaluation reveals distribution shift: the gradual divergence between the deployment distribution and the evaluation distribution. It also reveals new failure modes that were not anticipated during pre-deployment evaluation. A model deployed to a diverse user base will encounter prompts that no evaluation designer imagined, and some of those prompts will expose unexpected failures.

The feedback loop from production evaluation back to model development is one of the most valuable signals in the entire pipeline. Teams that invest in production evaluation infrastructure and use the signal to inform training data curation and fine-tuning decisions improve their models faster than teams that rely solely on benchmark evaluation.