You have probably seen the pitch. "Deploy an AI assistant that knows everything about your business." "A chatbot trained on your documents." "Custom AI, powered by your data." It sounds compelling — and the underlying technology is genuinely useful. But the phrase "trained on your data" is being used so loosely that it has become nearly meaningless. Most businesses evaluating AI chatbots right now are comparing products that work in fundamentally different ways without knowing it.
This article explains what's actually going on under the hood, why it matters for the quality of the answers your chatbot gives, and what questions you should be asking any vendor before you sign anything.
Start here: what ChatGPT actually knows
ChatGPT — and every other large language model (LLM) — was trained on a vast amount of text from the internet. Books, articles, websites, code, conversations. That training happened at a point in time, and then it stopped. The model knows what was in that training data. It does not know what happened after the cutoff. It does not know anything about your specific business, your products, your pricing, your policies, or your customers.
When you ask ChatGPT "what is our returns policy?", it has no idea. It will either say it doesn't know, or — and this is the dangerous version — it will make something up that sounds plausible. This is called hallucination, and it is the single biggest practical problem with deploying LLMs in business contexts.
So when a vendor says their chatbot is "trained on your data," they need to mean something very specific — that there's a mechanism connecting the LLM's ability to understand and generate language with the actual facts from your specific business. RAG is that mechanism.
Think of it like a brilliant new employee with amnesia
What RAG actually stands for — and what it does
RAG stands for Retrieval-Augmented Generation. Break that down:
Retrieval — when a user asks a question, the system first searches your documents, knowledge base, CRM records, or any other data source to find the relevant information. It doesn't search the internet. It searches your stuff.
Augmented — that retrieved information is added to the context that gets sent to the LLM. The model now knows both the question and the relevant facts from your business.
Generation — the LLM uses that context to generate an accurate, natural-language response. It's answering from your documents, not from a guess.
User asks a question
System retrieves relevant documents
Context is assembled and sent to the LLM
LLM generates a natural-language answer
That answer came from your policy document — not from the LLM's general training. If your policy changes, you update the document and the chatbot immediately gives the new answer. No retraining required. This is what makes RAG genuinely useful for businesses.
RAG vs. Fine-tuning — the difference that vendors hope you won't ask about
There is another approach you will hear about: fine-tuning. This is where you take an LLM and re-train it on your specific data — the model's weights are adjusted to incorporate your information. It sounds more powerful, and for some applications it genuinely is. But for most business chatbot use cases, it has significant practical disadvantages.
| Factor | RAG | Fine-tuning |
|---|---|---|
| Cost to set up | Moderate — vector DB + integration | High — GPU compute, specialist skills |
| Update when data changes | Update the document — instant | Retrain the model — days / weeks |
| Hallucination risk | Low — answers cite sources | Medium — still possible |
| Works well for | FAQs, policies, product info, support, internal knowledge | Tone/style matching, very specialised domains |
| Transparency | Can show which document the answer came from | Answer is baked into model — hard to audit |
| Right for most SMBs | Yes | Rarely |
Fine-tuning has its place — if you need the model to adopt a very specific writing style, or to understand highly specialised domain terminology that doesn't exist in general training data, it can make sense. But for a business that wants a chatbot to accurately answer questions about their products, policies, and processes, RAG delivers better results at a fraction of the cost and complexity.
What it actually looks like in a real business
Here are four situations where a properly built RAG system makes a measurable difference.
SaaS customer support
Internal HR / IT helpdesk
Travel agency pre-sales
The three questions to ask any AI chatbot vendor
Before you sign anything, get clear answers to these three questions. The answers will tell you more about the product than any demo.
What your data needs to look like for RAG to work
RAG is not magic. The quality of the answers is directly proportional to the quality of the documents you feed it. Before building, you need to be honest about the state of your knowledge base.
Structured, current documents work well. A regularly updated FAQ document, a well-maintained product manual, a clean HR policy document, a knowledge base with consistent formatting — these are the inputs that produce accurate, reliable answers.
Inconsistent, outdated, or contradictory documents produce unreliable answers. If your policy document says one thing and your pricing page says another, the chatbot will find both and either give you the wrong answer or hedge confusingly. The document quality problem doesn't go away by adding AI to it.
The content audit is the most important pre-build step. Before any RAG system is set up, the source documents need to be reviewed, updated, and organised. This is almost always more work than businesses expect — and it produces value well beyond the chatbot, because it forces the organisation to clarify and document how things actually work.
We have built RAG systems for SaaS support, travel agencies, professional services firms, and internal HR tools. In every case, the content preparation phase — getting the source documents into shape — took longer than the technical build. The technology is not the hard part. Getting your knowledge base into a state where it reliably contains the right answers is the hard part.
A properly built RAG chatbot typically costs between £12,000 and £45,000 to design, build, and deploy, depending on the number of data sources, integration complexity, and the volume of content that needs preparing. Ongoing costs include the LLM API usage (typically £200–£1,500 per month depending on query volume) and routine content maintenance. It's not a small investment — but for a team handling 500+ repetitive queries per week, the ROI calculation is usually straightforward.
Thinking about an AI chatbot for your business?
Tell us what you're trying to solve — support volume, internal knowledge, sales qualification — and we'll give you an honest assessment of whether RAG is the right approach, what your data readiness looks like, and what it would cost to build. No pitch. Just a straight conversation.
Request received.
Our AI team will review your use case and be in touch within 4 business hours to arrange a call.