A knowledge graph represents entities as nodes and their relationships as edges, creating a structured form of information for querying, reasoning, inference, and explainability. In LLM applications, it can turn unstructured text into a compact alternative or complement to vector-store retrieval. section 10.1 section 10.5
Represent the same knowledge through several graph models:
- Use triples such as (Roberto, isFanOf, InterMilan), with a subject, predicate, and object. section 10.5
- Use RDF with explicit types and properties, then query the graph with SPARQL. section 10.5
- Use proprietary graph representations and languages such as Cypher for Neo4j or Gremlin instead of RDF and SPARQL. section 10.5
A practical GraphRAG pipeline extracts entities and relationships from raw text, stores them in a graph database, generates Cypher or SPARQL from a natural-language question, executes the query, and gives the results to an LLM for answer synthesis. Few-shot examples and a carefully constrained schema prompt help keep generated queries within the available relationship types and properties. section 10.1 section 10.5
A small connected graph
Store Roberto as a person who works in software development and supports Inter Milan; store Inter Milan as a soccer team that plays in Serie A. These connected facts support relationship-focused queries that are difficult to express with simple similarity search. section 10.5
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.
Follow the KG-RAG architecture from a natural-language question through SPARQL generation and graph execution to LLM answer synthesis. section 10.5
Graph databases provide flexible relationship modeling and deeper inference, but their complexity can hinder adoption. Unlike relational databases, they do not share one universal standard, so representation and query language choices matter. section 10.5
