Fine-Tuning
Continuing to train a pretrained model on a smaller, labeled dataset so it adopts a specific behavior — a house voice, a fixed output format, a task — rather than new facts.
Fine-tuning takes a general pretrained model and trains it further on a smaller, curated set of examples so it internalizes a specific way of behaving. In practice you show it a few dozen to a few hundred labeled input-output pairs — questions and the ideal reply, tickets and the correct tag — and it nudges its weights to match (IBM). Modern support teams rarely retrain the whole model; parameter-efficient methods like LoRA freeze the base weights and train a small set of add-on parameters, which is why fine-tuning is far cheaper and faster than it sounds (LoRA, Hu et al. 2021).
The distinction that matters is behavior versus knowledge. Fine-tuning teaches a model how to answer — your tone, your reply structure, when to ask a clarifying question, how to call a tool — and it is the wrong tool for teaching it what is currently true. Facts change: prices, policies, the product catalog. For those you want retrieval (see RAG), where the knowledge is explicit, updatable, and citable. Most production support stacks use both — RAG for fresh facts, a light fine-tune for consistent voice and format (IBM).
What it hides: a fine-tune bakes in a snapshot. Whatever facts you trained on are frozen at that moment, so a model fine-tuned on last quarter's catalog will confidently discuss products you've discontinued and deny ones you just launched — and the only fix is to retrain. It also invites overfitting: chase a perfect house voice on a thin dataset and you can quietly erode the model's reasoning on everything you didn't cover. And it does nothing for hallucination — a fine-tuned model still needs grounding. Teams reach for it as a prestige fix when the real problem was usually a weak prompt or a knowledge base that was never cleaned up.