RAG development that survives production
Make your own documents answerable — with retrieval tuned on your real content, citations on every answer, and evaluation that proves it works before your users test it for you.
every answer points at the passage it came from
- Document ingestion
- Retrieval tuning
- Cited answers
- Best when
- The answers live in documents people already trust, and every answer needs a source.
- Not a fit when
- The knowledge is in people's heads rather than in writing, or the corpus is a few pages.
- First thing you get
- Retrieval measured on your real documents, with a scored test set you keep.
What is retrieval-augmented generation (RAG)?
Retrieval-augmented generation (RAG) makes a language model answer from your own documents. At question time, the most relevant passages are retrieved from your content and given to the model, so answers are grounded in your data and cite their source. We build RAG systems tuned and evaluated on your real content, with permissions enforced at retrieval.
Retrieval-augmented generation demos beautifully and fails quietly. The demo uses ten clean documents. Production has forty thousand, half of them scanned PDFs, several contradicting each other, and three that nobody outside finance is allowed to see.
The hard parts of RAG are not the model. They are chunking strategy for your actual document shapes, retrieval quality you can measure, access control that survives the embedding layer, and knowing what the system should say when the answer genuinely is not in the corpus.
We build for those problems first, then connect the model. Every answer carries citations back to source, so a user can verify rather than trust.
What this includes
- 01
Document ingestion
Pipelines for the formats you actually have — PDFs, scans, spreadsheets, wikis, ticket histories.
- 02
Retrieval tuning
Chunking, embedding, hybrid keyword-plus-vector search, and reranking tuned against your own corpus.
- 03
Cited answers
Every response links back to the source passage, so users verify rather than take it on faith.
- 04
Permission-aware retrieval
Access control enforced at retrieval time, so the system cannot surface a document the user could not otherwise open.
- 05
Freshness handling
Incremental re-indexing so updated documents are reflected without a full rebuild.
- 06
Retrieval evaluation
A measured test set for answer quality, so changes are validated instead of guessed at.
Situations we see most often
Internal knowledge assistant
Staff ask questions in plain language and get cited answers from policies, SOPs, and past tickets instead of searching four systems.
Regulated document search
Controlled search across validation records, protocols, and audit documentation with permissions and traceability intact.
Customer support deflection
Answering common questions from real documentation, with a clear handoff when the corpus does not cover it.
Contract and document review
Extracting specific clauses and obligations across large document sets into structured, checkable output.
What to know before you start
RAG or fine-tuning: which do you need?
Use RAG when the model needs to know your facts: policies, product documentation, contracts, past tickets. Retrieval looks them up at question time, so answers stay current as documents change and every answer can cite its source.
Fine-tuning changes how a model behaves rather than what it knows: a house style, a fixed output format, a narrow classification task. It is a poor way to teach facts, because they go stale and cannot be cited. Most knowledge assistants need RAG alone; fine-tuning is occasionally added on top.
How is a RAG system evaluated?
With a test set built from real questions your users ask, each paired with the passage that should answer it. We measure whether retrieval finds the right passage, whether the answer is correct and faithful to it, whether the citation points to the right source, and how often the system correctly says it does not know.
The test set is yours to keep. Every change to chunking, ranking, prompts or models is scored against it before release, so quality is a number you can track rather than an impression from a demo.
How are document permissions enforced?
Each indexed passage carries the access rules of the document it came from. When someone asks a question, retrieval is filtered by that person's own identity and permissions before anything reaches the model, so a passage they could not open cannot inform their answer.
Permission changes in the source systems are synced to the index, so someone who loses access to a folder also loses it in the assistant. This has to be designed in from the first day; it cannot be bolted on once documents are embedded.
How does the system stay current as documents change?
Documents are re-indexed incrementally: new and edited files are picked up on a schedule or as they change, and deleted ones are removed, without rebuilding the whole index. Answers can show which version of a document they came from.
Where documents contradict each other, such as an old SOP and its replacement, we use metadata like dates and status to prefer the current one, and surface the conflict instead of blending the two.
What drives the cost of a RAG system?
The model is rarely the expensive part of RAG. Cost follows the state of your documents and how carefully access has to be controlled.
| Factor | Effect | Why it matters |
|---|---|---|
| Document formats and quality | High | Scanned PDFs, tables, forms and inconsistent layouts need OCR and format-specific chunking; clean text is far cheaper. |
| Permission model | High | Mirroring fine-grained access rules from several source systems, and keeping them in sync, is careful engineering. |
| Number of sources | Medium | Each connector, whether a drive, wiki, ticketing system or database, needs ingestion, metadata and change detection. |
| Evaluation set | Medium | A scored set of real questions and expected sources takes effort to build, and is what makes quality measurable. |
| Update frequency | Medium | Content that changes daily needs incremental indexing and conflict handling; a static archive does not. |
| Query volume and model | Medium | Running cost follows the number of questions and the model used; reranking and caching keep it in check. |
| Where it lives | Low | A chat interface in an existing tool is cheaper than a new standalone application. |
What a typical engagement looks like
- 011–3 weeks
Discover
Process map
- 022–4 weeks
Design
Interactive prototype
- 03two-week cycles
Build
Working software each cycle
- 04ongoing
Ship & support
Automated pipeline
What we build it with
- Vector stores
- pgvectorPineconeQdrant
- Retrieval
- Hybrid searchRerankersElasticsearch
- Models
- ClaudeGPTEmbedding models
Questions we get asked
01How do you stop the system inventing answers?
Three ways that work together: answers are grounded in retrieved passages with citations the user can check, the system is instructed and evaluated to say it does not know rather than guess, and we measure hallucination rate on a test set before launch rather than discovering it afterwards.
02Can it respect our existing document permissions?
Yes, and it must. Access control is enforced at retrieval time against the user's own permissions, so a document that a person cannot open cannot be surfaced to them through the assistant either.
03Does our data get used to train someone's model?
No. We use enterprise API tiers where inputs are not retained for training, and for particularly sensitive corpora we can deploy open-weight models inside your own infrastructure.
04How many documents can it handle?
Corpus size is rarely the limiting factor — retrieval quality is. Systems in the hundreds of thousands of documents are routine; what actually determines success is how well chunking and ranking suit your content.
05Can it answer questions about spreadsheets and tables?
Yes, with care. Tables are ingested with their structure intact so values stay attached to their headings. For real numerical analysis, such as totals or trends, the system queries the data directly rather than relying on retrieved text.
06Where can the assistant live?
Wherever your team already works: inside an existing internal tool or portal, a chat tool your team uses, or a standalone web app. The retrieval layer is the same in each case, so you can add interfaces later.
Adjacent capabilities
Further reading
Tell us what you are building.
Share the problem and we will come back with an approach, a rough shape of the work, and what it would take to deliver it.