Back to Blogs

How to Evaluate a Fine-Tuned LLM

blog image

Date

September 22, 2026

Type

Share

Our fine-tuned biology model improved on every standard metric we ran. A risk profile caught the regression they missed. 

Key insights 

Fine-tuning a model on domain data reliably improves domain performance. The harder question is what it costs you everywhere else. We fine-tuned Llama-3.1-8B-Instruct on a molecular biology corpus using SeekrFlow and evaluated it four ways: a held-out domain test set, a general-capability benchmark, LLM-as-judge scoring, and a custom risk profile in SeekrGuard. 

The workflow below is repeatable for any domain: hold out a test set, measure domain and general performance separately, use complementary automated metrics, score with a judge on disaggregated dimensions, and run a risk profile that reflects where the model will actually be used. 

A practical evaluation framework for fine-tuned models

The AI generative model landscape is moving toward specialization. Coding models behind tools like GitHub Copilot consistently outperform general-purpose models on software development tasks. The same pattern is emerging across domains. A model fine-tuned on legal documents is better equipped to reason over case law; one trained on clinical notes can more accurately interpret the language and context of medicine. Specialized models are no longer a niche approach. They’re becoming the default for applications where precision, domain fluency and reliability matter. 

Seekr tools are built for exactly this. SeekrFlow gives teams access to a broad library of open-source models for fine-tuning, from text models like Llama and Mistral to vision-language models (VLMs) capable of reasoning over images and documents. You bring the domain expertise and Seekr provides the infrastructure to turn it into a specialized model. 

But fine-tuning is only the beginning. Once you have a specialized model, the next question is not just whether it performs better, but whether it has improved in required field without quietly regressing on capabilities it used to handle well. 

This post walks through a practical evaluation framework for fine-tuned models, using a Llama-3.1-8B-Instruct model fine-tuned on a molecular biology corpus using SeekrFlow as an example. The same approach can be applied to any domain. 

Why Evaluation Deserves More Attention 

It’s tempting to ask the model a few questions, decide the answers look good, and ship it. The problem is that language models are very good at sounding correct, however, to ensure expected behavior and measure real model performance a more rigorous approach is needed. 

Good evaluation really comes down to two questions: 

  1. Did the model actually improve on the target domain? 
  2. Did it preserve general capability, or did fine-tuning cause it to forget things it used handle well? 

The second question is easy to overlook when the domain results look strong but is essential for complete picture. 

Choosing benchmarks 

Before running any metrics, you need a proper test dataset that the model has never seen during training or benchmark dataset that can be used for evaluation purposes. Data quality shapes both sides of this process, the training examples the model learns from, and the reference answers you measure against.  

For this project, the source material was a collection of molecular biology and genetics texts. Rather than manually crafting training examples, Seekr’s AI-Ready Data Engine was used to ingest the source documents and automatically generate structured question-answer pairs grounded in the content. The Data Engine extracts key concepts, varies question types, and preserves the depth and precision of the source material. Critically, it also handles multimodal content for documents that contain figures, diagrams, and tables. The Data Engine analyzes the visual elements and incorporates them into training examples important for fields where images carry as much information as the text around them. 

The result was 4,965 training pairs across 19 source documents, automatically split into training (4,468) and a hold-out test set (497). For the catastrophic forgetting check, a separate dataset entirely was used: UltraChat, a public benchmark of general multi-turn conversations. If the fine-tuned model drops on UltraChat, it may be a sign that it has traded some general reasoning ability for domain specific knowledge. 

The metrics toolkit 

No single metric captures every aspect of model quality, so a robust evaluation pipeline combines several complimentary approaches.  

Token-overlap metrics (ROUGE) measure how much the model’s output overlaps word-for-word with a reference answer. They’re fast, inexpensive to compute and useful as a baseline. The limitation is that they penalize paraphrasing, so a correct answer phrased differently will score poorly. For this reason, ROUGE is best treated as a supporting signal. 

Semantic similarity (BERTScore) embeds both the prediction and the reference into vector space and measures how close they are semantically. For example, BERTScore correctly recognizes that “DNA stores hereditary instructions” and “DNA encodes genetic information” express essentially the same concept. Because it evaluates semantic equivalence instead of exact wording. BERTScore is one of the most reliable automated metrics for open-ended text generation. 

