Skip to content

GraphRAG

The hard part of GraphRAG is the graph

Retrieving over a knowledge graph beats retrieving over chunks, and that argument is settled. The open question is where the graph comes from, because a graph an LLM extracted from your documents carries every mistake the extraction made. graph.build builds it from your systems instead.

Book a demo Read the wider argument
Input Hierarchy Vocabulary supply-chain.ontology · Ontology Model Designer

Input

Class

Literal

IRI Config

http://graph.build/ontology/

hasPart hasLegalName hasDuns hasDescription hasLeadTime Supplier Part string string string integer supply-chain.ontology · 2 classes · 5 predicates

Publish

supply-chain.ontology

Name supply-chain

Access Private

Latest 2026-08-13 11:19

Version v14

publish to inform or restrict
the creation of other models

The question nobody asks

Two graphs, and only one of them is evidence

Both are called a knowledge graph. Only one can be traced back to a system of record.

extraction vs mapping

Extracted, or mapped

An extracted graph is produced by asking a model to read your documents and name the entities. It is fast to stand up and it is a second interpretation layered on the first. The nodes are the model's opinion of what your documents said. A mapped graph is produced by pointing Transformers at the systems themselves: SQL, APIs, Kafka, files. Each node exists because a row did. We do read documents too, with the Document Transformer, and it is aimed at an ontology you published rather than left to invent one. That settles the vocabulary. It does not turn a paragraph into a row.

The consequence: when the answer is challenged, one graph leads back to a source table and a run identifier, and the other leads back to a prompt.

studio · entity · Supplier · v14
gbo:Supplier/213847561 Northgate Ltd
gbo:Supplier/213847561 gbo:Supplier
gbo:Supplier/213847561 gbo:Part/HX-8841
gbo:Part/HX-8841 14 (integer)

n-triples 8 emitted, validated against supply-chain.ontology all passed
unmapped: 0 · quarantined rows keep their reason

Honest comparison

What each kind of retrieval is actually good at

This is not a table where one column wins. Vector search over text is very good at the thing it does, and a system that needs both should run both. The mistake is expecting either to do the other's job.

Question type Vector search Extracted graph Modelled graph
Find passages on a topic Included Not included Not included
Answer from prose nobody has structured Included Included Not included
Resolve one entity across systems Not included Not included Included
Traverse relationships more than one hop Not included Included Included
Cite the source system and the run Not included Not included Included
Enforce a definition the business agreed Not included Not included Included
Stay current as sources change Not included Not included Included

run both · vector for the prose, the graph for the facts

How it is built

Studio authors it. Transformers run it. Writers land it.

The same three moves the rest of the platform is made of. Nothing about GraphRAG needs a separate pipeline. The graph your analysts query and the graph your agents retrieve from are one graph.

Studio

Authors the model and the mapping files, validates them, publishes a version.

outputs · model + .map

publishes
v14

Transformers

Execute the mappings against SQL, APIs, Kafka and files. Resolve identity, quarantine what does not fit.

outputs · resolved records

hands off
batches + cdc

Writers

Emit your database's native load in insert or update mode, and keep it current through CDC.

outputs · your graph database

Serving path 16:9
Sources Build Store Consume
Kafka & Files
SQL
RESTful endpoints
graph.build Transformers
Ontology
Writers
Your graph database SPARQL · Gremlin · Cypher
Agent any model, any framework
MCP

MCP on the Studio Node: an assistant reads the published ontology, read-only, with no source credentials handed to the model

FAQ

What people ask about GraphRAG

Ask us something else
Do we have to replace our vector database?

No, and you should not. Vector search finds passages that resemble a question; graph retrieval returns entities, how they relate, and where each came from. They answer different questions. What a vector index cannot give you is a definition.

Can you extract a graph from our documents?

Yes, with the Document Transformer, which reads DOCX and PDF using an LLM. What separates it from generic extraction is that it works against an ontology you have already published, so the model is looking for your classes and properties in the text rather than deciding what they ought to be. That settles the vocabulary, and it is the part that usually goes wrong. It does not turn a paragraph into a row, so a node that came from a document is a reading of a document and worth checking like one. Most of a graph should still come from the systems that hold the facts: SQL, REST APIs, Kafka, and CSV, JSON, XML, XLSX and ODS files.

Which graph database does GraphRAG need?

Any database that speaks SPARQL, Gremlin or openCypher. The retrieval pattern does not depend on the vendor, and neither does the model, which means you can benchmark two of them on your own graph before committing.

How does the agent query it?

Against your graph database, in the dialect it speaks, under the access control you already run there. Studio also publishes a read-only MCP server that lets an assistant read the ontology, so it can work out what to ask for before it asks.

How current is the retrieved context?

As current as change data capture makes it. Debezium-compatible sources, including SQL databases, MongoDB and Cassandra, apply inserts, updates and deletes continuously, with provenance carried through. There is no re-embedding job to fall behind.

Try it against a question your RAG stack gets wrong

Pick a question that turns on an entity appearing in more than one system. We will model that corner and show you both answers.

Book a demo Talk to us
  • 45 minutes, your data
  • Keep your vector database
  • Any of the supported graph databases