Large language models know a lot about the world and nothing about your company. They have not read your price list, your return policy, your engineering handbook or last year's support tickets. Retrieval-augmented generation, usually shortened to RAG, closes that gap. Instead of asking the model to remember, the system looks up the relevant passages from your documents and gives them to the model along with the question. This article explains the moving parts and the mistakes we see most often.
How RAG works in four steps
Every RAG system, however sophisticated, follows the same basic pattern.
- Prepare. Your documents are cleaned and split into passages, often called chunks.
- Index. Each chunk is stored in a search index, usually with a numeric representation of its meaning called an embedding, plus the original text and metadata such as source, date and owner.
- Retrieve. When a user asks a question, the system searches the index and returns the most relevant chunks.
- Generate. The model writes an answer using only those chunks, ideally with references to the sources it used.
The model is the last step. Most of the quality is decided earlier.
Good answers start with good documents and search
Clean the source before you index it
Duplicate files, outdated policies and contradictory versions produce confused answers. Decide which documents are authoritative, remove or archive the rest, and assign an owner to each topic. Teams are often surprised to find that a week of content cleanup improves results more than any change to the model.
Chunk with meaning in mind
Cutting text every few hundred words regardless of structure splits tables, lists and sentences in awkward places. Prefer chunks that follow headings and paragraphs, keep a little overlap, and store the heading path with each chunk so that a passage about "returns" still knows which product line it belongs to.
Handle Arabic and mixed-language content properly
If your documents mix Arabic and English, test the embedding model on both and on mixed queries. Search quality in Arabic can vary a lot between models, so evaluate with real questions that your staff and customers ask, in the dialect and spelling they actually use.
Retrieval is a search problem
If the right passage is not retrieved, the model cannot answer correctly, no matter how capable it is. Improve retrieval before anything else.
- Combine meaning-based search with keyword search, so exact product codes, names and numbers are still found.
- Filter by metadata, such as product, branch, language or date, before ranking.
- Retrieve a few more passages than you need, then re-rank them and keep the best.
- Rewrite vague follow-up questions using the conversation history, so "and what about the second one?" becomes a searchable query.
Answer with citations, and know when to refuse
Ask the model to answer only from the supplied passages and to say clearly when they do not contain the answer. Show the user which documents were used, with links when possible. Citations build trust, make mistakes easier to spot, and give staff a quick way to verify an answer before they act on it.
Refusing is a feature. A knowledge assistant that says "I could not find this in our documents" is more valuable than one that invents a confident reply. We apply the same principle to the AI assistant on this website, which answers from the content Narmar publishes and cites the page it used.
Respect access rights
A company knowledge base usually contains material that not everyone should see: salary policies, contracts, customer data. Apply permissions at retrieval time, not only in the interface. Store access information with every chunk, filter results by the signed-in user, and never place restricted text into a prompt for a user who could not open the original document.
Measure it like a product
Build a test set early
Collect fifty to a hundred real questions with known correct answers and the documents that contain them. Run the set after every change to chunking, search settings or prompts. Without a test set, every improvement is a guess.
Check retrieval and answers separately
When an answer is wrong, find out whether the right passage was retrieved. If not, fix search or content. If it was, fix the instructions to the model. Separating the two saves days of confusion.
Keep the index fresh
Documents change. Plan how updates, deletions and new files reach the index: scheduled syncs, event-driven updates or manual triggers. In our own platforms we rely on Laravel queues and scheduling for this kind of background synchronisation, so that publishing a page and updating what the assistant knows happen without anyone remembering to do it twice.
Where RAG fits in real projects
Typical first uses are internal helpdesks, customer support assistants, sales enablement and onboarding guides. We have built chat assistants into products such as the Narmar Express Shipping Platform, where an assistant helps operators, and the NoLimit Tech website, which includes a built-in AI chat assistant. In each case the useful part was not the model itself, but the careful connection between the assistant and the company's own information.
RAG is not the answer to every problem. If you need the system to take actions, calculate figures or follow a strict process, combine retrieval with tools and business rules, and keep a person in the loop for decisions that matter.
Start small
Pick one knowledge area with clear owners, such as product support or HR policy. Collect the documents, build the test set, launch to a small internal group and review conversations weekly. Expand only when the quality is steady.
If you want to turn your documents into a reliable assistant, the Narmar team can help you scope the first use case and build it. See our AI services or contact us to talk it through.
