What Is a RAG System?
A RAG system is an AI architecture in which a large language model (LLM) doesn’t generate its answers solely from what it learned during training, but from documents that are specifically supplied to it at the moment of the query. RAG stands for Retrieval-Augmented Generation — generation enriched through retrieval. The term comes from a 2020 paper by Patrick Lewis and colleagues at Meta AI, but it only became a standard pattern once ChatGPT arrived and businesses needed to connect AI with their own data.
The problem RAG solves is familiar to anyone who has ever asked a language model about something internal to their company: it knows nothing about your price list, your contracts or your product manual — and, when in doubt, invents a plausible-sounding answer. A RAG system gives the model the relevant knowledge at the moment it’s needed. The answer reads just as well as one from ChatGPT, but its content comes from your own sources — and can be verified.
How Does Retrieval-Augmented Generation Work?
A RAG system consists of two phases. The first runs once, or whenever the documents are updated; the second runs on every query.
Phase 1: Indexing the Knowledge Base
- ▸Gather documents: PDFs, Word files, wiki pages, tickets, emails, database records — anything that should later be queryable.
- ▸Chunking: documents are broken into sections (“chunks”) typically 200 to 1,000 words long. Chunks that are too small lose context; chunks that are too large dilute the search. Chunking strategies that follow headings and paragraphs clearly outperform rigid character counts.
- ▸Vectorisation (embedding): an embedding model translates each chunk into a numerical vector — a numeric representation of its meaning. Texts with similar content sit close together in vector space, even if they use different words.
- ▸Storage: vectors plus metadata (source, date, department, access rights) land in a vector database such as pgvector, Qdrant, Weaviate or Pinecone.
Phase 2: Retrieval and Generation on Every Query
- ▸The user’s question is vectorised using the same embedding model.
- ▸Retrieval: the vector database returns the chunks whose vectors are closest to the question — a semantic search that recognises “holiday entitlement” and “how many days off do I get” as the same topic. Modern systems combine vector search with classic keyword search (hybrid search) and re-rank the results with a re-ranking model.
- ▸Augmentation: the best three to ten chunks are inserted into the language model’s prompt together with the question and an instruction (“answer only based on the following sources, and cite where you found it”).
- ▸Generation: the LLM formulates the answer from the supplied context and, ideally, cites the source. If retrieval finds nothing suitable, the model should say so — instead of guessing.
A metaphor that sticks in workshops: the language model is an eloquent consultant who doesn’t know your company. RAG is the assistant who, before every answer, puts the right three pages from the filing cabinet on the table in front of them.
RAG vs LLM: What’s the Difference?
It’s a question that keeps coming up, even though it’s framed the wrong way round: RAG isn’t a competitor to the LLM, it’s built on top of it. The LLM is the language model — GPT, Claude, Gemini, Llama, Mistral. RAG is the method for feeding it external knowledge. An LLM on its own answers from its training data, which is months old and doesn’t include your data. An LLM with RAG answers from your current documents. The model stays the same; what changes is the source of information.
Is ChatGPT a RAG system? At its core, ChatGPT is a language model with a chat interface. But when it searches the web or reads uploaded files, it does use RAG mechanisms: it retrieves content and generates from it. “Projects” and custom GPTs with knowledge files work on the same principle. An enterprise-grade RAG system goes further — with its own knowledge base, permissions management, source citations, and connections to internal systems.
RAG vs Fine-Tuning: When to Use Which?
| Criterion | RAG | Fine-Tuning |
|---|---|---|
| What happens | Knowledge is retrieved from documents at runtime | Model weights are retrained on your own data |
| Suited to | Factual knowledge, documents, frequently changing content | Style, tone, format, specialist language |
| Updating | Swap the document — effective immediately | Requires retraining |
| Traceability | Source can be cited | None — knowledge is embedded in the weights |
| Cost | Infrastructure + tokens per query | Training runs + hosting your own model |
| Data protection | Data stays in your database; only relevant excerpts go to the model | Data becomes part of the model — hard to retract |
| Typical failure | Wrong chunk retrieved | Model “forgets” or overwrites knowledge |
In practice, RAG is the right choice for over 90% of enterprise applications: it’s cheaper, updatable, and traceable. Fine-tuning pays off when the model needs to reliably master a particular style of expression or output format — and is then often combined with RAG. One special case is the huge context windows of modern models: if you only need to query 50 pages, you can load them into the prompt in full. At 5,000 pages, with permissions and cost control in play, there’s no way around RAG.
What Are the Benefits of a RAG System?
- ▸Fewer hallucinations: the model answers from the sources it’s given and can be instructed to say it doesn’t know when context is missing.
- ▸Freshness: upload a new price list and the AI knows it immediately. No training, no waiting.
- ▸Verifiability: every answer can point to a document and section. For compliance, customer service and internal search, that’s the decisive difference from a black box.
- ▸Data protection and access control: documents stay on your own infrastructure; metadata lets you control which sources each user is allowed to see.
- ▸Model independence: the language model is swappable. When a better or cheaper model becomes available, the knowledge base stays unchanged.
- ▸Cost: instead of training a model on millions of documents, you only pay for the tokens of the excerpts actually retrieved.
Use Cases: What Is RAG Particularly Good For?
- ▸Internal knowledge search: employees ask, in natural language, about processes, policies, contracts or technical documentation — instead of digging through SharePoint.
- ▸Customer service: a chatbot that answers from manuals, FAQs and ticket history and names its source. Because the answers come from vetted documents, liability risk drops too — as we describe in our article on AI chatbot liability.
- ▸Sales and quotes: retrieving product data, references and past quotes to answer enquiries quickly and consistently.
- ▸Legal and compliance: querying contracts, standards and internal rulebooks — with the source cited.
- ▸Technical support and maintenance: bringing together error codes, maintenance manuals and a device’s service history in a single answer.
- ▸Memory for AI agents: AI agents that carry out tasks need company knowledge — RAG is their long-term memory.
How Do You Build a RAG System?
The building blocks are commodity components in 2026; the real work lies in data quality. Here’s how we approach it:
- ▸1. Define the use case and questions: collect 30 to 50 real questions the system should be able to answer, along with the “correct” answers. This becomes your test set later.
- ▸2. Select and clean up sources: strip out outdated versions, duplicates and drafts. A RAG system that finds three contradictory price lists will give contradictory answers.
- ▸3. Set up the pipeline: ingest documents (including tables and scans via OCR), chunk them sensibly, add metadata, embed them, and write them to the vector database. Frameworks such as LangChain or LlamaIndex speed this up; ready-made platforms such as Azure AI Search, Google Vertex AI Search or Amazon Bedrock Knowledge Bases take care of the infrastructure.
- ▸4. Optimise retrieval: hybrid search, re-ranking, number of chunks retrieved, metadata filters. This is where most of the quality gains come from.
- ▸5. Define the prompt and model: a clear instruction to answer only from the sources; enforce source citation; choose the model by cost and quality — a smaller model is often enough if the context is good.
- ▸6. Evaluate and operate: run the test set, measure hit rate and answer quality, collect user feedback, keep documents up to date. A RAG system is a product, not a project.
A lean stack has proven its worth for SMEs: PostgreSQL with pgvector as the vector database (no extra infrastructure needed), a European or EU-hosted embedding and language model, n8n for the pipeline, and a connection to chat, website or ticketing system. Everything stays on your own servers and can be set up in days rather than months.
Challenges and Common Mistakes
- ▸Poor data: the most common problem. Unstructured PDFs with tables, scanned documents, outdated content. Data preparation accounts for 60% of the effort.
- ▸Bad chunking: if a table gets cut in half, or a clause is separated from its heading, the search either won’t find it or the model will misread it.
- ▸Retrieval failures: the right answer is in the document but isn’t retrieved — because of unusual phrasing, too many similar chunks, or missing metadata filters. That’s why a test set is essential.
- ▸Too much context: ten roughly relevant chunks are worse than three correct ones. More context costs tokens and confuses the model.
- ▸Missing access control: if the salary list sits in the index, anyone who asks will find it. Access rights must be enforced at retrieval time, not just in the interface.
- ▸Hallucination despite RAG: the model ignores the context or embellishes it. The remedy: strict prompts, mandatory source citation, and for sensitive applications, human review — see human-in-the-loop.
Our Verdict
RAG is the bridge between generative AI and your actual business. It turns a language model that knows everything and nothing in particular into a system that knows your documents, cites its sources, and updates itself with every new document. The technology is mature and affordable; success hinges on clean data, well-designed retrieval, and honest evaluation. Take those three things seriously, and within a few weeks you’ll have a knowledge search your company uses every day.
Do you have documents, manuals or tickets your team constantly digs through? We build RAG systems on your own infrastructure in the EU — from data preparation through to connecting a chatbot, intranet or customer service. Book an initial consultation.