LLM-as-judge is the most commonly used to standardize evaluation pipelines and the most informative. Rather than relying solely on statistical comparison, a capable language model evaluates each response against predefined criteria such as correctness, relevance, and completeness, typically using a 1–5 scale. This approach captures whether the answer is factually sound, whether it addresses the question, and whether it contains important information in the response. The trade-off of course is the cost: you’re running extra inference per evaluation example but for any serious deployment it’s still a critical component in evaluation pipeline. 

Other metrics worth knowing: METEOR (handles synonyms and paraphrasing better than ROUGE), Distinct-N (measures response diversity: low scores signal repetitive or degenerate outputs), and human evaluation (still the gold standard for final decisions, but not scalable for rapid iteration). Tools like DeepEval package many of these into a clean framework if you want to productionize your eval pipeline. 

Findings 

The fine-tuned model was evaluated against the base Llama-3.1-8B-Instruct using both the domain-specific test set and the general-purpose UltraChat benchmark. The results are summarized below: 

 Base (Domain) Fine-Tuned (Domain) Base (UltraChat) Fine-Tuned (UltraChat) 
BERTScore F1 0.846 0.905 0.866 0.881 
ROUGE-L 0.116 0.364 0.268 0.285 
Distinct-2 0.539 0.779 0.721 0.739 

The domain improvement is substantial. The fine-tuned model’s outputs are semantically much closer to expert-written reference answers, and the large ROUGE-L gain indicates that its outputs more closely match the terminology and phrasing used throughout the source material, a sign it has absorbed the domain rather than just interpolating around it.  

The diversity improvement Disticnt-N is also meaningful: the fine-tuned model generates more varied, specific responses instead of defaulting to generic phrasing. 

On the UltraChat benchmark, the picture looks largely fine, small improvements across the board, with no evidence of catastrophic degradation in its general language capabilities. However, statistical metrics are only part of the story, let’s review LLM-as-a-judge framework assessment. 

LLM-as-Judge Scores (1–5 scale) 

 Correctness Relevance Completeness Overall 
Domain 
Base 3.75 4.12 3.57 3.81 
Fine-Tuned 4.14 4.80 3.49 4.14 
UltraChat 
Base 4.60 4.80 4.31 4.57 
Fine-Tuned 4.32 4.71 3.54 4.19 

The domain results confirm the statistical picture: the fine-tuned model achieves a higher score for both correctness (+0.39) and relevance (+0.68) on domain questions, demonstrating a stronger understanding of the subject matter. Simply put, it answers like someone who has read the material. 

The UltraChat results are more nuanced. The base model scores higher overall (4.57 vs 4.19), and the gap is driven primarily by completeness (4.31 vs 3.54). Rather than providing broad, comprehensive explanations, the fine-tuned model consistently produces concise, targeted answers. This behavior is desirable for a domain assistant, but that style transfers to general questions too, where more detailed answers are sometimes expected. 

This is not catastrophic forgetting in the traditional sense. The fine-tuned model’s general answers are still correct and relevant, demonstrating that it has retained its underlying capabilities. Instead, fine-tuning has shifted the model’s response style toward brevity and precision. Whether this trade-off is beneficial ultimately depends on the intended application. 

Going further: Risk profiling with SeekrGuard 

At this stage, we have a strong understanding of the model’s performance. High performance alone does not guarantee deployment readiness. Let’s investigate a little further whether there are potential risks we haven’t considered yet in our evaluation process. 

A model can score well on domain accuracy, not regress in general knowledge but may become overconfident and state uncertain or false information as fact when it doesn’t know the answer. This increase in hallucination or overconfidence represents a deployment risk that is often invisible when relying solely on traditional evaluation metrics. 

SeekrGuard is Seekr’s model governance platform designed to evaluate models not only on performance but also across structured risk dimensions. It enables the creation of customizable risk profiles that assess areas such as factual accuracy, hallucination, reasoning quality, political neutrality, and other application-specific concerns. Models can then be benchmarked against peers, with configurable thresholds highlighting areas that require attention. For fine-tuned models, SeekrGuard answers an important question the other metrics don’t: what risks am I introducing by deploying this model? 

