GraphRAG: The Definitive Guide

Patterns and Techniques for GenAI Knowledge Graph Retrieval

With Early Release ebooks, you get books in their earliest form—the author’s raw and unedited content as they write—so you can take advantage of these technologies long before the official release of these titles.

Stephen Chin, Michael Hunger, and Jesús Barrasa

GraphRAG: The Definitive Guide

by Stephen Chin, Michael Hunger, and Jesús Barrasa

Copyright © 2026 Stephen Chin, Michael Hunger, and Jesús Barrasa. All rights reserved.

Printed in the United States of America.

Published by O’Reilly Media, Inc. , 1005 Gravenstein Highway North, Sebastopol, CA 95472.

O’Reilly books may be purchased for educational, business, or sales promotional use. Online editions are also available for most titles ( http://oreilly.com ). For more information, contact our corporate/institutional sales department: 800-998-9938 or corporate@oreilly.com .

Editors: Jeff Bleiel and Nicole Butterfield

Production Editor: Katherine Tozer

Interior Designer: David Futato

Cover Designer: Karen Montgomery

Illustrator: Kate Dullea

August 2026: First Edition

Revision History for the Early Release

2025-10-01: First Release

See http://oreilly.com/catalog/errata.csp?isbn=9798341630154 for release details.

The O’Reilly logo is a registered trademark of O’Reilly Media, Inc. GraphRAG, the cover image, and related trade dress are trademarks of O’Reilly Media, Inc.

The views expressed in this work are those of the authors and do not represent the publisher’s views. While the publisher and the authors have used good faith efforts to ensure that the information and instructions contained in this work are accurate, the publisher and the authors disclaim all responsibility for errors or omissions, including without limitation responsibility for damages resulting from the use of or reliance on this work. Use of the information and instructions contained in this work is at your own risk. If any code samples or other technology this work contains or describes is subject to open source licenses or the intellectual property rights of others, it is your responsibility to ensure that your use thereof complies with such licenses and/or rights.

979-8-341-63010-9

[FILL IN]

Brief Table of Contents (Not Yet Final)

Chapter 1: Introduction to GraphRAG (available)

Chapter 2: A Basic RAG Assistant (available)

Chapter 3: Better Answers with GraphRAG (unavailable)

Chapter 4: Knowledge Graph Concepts (unavailable)

Chapter 5: Basic GraphRAG Patterns (unavailable)

Chapter 6: Putting It In Practice: Use Case (unavailable)

Chapter 7: Knowledge Graph Construction (unavailable)

Chapter 8: Agentic GraphRAG (unavailable)

Chapter 9: Integrating Advanced Graph Analytics (unavailable)

Chapter 10: Advanced GraphRAG Patterns (unavailable)

Chapter 11: Explainability and Governance (unavailable)

Chapter 12: Conclusion (unavailable)

Chapter 1. Introduction to GraphRAG

A Note for Early Release Readers

With Early Release ebooks, you get books in their earliest form—the author’s raw and unedited content as they write—so you can take advantage of these technologies long before the official release of these titles.

This will be the 1st chapter of the final book. If you’d like to be actively involved in reviewing and commenting on this draft, please reach out to the editor at jbleiel@oreilly.com.

Graph databases have become an essential component of the generative AI (GenAI) ecosystem because they complement the strengths of large language models (LLMs). LLMs excel at processing and generating natural language, while knowledge graphs are optimized for representing structured information—capturing entities, relationships, and domain-specific context. When used together, these technologies are capable of solving problems that neither could address effectively on their own.

Early GenAI systems focused heavily on prompt engineering and vector search to improve model performance. While effective for general-purpose queries, these approaches struggle in enterprise settings where questions require domain understanding, relationship reasoning, or adherence to business rules. Without structured context, LLMs often produce answers that are vague, inconsistent, or incorrect. Knowledge graphs address this gap by encoding domain knowledge in a structured, queryable form that can be used to guide retrieval and enrich model responses.

This convergence has led to a new architectural approach known as GraphRAG. The term GraphRAG is a combination of “Graph” and “RAG” (Retrival Augmented Generation). GraphRAG systems use the semantic structure of a knowledge graph to retrieve context that is relevant, complete, and aligned with domain logic. This results in answers that are not only more accurate, but also easier to explain and verify. Beyond basic retrieval, LLMs can also use graphs as tools—issuing Cypher queries, traversing subgraphs, or interacting with memory-like graph structures through protocols such as MCP. As GenAI capabilities expand, the synergy between LLMs and knowledge graphs is becoming a foundational element of modern AI architectures.

This chapter will begin with an introduction to knowledge graphs. We’ll look at their basic components and explain why they have become a key tool for organizing enterprise knowledge and reasoning over structured and unstructured data.

With this foundation in place, we will introduce the term GraphRAG and define its scope within the context of generative AI applications. While the term originated as a shorthand for combining knowledge graphs with retrieval-augmented generation, it has grown to encompass a range of system architectures and interaction patterns. This section will clarify what is and is not considered a GraphRAG system, providing a shared vocabulary that will be useful in the chapters that follow. Establishing this definition will help frame the discussion and ensure that readers understand how these systems differ from standard RAG implementations.

Finally, the chapter will present several core architectural patterns used in GraphRAG systems, each designed to solve different types of retrieval, ranking, and reasoning challenges. These patterns range from query generation approaches like Text2Cypher to hybrid retrieval models that combine vector similarity with graph-based ranking or filtering. This will help you gain a deeper understanding of the technical decisions involved in building GraphRAG systems and how to apply the appropriate design depending on the use case and data structure.

Knowledge Graph Primer

To understand GraphRAG, it is important to begin with a foundational understanding of what a knowledge graph is and why it is particularly well-suited for representing complex, connected data. Knowledge graphs are not just another data format; they offer a flexible, intuitive way to model relationships and contextual meaning between entities. This structural richness provides a natural complement to generative AI systems, enabling more accurate, explainable, and relevant responses.

Knowledge graphs are a natural way of expressing information and have existed since humans have been able to turn ideas into pictures. A knowledge graph can be as simple as two words (nodes) with a line (relationship) between them. As you add more nodes and relationships the natural shape of a graph comes out. Properties allow you to store information within each node, which lets you explain even more complex business scenarios.

An example of a very simple knowledge graph is shown in Figure 1-1. The nodes are two people and a car. To describe the nodes, properties are attached such as the names of the people, Dan and Ann, and the brand and model of the car. Then relationships are created between the nodes to describe how they interact such “DRIVES” to describe the fact that Dan is the car driver or “OWNS” to describe that Ann is the registered owner of the car. And just like nodes, relationships can also have properties, for example, here we see the date which Dan started driving this car.

Figure 1-1. A simple knowledge graph showing now nodes, relationships, and properties are used

The term knowledge graph was coined by Austrian linguist Edgar W. Schneider in 1972 and has been the subject of innumerable academic discussions and research papers since. It came into general popularity in 2012 when Google created a searchable Knowledge Graph representation of the web that provided advantages over basic text search. Google’s PageRank algorithm also drew inspiration from graph-based proximity metrics, reinforcing the value of connected data.

The rise of knowledge graphs led to the development of general-purpose graph databases, which are optimized for storing and querying highly connected data. Unlike relational databases, which require expensive joins to navigate relationships, graph databases traverse connections directly. This allows for faster, more efficient querying of deep, complex data. Most graph databases support Cypher, a declarative graph query language, and many now adopt the ratified GQL standard, an ISO-certified language designed specifically for graph querying.

Graph databases are widely used in domains where connections are central to understanding. Fraud detection is a prominent example, where identifying patterns across accounts, devices, and transactions requires rapid traversal of multi-hop relationships. In life sciences, graphs are used to model the complex interactions between drugs, proteins, clinical trials, and regulations. Other common use cases include supply chain tracking, recommendation systems, financial transaction monitoring, and social network analysis. The ability to evolve graph schemas flexibly also makes this technology especially useful for data science and exploratory analytics.

A visual example of a supply chain graph is shown in Figure 1-2. While the graph is simple in design with only 12 nodes, it carries a lot of logistical information about the movement of shipments, delivery modes, material composition, and transport mode. This type of contextual modeling is difficult to achieve with traditional data tables but comes naturally with a graph.

Figure 1-2. Supply chain graph showing the logistics movement of shipments

Now that we have covered the basics of knowledge graphs, we can move on to how they are used in generative AI systems.

GraphRAG Primer

The term GraphRAG originated as a portmanteau of “graph” and “retrieval-augmented generation (RAG).” RAG is a popular architecture in which a large language model (LLM) is enhanced with external knowledge through a retrieval component. In a typical RAG system, the user’s query is used to retrieve relevant information, often from a vector database, and that information is passed as context to the LLM to generate a response. While powerful, traditional RAG pipelines suffer from a number of limitations. They often rely solely on vector similarity, struggle with noisy or ambiguous matches, and provide little transparency into how responses are constructed.

Beyond RAG

GraphRAG extends the standard RAG pattern by integrating a knowledge graph into the retrieval and reasoning pipeline. Graphs offer rich, structured representations of nodes and their relationships, allowing the system to surface more accurate, contextual, and explainable results. Instead of treating retrieved documents as isolated chunks of text, GraphRAG can trace how nodes are connected, apply semantic constraints, follow dependencies, and even reason across multiple hops. This enables more precise and trustworthy responses, especially in domains where relationships matter, such as enterprise knowledge management, life sciences, and supply chains.

Over the past few years, GraphRAG has evolved far beyond its original conception as “RAG with a graph.” It now encompasses a wide range of architectures, tools, and design patterns, each tailored to different information access and reasoning needs. This includes approaches that use graphs to refine vector search results, generate structured queries from natural language, or even perform dynamic subgraph retrieval based on query semantics. The field has gained significant traction in both industry and academia, with hundreds of research papers exploring various retrieval and integration strategies.

For the purposes of this book, we adopt a broad but practical definition:

GraphRAG is defined as any generative AI system that uses a knowledge graph to aid in information storage and retrieval.

This definition intentionally captures a spectrum of GraphRAG designs from basic augmentation of retrieval with graph lookups to more advanced multistep reasoning over dynamic subgraphs. The following subsection introduces the most common GraphRAG patterns in use today, highlighting how they differ in approach, capability, and application fit.

Core GraphRAG Patterns

Now that we have a working definition of GraphRAG, the next step is to explore how these systems are actually implemented in practice. There are multiple architectural patterns, each with different tradeoffs depending on the type of data, use case, and retrieval goals. Here are a few of the core GraphRAG patterns that have emerged in both industry and research to improve the precision, context, and explainability of generative AI outputs.

Text2Cypher - In this pattern, the user prompt and a schema or ontology describing the graph are passed to a language model, which generates a Cypher query to retrieve relevant data. The results of the query are then converted into a natural language response. This approach is especially useful when the graph is the authoritative source of truth and contains structured answers to well-defined queries. (See Chapter 4 for a deeper look at Text2Cypher.)

Graph Enhanced Retrieval - This pattern begins with a vector similarity search to identify semantically relevant nodes or documents. Once candidates are selected, the graph is used to expand the context by retrieving related nodes, relationships, or subgraphs. The enriched context is then passed to the LLM for response generation. This approach adds semantic grounding and improves relevance. (See Chapter 4 for details.)

Ranking of Vector Search - In this approach, an initial set of results is retrieved via vector search, and then reranked using additional signals from the knowledge graph—such as node centrality, relationship depth, or metadata constraints. Reranking can be applied before or after retrieval, and helps improve precision by filtering or reordering results based on domain-specific logic. (See Chapter 8 for more information.)

These are just a few of the many patterns where knowledge graphs and LLMs can be used together to aid in retrieval. In the next section we will delve into some of the limitations of LLMs and RAG, and how GraphRAG can improve on the accuracy, explainability, and relevancy of results.

Limitations of LLMs

While LLMs have unlocked powerful new capabilities in natural language understanding and generation, they also introduce a set of well-known limitations that impact the accuracy, reliability, and trustworthiness of their outputs. These limitations are especially important to understand when building production-grade AI systems that need to deliver factual, precise, and context-aware responses. Without the right safeguards and supporting data infrastructure, LLMs often generate responses that appear confident but are incorrect or misleading.

In this section, we look at how LLMs are trained, how they represent knowledge using word embeddings, and why this leads to hallucinations when precise or domain-specific information is required. This foundation will help explain the shortcomings of standard RAG systems and set the stage for how GraphRAG addresses these issues with structured, contextual data.

LLMs are very good at responding to general questions, but struggle to answer correctly when a specialized knowledge set is required or the answer needs to be highly precise and factual. However, LLMs are eager to provide a response even without the factual knowledge base to answer accurately and this produces hallucinations in their response.

An LLM hallucination is any time that the model answers a question with a response that is not grounded in information, facts, and relationships. This is a common occurrence when building systems with LLMs, so why does this phenomenon occur, and how can we prevent it? To better understand why LLMs hallucinate we first need to understand how they work.

LLMs are based on a very simple algorithm that helps them find associations in their training set and to answer questions. The first thing to understand is the LLMs do not think in words, but rather in word vectors. They decompose text into semantic chunks called word vectors and then map a statistical model of the relationship between different word vectors in multidimensional space. A good way to understand how word vectors work is to use a tool like the nlpl.eu website to see how word vectors relate to each other.

For example, if we take a cat as an example input, we can get a graph back of the statistical similarity between a cat and other word vectors as shown in Figure 1-3. In vector space a cat is similar to domestic animals like a dog or puppy, but far away from wild animals like pigs or ferrets. However, this is just one of many relationships that LLMs encode into word vectors. They may also look at the size of the animals, the species of the animal, and even how commonly they are referred to in literature. And this process is repeated between each of the other word vectors creating a huge set of statistical relationships that the LLM can use to evaluate text. This multidimensional set of vector embeddings creates the LLMs’ corpus of knowledge.

Figure 1-3. Word vectors similar to the word cat from the NLPL word embeddings online service

To further explain this, it is helpful to understand the algorithm by which these embeddings are created. The training text is fed into a transformer that finds the relationship between different word vectors in the input and encodes that in vector space. Each transformer stage is specialized and looks at a different aspect of the relationship between the input word vectors. By passing through multiple transformer stages insights about the text are encoded to build semantic meaning.

To illustrate this concept we can take a simple sentence and explain how each transformer stage hypothetically could encode additional information. For example, take the sentence “A developer’s best friend to code is AI.” The first transformer stage may identify parts of speech like subjects and verbs. The second transformer stage could build on this by relating the subjects to what actions they are taking. In this example the friend refers to “AI” and the coding is being done by both the developer and the AI. This is shown visually in Figure 1-4.

Figure 1-4. Example of the different transformer stages that are used to build embeddings

And finally we need to explain how the embeddings are used to generate a response to an input question. When you ask the LLM a question this is converted to a set of corresponding word vectors. The word vectors are fed into a neural network that uses the embeddings to guess the most likely next word vector in the series. As illustrated in Figure 1-5 this process is repeated to continually guess the next word vector until a full answer is created.

Figure 1-5. Simplified diagram of the feed forward layer of an LLM that calculates the next output word vector

With such a simple algorithm backing LLMs, how do they seem to have human-like thinking and reasoning capabilities? There is clearly no reasoning or intelligence in this algorithm that compares to how humans think. The surprisingly good results that come out of LLMs, because they have a huge training set. The GPT-3 model was trained on a corpus of 500 million words while the average human is only exposed to 100,000 words by the age of 10. This is huge advantage in trained knowledge and the reason why LLMs can respond to almost any topic with a seemingly intelligent answer.

As a result of this discrepancy in training data and mastery of natural language, LLMs appear much more capable than they actually are in domain specific tasks and reasoning. However, they are very useful as a communication agent with the end user since they can pull statistically related information to respond to almost any question. So what if we could combine the natural language and conversational fluency of LLMs with a curated database of unstructured documents that fill the knowledge gap. This is where retrieval augmented generation (RAG) comes into the picture.

Limitations of RAG

RAG stands for retrieval augmented generation. It is a technique that allows developers to build applications using general purpose LLMs that are able to answer questions outside the data set they are trained on. This makes it possible to take advantage of the language capabilities and large general knowledge pool of LLMs to solve domain specific business problems.

The basic flow of a RAG application is that the user prompt is intercepted and used to query an external data source. The external data source responds with information related to the user’s question. This additional context plus the user’s original query is passed to the LLM and used to compose the response to the question as shown in Figure 1-6 Because the LLM has the additional information from the external data source it is now able to answer questions and topics that it was never trained on.

Figure 1-6. Diagram of a RAG system showing flow from user prompt to a complete response

The most common implementation of RAG is to use vector similarity search to look up relevant results. Vector databases are a popular choice for this workflow, but vector search has become a standard feature of most databases including graph databases, so a dedicated vector database is no longer required.

The way vector similarity search works is that the data you want search on is run through an embedding model to create embeddings for vector similarity. This becomes the vector dataset than can be searched for additional context. When the question comes in the from the user this is also run through the embedding model and used to search for related data via vector similarity algorithms. The most relevant embeddings are returned and combined with the prompt to pass into the LLM to answer the question as shown in Figure 1-7.

Figure 1-7. Embedding and vector search to answer a user question with relevant data

Just like the capabilities of LLMs are easily overestimated, RAG systems appear promising at first, but often fail to deliver on business value. There are several reasons for this highlighted in the following sections.

Limited Data Context

RAG systems search and return only a fraction of the data that is related to the topic as context to the LLM. This is both a technical limitation of the vector search process, but also a limitation of LLMs that have finite context windows and also anchor on the first results presented.

As a result of the limited relevant information, the LLM often struggles to put together a coherent response and will fall back its large and general purpose training set in order to fill in the answer. This results in hallucinations where the answer is not accurate since it lacks grounding in domain specific knowledge. At best the answer appears useful and is harmless, but often the answer can be inaccurate and mislead the user.

Some of the GraphRAG patterns we will discuss later in this title address the context window issues by using graph topology algorithms to produce relevant content and/or to rerank the order the results are presented to the LLM.

Lack of Maturity

Vector databases are not as mature as traditional databases, so features required to run a production instance such as security, compliance, robustness, and high availability are often missing. Fortunately, vector search has become a standard feature of most databases including graph databases. This means you can use a reliable and high performance database and still get the benefits of vector similarity search to give the LLM contextual information.

Vector Similarity ≠ Relevance

The core assumption of RAG is that comparing vector similarity will result in relevant results being returned. This is not true in general, because there are many terms in vector space that are related, but given context are not relevant. For example, when discussing company performance it is obvious that references to Apple are for the company and not the fruit. Vectors are simply encoded statistical models of closeness, so without the context of the question and conversation it is impossible to reliably provide relevant embeddings.

Graphs solve this problem by relationships that are relevant for the domain. This means the application of graph similarity and graph data science algorithms can be used to extract conceptually similar nodes and data, greatly improving the accuracy and quality of the results.

Lack of Explainability

Vector search operates on statistical mappings that the model uses to encode relationships and information, but is lacking in transparency and explainability. This means that the output of the LLM becomes a black box that is impossible to understand and explain.

In contrast, knowledge graphs are a representation that works equally well for humans to understand as well as for machines to process. For the example in Figure 1-8 an apple is represented in both a knowledge graph and a vector representation. The vector embedding is simply a collection of indecipherable probabilities in multidimensional space. However, the knowledge graph has node names and relationship labels that make it obvious which parts of the graph refer to the structure of the apple versus the origin or type of fruit. Combining these two representations together with links between the graph and embeddings gives us GraphRAG, which is a very powerful representation that can be navigated based on both vector similarity and also graph closeness.

Figure 1-8. Comparison of the knowledge graph and vector index view encoding of data

GraphRAG to the Rescue

GraphRAG improves on the RAG model by using the context and data structure of a knowledge graph to retrieve more complete and relevant data than vector similarity search can return. This helps to address the main challenges with RAG systems, which struggle with getting highly accurate and relevant answer.

GraphRAG Architecture

The core architecture of a GraphRAG system is very similar to the RAG architecture we discussed earlier. The user question goes through a GenAI application that performs data retrieval and returns additional context to provide to the LLM. However, in addition to being able to look up context by vector similarity, graph databases can also retrieve information by graph closeness and traversal algorithms based on the additional context and structure contained in the knowledge graph as shown in Figure 1-9. This provides more relevant and accurate context to the LLM, which allows for a higher quality answer to the end user.

Figure 1-9. Diagram showing the general architecture of a GraphRAG application

There are several different approaches and patterns for the graph database retrieval step, but a good starting place is the graph enhanced retrieval pattern discussed in Chapter 4, which can be summarized with the following high-level steps:

Do a vector search on the input question to retrieve embeddings and nodes

Retrieve the nodes in the graph that are close and related to the embeddings

Pass the related nodes and embeddings to the LLM in the context

By using this approach you start with a very high response rate by the LLM since the vector search has a wider definition of what is similar. But by looking up related nodes from the graph you are improving the contextual accuracy and relevancy of the results. And it is easy to layer community groupings and more advanced graph algorithms on top of this to further improve accuracy.

GraphRAG Performance Studies

To evaluate the effectiveness of GraphRAG in real-world settings, several recent studies have benchmarked its performance against traditional RAG systems across a range of domains. These include enterprise data analysis, large-scale summarization, and customer service automation. Each study examines how using GraphRAG by integrating a knowledge graph into the retrieval process can improve the accuracy, efficiency, and relevance of responses generated by LLMs.

The following sections summarize three such studies from data.world, Microsoft Research, and LinkedIn. Together, they demonstrate that GraphRAG is not just a conceptual improvement over standard retrieval methods, but a practical solution to well-known challenges in applying generative AI to structured and semi-structured data. These examples offer concrete evidence of the advantages GraphRAG brings in terms of accuracy, token efficiency, and performance across complex query scenarios.

Data.world Knowledge Graph Performance

A benchmark study by data.world¹ compared the effectiveness of LLMs in answering natural language queries about a dataset in the insurance industry, with and without the support of a knowledge graph. The study focused on evaluating how well user questions were translated into accurate responses when working with different types of underlying data structures.

When the LLM was used without any knowledge graph support and relied solely on SQL-based retrieval, it achieved an overall accuracy of 16.7%. With the addition of a knowledge graph that modeled the structure and relationships within the data, accuracy increased to 54.2%. For queries that involved high schema complexity, accuracy without a knowledge graph was 0%, while the graph-assisted approach reached accuracy levels between 36% and 39%.

These results demonstrate that standard RAG systems are prone to fall short when the underlying data is highly structured or requires understanding of complex relationships. Knowledge graphs provide an additional layer of semantic organization that helps LLMs retrieve and interpret relevant information more effectively. In this benchmark, knowledge graph-based systems proved to be approximately three times more accurate than SQL-only RAG, reinforcing their value in enterprise settings where precision and reliability are critical.

Microsoft Research GraphRAG

Microsoft Research conducted a study on graph-based RAG² that showed strong evidence for the advantages of GraphRAG over traditional RAG architectures. The research addresses a core limitation in RAG systems: their reliance on retrieving semantically similar but often redundant or narrowly scoped text chunks. In contrast, GraphRAG organizes retrieved information into a structured knowledge graph that captures both the entities and the relationships within the source corpus. These graphs are clustered into communities using algorithms, allowing for the generation of high-level community summaries. When a user submits a query, GraphRAG generates partial responses from the most relevant communities and synthesizes them into a comprehensive answer.

By using the LLM-generated knowledge graph, GraphRAG vastly improves the “retrieval” portion of RAG, populating the context window with higher relevance content, resulting in better answers and capturing evidence provenance.³

Jonathan Larson, Partner Data Architect

This structure offers two primary advantages: improved accuracy and reduced cost. First, the quality of responses is significantly higher for complex or broad-scope queries that require synthesis across multiple information clusters. By reasoning over communities rather than isolated text snippets, GraphRAG delivers answers that are more complete and contextually relevant. Second, GraphRAG is more efficient in terms of token usage. Rather than passing multiple large documents into the language model, GraphRAG feeds compact, targeted summaries derived from the graph structure. This reduces the token load at inference time, lowering both latency and cost—particularly important when working with large-scale datasets that exceed typical LLM context windows.

Overall, the Microsoft study demonstrates that GraphRAG is not simply an enhancement to traditional retrieval workflows, but a foundational improvement. By structuring data before retrieval and using the graph topology to guide reasoning and summarization, GraphRAG systems can deliver more accurate results with less computational overhead, making them well-suited for enterprise-scale applications.

LinkedIn Customer Service

Traditional RAG systems trained off of historical support data struggle in customer service applications. These systems ingest past tickets, resolutions, and inquiries as flat, unstructured text, missing the deeper structure and interconnections between different types of issues. As a result, retrieval quality is limited, and generated responses often lack precision, contextual understanding, or explainability—especially when similar issues are expressed in different ways or span multiple problem categories.

A recent study by LinkedIn researchers:footnote[Retrieval-Augmented Generation with Knowledge Graphs for Customer Service Question Answering, https://arxiv.org/pdf/2404.17723] addresses these shortcomings by applying GraphRAG to customer service question answering. Their approach involves constructing a knowledge graph from historical support interactions, encoding both the structure within each support case and the relationships across similar or related cases. When a new customer query is received, the system retrieves a subgraph relevant to the issue and uses this structured context to inform the LLM’s response generation. The result is a system that not only understands isolated facts but also reasons over connections between them.

When deployed in a live setting at LinkedIn, the system reduced median issue resolution time by 28.6% over six months. These results demonstrate that GraphRAG is not simply an enhancement to RAG, but a necessary evolution for domains like customer service, where efficiency, accuracy, and relevance depend on understanding structured relationships. By leveraging knowledge graphs, organizations can build support systems that scale more intelligently, provide faster issue resolution, and deliver responses grounded in institutional knowledge rather than surface-level vector similarity.

GraphRAG in Practice: Case Studies

As organizations adopt generative AI technologies, it has become clear that model performance alone is not enough to deliver meaningful business outcomes. LLMs can generate fluent responses, but without access to well-organized, context-rich data, they often produce results that lack accuracy or relevance. To address this limitation, companies are beginning to focus on how data is structured, connected, and made accessible to AI systems.

In this section, we will examine two case studies that illustrate the practical application of GraphRAG. These examples from Data² and Klarna demonstrate how GraphRAG can be used to unify structured and unstructured data, surface hidden relationships, and deliver context-aware answers to complex questions. This section will help you to gain a clearer understanding of the architectural patterns, technical components, and organizational benefits of using knowledge graphs to improve the reasoning and reliability of generative AI systems.

Deeper Insights at Data²

Jeff and the leadership team at Data² recognized early on that traditional data architectures were falling short in industries like energy and defense, domains where the most critical information is buried deep within technical documents, operational reports, and siloed systems. These industries are inherently complex, with dense networks of people, processes, and infrastructure that don’t lend themselves well to relational models.

To solve this, they turned to Knowledge Graphs and Generative AI, creating one of the first real-world implementations of GraphRAG. They constructed a domain-specific knowledge graph in a Neo4j Graph Database that could unify structured and unstructured data—linking entities like facilities, suppliers, geopolitical risks, technical specifications, and regulatory frameworks into a semantically rich graph.

“We think of the knowledge graph as a dynamic, evolving brain that captures the full scope of an organization’s operating knowledge. Our generative AI agent learns and reasons over top of this brain to deliver context-relevant insights and recommendations grounded in data.”

Jeff Dalgliesh, Chief Technology Officer of Data^2^

Their approach combined deep domain expertise in energy and defense with cutting-edge AI techniques. They enriched their graph with insights extracted from unstructured sources like PDFs, maintenance logs, and operational plans using NLP and entity extraction pipelines. This allowed them to capture relationships and dependencies that were previously invisible.

On top of this graph, they layered a generative AI agent capable of interacting with users through natural language. Using an LLM-to-Cypher translation pipeline, the system enabled non-technical analysts to ask complex questions, such as “Which energy facilities are vulnerable due to supplier delays in conflict zones?” and receive structured, grounded, and explainable answers.

Their GraphRAG powered cloud application, shown in Figure 1-10, empowered analysts to explore complex “what-if” scenarios and uncover hidden patterns across multi-hop relationships, while ensuring that every insight remained traceable back to authoritative data.

Figure 1-10. Data²’s GraphRAG powered knowledge graph and GenAI system

Some of the ways that combining Knowledge Graphs and GenAI provided value to Data² include:

Graph as the Data Backbone: By using Neo4j as their graph database, the team was able to organize both structured and unstructured data into a single, semantically rich knowledge graph. This graph provided a more natural way to represent real-world relationships compared to traditional relational databases, making it easier to model complex business scenarios.

GenAI as the Natural Language Interface: The system used large language models to translate user questions into Cypher queries, enabling natural language access to the knowledge graph. This made the platform usable by non-technical users, who could ask questions in plain English and receive accurate, structured answers from the underlying data.

Contextual Reasoning Through the Graph: The knowledge graph provided grounding and context that improved the quality of LLM responses. By including relevant nodes and relationships in the model’s context window, the system increased accuracy and ensured that generated answers were based on reliable and interpretable information.

Data²’s early investment in GraphRAG positioned them as a pioneer in AI-assisted intelligence systems. By building a connected graph of knowledge they moved from simple automating of answers to augmenting human decision-making with a graph-native foundation.

Connecting Data Silos at Klarna

As Klarna scaled beyond 5,000 employees globally, it encountered a growing challenge familiar to most modern tech companies: institutional knowledge fragmentation. Due to a proliferation of SaaS tools for sales, customer support, HR, finance, and engineering, all of their organizational knowledge was locked in data silos. This made it difficult to impossible to make data-driven decisions at scale and lead to wasted effort and time navigating a maze of disconnected sources.

Seeing the strategic cost of this fragmentation, Klarna’s Co-Founder and CEO, Sebastian Siemiatkowski, championed a bold solution: combine the contextual reasoning power of LLMs with the semantic structure of knowledge graphs. This vision led to the creation of Kiki, Klarna’s internal AI assistant.

Built on a GraphRAG architecture, Kiki ingests structured metadata and relationships across systems, teams, and projects into a domain-specific knowledge graph. On top of this graph, Kiki leverages the natural language understanding of large language models to deliver answers that are grounded, contextual, and explainable.

Kiki brings together information across multiple disparate and siloed systems, improves the quality of that information, and explores it, enabling our teams to ask Kiki anything from resource needs to internal processes to how teams should work …​ It’s having a huge impact on productivity in ways that were not possible to imagine before without graph and Neo4j.

Sebastian Siemiatkowski, Co-Founder and CEO of Klarna

Rather than replacing people, Kiki augments them, enabling any employee to access institutional knowledge previously hidden behind departmental boundaries and SaaS data silos.

In the first year of operation, Kiki has shown impressive results with:

1200 SaaS applications eliminiated: By integrating structured and unstructured data into a unified knowledge graph, Kiki has reduced Klarna’s dependency on thousands of siloed tools

250K employee questions answered: Since launching in June 2023, Kiki has become a go-to resource across the organization, streamlining everything from onboarding to internal support

2000 daily queries processed: Kiki continues to scale with growing demand, supported by the performance and flexibility of graph-native architecture

87% employee adoption: 9 out of 10 employees use Klarna in order to gain insights into the business and augment their daily work

Klarna’s investment in Knowledge Graphs and GenAI wasn’t a proof of concept; it was a foundational shift in how knowledge moves inside the company. By replacing scattered data silos with a semantic interface to organizational intelligence, Klarna has improved productivity and redefined how modern enterprises can work at scale.

Summary

In this chapter, you have learned how knowledge graphs provide structure, semantics, and relationships that can enhance the capabilities of LLMs. We explored how knowledge graphs differ from traditional data representations and why they are uniquely suited to address the limitations of standard retrieval-augmented generation. With this understanding, you now have the tools to recognize where structured knowledge and graph-based modeling can add value to GenAI systems.

You have also seen how GraphRAG works in practice through a set of core design patterns, including Text2Cypher, graph-enhanced retrieval, and graph-based reranking. Each of these patterns provides a different path for integrating graph databases into your GenAI architecture, depending on your domain, data structure, and retrieval goals. Understanding these options gives you the flexibility to tailor a solution that fits your organization’s needs, whether that means improving the accuracy of customer service answers, enhancing internal search, or enabling AI agents to interact with business data more intelligently.

Finally, the case studies and benchmark results provided a view into how organizations are already applying GraphRAG to real-world problems. Whether you are working with structured data, a large corpus of unstructured documents, or fragmented enterprise knowledge, GraphRAG delivers higher accuracy, lower operational cost, and greater explainability.

¹ A Benchmark to Understand the Role of Knowledge Graphs on Large Language Model’s Accuracy for Question Answering on Enterprise SQL Databases, https://data.world/mstatic/assets/pdf/kg_llm_accuracy_benchmark_11132023_public.pdf

² From Local to Global: A GraphRAG Approach to Query-Focused Summarization, https://arxiv.org/pdf/2404.16130

³ https://www.microsoft.com/en-us/research/blog/graphrag-unlocking-llm-discovery-on-narrative-private-data/

Chapter 2. A Basic RAG Assistant

A Note for Early Release Readers

With Early Release ebooks, you get books in their earliest form—the author’s raw and unedited content as they write—so you can take advantage of these technologies long before the official release of these titles.

This will be the 2nd chapter of the final book. If you’d like to be actively involved in reviewing and commenting on this draft, please reach out to the editor at jbleiel@oreilly.com.

In today’s enterprise landscape, the ability to navigate and extract meaningful answers from organizational knowledge is becoming a core differentiator. With GenAI systems increasingly used for decision support, employee enablement, and intelligent search, companies are quickly realizing that quality information retrieval is even more important than model performance.

The next two chapters follow OMG Consulting, a fictional yet relatable firm, as it journeys from a basic vector-search based assistant that helps them to manage their employee skills and assignments to a knowledge-graph-augmented retrieval system using GraphRAG. Through their story, we’ll uncover the practical steps, technical architecture, and mindset shift needed to move from text-chunks to connections, and from isolated facts to contextual insights.

Note

Note that we’re not using any framework or library for the RAG and GraphRAG implementation in these chapters, as those evolve quickly and we want to focus on the concepts and techniques and show what’s happening under the hood.

Introducing OMG and the initial simple RAG system

To improve staffing efficiency, OMG Consulting, a small consulting firm, wanted to better match projects to consultants based on their skills, past experiences, and industry knowledge. To support this, the team initially implemented a basic Retrieval-Augmented Generation (RAG) chatbot that searched across CVs, project documents, and internal write-ups to answer staffing queries.

The team identified key use cases and questions that they wanted to cover:

Staffing queries: “Who has worked on JavaScript-heavy healthcare projects?”

Capability mapping: “Which consultants know AWS and have experience with insurance clients?”

Internal search: “Who can skill up on LangChain as a GenAI framework, and has worked on data projects?”

While promising at first, their basic RAG system quickly showed limitations. Those issues can be improved with advanced RAG techniques.

Throughout the rest of this chapter, we’ll explore:

How OMG thought about creating an internal assistant to help consultants find relevant projects

The data sources they ingested, including CVs, project documents, and internal documentation

The initial RAG setup using OpenAI models and ChromaDB for vector storage

The Streamlit app they built to allow users to ask questions and retrieve information

What questions the initial RAG system could answer and where it struggled

How OMG iterated on their RAG system to improve retrieval and answer quality

Example 2-1.

General RAG architecture

As discussed in Chapter 1, Retrieval Augmented Generation (RAG) grounds the answers of an Large Language Model (LLM) in facts retrieved from a trustworthy datasource. The most common approach for an RAG setup relies on the assumption that relevant data has similar meaning to the user’s question.

That’s why most basic RAG approaches, use text embedding vector search for that kind of data retrieval.

Vector embeddings use a machine learning model - an embedding model - to convert text (or other modalities like images, audio) into high dimensional (e.g. 1536) vectors (arrays of floating point numbers) that represent the meaning (or essence) of the content. Similiar phrases or concepts are close by by distance (euclidean) or angle (cosine) in that vector space.

The RAG setup first splits up and encodes the source document fragments with vector embeddings (and often stores them in a vector index). At runtime it encodes each user question into the same embedding space as the document parts before.

And then uses vector distance to

R etrieve the most similar text fragments, which

A ugment the main instruction-prompt and the user question for the LLM to

G enerate the final answer.

Data Sources

OMG had two primary types of data sources:

Unstructured documents

Resumes (PDFs, DOCX, text files)

Project tenders (PDFs)

Project reports (PDFs, DOCX, text files)

Internal documentation (Wiki pages, Confluence)

Structured sources

employee database, with skills

project database

client database

To move quickly and because most GenAI projects center on this type of data, the team focused first on the unstructured content, ingesting resumes and project documents to provide the data sources for their RAG assistant.

Here are two example documents from OMG’s consulting praxis that will be ingested, one CV from “Emily Johnson” and one project report from “NationWide Insurance”.

Both are in Markdown format, you can find them with all the other CV’s and project reports the data/ch02/cv and data/ch02/projects folders.

The CV contains relevant information about the consultants’ skills, experiences, and project assignments.

# Emily Johnson

## Professional Summary
Conversational AI and Intelligent Automation Leader with 9+ years of experience designing and implementing AI-powered conversation systems, virtual assistants, and process automation solutions. Expertise in natural language processing, dialogue management, and AI governance. Proven track record of delivering innovative conversational experiences that enhance customer engagement and operational efficiency.

## Contact Information
- **Email:** emily.johnson@omgconsulting.com
- **Phone:** (617) 555-3976
- **Location:** Boston, MA
- **LinkedIn:** linkedin.com/in/emilyjohnson
- **GitHub:** github.com/emily-johnson-ai

## Education
- **Master of Science in Computer Science**, Carnegie Mellon University (2014)
  - Specialization in Artificial Intelligence and Natural Language Processing
  - Thesis: "Context-Aware Dialogue Systems for Customer Service Applications"
- **Bachelor of Science in Computer Science and Linguistics**, University of Massachusetts Amherst (2011)
  - Double Major
  - Graduated Summa Cum Laude

...

The project report provides details about the client, project scope, team members, and technologies used.

# Insurance Claims Automation

## Project Overview

Intelligent automation of claims processing using AI, machine learning, and robotic process automation. This strategic initiative for NationWide Insurance aimed to transform their operations in the Insurance sector, leveraging cutting-edge technologies and methodologies to achieve significant business impact.

## Client Profile

NationWide Insurance is a leading organization in the Insurance industry that partnered with OMG Consulting to intelligent automation. The project was conducted between 2020-10-01 and 2021-08-31 with a budget of 2300000-3500000.

## Team Composition

OMG Consulting deployed a cross-functional team of 4 consultants to execute this project.

### Key Team Members and Roles

- **Project Lead**: Olivia Martinez (Supply Chain & Operations) - Process optimization, automation strategy, operational efficiency
- **AI Implementation**: Emily Johnson (Conversational AI) - NLP development, document processing, conversational interfaces
- **Data Science**: Sarah Johnson (Data Platforms & Analytics) - Predictive modeling, anomaly detection, algorithm development
- **Development Lead**: Aisha Patel (Enterprise Applications) - Automation development, system integration, workflow implementation
...

RAG Ingestion Process

OMG implemented a prototype GenAI assistant using OpenAI models for text embeddings (text-embedding-3-small) and as LLM (gpt-4.1) to generate answers, and ChromaDB as a vector store.

Note

The models used in this chapter are OpenAI’s text-embedding-3-small and gpt-4.1, which were available at the time of writing and might have been updated or replaced by the time you read this.

The ingestion process followed these key steps:

Load the text files from various document sources

Split their content into manageable chunks with consistent semantic meaning

Create text vector embeddings for each the chunks using an embedding model

Store both embeddings and chunks in a vector database

Let’s look at the code they used for this initial implementation of the ingestion process.

First we load the different document sources into lists.

def load_documents(base_path):
    documents = []

    # Load resumes from cv/*.md
    resume_path = os.path.join(base_path, "cv", "*.md")
    for file in glob.glob(resume_path):
        try:
            with open(file, "r", encoding="utf-8") as f:
                documents.append({"content": f.read(), "source": file})
                print(f"Loaded {file}")
        except Exception as e:
            print(f"Error loading {file}: {e}")

    # Load project descriptions from projects/prj_*.md
    projects_path = os.path.join(base_path, "projects", "prj_*.md")
    for file in glob.glob(projects_path):
        try:
            with open(file, "r", encoding="utf-8") as f:
                documents.append({"content": f.read(), "source": file})
                print(f"Loaded {file}")
        except Exception as e:
            print(f"Error loading {file}: {e}")

    return documents

Then these document lists are processed and split them into text chunks. For each text chunk a text embedding is created using OpenAI’s embedding model, and then the text, filename, chunk position and embedding are stored in a ChromaDB vector database.

# Text splitting - creating semantically meaningful chunks
# In the real world, you would use a more sophisticated text splitter,
# like splitting on headers or paragraphs
def split_documents(documents, chunk_size=500, chunk_overlap=50):
    chunks = []
    for doc in documents:
        text = doc["content"]
        source = doc["source"]
        for i in range(0, len(text), chunk_size - chunk_overlap):
            chunk = text[i:i + chunk_size]
            chunks.append({"content": chunk, "source": source})
    return chunks

# Create embeddings and store in Chroma
def create_vector_store(chunks, persist_directory="./chroma_db"):
    client = chromadb.PersistentClient(path=persist_directory)
    collection = client.get_or_create_collection("documents")

    for i, chunk in enumerate(chunks):
        response = openai.embeddings.create(
            input=chunk["content"],
            model="text-embedding-3-small"
        )
        embedding = response.data[0].embedding
        collection.add(
            documents=[chunk["content"]],
            metadatas=[{"source": chunk["source"]}],
            ids=[f"chunk_{i}"],
            embeddings=[embedding]
        )
    return collection

You can run the ingestion script to process the documents and create the vector store.

uv run python code/ch02/rag_ingest.py data/ch02/

Next, OMG built a simple Streamlit application to serve as the user interface for their RAG system.

Streamlit App for the OMG RAG Assistant

They created a Streamlit app to allow users to ask questions, retrieve relevant information from the vector store and have the LLM generate the answer.

Note

Streamlit is a popular framework for quickly building interactive web applications in Python, especially for data science and machine learning projects. It works in a straightforward way - you write a Python script that defines the UI and logic togeher, and Streamlit automatically generates a web app from it. The script is executed in a loop, and observes changes to the variables and UI elements, updating the web app accordingly.

OMG’s assistant, followed the same patterns as msot RAG based chatbots:

User inputs a question.

The app generates a text embedding for the question using the same embedding model.

The most releveant text chunks are retrieved by embedding similarity search from the vector store.

The context is assembled from system prompt, user question and the retrieved chunks.

The OpenAI LLM generates a final response based on that context.

The answer is displayed to the user.

The user can ask follow-up questions, and the process repeats.

import os
import streamlit as st
from openai import OpenAI

import chromadb

openai = OpenAI()
openai.api_key = os.environ["OPENAI_API_KEY"]
messages = [{"role": "developer", "content": """
             You are a helpful assistant to help OMG consultants to determine consultant placement,
             you have information about the consultants, their skills, and project experience as well as
             past project details, customers and their descriptions.
             """}]

@st.cache_resource
def load_vector_store(persist_directory="./chroma_db"):
    client = chromadb.PersistentClient(path=persist_directory)
    return client.get_or_create_collection("documents")

def similarity_search(vectorstore, query_embedding, top_k=5):
    results = vectorstore.query(
        query_embeddings=[query_embedding],
        n_results=top_k
    )
    return results["documents"][0]

def generate_embedding(query):
    response = openai.embeddings.create(
        input=query,
        model="text-embedding-3-small"
    )
    return response.data[0].embedding

# Generate a response using OpenAI LLM
def generate_response(context, query):
    prompt = f"""
    You are an assistant for OMG Consulting.
    Answer the question based on the following context.
    If the answer cannot be determined from the context, say so.

    Context:
    {context}

    Question: {query}

    Answer:
    """
    messages.append({"role": "user", "content": prompt.format(context=context, query=query)})
    response = openai.chat.completions.create(
        model="gpt-4.1",
        messages=messages,
        max_tokens=200
    )
    answer = response.choices[0].message.content
    messages.append({"role": "assistant", "content": answer})
    return answer

# UI setup
st.set_page_config(layout="wide")
st.title("OMG Consulting Assistant")
st.write("Ask questions about our consultants, their skills, and project experience")

# Load vector store
with st.spinner("Loading knowledge base..."):
    vectorstore = load_vector_store()

# User query section
query = st.text_input("Ask a question:")
if query:
    with st.spinner("Searching for information..."):
        # Generate query embedding
        query_embedding = generate_embedding(query)

        # Perform similarity search
        search_results = similarity_search(vectorstore, query_embedding, top_k=3)

        # Assemble context from search results
        context = "\n\n".join(search_results)

        # Generate response
        response = generate_response(context, query)

        # Display response
        st.write("### Answer")
        st.write(response)

        # Display sources (for transparency)
        st.write("### Source Documents")
        for i, doc in enumerate(search_results):
            with st.expander(f"Source {i+1}"):
                st.write(doc)
#                st.write(f"Source: {doc['metadata'].get('source', 'Unknown')}")

If you run the streamlit in the same folder where the vector database is stored, it opens the web application and you can start asking it simple questions.

uv run streamlit run code/c02/rag_app.py

If you ask for information like "Who is Emily Johnson?" or "What is the Cybersecurity Transformation project about?", you will get answers based on the ingested documents fragments, as you can retrieve enough of them to stitch together a coherent answer.

Initial RAG Implementation - Uses and Shortcomings

But if you ask slightly more complex questions like “Who has worked on the Cybersecurity Transformation project?”, the LLM cannot provide an answer, as the retrieved chunks don’t contain the relevant information. You might even end up with the model hallucinating an answer, as it cannot find the relevant information in the retrieved chunks but still tries to be helpful.

In these situation it is better to check if chunks were retrieved that contain the information you are looking for, and if not, to ouput a message like “I cannot answer that question” instead of trying to passing to the LLM which might make up an answer.

The chunks often contain the information that the person or project exists - which is also the relevant lookup phrase from the user’s question to find it in the vector store in the first place, but often not the associated details that are needed to answer the question.

As those pieces of text are no longer connected with each other, due to the chunking and storage, their original correlation cannot be reconstructed by the RAG system.

You can argue that in this case you could just store the whole (smallish) document with each chunk, but that would not scale well with larger documents and larger corpora.

While this initial RAG implementation worked for basic queries, OMG quickly discovered its limitations for more complex information needs. The vector-based approach struggled with questions whose structure and intent were not exactly represented in the source data or that required connecting information across documents (or even chunks) or understanding relationships between entities.

These were questions like:

“Who has worked across multiple healthcare projects?”

“What technologies has Emily Johnson not used in her past projects?”.

“What skills is Alexander Schmidt missing to staff this Global Investment Partners migration project?

Advanced RAG Patterns

This realization would lead the team to explore advanced RAG patterns like:

question rewriting

Rewrite user questions in the space and domain of the available documents to improve vector retrieval.

relating chunks

Relate chunks to each other based on their position (siblings) and to their parent documents.

hybrid retrieval

Combine vector search with keyword search to improve recall and apply re-ranking to the results.

contextual embedding

Generate embeddings not just for the document chunks but a combination of a summary of the document and a rewritten chunk in the context of the domain.

multi-question retrieval

Retrieve the same question slightly rephrased multiple times to improve recall and coverage of the vector search.

However, these techniques still fell short when it came to understanding the deeper relationships between entities like people, projects, clients, and skills. And especially the last techniques increased the complexity of the RAG pipeline and the amount of data that needed to be processed by the LLMs and embedding models without significant improvements for the more complex questions.

The GraphRAG Approach

Many of these advanced RAG techniques actually represent workarounds to restoring connections between contextual information. So they looked suspiciously similar to what a graph database would be able to do easily by representing both chunks and documents but also the entities like people, projects, clients, and skills as nodes and relationships in a graph.

Some consultants with past experience in graph databases started looking in the literature for advanced RAG patterns, that actually utilized graph databases for retrieval and unsuprisingly to us, discovered GraphRAG as a suitable technique.

So they untertook a second attempt of structuring their information into a connected network and using retrievers that take much more context into account when answering questions. They also wanted to see if it is possible to not only answer content questions but also questions like “How many people in our company have both GenAI and Healthcare experience?”

Summary

In this chapter, we followed OMG Consulting’s journey as they built their first RAG-based AI assistant to help match consultants to projects.

We explored their initial setup, the challenges they faced with complex queries, and the limitations of a basic vector search approach.

We also mentioned advanced RAG techniques they could try to improve retrieval and answer quality.

Finally we introduced the idea of using a graph database to represent the relationships between entities and documents, which would lead to the next chapter’s focus on GraphRAG.

About the Authors

Stephen Chin is VP of Developer Relations at Neo4j, conference chair of the LF AI & Data Foundation, and author of numerous titles with O’Reilly, Apress, and McGraw Hill. He has given keynotes and main stage talks at numerous conferences around the world including AI Engineer Summit, AI DevSummit, Devoxx, DevNexus, JNation, JavaOne, Shift, Joker, swampUP, and GIDS. Stephen is an avid motorcyclist who has done evangelism tours in Europe, Japan, and Brazil, interviewing developers in their natural habitat. When he is not traveling, he enjoys teaching kids how to do AI, embedded, and robot programming together with his daughters.

Michael Hunger has been passionate about software development for more than 35 years.

For the last 15 years, he has been working on the open source Neo4j graph database filling many roles, most recently leading Product Innovation and Developer Product Strategy. He especially loves to work with graph-related projects, users, and contributors, his current focus is generative AI, GraphRAG, cloud integrations and developer experience.

As a developer Michael enjoys many aspects of programming languages, learning new things every day, participating in exciting and ambitious open source projects and contributing and writing software and data related books and articles. Michael spoke at numerous conferences and helped organize several. His efforts in the Java Community got him accepted to the JavaChampions program.

Michael helps kids to learn to program by running weekly girls-only coding classes at local schools.

Dr. Jesús Barrasa is the Field CTO for AI at Neo4j, where he works with organisations combining the power of LLMs with Knowledge Graphs. He co-authored “Building Knowledge Graphs” (O’Reilly 2023) and is cohost of the Going Meta live webcast (https://goingmeta.live/). Jesús holds a Ph.D. in Artificial Intelligence/Knowledge Representation and is an active thought leader in the KG and AI space.