What is a RAG system?

It is a system that forces the AI model to search your documents before answering. RAG stands for retrieval-augmented generation: it first retrieves the passages that match the question, then writes the answer using only that material.

Does RAG stop the AI from making things up?

It reduces the problem a lot, but not on its own. The model stops improvising because the fact is in front of it, and on top of that you set the rule to stay silent when nothing was retrieved. Without that rule, a model with thin context still fills the gap.

How is RAG different from training a model on my data?

Training puts your information inside the model, and you repeat it every time a price changes. RAG keeps your data outside, in a store you update whenever you want, and the model reads it at answer time. For a catalog that moves, RAG is the practical route.

What documents do I need for the knowledge base?

Your catalog with prices and availability, your commercial terms, the questions your team already answers, and your site copy. That is enough to start; anything missing is added later without rebuilding.

What does a WhatsApp agent with RAG cost?

The WhatsApp Sales Agent pack includes the knowledge base with your catalog, prices and FAQs. Implementation is USD 1,000, the monthly plan is ARS 220,000, and delivery takes fifteen business days.

What a RAG System Is, and Why Your WhatsApp AI Agent Needs One

A RAG system is what makes an AI agent answer with your company's data instead of improvising it. RAG stands for retrieval-augmented generation: before writing a single word, the system searches your catalog, your prices and your documents, and hands the model only what it found. The model writes with that material. If the fact is not there, there is nothing to write, so the agent says so or hands the conversation to a person.

That is the whole idea. The rest of this article explains why it matters so much when the agent is answering real customers on WhatsApp, how the knowledge base is built, and when you do not need one.

The problem it solves

A general language model writes well and knows nothing about your business. Ask it what your product costs and it has nowhere to get that from, so by design it completes the sentence with something plausible. In a test chat that is a curiosity. In a WhatsApp conversation with a customer about to buy, it is an invented price somebody has to walk back.

The same applies to stock, delivery times, wholesale payment terms and anything else that changes weekly. The model does not know what changed. It only knows what an answer sounds like.

RAG cuts that short. The answer stops coming from the model's memory and starts coming from your database.

How it works, step by step

One: ingestion. You gather the sources that already exist in your company. The catalog with prices and availability, commercial terms, the questions your team answers every day, your site copy, product manuals. They do not need to be tidy; they need to exist. Two: chunking. Each document is cut into pieces the size of one idea. A product with its price and description is a chunk. A payment term is another. It is chunked this way because retrieval works on pieces, not on whole documents. Three: indexing. Each chunk is turned into a numeric representation of what it is about, not of which words it uses. That is why a customer writing "the five-hundred-gram one is cheaper by the case" finds the right chunk even when none of those words appear in the catalog. Four: retrieval. The customer's question arrives. The system finds the closest chunks and keeps a handful, the ones that actually answer it. This step decides the quality of everything downstream: retrieve the wrong passage and the model will write the wrong fact elegantly. Five: generation. The model receives the question plus those chunks, with the instruction to answer only from them. If the chunks are not enough, the instruction is to say so and offer a human.

What changes when the agent works on WhatsApp

A web search forgives a mistake: the user sees three results and picks. WhatsApp forgives nothing. There is one answer, written in the first person, and the customer reads it as coming from your company. Because it does.

With RAG, the agent selling on WhatsApp can quote the price of one specific item, confirm availability, explain the wholesale threshold and build the order with real catalog codes. Without RAG, the same agent does something much poorer: it answers in generalities and escalates everything to a person, which solves nothing.

There is a second effect, less obvious. When an answer comes from an identifiable source, the mistake becomes auditable. If the agent quoted an old price, the fault is in the knowledge base and it is fixed in one place. If the agent made it up, there is nothing to fix, and it comes back tomorrow.

An example with numbers

Take a distributor with eight hundred products in its catalog and prices updated every fifteen days. About one hundred and twenty WhatsApp enquiries arrive per day, and three out of four belong to the same family: price, availability, minimum per case, payment terms.

With no knowledge base, a person answers those ninety daily enquiries by reading a spreadsheet. With RAG, the agent answers them from that same spreadsheet, already loaded as a source, and the person keeps the thirty that need judgement: a negotiation, a complaint, a special order.

What changes is not only volume. It is the clock. Enquiries that land at eleven at night get an answer at eleven at night, with today's price.

What RAG does not fix

RAG does not improve a messy catalog. If your prices live in four spreadsheets that disagree, the agent will retrieve all four and answer with one of them. The knowledge base inherits the quality of its sources; it does not repair them.

It does not replace business rules either. Knowing the list price does not mean knowing when a discount is allowed: that is a rule, written separately, never left to the model. In our agents, sensitive commercial decisions are explicit rules, and what the model does is phrase an answer inside them.

And it is not magic over data that does not exist. If your return policy was never written down, the agent cannot explain it. That is the real work of an implementation: writing down what today lives in two people's heads.

Where retrieval usually goes wrong

When a RAG system answers badly, the model is rarely the culprit. Three things go wrong far more often.

The chunks are too big. A whole price list in one piece means the retriever hands the model fifty products when the customer asked about one. The right fact is in there, buried, and the answer comes out vague. The sources disagree. Two spreadsheets with different prices for the same item, both loaded. The system retrieves both and picks one. Nothing about that is fixable inside the model. The vocabulary does not match. Your catalog says "industrial degreaser 5L" and every customer writes "the strong cleaner". Semantic search absorbs a lot of that, but not everything, and the gap shows up as unanswered questions.

All three are fixed in the data, not in the prompt. That is good news: they are cheap to fix and they stay fixed.

How the knowledge base is maintained

A knowledge base is not a project that ends: it is a living file. If your prices change every fifteen days, the base changes every fifteen days, or the agent will quote an old price with total confidence.

There are two ways to maintain it, and the choice matters.

The first is to make your management system or your price sheet the source, and let the base update itself when that changes. This is the good one: nobody has to remember anything, and the fact has a single owner.

The second is loading changes into the base by hand. Fine for what lives nowhere else, such as commercial terms or a new frequently asked question. It fails when used for data that does have a system, because sooner or later somebody forgets.

The practical rule: anything that already exists elsewhere is synchronised, never copied. Anything that exists nowhere is written once and revisited when the business changes.

There is also a kind of maintenance that is about language rather than data. Customers name products in ways your catalog does not. Reading last month's conversations and adding those names as synonyms improves retrieval more than any technical tuning.

When you do not need it

If you sell five services at fixed prices and the questions are always the same, there is no knowledge base to build: those five answers are loaded directly. RAG starts paying off when the catalog is large, changes often, or when the questions are too varied to anticipate one by one.

The useful question is not whether you want RAG. It is how many different questions your business receives per week, and how many of them are already answered in a file you have.

How we implement it

The WhatsApp Sales Agent pack includes the knowledge base with your catalog, prices and FAQs, the agent that consults it on every reply, the handoff to a person when needed, and the dashboard where you see every conversation. Implementation is USD 1,000, the monthly plan is ARS 220,000, and delivery takes fifteen business days.

If you also need the agent to read real stock and record the order in your system, that is the Complete Operation pack, which joins the store, the backoffice and the agent into one flow.

Before deciding, it may help to read the concrete difference between an AI agent and a chatbot, because it is exactly this one: where the answer comes from.

Want to see it running on your catalog? Message us on WhatsApp and we will go through it with your own data.