Most enterprise RAG systems are built on naive vector search. A question is embedded. The embedding is compared to the embeddings of every chunk in the index. The closest chunks are returned. The language model synthesises an answer.

This architecture works well for specific factual lookups: "What is the termination clause in the ACME contract?" It fails for cross-document synthesis: "Which contracts have termination clauses that conflict with our standard liability limits?" For that, you need a knowledge graph.

Naive vector search retrieves text that is semantically similar to the query. That is a powerful capability - but it has a characteristic failure mode: it can only retrieve content that closely resembles the query in embedding space. Information that is relevant but not similar in language gets missed.

Failure mode 1: Cross-document questions "What were the total contract values across all customers acquired through our EMEA reseller programme in 2024?" No single contract contains this information. The answer requires aggregating across dozens of contracts - none of which individually scores highly against the query embedding.

Failure mode 2: Entity-centric questions "What is the relationship between Hoffman Partners and NovaTech Solutions?" The documents that answer this might use different names (Hoffman, Hoffman LP, the reseller), different relationship descriptions, and different contexts across hundreds of documents. Vector search returns documents that mention both names, but may not surface the specific relationship context.

Failure mode 3: Relationship traversal "Which suppliers are also customers?" A question that requires traversing a relationship (supplier → company → customer) cannot be answered by matching any single chunk against the query - the answer requires joining across entity relationships.

Failure mode 4: Taxonomy-sensitive questions "What AI regulations apply to our credit scoring models?" The relevant regulations apply to "AI systems in credit assessment" - a category that requires knowing that a credit scoring model is an AI system in credit assessment. Vector search matches the words; a knowledge graph matches the concepts and their categories.

A knowledge graph built from your document corpus captures what is in your documents - not as floating text chunks, but as a structured web of entities and relationships.

Entity extraction: During indexing, an AI model reads each document and extracts:

• Named entities: people, organisations, products, locations, dates, amounts
• Entity types: customer, supplier, regulation, contract, clause, obligation
• Entity attributes: a "Contract" entity has a value, a start date, an end date, parties involved

Relationship extraction: The model also extracts the relationships between entities:

• Company A is a customer of Company B
• Regulation X applies to AI system type Y
• Contract C contains Clause D
• Person E is responsible for Project F

The resulting graph can answer questions that require traversal: "which customers are also affected by Regulation X?" → traverse from Regulation X to AI system types it applies to → traverse from AI system types to deployments → traverse from deployments to customer relationships.

Community detection: Graph analysis algorithms (e.g., Leiden clustering) identify communities of densely connected entities - thematic clusters that answer questions about "what is this document corpus about" and enable global summarisation across a corpus.

Hybrid retrieval combines both approaches at query time:

Step 1: Parallel retrieval The query is embedded and matched against the vector index (top-k chunks by cosine similarity). Simultaneously, the query is parsed for entity mentions, and the knowledge graph is queried for relevant entities and their relationships.

Step 2: Graph expansion For each entity found in the graph, the system expands to include:

• Direct relationships (one hop)
• Entity community context (the thematic cluster this entity belongs to)
• Entity descriptions synthesised from the full document corpus

Step 3: Context assembly Chunk results and graph context are assembled into a structured context block passed to the language model. The model knows which parts are retrieved text chunks and which are graph-derived entity summaries.

Step 4: Generation The language model synthesises an answer using both chunk context and graph context. For relationship questions, it primarily uses graph context; for specific factual questions, it primarily uses chunk context.

The result: hybrid retrieval answers the 30-40% of enterprise queries that naive vector search cannot - cross-document synthesis, entity-centric questions, relationship traversal, and taxonomy-sensitive lookups.

A knowledge graph introduces security challenges that do not exist in pure vector search:

Entity access control: An entity in the knowledge graph might be derived from documents that different users have different access to. "NovaTech Solutions" might appear in a public press release (accessible to all) and in a confidential acquisition term sheet (accessible only to M&A team). The entity in the graph should only expose the attributes and relationships that the querying user has access to.

Relationship visibility: A relationship between entities might be sensitive independently of the entities themselves. The relationship "Company A was acquired by Company B" might be derived from a confidential board document. Even if both company names are publicly known, the relationship should only be surfaced to users with access to the source document.

Graph poisoning: If an attacker can write to the knowledge base (or if document ingestion is not sufficiently controlled), they can introduce false entities or relationships that corrupt the graph. Access control on ingestion is as important as access control on retrieval.

Inference attacks: A user who cannot directly access a document might be able to infer its contents by querying the knowledge graph. If the graph exposes the relationship "Contract C has clause type: force majeure" and the user knows Contract C involves Supplier X, they have indirectly learned that Supplier X's contract contains a force majeure clause - even if they cannot read the contract itself.

The secure pattern for enterprise knowledge graph access control:

Entity-level ACL: Each entity in the graph carries the access metadata of the documents it was derived from. If an entity was derived from multiple documents with different access levels, it carries the most restrictive level (or the union of all access groups, depending on your policy).

Relationship-level ACL: Each relationship carries the access metadata of the document that asserted it. A relationship visible only to the M&A team is not exposed to other users, even if both endpoint entities are visible.

Query-time filtering: Graph traversal applies access filters at each hop. When traversing from Entity A to its relationships, only relationships the querying user is authorised to see are returned. This prevents leaking restricted relationships through an allowed entity.

Inference risk mitigation: Consider whether entity-level visibility creates unacceptable inference risk. In high-security environments, restricting knowledge graph access to users who have read access to at least one source document (rather than exposing entity names globally) reduces inference exposure.

On Aicuflow, the full pipeline - document ingestion, entity extraction, knowledge graph construction, access-controlled hybrid retrieval - is configured visually without writing graph traversal code.

Ingestion: Connect document sources. Aicuflow reads access permissions from the source system (SharePoint groups, Google Workspace sharing settings, Confluence space permissions).

Entity extraction: During indexing, Aicuflow's built-in entity extractor identifies named entities, entity types, and relationships. The extraction is configurable - you can specify entity types relevant to your domain (e.g., "Contract", "Obligation", "Party" for a legal use case).

Graph construction: Entities and relationships are stored in a graph database with the access ACLs from the source documents attached to each node and edge.

Hybrid retrieval: Four retrieval modes are available: naive (vector only), local (vector + graph expansion), global (graph-first), and hybrid (adaptive combination). For production enterprise RAG, hybrid is the default recommendation.

Access enforcement: Every retrieval query applies the querying user's group memberships as a filter, applied within the graph traversal - not as a post-processing step.

The result: a RAG system that answers both simple factual questions and complex cross-document queries, with consistent access control applied at every layer.