RAG development that answers from your documents, with citations

Retrieval-augmented generation is a simple idea with a lot of engineering underneath: when a user asks a question, search your own content for the passages most likely to contain the answer, hand those passages to a language model together with the question, and have the model answer from them — quoting where it got each point. The model's job shrinks from 'know everything' to 'read these pages and answer', which is a job current models do very well. The knowledge stays in your documents, updates the moment a document changes, and can be shown to the user as a citation.

RAG is the right tool when the answers must be current, traceable and permissioned — policies, product documentation, contracts, engineering standards, support histories, regulatory circulars. It is the wrong tool for teaching a model a style or a format (that is fine-tuning), for reasoning over a handful of documents that fit in the model's context window (just send them), and for questions whose answer is a calculation over structured data (that is a query, and an agent that writes queries is the better fit). Most enterprise assistants end up as RAG at the core with one or both of the others around it, and we say so in the first week rather than after building the wrong one.

The assistant on this website is RAG in its smallest honest form. It answers from our case studies, services and team pages: a scoring function retrieves the four most relevant case studies for each question, they go into the prompt, and a hosted open model answers from them with instructions not to invent prices or timelines. There is no vector database, because for a corpus of a few hundred documents a scored keyword search is faster, cheaper and easier to debug. Retrieval should fit the corpus — that principle, applied to a corpus of two hundred thousand documents, is what the rest of this page is about.

The pipeline is the same in every RAG system we build: connectors pull documents from their sources and keep them in sync; a parser turns each into clean text with structure and metadata; a chunker splits it into passages sized for retrieval; an embedding model turns each passage into a vector; an index stores vectors and keywords side by side; at query time a retriever fetches candidates, a reranker orders them, and a generator writes the answer with citations; and an evaluation harness scores every stage. What differs is each choice inside it, and those are made on your data during the pilot, not copied from a tutorial.

Some of the choices that matter most: whether to keep tables and headings whole or split them (keep them, almost always); whether embeddings run on an open model in your environment or on an API (a data-residency decision first, a quality decision second); whether the index is Qdrant, pgvector on the PostgreSQL you already run, Elasticsearch if you already have it, or Chroma for a small deployment; whether a reranker is worth its latency (for most enterprise corpora, yes); and which model generates — Claude, GPT and Gemini through their APIs or in-region on Bedrock and Azure, or Llama, Qwen and Mistral on vLLM or Ollama when nothing may leave the building.

• Connectors — SharePoint, Confluence, Google Drive, S3, Liferay, ERPNext, Jira/ServiceNow, SQL databases, web crawls; incremental sync with deletions honoured
• Parsing — Docling for layout-aware PDF and Office parsing, OCR for scans, table extraction, language detection
• Indexing — hybrid vector + BM25, metadata filters, per-document ACLs stored with the chunks
• Retrieval — query rewriting, multi-query, reranking, parent-chunk expansion, source diversity
• Generation — grounded prompting, citations, refusal when unsupported, streaming, conversation memory
• Operations — evaluation harness, tracing, feedback capture, cost and latency dashboards, re-indexing jobs

When a RAG assistant gives a wrong answer, the model is usually blameless: the right passage was never retrieved, or it was retrieved along with six irrelevant ones and lost in the middle. So we treat retrieval as the product. Before the model is even connected we build a golden set with your subject-matter experts — a few hundred real questions with the documents and passages that answer them — and score retrieval on it: is the right passage in the top five, the top ten, at all? Every change to chunking, embeddings, filters or reranking is measured against that set, and the numbers go in the weekly report.

Only then do we measure the whole system: faithfulness (is every claim in the answer supported by a retrieved passage?), answer relevance (does it actually answer the question?) and context precision (how much of what was retrieved was needed?). We use an LLM judge for scale and human review for the cases that matter — regulatory answers, anything customer-facing — and we keep the golden set alive after go-live, adding the questions users actually ask and the ones the assistant got wrong. A RAG system without an evaluation set is a demo; the set is what turns it into something a compliance team will sign off.

