Fine-Tuning, LoRA and RAG: How to Customise an LLM

Say your team has API access to a capable model. It writes beautifully, but it invents your refund policy, answers in the wrong tone, and has never seen your product catalogue. You have three ways to fix that, and they cost wildly different amounts — from a few dollars of prompt text to hundreds of thousands in compute. Choosing the wrong one is how AI budgets get burned. This guide explains all three, so you can tell which problem you actually have.

This sits one step after the model itself. For how a base model is built and trained in the first place, start with inside large language models; for the basics of AI, see introduction to artificial intelligence. It deliberately does not re-cover two neighbours: how models are pre-trained from scratch, and the deep mechanics of retrieval — the latter has its own article, retrieval-augmented generation, which this page links across to rather than repeating.

Where a base model comes from — and why it isn't ready

A base model is what you get after the expensive first stage of training: months of reading enormous amounts of text to learn a single skill — predicting the next word. That makes it astonishingly fluent, and completely unaligned. It has no idea what an instruction is.

Ask a raw base model to "write a Python script" and it might reply with what looks like a forum thread of people arguing about Python, because that is a statistically plausible continuation of your words. It has no concept of being helpful, following an instruction, or staying inside safety limits.

Turning that raw predictor into something useful is post-training, also called alignment: instruction tuning teaches it to follow requests, and further alignment nudges it toward answers people rate as good. Every assistant you have used has been through this. This article is about the next question — how do you add your knowledge and your style on top?

Three ways to make a model yours

There are three mainstream ways to adapt a general model to your world. They are not really rivals — they answer different questions, and they are often combined.

• Full fine-tuning — retrain the whole model on your examples. It changes what the model is.
• LoRA, a form of parameter-efficient fine-tuning — leave the big model untouched and train a small "adapter" that sits on top. It changes the model's behaviour cheaply.
• RAG (retrieval-augmented generation) — do not touch the model at all; instead look up relevant documents and paste them into the prompt at question time. It changes what the model reads.

One line to hold onto, which the rest of this article unpacks: fine-tuning — full or LoRA — teaches behaviour; RAG supplies knowledge. If the complaint is "it answers in the wrong style", that points at fine-tuning. If it is "it doesn't know our facts", that points at RAG.

Full fine-tuning: total brain surgery

Full fine-tuning takes the pre-trained model and updates every one of its billions of internal numbers — its weights — using a curated dataset of your examples. Want a model that reasons like a senior medical diagnostician? You show it a very large collection of clinical notes and let it adjust all its weights accordingly.

The catch is cost. Retraining a model with tens of billions of weights needs a cluster of expensive GPUs, specialist engineers, and days or weeks of compute. It also risks catastrophic forgetting: push the model so hard on your narrow domain that it overwrites some of the general ability it started with — you get a sharper lawyer that has quietly become a worse writer.

LoRA: the adapter that made fine-tuning cheap

Parameter-efficient fine-tuning (PEFT) is a family of techniques that get most of the benefit of fine-tuning for a small fraction of the cost. The dominant one is LoRA — short for Low-Rank Adaptation.

The trick: instead of editing the model's hundreds of billions of weights, LoRA freezes them completely and bolts on a small set of new, lightweight matrices — the adapter. Training updates only the adapter.^[1] The saved adapter file is often a few hundred megabytes rather than hundreds of gigabytes, and a job that would need a data centre for full fine-tuning can finish on a single cloud GPU in hours.

Because adapters are small and swappable, one base model can wear many hats — a legal adapter in the morning, a marketing-copy adapter in the afternoon — without touching the model underneath. The honest limit: LoRA teaches behaviour and style, not fresh facts. The model still answers from statistical memory, so it can confidently make things up. For knowledge that changes, you want retrieval, not an adapter.

RAG: change what the model reads, not what it knows

The third option changes nothing about the model. RAG gives the model an open-book exam: when a question comes in, a separate system searches your documents — a wiki, a folder of PDFs, a database — pulls the most relevant passages, and pastes them into the hidden prompt alongside the question. The model's only job is to answer from the text it was just handed.

That makes RAG the most practical way to reduce hallucinations — confident, wrong answers — because the reply is grounded in specific passages you can trace and cite. It is also the only one of the three where updating knowledge is instant: change the document, and the next answer reflects it, with no retraining.

Retrieval has real depth of its own — chunking, embeddings, vector search, re-ranking — so this article deliberately does not re-cover it. For the full mechanism, see retrieval-augmented generation. Here it matters only as the third lever, and the one most teams should reach for first.

Which approach for which problem

The questions that decide it, side by side:

Read it as a decision, not a menu. Most business problems are either "it doesn't know our stuff" (RAG) or "it knows, but sounds wrong" (a LoRA adapter). Full fine-tuning is the specialist tool you reach for last.

Fine-tuning in Singapore: SEA-LION, the PDPA and governance

There is a concrete local example of post-training in action. SEA-LION is a family of open-source language models built by AI Singapore — a national programme supported by the National Research Foundation and hosted by the National University of Singapore — and adapted specifically for Southeast Asia's languages and cultural context. Recent versions start from an open base model (v4.5, released May 2026, builds on Qwen) and are aligned with human-curated regional data.^[2] It is exactly the pattern this article describes: take a capable open-weight base and post-train it for a purpose it was not originally built for.

If you fine-tune on your own data, remember what that data is. Under Singapore's Personal Data Protection Act (PDPA), personal data in a training set remains personal data — the protection obligation covers the dataset and the resulting model, and if training or the model runs overseas, the transfer limitation obligation applies too.^[3] Knowing where your fine-tuning physically happens is a real requirement, not a detail.

On governance, IMDA and the AI Verify Foundation published the Model AI Governance Framework for Generative AI in 2024, which asks the practical questions any fine-tuning or RAG project should be able to answer: where the data came from, whether you can explain an output, and whether the system was tested before and after it went live.^[4]

How to choose — and when to do nothing

The most common mistake is reaching for fine-tuning first — the most expensive, slowest lever, and usually not what you need. Start at the cheap end, and move up only when you have evidence the simpler thing failed:

1. Try prompt engineering first. A clearer instruction, a few worked examples, and a good system message fix more problems than people expect — and cost nothing to change.
2. If the gap is knowledge, use RAG. "It doesn't know our documents / it's out of date / it makes facts up" is a retrieval problem. Reach for RAG before any training.
3. If the gap is behaviour, try a LoRA adapter. "It knows enough, but the tone, format or house style is wrong" is what cheap fine-tuning is for.
4. Consider full fine-tuning last — only for deep specialisation at scale, with a large, high-quality dataset and budget for the compute and the risk of catastrophic forgetting.
5. Combine, do not choose blindly. Production systems often run a light adapter for style and RAG for facts; the two sit together happily.

And sometimes the right answer is to do nothing beyond a good prompt. If a general model with clear instructions already does the job, that is a finished solution, not a shortcut.

Building a custom AI solution?

Fine-tuning, adapters and RAG each demand different data, skills and infrastructure. Compare Singapore AI and software partners who design and run custom LLM systems.

Browse AI partners in Singapore

Frequently asked questions

Sources

1. Hu et al. — LoRA: Low-Rank Adaptation of Large Language Models (2021) — arXiv, 2021 reported
2. SEA-LION — a family of open-source Southeast Asian language models — AI Singapore, 2026-05 official checked 2026-09-06
3. Overview of the PDPA — Personal Data Protection Commission (PDPC) — PDPC official
4. Model AI Governance Framework for Generative AI — IMDA and AI Verify Foundation — IMDA, 2024-05 official