Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/jbarrasa/goingmeta/llms.txt

Use this file to discover all available pages before exploring further.

GraphRAG — Retrieval Augmented Generation over Knowledge Graphs — is the central theme of Going Meta from Session 22 onward. The core idea is that a pure vector search retrieval step for LLM prompts loses the structural, relational context that a knowledge graph preserves. By querying a graph rather than just a vector index, the retrieval step can follow relationships, traverse hierarchies, and surface facts that no single text chunk would contain. Going Meta layers ontologies on top of this to make the construction and retrieval steps schema-aware from the start.

​
Why Graph Beats Vector Alone

A vector index retrieves text chunks that are semantically similar to the query. That works well for single-document lookup but fails when the answer requires connecting multiple entities across the graph — for example, “Which artists exhibited at the same gallery as Hockney and also worked in watercolour?” A graph traversal answers this in a single Cypher query; a vector search would require multiple rounds of embedding comparison with no guarantee of finding the connecting path.

Vector Search Strengths

Fast approximate nearest-neighbour lookup. Finds semantically related chunks even when exact keywords differ. Works well for single-hop, single-entity questions.

Graph Traversal Strengths

Follows typed relationships across multiple hops. Respects ontology hierarchies (a query for Person also retrieves Artist, Director etc. via subClassOf). Answers multi-entity, multi-hop questions natively.

​
The GraphRAG Pipeline

Going Meta’s ontology-driven GraphRAG pipeline has five stages. Sessions 22–32 build this out incrementally from a simple RAG prototype to a full production-ready pipeline.
1

Design the ontology

Define the domain model as an OWL ontology — classes (entities), object properties (relationships), and datatype properties (attributes). The ontology acts as both a schema for the knowledge graph and a grounding constraint for the LLM during extraction.
2

Construct the knowledge graph

Pass unstructured documents (PDFs, CSVs, text files) plus the ontology to an LLM with a structured-extraction prompt. The LLM produces Cypher MERGE statements constrained to the ontology’s class and property vocabulary. These are executed against Neo4j to build the KG.
kgbuilder-openai.py
prompt = (
    "Given the ontology below run your best entity extraction over the content. "
    "The extracted entities and relationships must be described using exclusively "
    "the terms in the ontology. Return the output as Cypher using MERGE to allow "
    "for linkage of nodes from multiple passes. Absolutely no comments."
    + "\n\nONTOLOGY:\n" + ontology
    + "\n\nCONTENT:\n" + content
)
3

Create a vector index

Generate embeddings for key text properties (article body, document summaries, entity descriptions) and store them on the relevant Neo4j nodes. Create a vector index to support approximate nearest-neighbour search:
create-vector-index.cypher
CALL db.index.vector.createNodeIndex(
  'article-embeddings',
  'Article',
  'embedding',
  1536,
  'cosine'
);
4

Retrieve with hybrid query

At query time, combine vector search (for semantic similarity) with graph traversal (for relational context). The vector step finds the nearest matching nodes; the graph step expands their neighbourhood to collect supporting facts:
hybrid-retrieval.cypher
// Vector step: find semantically similar articles
CALL db.index.vector.queryNodes('article-embeddings', 5, $queryEmbedding)
YIELD node AS similarArticle, score

// Graph step: expand via ontology-grounded topic links
MATCH (similarArticle)-[:refers_to]->(c:Concept)-[:broader*0..2]->(parent:Concept)
RETURN similarArticle.title AS title,
       collect(DISTINCT c.prefLabel) AS directTopics,
       collect(DISTINCT parent.prefLabel) AS broaderTopics,
       score
ORDER BY score DESC LIMIT 5
5

Generate the answer

Pass the retrieved graph context (serialised as structured text) to the LLM along with the original question. The LLM generates a grounded answer backed by explicit graph evidence rather than parametric memory.
rag-generation.py
context = "Related documents:\n\n" + "\n\n".join([
    f"title: {r['title']}\nbody: {r['body']}"
    for r in results
])
response = client.chat.completions.create(
    model="gpt-4o",
    messages=[
        {"role": "system", "content": "Answer based on the provided context only."},
        {"role": "user",   "content": context + "\n\nQuestion: " + question}
    ]
)

​
Ontology-Driven vs. Schema-Free GraphRAG

A key distinction Going Meta explores is between schema-free KG construction (where the LLM decides what entities and relationships to extract) and ontology-driven construction (where an OWL ontology constrains extraction):
ApproachProsCons
Schema-freeQuick to start, flexibleInconsistent labels, duplicate entities, no semantic hierarchy
Ontology-drivenConsistent schema, inferencing possible, SHACL-validatableRequires upfront ontology design
From Session 28 onward, Going Meta strongly advocates the ontology-driven approach: the extra investment in ontology design pays off in graph quality, validation, and LLM answer precision.
The getNLOntology(graph) utility function (session 29, utils.py) converts a parsed RDF graph into a natural-language ontology description. Passing this to the LLM as part of the system prompt is often more effective than including raw Turtle, as the LLM understands plain English constraints better than formal syntax.

​
GraphRAG Sessions in Going Meta

Session 22 — RAG with KGs

First full RAG pipeline: vector index, LLM generation, graph-enriched context.

Session 23 — Advanced RAG

Parent-child chunking, multi-hop traversal, Streamlit art gallery assistant.

Session 31 — GraphRAG End-to-End

Full ontology → KG → vector index → retrieval → generation pipeline with neo4j-graphrag.

Session 33 — Retrieval Methods

Systematic comparison of vector, keyword, graph traversal, and hybrid retrieval.

Build docs developers (and LLMs) love

Get started for freeTalk to us