Enterprise RAG: the production pattern where the LLM grounds every answer on your corpus, with citations.

Retrieval-Augmented Generation is the dominant production pattern for enterprise LLM use. At ingestion time, documents are chunked, embedded as vectors and stored in a vector database. At query time, the user's question is embedded, the nearest chunks are retrieved, and the LLM is prompted to answer using the retrieved context. The architectural payoff: the LLM's knowledge stays current (re-ingest to refresh), domain-specific (choose what to ingest) and traceable (the answer cites the chunks it grounded on).

Three reasons. (1) Freshness — RAG knowledge updates with a re-ingestion job; fine-tuning requires a new training run. (2) Auditability — every RAG answer cites the chunks it grounded on, so the regulator can replay the answer chain; fine-tuned knowledge is opaque inside the weights. (3) Cost — building and operating a RAG pipeline is cheaper than running periodic fine-tuning at quality parity, particularly for the common case of "the model needs to know our policies and documents" rather than "the model needs to adopt a specific output format or voice." Fine-tuning earns its keep on the format/voice problem; RAG wins on the knowledge problem.

Layer 1 — ingestion and chunking: parsers for the customer's document types, chunking strategies tuned per type, metadata extraction. Layer 2 — embedding and storage: a sovereign-deployable embedding model (nomic-embed-text or BGE-M3), a vector database (pgvector under 10M chunks, Qdrant for 10–100M, Milvus beyond). Layer 3 — retrieval: hybrid dense plus BM25 search, a cross-encoder re-ranker, optional query expansion or HyDE. Layer 4 — generation: the LLM, the prompt template, the response post-processing including citation insertion and PII guardrails.

Six common failure modes. (1) Naive chunking — fixed-size character splits break sentences and drop semantic boundaries. (2) No hybrid retrieval — pure dense retrieval misses rare entities and exact-match queries. (3) No re-ranking — top-K retrieval surfaces relevant-but-not-best chunks, the LLM grounds on weak context. (4) Stuffed context — teams assume more chunks is better; quality typically degrades past 5–8 chunks due to the lost-in-the-middle effect. (5) No eval suite — quality regressions ship to production undetected. (6) No incremental ingestion — every corpus update is a full re-embed.

Yes — and for regulated industries this is the default deployment model. MindMap Digital's sovereign RAG stack runs entirely inside the customer's perimeter: embedding model on customer GPUs, vector database in customer Kubernetes, LLM serving via vLLM on customer GPUs, retrieval API as a customer-namespace service. Network egress is blocked at the namespace level. Every retrieval and every model call streams into the customer's SIEM. The compliance posture matches the customer's sovereign LLM serving layer because they share the same cluster.

Four metrics, scored against a customer-built eval set on every change. Context precision — what fraction of retrieved chunks are relevant. Context recall — what fraction of the relevant chunks in the corpus were retrieved. Answer faithfulness — does the answer actually ground on the retrieved context or hallucinate. Answer relevance — does the answer actually address the user's question. The open-source RAGAS framework computes all four; MindMap deploys it inside the perimeter alongside Langfuse for production observability. The gating rule: no merge if any metric regresses below the customer's acceptance threshold.

MindMap Digital's standard sovereign RAG deployment is 6–9 weeks from contract to production for a first corpus. Week one: corpus inventory and chunking-strategy design. Weeks two to three: stack deployment (embedding model, vector DB, retrieval API, eval harness). Weeks four to five: corpus ingestion, eval build, retrieval tuning. Weeks six to seven: end-to-end pilot with hypercare. Weeks eight to nine: phased rollout. Subsequent corpora on the same platform deploy in two to three weeks because the infrastructure, identity integration and eval framework are already in place.

For embedding: nomic-embed-text for English-primary corpora, BGE-M3 for multilingual workloads — both open-weights and locally deployable. For re-ranking: bge-reranker-v2-m3, runs on CPU for low-traffic deployments, on a small GPU at production scale. For generation: Llama 3.3 70B or Qwen 2.5 72B for high-quality general workloads, Llama 3.3 8B or Mistral 7B for high-throughput specialised workloads, all served via vLLM. We deliberately choose open-weights at every layer — closed-source frontier APIs cannot be deployed on-prem and are therefore ruled out for sovereign-mandated buyers.