GraphRAG uses a knowledge graph instead of relying only on similarity search. Entities become nodes, relationships become edges, and structured retrieval supports complex reasoning over connected data. section 10.1
A typical pipeline converts unstructured text into graph data, turns a natural-language question into Cypher or SPARQL, executes that query, and gives the results to an LLM for response generation. section 10.1 section 10.5
A practical implementation separates the workflow into these responsibilities:
- Extract entities and relationships from raw text and store them in a knowledge graph. section 10.1
- Generate a database query with a few-shot prompt constrained by the graph schema. section 10.5
- Execute the query with a graph database, then pass the original question, generated query, and results to an LLM. section 10.5
- Combine graph queries with knowledge graph embeddings when semantic search should complement structured graph queries. section 10.5
A connected graph fact
A small graph can represent Roberto as a software developer and Inter Milan fan, while connecting Inter Milan to Serie A. Such relationships support queries that require following multiple edges.
Figure 10.5 The Knowledge Graph RAG architecture (KG-RAG) is similar to vector store–based RAG setups, but it uses a SPARQL generator. The generator converts a natural language question into SPARQL, which is executed on the knowledge graph database. The retrieved graph data is then provided to the LLM, along with the original question, to synthesize the answer.
Trace the KG-RAG architecture from a natural-language question to generated SPARQL, graph retrieval, and LLM-generated response. section 10.5
