Enterprise Knowledge and Vector Search: retrieval your models and agents can trust

Retrieval-augmented generation exists because training a model to "know" an enterprise's current, proprietary knowledge is neither practical nor durable; the knowledge changes constantly, and retraining is slow and expensive. Vector search solves this by embedding content into a form a model can search semantically at inference time, but the architecture question that actually determines whether this works safely in an enterprise is rarely the choice of vector database; it is whether the index inherits the access controls the data layer already enforced, and whether retrieval quality is good enough that the model is grounded rather than merely supplied with noise.

Many first-generation RAG deployments treat retrieval as a solved problem once documents are embedded and indexed, and discover in production that retrieval quality (irrelevant or incomplete results) or, more seriously, access-control gaps (a user's query surfacing a document they were never permitted to read) undermine the system's reliability and, in regulated settings, its compliance posture.

This layer consumes governed, quality-checked data from Layer 04 and serves retrieval results to Layer 07 (AI Platforms), Layer 08 (LLM Engineering, specifically RAG pipelines) and Layer 09 (AI Agents, for knowledge-grounded tool use). Its access-control model must be a direct extension of Layer 04's, not a parallel, independently maintained permission system that drifts out of sync.

Embedding generation and management; vector indexing and approximate nearest-neighbour search; hybrid retrieval (combining vector similarity with keyword/metadata filtering); reranking; knowledge graph integration for structured relationship retrieval; access-controlled, permission-aware retrieval; index freshness and update pipelines.

Milvus is a purpose-built, open-source vector database designed for large-scale, high-performance similarity search, well suited to enterprises with substantial engineering resources wanting full control and self-hosting. Pinecone is a managed vector database service, favoring speed to production and reduced operational burden, at the cost of self-hosting control that sovereignty-constrained deployments may require. Weaviate combines vector search with a native object/graph data model and hybrid search capability, useful where retrieval needs to combine semantic similarity with structured filtering in one system. Qdrant is a performance-focused, open-source vector database with strong filtering capability, often selected for latency-sensitive, self-hosted deployments. pgvector extends PostgreSQL with vector search capability, the pragmatic choice for organizations that want to avoid operating a separate specialized database and can accept its scale and performance ceiling relative to purpose-built vector engines. The selection criterion is rarely raw benchmark performance in isolation; it is self-hosting requirement (driven directly by Layer 01 sovereignty commitments), existing data platform investment (pgvector is compelling specifically where Postgres is already the system of record), and query pattern (pure semantic search versus hybrid search requiring structured filtering and, increasingly, multitenancy-aware isolation between customers or business units sharing one index).¹

Managed (Pinecone) versus self-hosted (Milvus, Qdrant, Weaviate, pgvector) is, again, largely a sovereignty and control decision before it is a performance decision. Purpose-built vector engines versus a vector extension to an existing database (pgvector) trades peak performance and feature depth against operational simplicity and reduced system count. Pure vector similarity versus hybrid retrieval (vector plus keyword and metadata filtering, often with a reranking step) trades implementation simplicity against retrieval precision, and hybrid retrieval with reranking is now the practical baseline for enterprise-grade RAG rather than an advanced optimization.

Access-controlled retrieval that enforces the same permission model as the source data, evaluated per query, not per index build; encryption of embeddings and metadata at rest and in transit; audit logging of what was retrieved for which query, sufficient to reconstruct why a model produced a given answer; index freshness monitoring so retrieval does not silently serve stale content after a source document changes or is deleted; and retrieval quality evaluation (precision/recall against a labeled test set) as an ongoing operating discipline, not a one-time acceptance test.

Discover (knowledge sources, access-control requirements, query patterns); architect (vector database selection, hybrid retrieval and reranking design, access-control integration); prototype (retrieval quality validated against representative queries and a labeled evaluation set); industrialize (index update pipelines, monitoring, access-control testing); deploy; govern (ongoing access and content review); operate (index freshness, performance); optimize (retrieval quality tuning based on production query analysis).

Financial services and government use cases frequently require the strictest access-controlled retrieval, since document sets often mix public, internal and highly restricted material within the same corpus. Healthcare and life sciences retrieval systems must respect patient-data and research-data access boundaries with particular care. Universities and research institutions often benefit most from knowledge-graph-augmented retrieval, where relationships between entities (researchers, grants, publications) matter as much as document similarity.

Retrieval precision and recall against a labeled evaluation set; access-control violation rate (target: zero, continuously tested); index freshness lag; end-to-end grounded-answer accuracy as measured by the evaluation framework at Layer 08.

Building a vector index without carrying forward the source system's access controls; treating retrieval quality as solved once a demo works well on a handful of hand-picked queries; choosing a vector database purely on a marketing benchmark without testing against the organization's actual query and content patterns; and neglecting index freshness, so a retrieval system continues surfacing documents that have since been corrected, deleted or reclassified.

Scignal designs retrieval architecture as a direct, tested extension of the access controls and quality discipline established at Layer 04, on infrastructure CoralDC provisions to keep sensitive indices inside the required sovereignty boundary.