In short
A procurement manager wants to know which suppliers that delivered late in the last six months also supply the production lines with the most orders in the backlog. The answer depends on following a chain of relationships: supplier, purchase order, component, production line. Traditional RAG retrieves passages similar to the question and stops there. GraphRAG is the variation that assembles the context by traversing a graph of entities and relationships. It ties directly into the Company Brain, the layer that knows the company: what data exists, where it lives, how it connects and who may see what.
In traditional RAG, the unit of retrieval is the text passage most similar to the question. In GraphRAG, the unit of retrieval is the entity and its neighbourhood in the graph: the supplier, the orders linked to it, the components in those orders and the lines that consume those components.
The process has three steps. The system identifies the entities mentioned in the question, locates those entities in the graph and expands the slice through the relevant relationships. The resulting subgraph, along with the texts associated with each node, goes into the prompt.
The approach got its name when Microsoft Research researchers proposed a graph-based index to answer questions about entire document collections and called the method GraphRAG. The study started from a known limitation: traditional RAG fails on global questions, such as what the main themes of a set of texts are, because no single passage contains that answer.
The proposal uses an LLM to extract entities and relationships from the documents and groups the most closely connected entities into communities. Each community gets a summary generated in advance. Faced with a global question, the system combines these summaries into a single answer. In the study's tests, these answers were more comprehensive and more diverse than those from traditional RAG.
Implementations split by where the graph comes from:
The two variants can coexist. In the first, each node is an inference by the extraction model. In the second, each node corresponds to a record with a known owner and source.
The advantage shows up in three types of question:
For point questions, whose answer is written in a single paragraph, traditional RAG is usually enough and costs less.
The GraphRAG variant that extracts the graph from documents inherits the inaccuracies of the extraction model. The same supplier shows up as three nodes because it was written with an acronym, without the acronym and under its trading name. A relationship is created because two names appeared in the same paragraph, without the text stating any link between them. Every error of this kind spreads to every answer that passes through the node.
There is also the indexing cost. Each document goes through calls to the model for extraction, and the community summaries require further calls. When the documents change, extraction has to run again, and the outdated graph keeps answering with the old relationships.
Then there is governance. An extracted graph mixes documents with different access levels. A relationship inferred from a restricted legal opinion may appear in the answer for someone who never had access to that opinion, and the graph rarely records which passage each edge came from.
In the Company Brain, the knowledge graph is born from the records in the source systems. The supplier is the ERP master record, the purchase order is the record with a number and a date, and the link between them is the one the system itself already holds. The business ontology defines what each entity and each relationship means.
Permissions are inherited from the source. Each node and each edge carries the access rule of the system it came from, and the slice served to the model over MCP contains only what the person asking can already see. Each relationship points to the source record, which makes the answer auditable.
Text search comes in as a complement. Minutes, contracts and reports are indexed and linked to the entities in the graph, and the semantic layer decides when the question calls for the path between records, when it calls for a written passage and when it calls for both.
GraphRAG over structured data requires sources with reasonably consistent identifiers. Duplicate records in the ERP itself reach the graph and have to be handled in entity resolution, with human review in ambiguous cases. The ontology's definitions also need a responsible team, because a poorly defined relationship produces answers that are coherent and wrong.
The practical starting point is a question that today requires querying two or three systems in sequence and that comes up every week. It defines the entities, the relationships and the sources of the first slice. Next come the documents that help explain those entities, linked to the graph and subject to the same inherited permissions.
