The Knowledge Graph Mullet: Trimming GraphRAG Complexity - William Lyon

Hey everyone, my name is Will, and in this talk we're going to be learning all about the knowledge graph mullet and how it can trim GraphRAG complexity. Uh, let's jumpright in. So, bear with me a little bit in this analogy, but if you're familiar with the mullet haircut, this is a classic business in the front, party in the back, sort of short up front, long in the back hairstyle that was popular in the '80s and '90s.

And if we think of, like, what are the benefits of the mullet haircut, it's really all about low maintenance, easy to work with, but versatile and adaptable in different environments. And if we extend that analogy to knowledge graphs, that gives us the knowledge graph mullet, which is all about property graph in the front and RDF triples in the back.

So really what this talk is about is combining concepts from the property graph world and the RDF world to have a hybrid and versatile approach for working with knowledge graphs. So if you're familiar with the graph ecosystem at all, you've probably heard some of this terminology, but property graph and RDF are typically thought of as two totally different paradigms for working with graphs.

In the property graph world, we're thinking about nodes, relationships, key-value pair properties. We're thinking about traversing the graph using pattern matching, often with a query language called CIPHER. In the RDF world, we're typically talking about ontologies using a query language called SPARKL, thinking about triples.

RDF comes from the semantic web and linked data world. And what I want to show today is that really these concepts can be used together, where we can really leverage the benefits and sort of best of both worlds to, again, expose a property graph model for how we want to think about and query the data, but leverage the scalability of RDF triples in our knowledge graph system.

We're going to take a look at an open-source project called Dgraph to work with our knowledge graphs. Let's talk about, really, like, a working definition of knowledge graph first of all. So we're going to say that a knowledge graph is really just an instance of a property graph.

So the property graph model is all about nodes. Nodes can have one or more labels, which is a way to

tell us what type of node we're talking about, a way to group nodes. You can think of labels as kind of similar to, like, tables from the relational database world. And then we have relationships that have a single type and direction.

Then we can store arbitrary key-value pair properties on nodes and relationships. And the semantics,right, so how our entities are connected, is encoded in the data model. We don't just say that two nodes are related to each other. We say that this talk has a certain topic, or this talk was presented at a conference,right?

We're talking about things, not strings, which was the title of Google's blog post in 2012 introducing the Google knowledge graph. But I think that'sright. I think that's one of the most important pieces of thinking about knowledge graphs is that we have a canonical representation of the thing.

Dgraph was first open-sourced and released in 2017, and initially was really optimizing for large-scale graph data. So the D is for distributed and scale in terms of volume. So the original Dgraph team came from ex folks from Google that were inspired by Google's Spanner graph.

Dgraph is this really interesting sort of hybrid in this world of graph databases, where we use the property graph model for data modeling and querying, but we use RDF for data interchange, and we work with triples as the smallest unit of record.

So if we take a look at these two paradigms that we're talking about, the property graph model where nodes, node labels, relationship types, and key-value pair properties are sort of the core fundamentals of the data model. And if we compare that with RDF, which is all about triples.

So subject, predicate, object, which we can think of as, like, a sentence. The subject, this is always going to be a node. A predicate can be a relationship or a property. And then an object, in the case where the predicate is a relationship, is a node or the value of a property.

Let's look at how Dgraph works with both property graphs and triples. So the first thing we need to do to model a property graph as an RDF triple is to have a unique ID for each node. The unique ID maps to some offset in disk so that we're able to traverse the graph very quickly and efficiently.

Then the next piece is, again, to think of our node as the value of our unique ID. So the subject, we said, is always going to be a node, and really specifically it's always going to be a unique ID that's like a pointer to the node.

Then the predicate is going to be a relationship or a property. And in the case where it's a relationship, then our object is going to be another node ID. So this is going to be a predicate that connects two nodes as a relationship, or it's going to be the value of our property.

Dgraph uses an important optimization called a posting list, where we are grouping by predicate and using a list of the unique node IDs of all the nodes that this node is connected to by that predicate. So this allows us to traverse the graph very efficiently.

DQL, we said, is the query language that we use with Dgraph. DQL was very much inspired by GraphQL. GraphQL was open-sourced by Facebook shortly before Dgraph was released, and at that time there was a lot of interest in exploring GraphQL beyond its intention as an API query language.

