GraphRAG uses a knowledge graph to expand retrieval beyond vector similarity with graph context, structured queries, and filtering.
2
Ontologies provide an implementation-agnostic description of a domain that can guide both structured and unstructured knowledge graph construction.
3
Storing an ontology in the graph lets retrieval behavior change dynamically, without hardcoding every domain relationship into the retriever.
Summary
Jesús Barrasa explains how ontologies can give GraphRAG applications a shared model for building graphs and retrieving information. GraphRAG replaces the vector database in a traditional RAG flow with a graph database, allowing an application to combine vector search with graph navigation, contextualization, filtering, aggregation, and structured queries. Barrasa shows that graph construction pipelines often need a schema, but currently express it through JSON, Pydantic, or natural-language prompts. An ontology offers a common, implementation-agnostic representation of the domain. He then shows how an ontology can describe which relationships should be used during retrieval. Instead of hardcoding movie-domain knowledge into a retriever, the system can inspect ontology metadata and decide which connections to follow after vector search. Changing the ontology changes the retriever's behavior dynamically. The talk makes a practical case for model-driven graph construction and retrieval logic.
GraphRAG grounds generation with a connected knowledge base
Barrasa describes GraphRAG as a standard RAG flow where a knowledge graph replaces the vector database. The application receives a user prompt, retrieves potentially relevant information from a curated knowledge base, and passes that material to the LLM as context. A graph adds retrieval options beyond vector similarity because it stores connections between data points. The system can perform vector semantic search, contextualize results through graph connections, generate structured queries, and filter or aggregate information. Barrasa says this can improve completeness, relevance, precision, and faithfulness compared with relying only on vector search.
A GraphRAG graph contains both domain entities and source-document structure
The property graph model uses nodes and directed relationships. Nodes can represent people, objects, places, events, or documents, with properties such as names and dates. Barrasa calls this the domain graph. A graph built from unstructured material can also include a lexical graph that describes the source documents. A document may contain sequential chunks, or a richer hierarchy of sections and subsections, as in a legal contract. Chunks connect to domain entities through extraction links that record where an entity is mentioned. The chunks can also store vector representations, so vector search and graph connections live in the same platform.
Graph construction needs a target model for both structured and unstructured data
For structured sources, a pipeline maps records from databases or files onto a target graph schema, assigning records to node types and relationships. For unstructured sources, the pipeline splits documents into chunks, embeds them, extracts entities, and writes the results to the graph. Barrasa says the extraction step needs a description of the domain, such as patients and symptoms in medical documents or account holders, accounts, and money transfers in financial data. The same requirement appears across Neo4j's GraphRAG package and its LangChain and LlamaIndex integrations, even though each path may express the schema differently.
Ontologies provide one domain description across different pipelines
Barrasa defines an ontology as a shared, formal description of a domain that is independent of a particular implementation. Ontologies can be represented in several serialization formats and can describe classes, subclass relationships, and connections between classes. His example uses the FIBO financial industry ontology, where a privately held company and a stock corporation are related by a subclass relationship, and a stock corporation is connected to a board agreement. The same ontology can guide graph creation from structured and unstructured sources instead of maintaining separate JSON schemas, Pydantic descriptions, or prompt instructions.
A model-driven graph improves later retrieval work
Barrasa argues for building the graph from an explicit model. He says this is good data-engineering practice and that it produces a better graph from the start. The model also affects retrieval. A well-described graph gives text-to-structured-query systems a better basis for generating accurate queries. It also gives vector retrieval more useful graph structure for contextualization. In this view, the ontology is not only a construction specification. It is a reusable domain artifact that can support later operations over the graph.
Vector hits become more useful when the retriever returns to the graph
Barrasa explains that embedded chunks create a search space in which a query can find nearby vectors. Because each vector belongs to a graph node, the retriever can use the vector result as an entry point back into the graph. It can then navigate connections, enrich the result with related information, filter it, or aggregate data before sending context to the LLM. His movie example searches embedded movie plots for a description of a hacker discovering a simulated reality controlled by machines. The retriever returns a chosen number of results and applies additional graph logic to each one.
Ontology metadata can replace hardcoded retrieval paths
A manually written movie retriever needs to know that actors act in movies and that movies have plots. Barrasa says this makes the retriever somewhat rigid because domain knowledge is embedded in its logic. If the ontology is stored in the graph, the retriever can query the ontology for relationships marked as contextualizing relationships. It can then follow those relationships when expanding a vector result. In the example, the ontology determines that the retriever should follow actor relationships rather than producer or director relationships. The retrieval path comes from data in the ontology instead of fixed code.
Changing the ontology changes retrieval behavior dynamically
Barrasa describes the ontology as a level of indirection between the domain model and the retriever. The retriever consults the ontology, finds the relationships designated for contextualization, and uses them to decide how to explore the graph. Because the ontology is stored as a data artifact, changing it changes the retriever's behavior without rewriting the retriever itself. His two conclusions are that ontologies can provide an implementation-agnostic model for knowledge graph creation and that storing them in the graph can drive dynamic retriever behavior.
"I can change my ontology and by changing my ontology, which is a data artifact in my graph, I'm changing the behavior of my retriever on the fly and dynamically."13:13
Who should watch
You are building a GraphRAG system and need retrieval to use graph relationships as well as vector similarity.
Your ingestion pipeline handles several data formats and you want one domain model to guide structured and unstructured graph construction.
Your retriever contains hardcoded domain-specific traversal logic that you want to change through data rather than code.
