Short answer: if you want an AI that answers questions from your documents, prices, policies or customer data, you almost always need RAG (Retrieval-Augmented Generation), not fine-tuning. Fine-tuning is for changing how a model behaves — its tone, format or a narrow, repeated task — not for teaching it facts. Many strong systems use RAG first and add a small amount of fine-tuning later, only if needed.
The two approaches in plain English
Think of a large language model as a very capable new employee.
- RAG gives that employee a well-organised filing cabinet. Before answering, the system searches your documents, pulls out the most relevant passages and hands them to the model with the question. The model answers from those passages and can show where the answer came from.
- Fine-tuning sends the employee on a training course. You show the model hundreds or thousands of example inputs and ideal outputs, and its internal weights are adjusted so it naturally responds in that style.
OpenAI's own guide to optimizing LLM accuracy makes the same split: RAG (which it calls context optimization) fixes problems where the model lacks knowledge or has outdated information, while fine-tuning fixes inconsistent formatting, tone or reasoning. It also notes the two are additive, not either/or, and recommends trying good prompting first.
RAG vs fine-tuning at a glance
| RAG | Fine-tuning | |
|---|---|---|
| Best for | Answering from your own, changing information | Consistent style, format or a narrow repeated task |
| Updating knowledge | Edit or upload a document — live in minutes | Prepare new training data and retrain |
| Shows sources | Yes, can cite the exact document and page | No, answers come from the model's memory |
| Risk of made-up answers | Lower, if retrieval is well built | Can still invent facts confidently |
| Data needed to start | Your existing documents | Hundreds to thousands of high-quality examples |
| Access control | Can limit each user to documents they may see | Anything learned is available to every user |
| Main cost | Data pipeline, search tuning, vector database | Data preparation, training runs, re-training, hosting |
When RAG is the right choice
Choose RAG when the answer depends on information the model was never trained on, or that changes:
- A customer-support assistant that answers from your help centre, manuals and returns policy.
- An internal assistant for staff over HR policies, SOPs, contracts or project files.
- A sales or booking assistant that needs today's prices, stock or opening hours.
- Regulated teams (legal, healthcare, finance) that must show where an answer came from.
The access-control point matters more than people expect. If you fine-tune a model on HR files, salary data or client contracts, that knowledge is baked into the model for everyone who uses it. With RAG, permissions are checked at search time, so a junior employee simply never receives documents they're not allowed to see.
When fine-tuning is worth it
Fine-tuning earns its place when the problem is behaviour, not knowledge:
- You need output in a strict format every time, such as structured JSON, a report template or a coding standard.
- A narrow, high-volume task (classifying tickets, extracting fields from invoices) where a small fine-tuned model can match a large one at a fraction of the running cost.
- A distinctive brand voice or domain language that prompting alone can't hold consistently.
- You're running a smaller open-source model on your own servers and want it to perform closer to a larger one on your specific task.
Notice that none of these is “make the model know our documents”. Fine-tuning on a pile of company PDFs is one of the most common — and most expensive — mistakes we see businesses consider.
What each one costs in 2026
RAG
Most of the cost is in the build: connecting data sources, cleaning and chunking documents, tuning search and testing answers against real questions. Running costs are model usage plus a vector database and hosting. We've broken this down in detail in How Much Does a RAG Chatbot Cost in 2026?
Fine-tuning
The training run itself is often the smallest line item. The real costs are:
- Training data. Someone has to write or curate hundreds to thousands of correct examples, and check them.
- Re-training. Every time your products, rules or style change, the examples change and the model is trained again.
- Hosting. Some platforms only serve custom models on reserved capacity. For example, Amazon Bedrock's pricing page lists custom Llama 2 models as available only on provisioned throughput at $23.50 per model unit per hour with no commitment — roughly $17,000 a month if left running around the clock. Newer options on Bedrock, such as fine-tuned gpt-oss-20b, are billed per token instead, so check the model you plan to use.
Platform risk is real. OpenAI is winding down self-serve fine-tuning. Its deprecations page says organisations that had never fine-tuned lost access to new training jobs on 7 May 2026, and active existing customers can no longer create new fine-tuning jobs from 6 January 2027. Existing fine-tuned models keep working only until their base model is retired. If you fine-tune, own your training data and prefer models you can move or host yourself.
A simple test: which do you need?
- Write down 20 real questions your customers or staff ask.
- Ask a good off-the-shelf model those questions, pasting in the relevant document by hand.
- If the answers are good once it has the right document, you need RAG — the model just needs to be handed the right information automatically.
- If the facts are right but the format or tone is consistently wrong even with clear instructions and examples, consider fine-tuning (on top of RAG if facts also matter).
- If it fails even with the right document, the issue is usually messy data or the wrong model, not a need for fine-tuning. Fix the data first.
The hybrid approach
For larger projects the best answer is often both: RAG supplies current, permission-checked facts, and a lightly fine-tuned model handles a fixed output format or keeps a smaller self-hosted model sharp on your task. This is common when data can't leave your environment and you run an open-source model inside your own AWS account — see our guide to private LLM deployment. Start with RAG, measure, and only add fine-tuning when you can point to a specific behaviour that prompting couldn't fix.
Common mistakes to avoid
- Fine-tuning to add knowledge. It's slow to update, can't cite sources and still makes things up.
- Cheap RAG with poor search. Most “the chatbot gives wrong answers” complaints are retrieval problems: bad chunking, no re-ranking, outdated documents.
- No evaluation set. Without a list of real questions and correct answers, you can't tell whether a change made things better or worse.
- Locking yourself in. Keep your documents, training data and code in formats you own.
Not sure which one fits?
At IRT Solutions we build RAG chatbots and private, self-hosted LLMs for businesses that need correct answers from their own data. Book a free AI audit and we'll look at your data and use case and tell you honestly whether you need RAG, fine-tuning, both — or neither.
Frequently asked questions
Is RAG better than fine-tuning?
Neither is better in general; they solve different problems. RAG is better for answering from your own, changing information with sources. Fine-tuning is better for consistent style, format or a narrow repeated task. Most business chatbots should start with RAG.
Can I fine-tune ChatGPT on my company documents?
You can train on examples, but it is a poor way to add knowledge: answers can't cite sources, updates need retraining, and OpenAI is winding down self-serve fine-tuning. RAG is the usual approach for company documents.
Is RAG cheaper than fine-tuning?
Usually, yes, over the life of the project. RAG updates by changing documents, while fine-tuning needs curated training data, repeated training runs and sometimes dedicated hosting.
Can I use RAG and fine-tuning together?
Yes. A common setup uses RAG for facts and a lightly fine-tuned model for a fixed output format or to improve a smaller self-hosted model on your task.