In production, every question, retrieved passage, prompt and answer is traced, so when a user reports a bad answer we can see in seconds whether it was a parsing gap, a retrieval miss, a permission filter or the model — and fix that, not guess.

The first question a bank, hospital or government department asks about a RAG assistant is not accuracy but leakage: will it quote an HR document to someone who cannot open it? The answer has to be enforced at retrieval, not by asking the model to be discreet. We store each document's access list with its chunks, resolve the user's groups from your identity provider (Entra ID, Okta, Keycloak, LDAP) at query time, and filter the index before the model sees anything. Permission changes at the source propagate on the next sync, and the audit log records which passages were shown to whom.

Where the system runs is the second question. Our default for regulated clients is a deployment inside your cloud account or data centre — embeddings and the vector index on your infrastructure, and generation either on an open model served by vLLM or Ollama on your GPUs, or through an in-region managed endpoint such as Amazon Bedrock or Azure OpenAI with no training on your data. For Indian clients that keeps the corpus inside the country and inside the controls you already have for the Digital Personal Data Protection Act and sector regulators; for our GCC clients it keeps it in-Kingdom or in-country. PII redaction before indexing, prompt-injection guardrails on user input and on retrieved content, and topic restrictions on output are configured per deployment, not bolted on later.

Much of this work is the same data and permissions engineering we have done on document platforms for years. Engineers India Limited's 200,000-document engineering repository, with metadata classification, role-based access aligned to project hierarchies and Elasticsearch search that turned hours of retrieval into seconds, is exactly the kind of corpus a RAG assistant sits on top of — and the metadata and access model are most of the work.

As a guide from our engagements: a two-week discovery produces the use case, the source inventory, the golden question set and a costed plan; a pilot on one corpus and one user group takes four to six weeks and ends with measured retrieval and answer quality you can compare against the bar you set; and production — all sources, permissions, integration into the channel users live in (a portal, Teams, Slack, your app), monitoring and hand-over — is typically three to four months from kick-off. Adding sources or user groups afterwards is incremental work, because the pipeline is built for it.

Five things set the cost. The number and messiness of the sources — a clean SharePoint is one thing, twenty years of scanned PDFs another; the permission model, because per-document ACLs from three identity sources are real work; the quality bar and the languages it must hold in, which decide how much evaluation and tuning is needed; the hosting choice, where API models are cheap to start and self-hosted GPUs are cheaper at volume and mandatory for some data; and the integration surface — a chat box is quick, a copilot inside an existing workflow is not. Running costs are mostly model tokens or GPU hours plus the index, and we give you a per-question estimate during the pilot so the business case is arithmetic rather than hope.

Discovery is a fixed fee, the pilot is a fixed price, and production is a fixed price for the agreed scope with change control. We do not publish a rate card because a RAG system without a source inventory is a guess; tell us what you want it to answer and from what, and we will send a bracket within a week.

Policy and compliance assistants for banks and insurers — RBI and IRDAI circulars, internal policies and product manuals — that answer branch and operations staff with the clause cited, so the human check is a glance rather than a search. Engineering and standards repositories, where the question is 'which revision of which specification applies to this project' and the answer must be exact. Manufacturing SOPs, quality manuals and maintenance histories on the shop floor, in the language the operators speak. Clinical protocols and formularies for healthcare staff. Support and service desks that answer from resolved tickets and product documentation before a human picks up. And HR and IT self-service inside an intranet, which is where most organisations sensibly start.

In each case the assistant is a front end on the systems you already have — often a Liferay portal or an ERPNext instance we built or maintain — and the best deployments put the answer where the work happens rather than in a separate chat window. When the questions start to need action rather than answers — raise the ticket, draft the reply, run the report — the same retrieval layer becomes the knowledge behind an agent, which is the next page in our enterprise AI practice.