Enterprise Knowledge Systems: Knowledge Graphs, Vector Databases, GraphRAG, and Governed AI

The wrong argument

Since Microsoft Research published GraphRAG in April 2024, many enterprise AI roadmaps have acquired a line item for a knowledge graph. Vendors of graph databases, vector databases and search engines each argue that their engine is the natural home for enterprise knowledge. The debate is usually framed as a technology choice.

Our argument is that the technology choice comes third. First, classify the questions users actually ask. Second, check whether the entities those questions are about already exist, curated, in systems of record. Only then pick the store. Most enterprises will find that the bulk of their questions are answered well by hybrid search over well-chunked documents, that a small set of high-value questions genuinely needs a graph, and that the cheapest good graph is the one assembled from master data and existing relationships rather than extracted from text by a language model.

There is a fourth point that matters more than the other three in regulated organizations. Every knowledge system makes copies: chunks, embeddings, extracted entities, community summaries. Each copy must carry the classification, permissions and lineage of the record it came from. A knowledge graph that summarizes ten restricted documents into one unrestricted node is a data leak with good recall.

Three ways to represent enterprise knowledge

The three approaches store different things and answer different questions.

Vector indexes store embeddings of text passages and find passages whose meaning is close to the question. They need no schema, ingest anything, and are strong at "find me the part of the policy that covers this". They are weak at questions whose answer is spread across many documents, and at exact constraints such as part numbers, dates or names, which is why production systems combine them with keyword search. The BEIR benchmark, published at NeurIPS 2021, found BM25 keyword ranking to be a strong zero-shot baseline across 18 datasets, while dense retrievers often underperformed other approaches on unfamiliar domains.

Knowledge graphs store entities and typed relationships: this supplier provides that component, which is used in this product, which is governed by that regulation. They are strong at questions that follow relationships across several steps, at questions about a specific entity and everything connected to it, and at enforcing the same identity for "Saudi Aramco", "Aramco" and "أرامكو". Google popularised the idea for search in 2012, launching its Knowledge Graph with more than 500 million objects and 3.5 billion facts, drawing on curated public sources such as Freebase, Wikipedia and the CIA World Factbook rather than on free-text extraction alone. The standards are mature: RDF and SPARQL at the W3C, with RDF 1.2 at Candidate Recommendation in April 2026, and ISO/IEC 39075 GQL for property graphs, published in April 2024 as the first new ISO database query language since SQL.

GraphRAG and its relatives use a language model to build a graph from unstructured text, then use the graph during retrieval. Microsoft's version extracts entities and relationships from every chunk, clusters the graph into hierarchical communities and pre-writes a summary of each community. That last step is what lets it answer questions about a whole corpus.

What the evidence says about GraphRAG

The GraphRAG paper by Edge and colleagues is specific about what it tested. It targeted global sensemaking questions, such as "what are the main themes across these transcripts", which conventional retrieval handles badly because no single passage contains the answer. On two corpora of roughly one million and 1.7 million tokens, a podcast transcript set and a news dataset, GraphRAG's answers beat a vector RAG baseline on comprehensiveness in 72 to 83 percent of head-to-head comparisons, and on diversity in 62 to 82 percent, with an LLM acting as the judge.

Three qualifications matter for enterprise use.

1. It was a test of global questions. The authors say their evaluation covered sensemaking questions on two corpora of about a million tokens each, and that generalization to other domains needs more work. It is not evidence that graphs improve ordinary lookup questions.
2. Independent comparisons are mixed. A 2025 systematic evaluation by Han and colleagues compared RAG and GraphRAG on standard question-answering and summarization tasks and found that each wins on different task types, with the best results from routing between them or combining them.
3. Other graph methods target other question types. HippoRAG, presented at NeurIPS 2024, uses a knowledge graph and Personalized PageRank for multi-hop questions, reporting gains of up to 20 percent over prior methods and single-step retrieval 10 to 30 times cheaper than iterative retrieval. "Graph-based retrieval" is a family of techniques, not one product.