So we can see some similar concepts from DQL. We start every DQL graph traversal with a well-defined starting point, so that's our root criteria here, where we're often using an index to find the nodes as the starting point for our traversal.

Then we use a selection set structure, which is this nested structure that specifies both the properties that we want to return to our query, but also this nested structure represents a traversal in the graph.

Similar to GraphQL, the data returned from a DQL query is JSON that matches the structure of our selection set. Let's take a look at an example using news data. So how would we create a knowledge graph of news articles?

So here's an example from the New York Times. So we have a news article, and if we think of what sort of graph model we would build from this, well, we would think of the entities that are mentioned, like what are the organizations, the people, the topics that are mentioned.

We might model those as nodes in the graph. We also have the author. We have images to think of. And we also have unstructured data to work with in the graph. Now, there are different approaches for how we might chunk and embed unstructured data, maybe using the semantic structure of the article.

In this example, we're just going to say every paragraph is a chunk, and we're going to model those chunks as nodes in the graph. So here's a graph model that we're going to use to represent our news knowledge graph.

We have an article node that represents the article itself. It has a URL, a publish date, a title, and abstract. But then we have the author of the article, topics that may be mentioned in the article, organizations that may be mentioned.

We also have geographic areas that might be mentioned in the article, and images as well. So you can see how we can traverse from the article to the topic node to then other articles that have the same topic or that mention the same geographic location.

Now, we mentioned chunking and embedding earlier. What we're going to do is calculate an embedding of each chunk and store that as a node property. This will allow us to use vector search as an entry point for our graph.

So vector similarity search gives us an entry point into the graph. We can think of this as the lexical graph, where we're identifying chunks of a document that are close to vector space of an embedding of our query.

But that's just the start in GraphRAG. In a naive RAG approach, we would do the vector search to find these chunks. That document would then be injected into the prompt to add context. But in GraphRAG, that's just the starting point.

Then we traverse through the graph to the article nodes, to the topics that are relevant for this article, to other articles that have the same topic or that mention the same organization. And again, that's just one entry point.

The other entry points might be using a geospatial index. Maybe we want to find all of the news about

areas within a certain region or find news articles near me and then traverse the graph to find other relevant articles that become context for our model. Similarly, we might have an image embedding model where we're doing image similarity search as well, again, just as an entry point.

So I like to think of GraphRAG really being all about different subgraph entry points, where we have this concept of the lexical graph for vector search with unstructured data, the domain graph that we're sort of traversing through to find relevant context for the model.

Let's take a look at a hands-on example of actually using this data with Dgraph. This is a tool called Retell, which is a query workbench for Dgraph. We can execute DQL queries and work with and visualize the results.

Our initial query was just a simple count of the number of articles. Let's look at a more complex query where we are searching for the first 10 articles, then traversing the graph to find topics connected to those articles.

So we can inspect the graph in this graph visualization to have an idea of how these topics are connected to articles. Let's look at a more complex example. So here we are filtering for articles that are published after a certain date and then traversing to the geographic areas mentioned in those articles.

Let's see how we can use the

geographic distance search in Dgraph. So here we're looking for geographic areas in the news that are within 50 kilometers of New York City and then traversing to find the articles connected to those geographic regions. And we can see things like Manhattan and Brooklyn.

Let's look at a vector search example. So using the vector similarity search functionality in Dgraph, we're passing an embedding. I think this is an embedding of the phrase "money laundering" and looking for articles that are close in vector space and then traversing to find

topics, geographic regions, organizations connected to

these articles. We can then add a more complex traversal to then search from those articles that were a match for our vector similarity search to traverse through the topic nodes to find other articles that have overlapping topics but that may not have shown up through our vector similarity search.

And this gives us a way to, in this case, visually explore the graph. But of course, we can look at the JSON representation of the data return that matches our selection set. Okay, that was a quick look at using DQL to query our Dgraph instance.

I want to talk about some of the features in the latest release of Dgraph. The first interesting bit is that all of the enterprise features of Dgraph have been moved into a single open-source release, and we're continuing to add new features.

The interesting one I want to dive into in this case is Model Context Protocol, so the MCP server for Dgraph. So let's talk a little bit about MCP, and then we'll look specifically at the Dgraph MCP server. So this is a screenshot from the Anthropic Deep Learning.ai course, which is linked here.