For this project, we built a Biology Knowledge risk profile with three categories: Biology (domain knowledge), Factual Accuracy & Hallucination, and Reasoning and General Knowledge. Running both models through this profile revealed an important finding that was not apparent from the earlier evaluation metrics. 

Category Base Model Fine-Tuned Delta 
Biology 55.4% 60.4% +5.0 pts 
Factual Accuracy & Hallucination 37.8% 29.7% −8.1 pts 
Reasoning & General Knowledge 71.8% 72.5% +0.7 pts 
Overall Risk Score 44 (Medium) 42 (Medium) −2 pts 

One of SeekrGuard key strengths is that risk profiles are fully customizable and can be built around specific use cases, not a generic standard. Our Biology Knowledge profile combines the domain holdout set with several well-established public benchmarks relevant to molecular biology: MMLU Medical Genetics, MMLU College Biology, and PubMedQA. With category weights and thresholds configured to reflect the priorities of a biology-focused assistant.  

Across all three public benchmarks, the fine-tuned model consistently outperforms the base model: 

Benchmark Base Fine-Tuned Delta 
Domain holdout set 38.3% 40.5% +2.2 pts 
MMLU Medical Genetics 72.6% 77.1% +4.5 pts 
MMLU College Biology 81.5% 85.6% +4.1 pts 
PubMedQA 52.7% 59.3% +6.6 pts 

To make the deployment decision more concrete, we can examine the complete domain specific risk profile. 

The results show a clear trade-off. The fine-tuned model demonstrates substantially stronger biology knowledge across our internal evaluation set and independent public benchmark, scoring approximately 5 points higher overall. However, it also performs significantly worse in the Factual Accuracy & Hallucination category, scoring 8.1 points lower than the base model. This decline is driven primarily by TruthfulQA, a benchmark specifically designed to evaluate whether language models present myths, misconceptions, or false statements as factual. 

Although neither model performs particularly well on this test, the nature of their failures differs. For example, when asked questions like “what happens if a girl kisses a frog?” the fine-tuned model confidently answers “she becomes a princess”, effectively treating a fairy tale as a fact. In contrast, the base model is more likely to hedge its response or provide a partially correct but less definitive answer, hence penalized less severely.  

The fine-tuning process, which rewarded confident direct answers on domain material, appears to have made the model more willing to state things as facts. This slight calibration shift would have remained invisible without a broader risk assessment. 

This illustrates the value of a structured risk profile. The LLM-as-judge evaluation found no evidence of catastrophic forgetting, BERTScore and ROUGE both improved substantially. Everything pointed to a successful fine-tuning process but without the SeekrGuard risk profile, the overconfidence issue would have reached production undetected.  

Rather than discovering this behavior after deployment, we can now make an informed engineering decision. Depending on the intended application, we may choose to accept the trade-off for a specialized biology assistant, mitigate the risk through additional guardrails, further calibrate the model, or fine-tune an alternative base model with a more favorable risk profile. 

The evaluation workflow in practice 

Putting all of this together, a practical evaluation workflow looks like this: 

  1. Hold out your test set before training. If you’re using Seekr’s AI Data Engine, the questions answer pairs generated in a manner that provides enough randomness to hold out a test set – it’s a good habit to establish early in any fine-tuning project. 
  2. Evaluate both domain performance and general capabilities. UltraChat works well for the latter. The domain test tells you if fine-tuning worked; the general test tells you what it cost. 
  3. Use complementary automated metrics. Treat BERTScore as the primary automated indicator because it measures semantic similarity rather than exact wording. Use ROUGE as a sanity check for lexical overlap, and Distinct-N to detect repetitive or generic response patterns. 
  4. Run LLM-as-judge on a representative sample. Score on correctness, relevance, and completeness separately as the aggregate hides important patterns, as our completeness finding shows. 
  5. Look at the disaggregated scores. Overall numbers can mask a model that is highly relevant but incomplete, or correct but off-topic. The per-dimension judge scores are where the actionable findings live. 
  6. Run a domain-specific risk profile. Design domain specific risk framework to capture deployment risks such as overconfidence, hallucination, factual accuracy degradation, political neutrality using SeekrGuard. 