The best-documented enterprise deployment is not a corpus-summary use case at all. LinkedIn's customer service team built a knowledge graph from historical support tickets, keeping each ticket's internal structure and the links between related tickets, and used it for retrieval. Their SIGIR 2024 paper reports a 77.6 percent improvement in mean reciprocal rank over a text-only baseline and a 28.6 percent reduction in median per-issue resolution time after about six months in use. The graph worked because tickets are entity-centric, structured and linked, which is the profile to look for.

What graphs cost to build and keep

The paper's indexing run on the podcast corpus took 281 minutes using GPT-4-turbo, producing 8,564 nodes and 20,691 edges from about one million tokens. Every chunk passes through the model at least once to extract entities and relationships, again to summarize each entity and relationship, and again to summarize each community. Microsoft's own repository warns that indexing "can be an expensive operation" and tells users to start small.

Microsoft Research's follow-up, LazyGraphRAG, published in November 2024, is the clearest statement of the trade-off. It defers language-model work to query time and reports indexing costs identical to vector RAG and 0.1 percent of full GraphRAG's, with comparable quality on global questions at more than 700 times lower query cost than GraphRAG's global search. As of 23 July 2026, the open-source GraphRAG repository describes itself as a demonstration, not an officially supported Microsoft offering, and as largely in maintenance mode. Teams that adopted it as a platform should plan accordingly.

The larger cost is not tokens. It is maintenance:

• Entity resolution. An LLM extracting entities from text will create "Ministry of Health", "MoH" and "وزارة الصحة" as three nodes unless something reconciles them. In bilingual Gulf organizations this is the main source of graph quality problems. Master data already solves it for customers, suppliers, products and sites.
• Refresh. When a document changes, its extracted entities, their summaries and every community summary that included them may be stale. Full re-indexing is expensive; incremental updates are hard to get right.
• Schema drift. Free extraction produces whatever relationship types the model invents. Without an ontology, the graph becomes hard to query and impossible to govern.

INVISOM analysis: this is why we recommend building the first graph from structured sources (master data, reference data, the CMDB, contract and asset registers, the org chart) and using LLM extraction only to attach documents and passages to entities that already exist. That gives a graph with stable identities and known lineage at a fraction of the cost, and LLM extraction becomes an enrichment step rather than the foundation.

Choosing where vectors live

For the vector side, there are three families, and the choice is mostly about where your data and operations already are.

pgvector illustrates how far the general-purpose route now goes. As of version 0.8 it supports HNSW and IVFFlat indexes, half-precision, binary and sparse vectors, six distance functions, and iterative index scans that keep returning results when a metadata filter removes candidates, which matters directly for permission filtering. OpenSearch offers vector search through Faiss and Lucene engines, hybrid lexical and vector queries, and filtering in the same request.

Our view is that the default should be the store your organization already operates, secures and backs up, unless measured scale or latency says otherwise. A new database is a new place where permissions can drift from the source.

Governance: permissions, provenance and lineage

The governance problem is the same for graphs and vectors, and it is sharper than in a data warehouse because the transformations are probabilistic and the outputs are copies.

Access control must be enforced at retrieval, from the source. The OWASP 2025 Top 10 for LLM applications lists vector and embedding weaknesses as a distinct risk, including unauthorized access through weak access controls and leaks between tenants or groups, and recommends permission-aware vector stores with strict partitioning. In practice that means each chunk, node and edge carries the access-control list or classification of its source record, and every query filters on the requesting user's entitlements before results reach the model.

Derived artefacts inherit the strictest source. A community summary, an entity description merged from several documents, or a cached answer is only as open as the most restricted input it used. Few toolkits enforce this by default; it has to be designed in.

Embeddings are not anonymization. Morris and colleagues showed at EMNLP 2023 that text can be reconstructed from embeddings, recovering 92 percent of 32-token inputs exactly and extracting full names from clinical notes. Treat a vector index as holding the same data as its source, with the same classification and residency obligations.

Provenance must reach the answer. Every passage, node and relationship should record the source document, version, extraction method and date, so an answer can cite its sources and a reviewer can trace a wrong answer back to a wrong document or a wrong extraction.

Retrieved content is untrusted input. Greshake and colleagues demonstrated in 2023 that instructions planted in documents an AI system retrieves can steer its behaviour. Ingestion pipelines that feed a knowledge base from email, tickets or the web need the same scrutiny as any other untrusted input.

