Is RAG the same as fine-tuning?

No. Fine-tuning changes the model's weights and is for changing behavior or style; RAG keeps the model untouched and feeds it facts at question time. For "answer from our documents", RAG is cheaper, updatable in minutes and does not forget — fine-tuning is rarely the right tool for that job.

Can it cite its sources?

Yes, and it should always be configured to. Each retrieved chunk knows which document and page it came from; a good implementation shows the citation next to the answer. Citations are what turn the system from a black box into something a colleague can verify.

How accurate is it, really?

On well-chunked, current documents, expect high precision on questions the material covers — with honest refusals on the rest. The failure you must design for is not wrong answers on covered questions; it is confident answers on uncovered ones, which is why the "say I don't know" behavior is a hard requirement, not a nicety.

// ai

RAG, without the jargon: letting AI answer from your own documents

3 min read · all guides

Retrieval-augmented generation — RAG — is the technique behind every "chat with your documents" product. The idea fits in one sentence: instead of hoping the model memorized your manuals, you fetch the relevant pages at question time and hand them to the model with the question. The model reads, then answers, and cites where it found things.

It is the most deployed AI pattern in business, and it fails in predictable ways. This guide explains how it actually works, what a serious deployment costs, and the three failure modes you should test before going live.

How it works, concretely

Your documents are cut into chunks, each chunk is converted into a numerical fingerprint (an embedding), and the fingerprints go into a vector database. When a user asks something, the question gets the same treatment, the system pulls the chunks with the closest fingerprints, and those chunks land in the prompt as context. The model's job shrinks from "know everything" to "answer using these three pages" — which is exactly the job it is good at. The whole pipeline is a few well-understood components glued together; the magic is mostly in the gluing.

What it is genuinely good at

Employee knowledge bases (policies, procedures, onboarding), customer support from real manuals and tickets, contract and regulation lookup, technical documentation search. The pattern shines where answers exist in writing but are scattered across hundreds of pages, and where a wrong guess is worse than an honest "I don't know". A well-built RAG system answers from your material only, cites its sources, and says when the material says nothing — three properties a raw chatbot does not have.

The three ways RAG deployments fail

Bad chunks: documents split mid-thought lose their meaning, and retrieval misses. Test by asking questions you know are answerable and checking what got retrieved — this is the number one defect we find in audits. Stale data: the index built once in January is confidently wrong by June; you need re-ingestion wired into wherever documents live. Prompt drift: teams quietly add "also use your general knowledge" and the system starts answering from the internet — at which point you own everything it hallucinates. Each failure is cheap to prevent and expensive to discover in production.

What a serious deployment costs

The infrastructure is almost free at business scale: vector storage and embeddings for tens of thousands of documents run in the tens of euros per month. The real costs are engineering and content hygiene. Budget for: document cleanup (nobody's PDFs are as clean as they think), the ingestion pipeline with its update triggers, evaluation — a fixed set of fifty questions with known answers you re-run after every change — and access control, because a knowledge base chatbot must respect who may read what. A focused first version is typically weeks, not months, for a team that has done it before.

Frequently asked questions

Is RAG the same as fine-tuning?: No. Fine-tuning changes the model's weights and is for changing behavior or style; RAG keeps the model untouched and feeds it facts at question time. For "answer from our documents", RAG is cheaper, updatable in minutes and does not forget — fine-tuning is rarely the right tool for that job.
Can it cite its sources?: Yes, and it should always be configured to. Each retrieved chunk knows which document and page it came from; a good implementation shows the citation next to the answer. Citations are what turn the system from a black box into something a colleague can verify.
How accurate is it, really?: On well-chunked, current documents, expect high precision on questions the material covers — with honest refusals on the rest. The failure you must design for is not wrong answers on covered questions; it is confident answers on uncovered ones, which is why the "say I don't know" behavior is a hard requirement, not a nicety.

// next steps

Working on something adjacent? Tell us about it — or read the services we deliver today.