Evaluating Trained Models

Imagine an email service that must decide, for every incoming message, whether it is spam or not spam. The service has never seen the message that just arrived, so it cannot look up an answer. What it needs is a system that has learned from earlier examples what spam tends to look like, and can then apply that learning to a message it has not encountered before.

Training such a system is only part of the story. Once training has finished, you still have to find out how well the model performs on the task you cared about. A changed model is not automatically a better one. This article follows a fine-tuned model from the end of training to a single performance number, and it shows what each step does to the information along the way.

The supervised learning workflow for predictive modeling is a sequence of stages that run in a fixed order. Stage one is training. A learning algorithm uses a labeled dataset to produce a trained model. Stage two is inference, in which the trained model is applied to new observations whose labels are unknown and returns predicted labels.

In the spam case, the training dataset is a collection of emails, and each email comes with a label of either spam or not spam that a human has identified. The emails are the inputs the model looks at, and the labels are the answers it is supposed to learn to produce. Without the labels, the dataset would contain only emails, and nothing would signal to the learning procedure which emails were right or wrong.

The two stages use data in opposite ways. During training, both the examples and their labels are known, and the learning algorithm uses that complete pairing to build the model. During inference, the model receives only the new observations. Their labels are unknown, and the model's job is to predict them. The trained model is the hinge of the whole process: training produces it, and inference uses it.

A trained model is not automatically ready for use. Training produces a model that has fit the labeled examples, but the workflow requires one more check before the model is applied to real observations. A model evaluation step is placed between the training and inference stages to check that the model satisfies the performance criteria we care about before it is used in a real-world application.

Read the diagram from left to right. The labeled dataset and the learning algorithm together make up the training stage, and their result is a trained model. The model is then evaluated. Only after that does the workflow move to inference. The evaluation step is the gate: its purpose is to confirm that the model meets the criteria before the model receives real observations.

Evaluation starts with a test set, which is a set of inputs the model was not trained on. The fine-tuned model is run on each item in the test set, and its responses are collected. At this point the collection holds raw responses, and nothing has been judged yet. The next step is scoring, in which each response receives a score. Finally, the scores are averaged, and the average is the number that quantifies performance.

Trace the state at each point. Before any step runs, the evaluation holds only the test inputs. After the model runs, it holds raw responses. After scoring, the collection is a list of responses with a score attached to each. After averaging, the collection has become a single value. Each transition changes what the collection is, not just what it contains.

The source gives one concrete tool for the scoring step. The Ollama application, paired with an 8-billion-parameter Llama model, can automatically score the fine-tuned model's responses on the test set. The source also notes that another LLM can serve as the scorer, so the scoring role is not tied to one particular model.

Notice that the number of items shrinks from many to one at the last step. The test set may contain many examples, but the reported performance is a single number. Any question about one particular example can be answered only by going back to the scored collection that existed before the averaging took place. This is why the per-item scores are worth keeping when you need detail.

The test set is made of inputs the model was not trained on. This separation matters because a score computed on examples the model learned from would say how well it memorized them, not how well it handles new observations. The evaluation therefore draws its inputs from a portion of the data that training did not use.

In data-flow terms, a labeled dataset is divided into a training portion and a test portion. The training portion flows into the learning algorithm and shapes the trained model. The test portion flows into evaluation, where the fine-tuned model runs on it, its responses are scored, and the scores are averaged. Each example goes to one of the two roles, and the evaluation depends on keeping them apart.

The same workflow describes how Large Language Models are trained and used. The general pattern of training, evaluation, and inference stays the same. What changes is the inference behavior, which depends on the kind of task. The source distinguishes two kinds of LLM task: text classification and text generation.

The source states the workflow applies to both cases, while noting that inference behaves differently between them. When reading evaluation results, keep track of which kind of task produced the responses, because the responses being scored look different in each case.