We design and build retrieval-augmented generation systems that read your SharePoint, Confluence, ticketing and databases, respect who may see what, and cite every answer.
Organisations whose knowledge is spread across too many systems
A proof of concept over a folder of PDFs is a weekend's work. An enterprise knowledge base is a different problem: dozens of sources, changing content, permissions, and users who will stop trusting the system after one confident wrong answer.
Enterprise RAG is the right fit when people already spend hours a week searching, re-asking colleagues, or rewriting answers that exist somewhere. It suits support organisations, engineering teams with large runbooks, regulated firms with policy libraries, and professional services firms with precedent archives. If you want the background first, read RAG explained.
Outcomes we design for
Answers grounded in your documents, each with a clickable source
Users only ever see content they are already allowed to open
New and changed documents searchable within minutes to hours
Measured retrieval and answer quality on every release
Predictable monthly cost, with a model you can swap later
A system your own team can operate after handover
Reference architecture
Security controls at every hop, not bolted on at the end
Each stage in the request path owns one control, and the ingestion path feeds the index with permissions already attached.
Request path (top) and ingestion path (bottom). Permissions are attached at chunk time and enforced inside the retrieval query, so forbidden content never reaches the prompt. Every answer is logged with its sources for evaluation.
Three design decisions in this picture do most of the work. First, the access-control filter runs inside the vector query, so the index returns only chunks the user may read. Second, the model gets no tools by default; it answers from the supplied context and nothing else, which keeps prompt injection contained. Third, output checks reject any factual answer without a source. We cover the threat model in depth on the secure RAG architecture page.
What we deliver
Six components, each handed over with code, tests and runbooks
Ingestion pipeline
Connectors with incremental sync, layout-aware parsing, structure-preserving chunking and permission capture. Re-runs are idempotent, so a failed sync never leaves half an index.
Retrieval service
Hybrid search (keywords plus vectors), metadata filters, reranking and query rewriting behind one API. Tuned on your labelled question set, not on defaults.
Prompting and guardrails
Versioned prompts, context budgeting, refusal rules for out-of-scope questions, injection screening and PII handling. Every rule has a test that fails if it is removed.
Evaluation harness
A question set written with your experts, scored for retrieval hit rate, groundedness and answer quality. Runs in CI, so a prompt or model change cannot ship a regression.
Observability and admin
Traces per answer, cost per query, unanswered-question reports and a content-gap view for knowledge owners. Built on the practices in LLMOps and monitoring.
Handover and enablement
Architecture notes, runbooks, a content-owner guide and two to four weeks of paired operation. Your team runs it; a support retainer is optional.
Ingestion connectors
Sources we connect in a typical enterprise build
Every connector pulls content, metadata and permissions, and resyncs on a schedule or a webhook. Where an API is missing or slow, we fall back to exports with change detection.
SharePoint and OneDriveGoogle DriveConfluenceZendeskSalesforce KnowledgeServiceNowNotionJiraSlack and Teams exportsPostgreSQL, MySQL, SQL ServerPDF, DOCX, PPTX, XLSXScanned documents (OCR)Websites and intranetsEmail archives
Structured sources such as CRM records and database tables are handled differently from documents. We generate natural-language summaries of rows for retrieval and keep a path to the live record, so the answer can quote a current value rather than a stale embedding. The AI data engineering page describes the pipelines behind this.
Design choices
Chunking, reranking and evaluation: what we pick and why
These three decisions determine most of the retrieval quality. We make them from measurements on your content, then revisit them when the evals say so.
Decision
Options
When we use it
Trade-off
Chunking
Fixed windows with overlap
Uniform prose such as manuals and articles
Cheap and predictable; splits tables and lists mid-way
Chunking
Structure-aware (headings, sections, pages)
Policies, contracts, wikis with clear hierarchy
Better citations; needs a parser that keeps layout
Chunking
Parent–child (small chunks, large context)
Long documents where the answer needs surrounding text
Higher recall; more tokens per answer
Reranking
None (vector top-k only)
Small corpora, latency-critical paths
Fastest; weakest precision on ambiguous queries
Reranking
Cross-encoder reranker over 30–100 candidates
Most enterprise corpora
Large precision gain; adds a model call per query
Reranking
LLM-based relevance scoring
High-value, low-volume questions
Best judgement; slowest and most expensive
Evaluation
Retrieval metrics (hit rate, MRR)
Every build, from week one
Objective and cheap; says nothing about the final answer
Evaluation
LLM-as-judge groundedness and completeness
Every release, on the labelled set
Scales well; needs calibration against human scores
Evaluation
Expert review of sampled answers
Launch and quarterly
Gold standard; slow, so used sparingly
If you want the vocabulary behind this table, the glossary entries on chunking and reranking are short. Our hybrid search page explains why keywords still matter alongside vectors.
How we work
From content audit to a measured production release
Discover and audit
Two to three weeks. We map sources, owners, permissions and the top questions people actually ask. Output: a scoped backlog and a go or no-go on each source.
Build the question set
Your experts write 100–300 questions with ideal answers and sources. This becomes the evaluation harness every later change is measured against.
Ingest and retrieve
Connectors, parsing, chunking and hybrid retrieval, tuned until retrieval metrics plateau. Vector store chosen with our selection guide.
Generate and guard
Prompts, citations, refusal rules, injection and PII controls. Output checks wired to the evaluation harness so a regression blocks the release.
Pilot, launch, hand over
A pilot group uses it for two to four weeks while we fix the gaps the logs reveal. Then launch, runbooks and paired operation with your team.
Service goals we design to (agreed per project, not guarantees)
Answer latency measured at the 95th percentile and kept within a few seconds for the common path. Freshness: a changed document searchable within minutes for webhook-driven sources and within hours for scheduled ones. Citation rate: every factual answer carries at least one resolvable source, or the system declines. Quality: retrieval hit rate and groundedness scored on the labelled set on every release. Actual targets go into the statement of work once we have seen your content.
What goes wrong
Why enterprise RAG projects stall, and how this plan avoids it
Indexing everything on day one, including duplicates and retired pages, so the best answer is buried
Skipping permissions in the pilot and discovering the rework when legal asks
Judging quality by demo questions instead of a labelled set
Choosing a vector database before measuring scale, filtering and hosting needs
Treating the model as the product and retrieval as plumbing
A focused first release usually takes 8–14 weeks: two to three weeks of discovery and content audit, then build in two-week sprints with an evaluation gate before launch. The number of connectors and the complexity of permissions move the range far more than document volume does. Ask for a scoped estimate.
Which language model do you use for RAG?
We are model-agnostic. Claude, OpenAI, Gemini or open-weight models such as Llama and Mistral can all sit behind the same retrieval layer. Retrieval quality decides most of the outcome, so we fix retrieval first and keep the model behind an abstraction you can swap. See LLM app development.
Can RAG respect our document permissions?
Yes, and it must. We attach access-control metadata to every chunk at ingestion and apply the user's identity as a filter inside the vector query, not after it. The internal copilot page explains the mechanism.
Do we need to fine-tune a model as well?
Rarely for knowledge tasks. Fine-tuning changes how a model writes, not what it knows, and it goes stale as content changes. We recommend it only when evals show a style or format gap that prompting cannot close. See fine-tuning and evals.
How do you prove the answers are correct?
With a labelled question set built with your experts, scored for retrieval hit rate, groundedness and answer quality on every release. Nothing ships if a score regresses. Our guide to evaluating LLM outputs covers the method.
Where does our data live?
In your tenant or VPC. Vectors sit in PostgreSQL with pgvector or Milvus under your control, and model calls can go to a regional endpoint or a self-hosted open-weight model. Our AI data privacy page sets out the options.
Ready to make AI work in production?
Tell us about your systems, your data and your constraints. We reply within one business day with a straight answer and a suggested next step.