Knowledge graphs and GraphRAG: when relationships matter more than similarity

01

What is a knowledge graph, and how does it differ from a document collection?

A knowledge graph stores entities as nodes and relationships as named edges, for example "pump contains seal". A document collection stores text in which such relationships only appear implicitly. The graph makes connections directly queryable, even across several steps. In exchange, someone has to define which kinds of things and relationships exist, and keep the data current.

A search system over documents works with passages of text. It finds the passage stating that a seal comes from Supplier A, and a separate passage stating that pump P200 contains that seal. The question "Which pumps are affected if Supplier A fails?" requires connecting both passages. A knowledge graph holds exactly that connection as a stored fact.

The survey by Hogan and others (ACM Computing Surveys, 2021) covers knowledge graphs across data models, query languages, schema and knowledge extraction, and distinguishes open graphs such as Wikidata from enterprise-internal ones. Knowledge management with AI places knowledge graphs within the bigger picture of knowledge management.

02

RDF or property graph: which graph model fits which purpose?

RDF, the W3C's graph model, describes everything as subject-predicate-object statements with globally unique identifiers, and is built for exchange and linking across system boundaries. Property graphs store nodes and edges with arbitrary properties directly and are common in many graph databases. RDF wins on interoperability and formal semantics, property graphs on simple modelling within a single application.

The RDF 1.1 Concepts specification (W3C, 2014) defines an RDF graph simply as a set of triples. The successor, RDF 1.2, adds triples that can themselves be the object of a statement. That makes it possible to record, for instance, which document a relationship came from, something property graphs solve through edge properties. For the example question from the first section, a SPARQL query looks like this:

PREFIX ex: <https://example.org/>

SELECT ?product WHERE {
  ?product ex:contains ?part .
  ?part ex:suppliedBy ex:SupplierA .
}

03

What is an ontology, explained in plain language?

An ontology is an agreed, machine-readable vocabulary: it defines which kinds of things exist, which relationships between them are allowed, and which rules apply, such as a seal being a type of part. It makes sure that people and machines mean the same thing by "supplied by". Not every graph needs an elaborate ontology; a simpler level is often enough.

A common mistake is starting with the complete ontology for an entire company. A small vocabulary for the questions actually being asked, growing as needed, holds up far better. SKOS suits this well, because it maps terms and synonyms without requiring logical rules. SHACL becomes important as soon as a language model supplies data, because validation rules catch statements that do not fit the vocabulary.

04

How do entities and relationships emerge from unstructured text?

Entities and relationships emerge in several steps: text is split into sections, a language model or a specialised model recognises things and relationships within it, the same thing under different names gets merged, and the result is checked against the vocabulary. Every statement should keep its source, so errors stay traceable and correctable.

1. Split

   Documents are divided into sections (chunking). Sections that are too small tear relationships apart; sections that are too large overwhelm extraction.

2. Recognise entities

   The model flags products, people, places, standards or concepts and assigns them to types from the vocabulary.

3. Extract relationships

   Sentences become statements such as "contains" or "replaces". The GraphRAG paper (Microsoft Research, 2024) also extracts claims about entities.

4. Ask again

   In the GraphRAG process, the model gets its own list handed back with a prompt to add any entities it missed. That raises the yield, along with the number of model calls.

5. Merge (entity resolution)

   "Supplier A", the same company written with its legal suffix, and an abbreviation used in the ordering system all get recognised as the same entity. This is where most silent errors originate.

6. Validate and record provenance

   Validation rules reject statements that do not fit; every statement points back to the document and section it came from.

Typical failure patterns include invented relationships that the text only hints at, dropped negations ("does not contain seal D17"), missing time validity ("supplied by, until 2023") and duplicate nodes caused by name variants. Structured sources such as bills of materials or master data deliver relationships more reliably than any text extraction, and belong in the graph first wherever they exist.

05

How does GraphRAG, the method from Microsoft Research, work?

GraphRAG uses a language model to build an entity graph from the source texts, groups tightly connected entities hierarchically into communities, and has a summary written for each community. It answers overview questions by generating partial answers from these summaries and merging them. It answers questions about individual entities through their neighbourhood in the graph.

The paper "From Local to Global: A Graph RAG Approach to Query-Focused Summarization" by Edge and others appeared on arXiv in April 2024, with a revised version in February 2025. It addresses a weakness of classic retrieval-augmented generation: questions like "What are the main themes in these documents?" are not a search for one passage, but a summary over the whole collection. Such overview questions were studied on datasets of around one million tokens (Microsoft Research, 2024).