For Saudi public entities and their suppliers, this maps directly onto the NDMO standards: every dataset receives an impact-based classification of Top Secret, Secret, Confidential or Public, recorded as metadata. That label has to follow the data into chunks, embeddings and graph nodes, and the vector store and graph have to be in the residency scope that the source classification requires. Our guide to the NDMO standards covers the classification method.

A decision table

What to do in the next 90 days

1. Log real questions. Collect 200 to 500 questions from users or pilot logs and tag each with the pattern from the table above. The distribution decides the architecture.
2. Fix hybrid retrieval first. Measure keyword-plus-vector search with reranking on the logged questions before building any graph. It sets the baseline any graph must beat.
3. Build the first graph from master data. Use entities and relationships you already govern, then attach documents to them. Defer free LLM extraction.
4. Pilot GraphRAG-style indexing on one bounded corpus where global questions recur, and record indexing cost, refresh cost and answer quality against the baseline.
5. Carry permissions into every artefact. Put source ACLs and classification on every chunk, node and summary, and filter before generation. Test it with users of different entitlements.
6. Record provenance and lineage from source document to answer, and require citations in the user interface.
7. Use the store you already run unless measured scale says otherwise, and put any new store through the same security review as the source systems.

For the related choice between retrieval and changing the model itself, see RAG, fine-tuning, continued pretraining or a custom LLM. For the platform underneath, see data warehouse, lake, lakehouse or mesh.

Frequently asked questions

Do I need a knowledge graph for enterprise RAG?

Usually not to start. Most enterprise questions are answered by hybrid keyword and vector search over well-prepared documents. A graph earns its cost for multi-hop, entity-centric or corpus-wide questions, and is cheapest when built from master data you already govern.

Is GraphRAG better than vector RAG?

For global sensemaking questions over a corpus, Microsoft's evaluation found GraphRAG answers more comprehensive and diverse. For ordinary lookup questions the evidence is mixed, and independent studies find each approach wins on different tasks. Routing between them works best.

How expensive is GraphRAG indexing?

Full GraphRAG passes every chunk through a language model several times to extract and summarize entities and communities. Microsoft's own repository warns it can be expensive. Microsoft Research reports that LazyGraphRAG indexing costs about 0.1 percent of full GraphRAG.

Should I use pgvector or a dedicated vector database?

Start with the database or search engine you already operate and secure, unless measured scale or throughput requires otherwise. pgvector and search engines with vector support cover many enterprise workloads, and fewer copies of sensitive data mean fewer places for permissions to drift.

Sources and further reading

• From Local to Global: A Graph RAG Approach to Query-Focused Summarization, Edge et al., Microsoft Research, April 2024, revised February 2025.
• LazyGraphRAG: Setting a new standard for quality and cost, Microsoft Research, 25 November 2024.
• GraphRAG repository, Microsoft. Cost warning and project status, accessed 23 July 2026.
• RAG vs. GraphRAG: A Systematic Evaluation and Key Insights, Han et al., 2025.
• HippoRAG: Neurobiologically Inspired Long-Term Memory for Large Language Models, Gutiérrez et al., NeurIPS 2024.
• Retrieval-Augmented Generation with Knowledge Graphs for Customer Service Question Answering, Xu et al., LinkedIn, SIGIR 2024.
• Introducing the Knowledge Graph: things, not strings, Google, 16 May 2012.
• BEIR: A Heterogenous Benchmark for Zero-shot Evaluation of Information Retrieval Models, Thakur et al., NeurIPS 2021.
• pgvector, pgvector project. Index types, vector types and filtering, accessed 23 July 2026.
• Vector search, OpenSearch documentation.
• RDF 1.2 Concepts and Abstract Syntax, W3C Candidate Recommendation Snapshot, 7 April 2026.
• GQL: A New ISO Standard for Querying Graph Databases, The New Stack, 2024.
• LLM08:2025 Vector and Embedding Weaknesses, OWASP GenAI Security Project.
• Text Embeddings Reveal (Almost) As Much As Text, Morris et al., EMNLP 2023.
• Not what you've signed up for: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection, Greshake et al., 2023.
• Data Management and Personal Data Protection Standards, Version 1.5, National Data Management Office, SDAIA.