What Happens After Fine-Tuning: Evaluation, Testing, and Knowing When Your Model Is Ready to Ship

TL;DR

Most fine-tuning projects spend 90 percent of their time on training and 10 percent on evaluation. That ratio is backwards. A model that completed training successfully is not the same thing as a model that works. This post covers how to evaluate a fine-tuned model properly, what metrics actually matter for your use case, how to run a head-to-head comparison against the base model, and the signals that tell you a model is ready to ship versus the signals that tell you to go back and fix something first.

Training is done. The loss curve looked reasonable. The job completed without errors.

Now someone asks: is it good?

And if you do not have a clear answer to that question, you are not done. You are at the most important part of the process and you are about to skip it.

I have seen teams ship fine-tuned models that surprised them in production. Not because the training was bad. Because they never built an eval process that would have caught the problems before users did. Do not let that be you.

Here is how to actually know if your model is ready.

Step One: Compare Against the Base Model

This is the first thing you should do after every training run. Take your fine-tuned model and the base model it came from. Give them the same inputs. Compare the outputs side by side.

This sounds obvious. Most people skip it.

The comparison tells you two things immediately. First, did the fine-tuning actually change behavior? If the outputs look nearly identical to the base model, either your training data did not cover enough of the relevant cases, your learning rate was too low, or your dataset was not formatted correctly.

Second, did the fine-tuning change behavior in the right direction? Sometimes a model changes and the change makes things worse. You will not catch this from loss curves. You catch it by looking at outputs.

Do this manually on at least 20 to 30 diverse inputs that represent the real range of what your model will see in production. Not the same inputs you trained on. New ones.

Step Two: Build a Task-Specific Eval Set

A held-out validation set tells you how well the model fits your training distribution. That is not the same as knowing how well the model works on your actual task.

Build a separate eval set that reflects production conditions. This means:

Inputs that cover the edge cases your training data did not include. Inputs that are phrased differently from your training examples but mean the same thing. Inputs that represent the hard cases, not just the easy ones.

For a classification task, your eval set should include ambiguous examples where the right answer is not obvious. For a summarization task, it should include long inputs, short inputs, and inputs with unusual structure. For a chat assistant, it should include multi-turn conversations that probe the limits of the model.

How big does it need to be? For most tasks, 100 to 500 carefully chosen examples is more useful than 5,000 randomly sampled ones. Quality over quantity applies to evals just as much as it applies to training data.

Step Three: Pick the Right Metrics for Your Task

Loss is not a metric for your task. It is a metric for how well the model fits your training data. These are related but they are not the same thing.

Here is what to measure depending on what you built.

For classification tasks: accuracy, precision, recall, and F1. These are exact. You know the right answer and you check if the model got it.

For structured extraction tasks: exact match on the fields you care about. If you are extracting dates, names, or codes, you can check whether the model got them right programmatically.

For summarization and generation tasks: this is harder. BLEU and ROUGE scores exist but they measure surface similarity to a reference output, not actual quality. They are better than nothing but do not rely on them alone. Use them alongside manual review.

For chat and instruction-following tasks: human evaluation or LLM-as-judge is the most reliable approach. Pick 50 to 100 inputs, generate outputs from your fine-tuned model and the base model, and have someone rank which one is better without knowing which is which. Even a small blind comparison like this tells you more than any automated metric.

Step Four: Check for Catastrophic Forgetting

This one trips people up and it is easy to miss.

Fine-tuning on a narrow task can degrade the model's performance on things it used to do well. A model fine-tuned to always respond in a specific JSON format might start struggling with free-form conversational inputs it handled fine before. A model fine-tuned on medical terminology might start making basic reasoning errors it did not make before training.

This is called catastrophic forgetting and it happens when the fine-tuning data is narrow and the training runs too long or at too high a learning rate.

How to check for it: keep a small set of general capability tests that you run against every checkpoint. Basic reasoning questions, instruction following examples, and a few conversational inputs that have nothing to do with your fine-tune task. If the fine-tuned model performs noticeably worse on these than the base model, you have a forgetting problem.

The fix is usually to reduce the number of epochs, lower the learning rate, or add a small amount of general instruction-following data to your training set to keep the model balanced.

Step Five: Test on Real Production Inputs

Before shipping, get as close to real production conditions as you can.

If your model will receive inputs from users, test it on real user inputs from a staging environment or from a sample of what your system already receives. If your model will be called by other systems with structured inputs, test the exact format those systems will send.

Production inputs are almost always messier than your training data. They have typos, unusual formatting, edge cases you did not anticipate, and phrasing your training set did not cover. The goal of this step is to find the failure modes that your controlled eval set did not surface.

Run at least 200 to 500 real-condition inputs through the model before declaring it production-ready. Look for patterns in the failures. If the same type of input keeps producing bad outputs, that is a signal your training data underrepresented that case.

When Is the Model Actually Ready

Here is the honest answer. There is no single threshold that tells you a model is done. What you are looking for is:

Performance on your task-specific eval set that meets the bar you defined before training started. You should have defined this bar before you wrote a single line of config. If you did not, define it now and rerun your eval.

No significant regression on general capability tests compared to the base model.

No systematic failure patterns on real production inputs.

A clear win over the base model on the inputs that matter most to your use case.

If all four of those are true, you have a model worth shipping. If any of them are not, you have a specific problem to fix and a clear next experiment to run.

Where Heulistic Fits In

Building a solid eval pipeline takes work. But it is also one of the places where having the right infrastructure matters most.

When your training environment is reproducible and your runs are tracked, evaluation becomes part of the loop rather than something you bolt on at the end. Every checkpoint is comparable. Every experiment has a result you can act on.

That is what Heulistic is built for. Not just running the training job but making the whole iteration cycle, including evaluation, fast enough that you can actually do it right. You can get started at heulistic.com.