The Misconception at the Heart of Fine-Tuning
There is a persistent and consequential myth circulating in AI development circles: that fine-tuning a large language model is how you teach it new facts. Teams invest weeks of effort collecting proprietary documents, carefully formatting training data, running overnight GPU jobs — only to find that their model still hallucinates the very information they were trying to embed. The problem is not the process. The problem is the expectation. Fine-tuning does not primarily change what a model knows. It changes how a model behaves.
Understanding this distinction is not a semantic exercise. It determines whether fine-tuning is the right tool for your problem at all — and, if it is, how you should construct your dataset, measure success, and avoid wasting significant compute and engineering time.
What LoRA and QLoRA Actually Do to a Model
Most practical fine-tuning today does not update every parameter in a model. Doing so for a modern large language model would require hardware budgets beyond the reach of most teams. Instead, techniques like LoRA — Low-Rank Adaptation — work by inserting small trainable matrices alongside the model's existing weight matrices. During training, only these adapter layers are updated. The original model weights are left frozen.
What this means mechanically is that the model's vast repository of world knowledge, encoded across billions of parameters during pre-training, remains largely untouched. The adapter layers learn to steer outputs: adjusting tone, enforcing response structure, shifting the probability distribution toward certain styles or formats, and embedding task-specific patterns of reasoning. You are not rewriting the encyclopedia — you are teaching the model new habits of expression and response.
QLoRA extends this further by quantising the base model weights to lower precision during training, dramatically reducing GPU memory requirements. This makes fine-tuning accessible on consumer-grade hardware and smaller cloud instances. But the fundamental dynamic is the same: the adaptation is surgical, not encyclopedic. The model learns how to respond in a new context, not what is true about the world.
Fine-Tuning vs. RAG: Choosing the Right Tool
Because fine-tuning changes behaviour rather than facts, the decision about when to use it — versus retrieval-augmented generation, or RAG — becomes much clearer once the distinction is properly understood.
RAG is the appropriate architecture when the goal is grounding model responses in specific, up-to-date, or proprietary factual content. In a RAG pipeline, relevant documents are retrieved at inference time and injected into the model's context window. The model reasons over real source material. The knowledge lives outside the model, in a vector store or document index, which makes it auditable, updatable, and less prone to hallucination on factual claims.
Fine-tuning, by contrast, is the right choice when the problem is about how the model responds rather than what it knows. If you need a model to consistently produce output in a specific schema, adopt a particular communication style, follow a domain-specific reasoning pattern, or resist certain types of outputs it would otherwise generate — those are behavioural problems. They are precisely what fine-tuning is designed to solve. Common legitimate use cases include training a model to always return structured JSON, to respond with the formality expected in a legal or medical context, or to apply a consistent chain-of-thought pattern for a specific class of problems.
Many teams make the mistake of reaching for fine-tuning when RAG would serve them better, then wondering why their model still produces inaccurate factual claims about their internal knowledge base. The answer is that fine-tuning was never going to solve that problem in the first place.
Dataset Quality Is the Dominant Variable
Assuming fine-tuning is the correct approach, the single most important factor in whether training succeeds is dataset quality — not model size, not the number of training steps, not hyperparameter tuning. This is consistently underappreciated by teams new to the process, who often focus heavily on the technical scaffolding of training while treating data collection as a secondary concern.
The model will learn exactly the patterns present in your training data. If your examples are inconsistent — varying in format, tone, or the logic applied to similar inputs — the model will learn that inconsistency. If your examples contain subtle errors or reflect reasoning shortcuts, those shortcuts will be amplified. If your dataset is small but high-quality, it will typically produce better results than a large dataset of mediocre examples.
What high-quality data looks like in practice means: clear, consistent input-output pairs where the output genuinely demonstrates the behaviour you want; edge cases and varied phrasings so the model generalises rather than memorises; and careful human review rather than purely automated generation. It is worth investing three times as long as you think you need in dataset curation, because problems baked into training data cannot be corrected by adjusting learning rates or running more epochs.
There is also a structural trap worth naming explicitly. Teams sometimes generate their fine-tuning dataset using the same base model they intend to fine-tune. This creates a circular pattern where the model learns to reproduce its own existing tendencies rather than genuinely new behaviour. If the goal is to shift behaviour, training data should represent the target behaviour — which often means human-authored examples or examples from a significantly different source.
The Evaluation Step That Almost Never Happens
Perhaps the most consistently skipped phase of the fine-tuning workflow is rigorous evaluation. It is common for teams to monitor training loss, see it decreasing, and conclude the model is improving. Training loss is a necessary signal, but it is not sufficient. A model can overfit to your training distribution while performing worse on real inputs. It can reproduce training examples with high fidelity while failing to generalise to slight variations in phrasing or context.
Proper evaluation requires a held-out test set of examples the model has never seen during training, covering the range of inputs it will encounter in production. It requires human review of model outputs — not just automated metrics — because the behaviours that matter most are often subtle and difficult to capture in a single score. And it requires a clear definition, established before training begins, of what success actually looks like for this specific use case.
Without this evaluation layer, it is impossible to know whether fine-tuning worked, whether it regressed performance in other areas, or whether the same result could have been achieved with a better system prompt at a fraction of the cost. The evaluation step is unglamorous and time-consuming, which is precisely why it is the step most likely to be abbreviated or skipped entirely — and why it is also where the real learning happens.
Fine-Tuning as Behavioural Sculpting
Reframing fine-tuning as behavioural sculpting rather than knowledge injection clarifies nearly every decision in the process. It explains why dataset quality dominates training outcomes — because you are literally demonstrating the behaviour you want, and the model is pattern-matching against those demonstrations. It explains why RAG is the correct solution for factual grounding, while fine-tuning handles stylistic and structural adaptation. It explains why evaluation against real-world inputs is non-negotiable — because the behaviour you care about only exists at inference time, not in training loss curves.
Large language models arrive from pre-training with an enormous substrate of capability. Fine-tuning, done well, shapes how that capability is expressed. Done poorly — with vague goals, inconsistent data, and no evaluation — it produces a model that is confidently different in ways that are hard to predict and harder to fix. The teams getting consistent value from fine-tuning are not the ones with the most compute. They are the ones who understood what they were actually trying to change before they started training.