For the communities, GraphRAG uses the Leiden algorithm by Traag, Waltman and van Eck (Scientific Reports, 2019), which, unlike its predecessor Louvain, only ever produces well-connected communities, recursively down to the smallest subgroups. For a global question, partial answers are generated in parallel per summary, ranked by usefulness, and condensed into a final answer up to the limit of the context window.

The evaluation had a language model score answers pairwise on comprehensiveness, diversity, reader empowerment and directness. GraphRAG led on comprehensiveness and diversity; classic vector RAG delivered the more direct answers. The open-source project's documentation now describes several query modes: global search over community summaries, local search over an entity's neighbours, a hybrid called DRIFT, and plain vector search. Query decomposition and the advanced RAG toolkit shows where GraphRAG sits alongside decomposition and RAG fusion.

AI-GENERATEDAI-GENERATED

06

When does a graph beat vector search, and when does it not?

A graph beats vector search on questions that trace relationships across several steps, on aggregations such as "how many" or "which ones", and on overview questions across an entire collection. For questions pointing to a single passage, for fast-changing documents and for small collections, vector search combined with keyword search is usually the better and simpler choice.

Both approaches can be combined; Semantic search in the enterprise explains how full text, vectors and hybrid search work.

07

Why is upkeep the biggest cost driver of a knowledge graph?

Upkeep drives the cost because a graph has to be updated every time the sources change: extracting new entities, merging duplicates, removing stale relationships, adjusting the vocabulary. With GraphRAG, many model calls for extraction and summarisation come on top. The query itself is rarely the problem; keeping the graph correct and current is what gets expensive.

Microsoft's GraphRAG GitHub repository explicitly points out that indexing can be an expensive operation, and recommends starting small and tuning the prompts to your own data, because the default settings do not give the best results. In November 2024, Microsoft Research introduced a variant called LazyGraphRAG that shifts model calls from indexing to query time; according to Microsoft Research (2024), that brings indexing costs down to the level of vector RAG, at 0.1% of those for full GraphRAG.

A graph adds to the running costs of a RAG system; see What a RAG system actually costs to run.

08

Which W3C standards belong to knowledge graphs, and what does each one do?

The W3C has standardised the building blocks of the semantic web: RDF as the data model, SPARQL as the query language, OWL for ontologies, SKOS for thesauri and taxonomies, SHACL for validation rules and JSON-LD for embedding in JSON. For property graphs, ISO/IEC has published its own query language, GQL. The standards are stable, which makes long-term data management easier.

ISO/IEC 39075:2024 defines GQL, a database language for property graphs, developed within the standards body ISO/IEC JTC 1/SC 32. JSON-LD is often the first point of contact with RDF, because it is what marks up structured data on web pages. A graph built on these standards can be exported and linked to public vocabularies or Wikidata, without being tied to any one product.

09

Which myths about knowledge graphs and GraphRAG persist?

The most persistent myths are that GraphRAG always outperforms classic RAG, that a language model builds a graph from documents without error, that a project must start with a complete ontology, and that a graph replaces existing systems. Each of these assumptions leads to projects that generate more effort than benefit, even though the underlying approach itself holds up.

10

How does a mid-sized company get started with a knowledge graph?

A workable starting point begins with a handful of questions that cannot be answered today, a narrowly scoped area, and structured sources that already contain the relationships. Next come a small vocabulary, a graph with stored provenance, and a direct comparison against vector search using the same test questions. Extraction from text only becomes worthwhile once the graph helps measurably.

Say a pump manufacturer with 250 employees (a made-up example) wants to answer which products are affected by a supplier change or a revised material standard. Bills of materials and supplier master data already contain the relationships. The first graph is built from those without any language model; inspection reports follow later through extraction.

1. Collect ten to twenty real questions that currently trigger follow-up queries or manual work.
2. Check which relationships are needed for them and where they already exist in structured form.
3. Define a small vocabulary, with an owner for every class.
4. Build the graph from structured sources, storing provenance for every statement.
5. Run the same test questions against both the graph and vector search, and compare.
6. Only then add extraction from text, with validation rules and spot checks.

If an AI agent needs to query the graph as a tool, AI agents in knowledge work covers the loop of planning, querying and checking. Graphify shows that a graph can structure software knowledge too, turning a codebase into a locally queryable graph.