This is, I think, a really good course if you're interested in not just learning about the concepts of MCP, but how do you actually build and deploy MCP servers. Fundamentally, MCP is a way of exposing tools to models.

And in the context of databases, this means we're giving the database we're giving the model, rather, a way to interact with our database. With Dgraph, each Dgraph instance serves an MCP server. There's a read-only instance, which will only expose the ability to execute queries or inspect the schema.

And then the full endpoint also exposes functionality for mutation, so adding data, and also a tool for altering the schema.

So some of the use cases for the Dgraph MCP server are in agentic coding assistance environments, so tools like Windsurf or Cursor, where we're able to do things like leveraging the schema or the data that are retrieved from the MCP server to

auto-generate writing CRUD endpoints in our app or other way generating DQL queries in our app. Another use case might be more exploratory data analysis, which we might do in a tool like Claude Desktop, where we're actually generating DQL queries and fetching data from the database to understand what data is in our graph.

Let's take a look at using the Dgraph MCP server with Claude Desktop. So the first thing I'm going to do is sign in to Hypermode and create a new graph. Hypermode graphs are powered by Dgraph, so this is going to deploy a Dgraph cluster, including the MCP server endpoint.

So we can see the MCP configuration in addition to the Dgraph connection string. So we'll copy the MCP configuration, and in Claude Desktop, we'll edit the developer config and paste in that MCP configuration and then restart Claude, which will give us access to the MCP server tools for Dgraph.

Let's load some sample data into Dgraph. So let's create fictitious customer, product, and order data for, say, for an e-commerce use case. And so the first thing that Claude is going to do is update the schema. I should say, actually, the first thing it's going to do is inspect the schema and see that our database is empty.

Then generate a graph schema that represents the data model that we're going to work with, so orders and how they're connected to products and customers. Then Claude is going to generate a series of mutations to actually create data in the graph, generating fictitious customer names, customer information, products, and so on.

Now, it's important to point out here that with database MCP servers, it's the model that is generating the database query and then using the tools defined in the MCP server to execute those queries against the database. And Claude is smart enough to verify that the data created in the database matches its expectations.

So here we can see that Claude is generating DQL queries to verify the data was actually created as expected.

In this case, it found missing relationships, and so it's adding a mutation to add those relationships to the graph. Now, this is a really interesting way for learning new developer tooling. So here we've created a graph schema. We've added data to the graph without really having to worry about the specific query language.

But it's a great way to learn that query language, learn how to use these developer tools. Now let's generate a graph visualization to understand the data in the graph. So here Claude generates a query to fetch data from the graph and generates the JavaScript to render a graph visualization.

So this is a helpful way to understand the connections in our graph. And we have ways for viewing the schema, zeroing in on customers and orders, or just inspecting product information. We have different layout options in addition to the typical force-directed layout.

Hierarchical or radial layouts can be useful for interpreting graphs. But let's stick with the force-directed layout, and let's explore using Dgraph for generating product recommendations for a specific user. So this is a typical graph database use case, generating personalized recommendations by traversing the graph.

You can think of the different approaches we could take here, from collaborative filtering, which could be find similar users in the graph. What are those users purchasing that our user is not? Those may be good items to recommend to the user, to content-based recommendations based on the purchase history of our user.

What are attributes that they may be interested in? Demographic approaches as well. And here Claude is generating queries that show us using these different approaches and then how these can be combined to generate a single database query. Now, Claude doesn't always get the queriesright.

So this example, we can see there's an error with the first approach. And so Claude is going to iterate a bit until we get back results as expected. Again, really useful tool, I think, for understanding some of these concepts.

Now, our final deliverable here is going to be an HTML report that Claude is going to generate that allows us to explore the different approaches for implementing these recommendations and show us the results as well as the DQL query used for each of these.

So that was a look at the Dgraph MCP server. If we zoom out a little bit, so far we've seen how to work with knowledge graphs, how to expose tools to a model for interacting with that knowledge graph through Dgraph.

But there's a piece that's missing here, which is the agent orchestration. And so to enable building agentic apps, at Hypermode, we've created the Modus Agent Orchestration framework, which is an open-source framework for creating AI agents, really for bringing data to models and exposing tools and abstractions for working with agentic flows.

