Does RAG stop hallucinations completely?

No, but it reduces them sharply. Grounding answers in retrieved text, requiring citations and instructing the model to decline when context is missing make wrong answers rarer and easier to detect.

Which vector database should we use for RAG?

For most teams pgvector inside PostgreSQL is enough to start; dedicated stores such as Pinecone, Weaviate or Qdrant help at larger scale or with heavy filtering. Retrieval quality depends more on chunking and re-ranking than on the database.

Can RAG respect document permissions?

Yes. Store access metadata with each chunk and filter retrieval by the signed-in user's permissions, so the model never sees content the user is not allowed to read.

How long does it take to build a production RAG system?

A focused proof of value on one document set can be ready in a few weeks; production hardening — connectors, permissions, evaluation and monitoring — typically follows over the next one to three months.

What Is RAG? A Practical Guide to Retrieval-Augmented Generation for Enterprises

What retrieval-augmented generation (RAG) is, how it works, when to use it instead of fine-tuning, and how to build RAG that holds up in production.

Retrieval-augmented generation (RAG) lets a large language model answer questions using your own documents and data. At question time the system retrieves the most relevant passages and gives them to the model as context, so answers are grounded, current and traceable to a source — without retraining the model.

What is retrieval-augmented generation?

A large language model only knows what was in its training data. It does not know your policies, contracts, product catalogue or last week's tickets, and if you ask it anyway it may produce a confident but wrong answer. RAG closes that gap by adding a retrieval step before generation.

When a user asks a question, the system searches a knowledge store for passages related to the question, places the best matches into the prompt, and instructs the model to answer using that context. The model does the reasoning and writing; the retrieval layer supplies the facts.

How does a RAG pipeline work?

A production RAG system has two halves: an ingestion pipeline that prepares your content, and a query pipeline that answers questions.

When should you use RAG instead of fine-tuning?

Use RAG when the problem is knowledge: answers depend on facts that change, that are private, or that must be cited. Updating a RAG system is as simple as re-indexing a document, and access control can be enforced per user.

Use fine-tuning when the problem is behaviour: a consistent output format, a domain's tone and terminology, or a narrow task that a smaller, cheaper model should do reliably. Many strong systems combine both — a fine-tuned model that is good at the task, grounded by RAG on the latest facts.

Which RAG techniques matter beyond the basics?

Simple top-k vector search is enough for a demo. Real document collections usually need more:

How do you measure whether a RAG system is good?

Build an evaluation set of real questions with known correct answers and sources before you tune anything. Measure retrieval quality (did the right passage come back?) separately from answer quality (is the answer correct, complete and faithful to the context?).

Track faithfulness — answers that are supported by the retrieved text — as a first-class metric, and log every production query with its retrieved context so failures can be diagnosed. Frameworks such as Ragas and LLM-as-judge scoring help automate this, but a human-reviewed golden set remains the reference.

What are the common RAG failure modes?

Most RAG problems are data problems: poorly parsed PDFs, chunks that cut tables in half, stale indexes, or missing permissions metadata. The next most common issue is retrieval that returns plausible but wrong passages, which the model then repeats confidently.

Guard against these with document-quality checks at ingestion, re-ranking, an instruction to say "I don't know" when the context is insufficient, and per-user access filtering at retrieval time rather than after generation.

If you are planning a private-data assistant, our team builds RAG and knowledge systems end to end — see our RAG service page for the approach we use.

Ingest: pull documents from file shares, wikis, ticketing tools, databases and email, and keep them in sync.
Parse and chunk: extract clean text (including tables and scanned pages), then split it into passages small enough to retrieve precisely but large enough to keep meaning.
Embed and index: convert each chunk into a vector embedding and store it in a vector database alongside metadata such as source, date and access permissions.
Retrieve: for each question, run vector search — usually combined with keyword search — and filter by the user's permissions.
Re-rank: use a re-ranking model to put the most relevant passages first and drop weak matches.
Generate and cite: the LLM answers from the retrieved passages and returns citations so users can check the source.
Hybrid search (vector + BM25 keyword) so exact terms like product codes and clause numbers are not missed.
Contextual chunking that keeps headings and document titles attached to each passage.
GraphRAG or knowledge graphs when answers depend on relationships between entities, not single passages.
Text-to-SQL for questions whose answers live in databases rather than documents.
Query rewriting and multi-step retrieval for complex or multi-part questions.
Caching of frequent questions and retrieved context to cut latency and token cost.