GenAI Course · Module 7 · Session 25

Adaptation, Quantization & Evaluation

⏱ 15 min read🎯 Intermediate🖼 2 diagrams🧪 4 live demos🐍 Python code

You have a pre-trained model. Three practical questions come next: How do I make it good at my task? How do I make it small enough to run? And how do I know if it is actually good? This session answers all three.

In this session

  • Transfer learning and domain adaptation
  • Prompting vs RAG vs PEFT vs full fine-tuning: a decision matrix
  • Quantization: INT8, INT4 and GGUF, with real numbers
  • Evaluation: perplexity, BLEU, ROUGE, METEOR and human evaluation
  • A real example of automatic metrics giving the wrong answer

01Transfer learning and domain adaptation

Transfer learning means reusing what a model learned on general text for a new task. You don’t start from zero; you start from a model that already knows language.

Domain adaptation teaches the vocabulary of your field (NEFT, KYC, chargeback); task fine-tuning teaches the job.
👨‍⚕️

Like a doctor’s training. MBBS gives general medical knowledge (pre-training), MD in cardiology adds domain knowledge (domain adaptation), and training on one hospital’s procedures prepares for the exact job (task fine-tuning).

02Prompting vs RAG vs PEFT vs full fine-tuning

This is one of the most common questions in real projects. Use this matrix:

PromptingRAGPEFT (LoRA)Full fine-tuning
What changesOnly the input textInput + retrieved documentsSmall adapter weightsAll model weights
Data neededA few examplesYour documentsHundreds – thousands of examplesThousands – millions
Cost and timeMinutes, almost freeDays to build the pipelineHours on 1 GPUDays on many GPUs
Keeps facts freshNoYes, just re-indexNo, retrainNo, retrain
Best forFormat, tone, simple tasksAnswering from private or changing knowledgeStyle, structured output, domain tasksNew languages or very large behaviour changes
Golden rule: start with prompting, add RAG for knowledge, and fine-tune only when you have clear evidence that the first two are not enough. Session 39 goes deeper.

03Quantization: making models smaller

Model weights are normally stored as 16-bit floating-point numbers. Quantization stores them with fewer bits, like 8 or 4, using a scale factor. The model becomes 2–4× smaller and often faster, with a small loss in quality.

Weights of a 7B-parameter model at different precisions.
Format / methodWhat it isTypical use
INT8 (e.g. bitsandbytes LLM.int8)8-bit weights with special handling of outlier valuesNear-lossless; halves memory
INT4: GPTQ, AWQ4-bit weights calibrated on sample dataServing on GPUs
NF4 (QLoRA)4-bit format designed for normally distributed weightsFine-tuning big models on one GPU (Session 40)
GGUFFile format from llama.cpp with levels like Q8_0, Q5_K_M, Q4_K_MRunning on laptops and CPUs (llama.cpp, Ollama, LM Studio)
load_in_4bit.py
# pip install transformers accelerate bitsandbytes
import torch
from transformers import AutoModelForCausalLM, BitsAndBytesConfig

bnb = BitsAndBytesConfig(load_in_4bit=True, bnb_4bit_quant_type="nf4",
                         bnb_4bit_compute_dtype=torch.float16)
model = AutoModelForCausalLM.from_pretrained("Qwen/Qwen2.5-7B-Instruct",
                                             quantization_config=bnb, device_map="auto")
print(f"{model.get_memory_footprint() / 1e9:.1f} GB")   # roughly 5 GB instead of ~15 GB

04Evaluation metrics

Perplexity: how surprised is the model?

Perplexity is the exponential of the average negative log-probability the model gave to the real tokens. Lower is better. A perplexity of 2 roughly means the model was, on average, choosing between 2 equally likely options.

BLEU, ROUGE and METEOR: comparing with a reference

MetricMeasuresMainly used for
BLEUHow many n-grams (1–4 words) of the output appear in the reference (precision), with a penalty for being too shortMachine translation
ROUGE-1 / ROUGE-2 / ROUGE-LOverlap of single words, word pairs, and the longest common word sequenceSummarisation
METEORWord matches including stems and synonyms, balancing precision and recallTranslation; closer to human judgment than BLEU

Where automatic metrics mislead

These metrics only count matching words. Look at this real calculation. The reference is “The card has been blocked for your safety.”

This is why teams always add human evaluation: people rate outputs for correctness, helpfulness, fluency and safety, often by comparing two answers side by side. A cheaper middle path is LLM-as-a-judge, where a strong model grades answers using a clear rubric, checked regularly against human ratings.

metrics.py
# pip install rouge-score sacrebleu
from rouge_score import rouge_scorer
import sacrebleu

ref = "The card has been blocked for your safety."
cands = ["Your card is now blocked for safety.",
         "The card has been blocked for your account."]

scorer = rouge_scorer.RougeScorer(["rouge1", "rouge2", "rougeL"], use_stemmer=True)
for c in cands:
    r = scorer.score(ref, c)
    bleu = sacrebleu.sentence_bleu(c, [ref]).score
    print(c, {k: round(v.fmeasure, 2) for k, v in r.items()}, "BLEU", round(bleu, 1))
Your card is now blocked for safety. {'rouge1': 0.67, 'rouge2': 0.15, 'rougeL': 0.53} BLEU 14.6 The card has been blocked for your account. {'rouge1': 0.88, 'rouge2': 0.86, 'rougeL': 0.88} BLEU 75.1

Explainability

To understand why a model gave an answer, teams use attention maps (Session 19), feature-attribution tools like SHAP, LIME or integrated gradients that score how much each input word mattered, and for LLMs, asking for citations to retrieved sources (RAG). In regulated fields like banking, explanations and audit logs are often a requirement.

05Summary

06Quick quiz

1. Your product rules change every week. Best approach?

2. INT4 weights take roughly how much memory compared with FP16?

3. For perplexity…

4. Which metric is most common for summarisation?

5. Why add human evaluation?

07References

Created by Ajeetkumar