So Modus is an open-source project. You can find this on GitHub. Really, the functionality we think of in Modus is abstractions, not only for working with models and data, but a runtime for working with large-scale number of agents that are stateful and long-running, which is why we think it's important to have a runtime as well as an SDK library for working with agents.

Modus does some interesting things with WebAssembly. So we use WebAssembly to target multiple languages for different SDKs. So you're able to write your logic in languages like Go or AssemblyScript. And then under the hood, that is compiled to WebAssembly, and a single unified GraphQL API is generated that leverages the types that you've defined in your Modus app and the signature of the functions you've defined to stitch a single GraphQL schema together.

The Modus runtime, leveraging WebAssembly, gives us some advantages as well for security and a sandbox environment for your AI agents to run in. But all of that WebAssembly aspect is abstracted away from the user.

So leveraging now these open-source components, so the Modus Orchestration framework, leveraging Dgraph for building knowledge graphs. Let's take a look at building domain-specific agents, starting with a prompt. So this is the core for Hypermode agents, where we think it's really important to be able to get up and running with a domain-specific agent by writing a prompt and exposing tools via MCP server.

So for my final demo, we'll take a quick look at Hypermode agents. I'm going to switch back to Hypermode, and we're going to go to the Threads tab, which is our area for building agents. Let's create a new agent.

We'll give them a name, blah, blah, blah. Works in our marketing department as a social media intern. We're going to define a prompt, which gives our agent a bit of background. He's going to be a social media expert who's really good at creating short snippets that are showing developers how to use deep technical tooling and explain technical concepts.

We'll choose a reasoning model. We'll use the GPT-4.1 model to orchestrate this agent. And then the next thing we need to do is add connections. So our agent needs to be able to interact with its environment. So we'll give him access to GitHub, Notion, and our company docs through Ref.

These are all MCP servers that are exposing tools that allow the agents to interact with those services and authorize on our behalf. So let's give him a task to analyze a specific GitHub repo, in this case, the hyper-news repo, which has the tooling for importing, building, querying, and working with that news knowledge graph that I showed earlier.

And we're going to generate social media posts that explain how to use some of the concepts explained in that GitHub repo. So at the beginning, we can see the tool calls that our agent made. So first, he's searching for the hyper-news GitHub repo using tools from the GitHub MCP server, then getting specific file contents to use to generate social media posts that show how to use specific features explained in, or I should say, implemented in this GitHub repo.

So this is a good start, but let's ask our agent to update these posts to include some relevant code snippets. And so our agent is now going to choose what tools to call here, going back to GitHub, looking at source files that may be relevant, and adding code snippets here.

So now you can see our social media posts have code snippets where appropriate. And this is a mix of DQL queries when we're talking about Dgraph, some Go code from the Modus SDK, some terminal commands. This looks good.

Let's ask our agent to save this to our Notion workspace so that we can queue these up to post on our Twitter account. And we need to tell our agent what page to use. So we'll say, let's post these to my private Scratchpad.

And again, we've authorized the agent to have access to our Notion workspace through the Notion MCP server. So that's how our agent is able to access my Scratchpad page. And we can see the Notion tools that our agent used to update our Notion page.

And if we switch over to Notion, we can see my Scratchpad that includes our updated code snippets for our social media posts. So that's really cool. We built an agent just from a prompt, gave him access to actually interact with GitHub and Notion on my behalf.

One thing that's really neat about Hypermode agents is I can now eject to code to have the Modus code that we're using to actually run this agent. So I can then add more complex logic, other connections to enhance my agent using Modus.

So that was a quick look at Hypermode agents, being able to create an agent from a prompt and access to MCP-powered connections while also being able to eject to code, leveraging our open-source tooling. Hypermode agents is in early access now.

So there's a link there on the screen if you'd like to sign up to give this a try for early access.

Great. Well, that was a look at the knowledge graph mullet, how we can leverage tools from the property graph and RDF ecosystems to build powerful GraphRAG workflows as the foundation for building AI agents. I hope you found that useful.

Feel free to use that link on the screen to check out the slides and also look at the resources that we've added in the video description. Thanks a lot for watching. Cheers.