A language model knows almost everything except one thing: your company. It has no idea what your prices are, what the client contract says, what your return policy is, or whether an item is in stock. Ask it directly and it will either decline honestly or invent a plausible answer. The second is worse.
RAG solves exactly this problem. It turns a general-purpose model into an employee who has read all your documents and answers strictly from them.
Without RAG, an AI agent is a smart conversationalist who guesses. With RAG, it is a worker that looks up the answer in your documents — and can say "that is not in the knowledge base."
What RAG is, in plain language
RAG stands for Retrieval-Augmented Generation. The name is intimidating, the mechanics are simple, and it comes down to three steps:
- You load your company documents into a dedicated database, once.
- A question comes in — the system first retrieves the relevant chunks of text from that database.
- The model composes an answer based on those chunks, not on its general knowledge.
An analogy. You hired someone and had them read every manual, price list and FAQ. But they do not memorise it — they keep the folder at hand and check it every time. That is precisely why they do not make things up: they look at the document before answering.
One detail that often gets missed: the model does not "remember" anything and is not retrained. The documents stay yours, sit in your database, and updating them means replacing a file. Fine-tuning a model is a different, far slower and more expensive story — and for the task of "answer from our documents" it is almost never needed.
Why plain ChatGPT is not enough
A general model does not and cannot know:
- your prices, discounts and terms for specific clients;
- your product range and stock levels;
- internal procedures — how to process a return, who signs off a contract;
- the history of correspondence with this particular client;
- the specifics of your industry in Uzbekistan, from paperwork requirements to established practice.
A fair objection: why not just paste the documents into the chat? At a small scale this works and is a perfectly reasonable first step. But ten documents fit into one request and a thousand do not. And even when they fit, you pay for all those pages with every single question, while the model gets worse at locating the relevant part in a large pile. RAG supplies only the three to five fragments that actually relate to the question.
How it works under the hood
1. Chunking
Documents are cut into pieces of 500–1000 characters with a small overlap. Supported formats include PDF, Word, Excel, tables, web pages and exports from 1C and your CRM. The overlap exists so that a thought split across a chunk boundary is not lost entirely.
2. Embeddings
Every chunk is converted into a set of numbers — a vector, a mathematical representation of meaning. This is the core trick: search runs on meaning, not on words.
Example. The query "what discounts do you have" will find the fragment "special offers and promotions for regular customers" even though the word "discount" never appears in it. Keyword search would return nothing.
3. The vector database
Vectors are stored in a database — pgvector (an extension to ordinary PostgreSQL), Pinecone, Weaviate. Searching hundreds of thousands of fragments takes milliseconds. For most companies under 150 people pgvector is enough: no separate service, and the data sits next to everything else.
4. Generating the answer
The retrieved fragments go to the model along with the question and an instruction: answer only from this data, and if the answer is not there, say so. That instruction matters more than it sounds — it is what separates a system you can trust from one that lies elegantly.
Insist that the agent shows its source — document name and section. This is not decoration: an employee can verify an answer in ten seconds, and you get to see which documents have gone stale.
Where RAG is used
| Area | What goes into the base | What changes |
|---|---|---|
| Customer support | Catalogue, FAQ, delivery and warranty terms | Routine questions close without an operator; a human steps in on the hard ones |
| Legal | Contracts, procedures, Uzbek regulations | Finding the right clause takes seconds instead of half an hour |
| Sales | Proposals, case studies, decks | The rep gets a ready answer with a link to the source document |
| Onboarding | Processes, instructions, internal rules | New hires ask the bot instead of interrupting colleagues |
All four share one trait: the answers exist and are written down, but finding them takes longer than asking a person. RAG closes exactly that gap.
Where RAG breaks
This part rarely gets written about, and it is worth knowing in advance. All three problems are solvable, but they have to be planned for.
Stale documents. The agent will answer honestly from the base — and if the base holds a six-month-old price list, it will quote the old price. That is not a technology problem; it needs an update routine and someone responsible for it.
Contradictions inside the base. If one document says one thing and another says the opposite, the system will retrieve both fragments and produce weighted-average nonsense. Loading documents almost always surfaces contradictions the company did not know it had. Unpleasant, but useful.
Badly structured sources. A contract scanned as an image, a table with merged cells, a deck made entirely of pictures — all of it either fails to parse or gets chopped into meaningless pieces. Preparing documents is usually the most labour-intensive part of the project, and it is done not by the contractor but by whoever knows the content.
What it costs
Cost consists of two different things, and it is important not to conflate them.
Development — one-off work: preparing documents, setting up the base, integrating with the channel where people will ask, and testing on real questions. We do this as a pilot $1,500: one process, two to three weeks, a measurable result before any expansion.
Running costs — the model's API usage, typically tens of dollars a month at the load a small or mid-sized business generates. A pgvector database costs nothing extra if you already run PostgreSQL.
A detailed budget breakdown is in how much AI automation costs.
Frequently asked questions
Will our documents end up training the model?
No. Fragments are passed within the request and are not used for training — given correct configuration and a plan where the provider guarantees it. The documents themselves stay in your database. This is worth verifying and putting in the contract rather than taking on trust.
How many documents do we need to start?
Enough to cover the most frequent questions. That is usually 20–50 files, not the entire archive. Starting with "first we will digitise everything" is a reliable way never to launch.
What happens when the answer is not in the base?
A properly configured agent says "this is not in the knowledge base" and hands the question to a human. That is not a shortcoming but a requirement: a system that always produces an answer will eventually produce a wrong one.
Does RAG work in Uzbek?
Yes — modern models handle Uzbek, Russian and English. Semantic search quality in Uzbek is slightly below Russian, and that gets verified on your real questions during the pilot rather than on promises.
How is this different from site search?
Search returns a list of documents and leaves the reading to you. RAG returns an answer to the question you asked, with a link to the source if you want to check.
Where to start
Write down the twenty questions your staff get asked most often by clients or colleagues. If the answers exist in documents but take a long time to find, you have a RAG use case. If the answers live only in people's heads, they have to be written down first — and that is work outside of AI.
Want to test it against your own documents? We run a free assessment: we look at what you have and tell you plainly if there is not yet enough of a base for RAG.