Instruction Fine-Tuning Basics
Evaluating an instruction-fine-tuned LLM checks whether tuning changed the model's performance.
Why a Finished Training Run Is Not Enough
Instruction fine-tuning trains a language model on examples of instructions and the responses that should follow them. Once that training is complete, a natural question arises: did the model actually get better at following instructions? Training finishing without errors does not answer that question. Evaluating an instruction-fine-tuned LLM is the step that checks whether the tuning changed the model's performance in the way it was intended.
What do you think happens?
You trained a model on instructions, then tested only the single example you were most hopeful about and it answered well. What could go wrong with concluding that tuning worked?
Reveal answer
One hopeful example can make the tuning look successful without showing whether it changed the model's behavior in general. A single good response also carries no information about what the model would have said before tuning, so there is nothing to compare it against.
The evaluation question is about the change between two states of the model. A result selected because it looked promising cannot establish that change.
The Two States That Matter
Think of the model as having two states that matter for evaluation: the state before instruction fine-tuning and the state after it. The evaluation question is about the change between them. Nothing about the tuned model can be judged in isolation, because a single response carries no information about what the model would have said before the tuning.
The diagram below shows the two states side by side. The instruction set is the same on both sides. That shared input is what makes the comparison meaningful: any difference in the responses can be attributed to the change in the model rather than to a change in the questions.
Three Parts of a Fair Comparison
Evaluating an instruction-fine-tuned LLM checks whether tuning changed the model's performance. The comparison is made against the model's own earlier behavior on the same instructions.
The core reasoning has three parts. First, fix a set of instructions that will be used for testing. Second, record how the model responds to them before tuning and after tuning. Third, compare the two sets of responses against the goal the tuning was meant to achieve. Each part protects the conclusion against a different kind of error. Fixing the instructions prevents a change in question difficulty from being mistaken for a change in ability. Recording both sets of responses means the comparison rests on actual outputs rather than memory. Comparing against the stated goal keeps the judgment tied to what the tuning was supposed to accomplish.
Specific metrics for scoring responses are not established in this source. Those should be taken from the course materials, so this article focuses on the structure of the comparison rather than on any particular scoring formula.
Tracing One Test Instruction Through Both States
The following example is an invented illustration of the procedure, not a result from any real model. Suppose a team wants to know whether tuning improved how a model follows short formatting requests. They write a fixed set of test instructions before any tuning begins and keep that set unchanged for the whole evaluation.
Comparing one instruction before and after tuning
Test instruction: List three fruits, one per line, with no other text. Does the tuned model's response differ from the base model's response, and can the difference be attributed to tuning?
- 1Fix the instruction
The instruction is written down once and stored in the test set. It is not rewritten for the tuned model, so the input stays identical across both runs.
- 2Record the base model response
Before instruction fine-tuning, the model receives the instruction and its full response is saved exactly as produced.
- 3Record the tuned model response
After instruction fine-tuning, the same instruction is given again and the new response is saved alongside the earlier one.
- 4Compare against the goal
The two saved responses are judged against what the tuning was meant to achieve, here following the formatting request. Because the input never changed, a difference in the responses reflects the change in the model rather than an easier or harder question.
The comparison is trustworthy because both responses answer the same saved instruction. A tuned response that drops the extra text, or one that still adds it, is a direct before-and-after observation. One instruction is still a small sample, so the team would extend the same procedure across the whole fixed test set.
This example protects against a specific failure. If the team had written new instructions for the tuned model, any improvement could have come from easier questions rather than from better instruction following. Keeping the test set fixed removes that alternative explanation.
Mistakes That Make a Tuned-Model Evaluation Unreliable
The source supports a short list of errors that weaken an evaluation. The comparison below contrasts the conditions that keep the comparison fair with the conditions that break it.
Common mistake Evaluating only the tuned model
What it looks likeThe team reports that the tuned model answers well and stops there.
Why it failsA single response carries no information about what the model would have said before tuning, so it cannot show that tuning changed anything.
Do this insteadRecord the model's responses before tuning on the same instructions and compare the two sets.
Common mistake Changing the instructions between the two runs
What it looks likeNew, easier questions are written for the tuned model.
Why it failsAny improvement may come from easier questions rather than better instruction following.
Do this insteadHold the instruction set fixed across both runs.
Common mistake Keeping only the most impressive response
What it looks likeThe team saves the one tuned answer that looked best and discards the rest.
Why it failsThe conclusion is built on a selected result rather than on the full set of recorded responses.
Do this insteadSave every response from both runs so the comparison covers the whole set.
Common mistake Treating completed training as proof of success
What it looks likeThe team concludes the model improved because the training run finished without errors.
Why it failsTraining finishing without errors does not answer whether the model's performance changed as intended.
Do this insteadRun a separate evaluation that compares behavior before and after tuning.
Planning a Simple Evaluation
A simple evaluation plan follows the same order as the reasoning in this article. The flowchart below lists the steps from choosing test instructions through comparing the two models.
- 1Write a fixed set of test instructions before any tuning begins.
- 2Run the base model on every instruction and save each response.
- 3Perform instruction fine-tuning.
- 4Run the tuned model on the same instructions and save each response.
- 5Judge both sets of responses against the goal the tuning was meant to achieve, using metrics from the course materials.
- 6Report the comparison, including responses that did not improve.
Plan an evaluation for a model you have tuned to follow instructions. Name the goal the tuning was meant to achieve, write five test instructions that will stay fixed, state how you will save the base model and tuned model responses, and explain which of the common mistakes from this article your plan avoids.
Hints
- Start from the goal of the tuning before choosing any instructions.
- Make sure the same instructions are used for both runs.
- Decide in advance how you will save every response, including the disappointing ones.
Key Takeaways
- Evaluating an instruction-fine-tuned LLM checks whether tuning changed the model's performance; a completed training run does not answer that question on its own.
- The evaluation compares two states of the model, before and after tuning, on the same fixed set of instructions.
- The comparison has three parts: fix the test instructions, record responses before and after tuning, and compare both against the goal of the tuning.
- Unreliable evaluations often come from changing the instructions, keeping only the best response, evaluating only the tuned model, or testing on examples the model was trained on.
- Specific scoring metrics are not established in this source and should be taken from course materials.