Your AI doesn't know your business. RAG fixes that

Plenty of people teach how to connect n8n to an AI model and call it an assistant. In the demo it works. In production, and this is my experience, it is where most chatbots fail: the model answers with what it learned on the internet, not with what your business knows.

The chatbot is only the visible part of the problem. The cause is underneath, and the fix is useful for much more than customer service.

The problem is not the model

A language model doesn't know your current prices, your contracts, your team's procedures or your customers' history. None of that was ever part of what it learned.

And when it doesn't know, it doesn't say "I don't know". It produces the answer that sounds most likely. Three failures keep repeating:

• It makes things up. A delivery date, a warranty condition, a feature that doesn't exist, all said with confidence.
• It is out of date. What the model learned has a cut-off date. Your price list changed after that.
• It can't see what is private. Internal procedures, old proposals and contracts were never within its reach.

A confidently wrong answer is worse than no answer.

What RAG is, in one minute

RAG stands for Retrieval-Augmented Generation. The simplest way to understand it is the difference between a closed-book exam and an open-book exam. Instead of asking the model to answer from memory, you hand it the right documents at the moment of the question.

1. Before anything else: your documents are split into passages and indexed, so they can be searched by meaning and not only by exact word.
2. Someone asks a question.
3. The system searches and finds the most relevant passages.
4. The model receives the question plus those passages and is told to answer only from them.
5. The answer comes with its source, so the reader can check it.

n8n is not the problem

n8n is still an excellent glue for connecting systems. The difference between an assistant that makes things up and one that gets it right is in the middle step: what happens between the question and the model.

In practice, the hard part is never calling the model. It is making sure the search brings back the right passages.

Where RAG applies (beyond the chatbot)

The idea works anywhere someone wastes time looking for information or answering the same question for the tenth time. These are examples of where the technique applies, not client cases:

Use	RAG fetches from…	What changes
Customer service	FAQ, policies, catalogue	Consistent answers, using the current policy, instead of improvising
Internal team	Procedures, wiki, manuals	New hires ask the system instead of interrupting the most senior colleague
Proposals and tenders	Past proposals, case studies, data sheets	A first draft built from what the company has already written and approved
Contracts and legal documents	Contracts, clauses, policies	Finding the right clause in seconds. The decision is still a person's
Technical teams	Documentation, tickets, architecture decisions	Less time asking "why was this done this way?"
Sales	CRM, meeting notes, emails	Preparing for a meeting without rereading thirty emails

Why this lowers costs

I won't put percentages here, because they depend on volume and on the case. What can be explained is the mechanism:

1. Fewer hours searching and repeating. Repeated questions stop consuming the time of whoever knows the answer.
2. Less text sent to the model per question. Instead of pasting whole documents into the request, only the relevant passages go. You pay for the context that matters.
3. A smaller model is often enough. When the answer is already in the passages, the model has to read and phrase it, not know it. In many cases a cheaper model is enough, but that gets measured, not assumed.
4. Updating means replacing a document. A price changed? Change it in the document and it enters the index. There is no model retraining.
5. Fewer expensive mistakes. A wrong answer to a customer can turn into a refund, a complaint or lost trust. With the source in view, any answer can be checked.

Where RAG also fails

It is worth knowing this before you invest:

• Bad documents give bad answers. RAG doesn't fix outdated or contradictory information. It exposes it, and often it is the first time anyone sees it.
• The search can bring back the wrong passages. Then the model answers the wrong passage very well, and the answer looks convincing.
• Without measurement you don't know whether it works. You need a set of real questions with the correct answer known, to test before and after every change.
• There is GDPR. If the documents contain personal data, you need to think about the legal basis, minimisation (don't index what isn't needed), access control (each person should only get what they could already see), where the model runs, whether data is transferred outside the EU, and how long each thing is kept.

How to start without burning money

1. Pick a question that comes up a lot and identify the source of truth where the answer lives.
2. Gather a few dozen real questions, with the correct answer.
3. Build the minimum and measure. Is it right? Does it cite the source? Does it say "I don't know" when it doesn't?
4. Only then automate and widen. That is where n8n and the integrations come in.

---

If you have internal documents or data and want to know whether RAG makes sense in your case, talk to us. And if you already have an AI system in production that nobody has reviewed, the first step is a review and fix of AI-built apps.