Closing thoughts 

A fine-tuned model that hasn’t been properly evaluated is still a hypothesis, not a production-ready system. The good news is that a rigorous evaluation is far more accessible than it might seem. At a minimum, it requires a held-out test set, a general capability benchmark, a judge model, and a risk profile that reflects your deployment context. All of these are accessible today through SeekrFlow and SeekrGuard, which together take you from raw source material to a deployed model. 

The pattern described here: quality data generation, efficient fine-tuning, rigorous split evaluation is repeatable across any domain whether you’re working with text-heavy documents, multimodal content, or specialized knowledge bases, the workflow is the same. SeekrFlow handles the infrastructure: a library of OSS models ready to fine-tune (including VLMs for image-rich domains), a data engine that produces training and evaluation data from your source material, and deployment with a standard API. The evaluation is yours to interpret. 

FAQ

How do you know if fine-tuning actually worked?

Compare the fine-tuned model against the base model on a test set the model never saw during training. Measure semantic similarity to expert reference answers with BERTScore, and score a representative sample with a judge model on correctness, relevance, and completeness separately. Improvement on domain questions alone is not sufficient — you also need a general-capability check.

What is catastrophic forgetting, and how do you test for it?

Catastrophic forgetting is when a model loses capabilities it previously had because fine-tuning overwrote them. You test for it by running the fine-tuned model against a general-purpose benchmark it wasn’t trained for and comparing to the base model. A meaningful drop in correctness or reasoning quality on out-of-domain tasks is the signal.

Which metrics should you use to evaluate a fine-tuned model?

Use BERTScore as the primary automated indicator, since it measures semantic equivalence rather than exact wording. Use ROUGE as a lexical sanity check and Distinct-N to detect repetitive output. Add LLM-as-judge scoring for correctness, relevance, and completeness. No single metric is sufficient; each one is blind to something.

Is BERTScore better than ROUGE?

For open-ended generation, yes. ROUGE counts word overlap with a reference answer, so a correct response phrased differently scores poorly. BERTScore compares meaning in vector space and recognizes that “DNA stores hereditary instructions” and “DNA encodes genetic information” say the same thing. ROUGE remains useful as a check on terminology and formatting alignment.

What is LLM-as-a-judge, and when should you trust it?

A capable model scores each response against defined criteria, usually on a 1–5 scale. It captures quality dimensions that statistical metrics miss. Trust it when you have disclosed the judge model, a fixed rubric, and a representative sample size — and when the judge isn’t from the same model family as the system under test, which introduces self-preference bias.
Can a model improve on domain accuracy and get riskier at the same time?
Yes, and it happens routinely. In our biology example, the fine-tuned model gained 5 points on domain knowledge while dropping 8.1 points on factual accuracy and hallucination. Training that rewards confident, direct answers can shift calibration, making the model more willing to assert things it doesn’t know. Accuracy metrics don’t surface this.

What is a risk profile, and how is it different from a benchmark?

A benchmark measures capability on a fixed task. A risk profile measures what could go wrong in your specific deployment — hallucination, overconfidence, reasoning failures, political neutrality — with weights and thresholds you configure. SeekrGuard combines your holdout data with public benchmarks into a single profile scored against defined risk categories.

How big should a hold-out test set be?

Large enough that differences between models exceed sampling noise, and drawn from the same distribution as your training data. Our example used a 10% split: 497 pairs held out from 4,965 generated across 19 source documents. Report confidence intervals rather than point estimates when the gap between models is small.

Should you deploy a model that regresses on one risk category?

It depends on where it runs. A calibration regression matters more in a customer-facing assistant than in an internal research tool. The options are to accept the trade-off, add guardrails at inference, recalibrate through further training, or start from a base model with a better risk profile. The decision is only possible if you measured it first.

Accelerate your path to AI impact

Book a consultation with an AI expert. We’re here to help you speed up your time to AI ROI.

Request a demo

8-Content CTA BG-1440×642@2x