AI Engineer World's Fair 2026
A Practitioner's Guide to Graphs - Tim Ainge, Good Collective
Read the talk
Useful Graphs Begin with Structure
From recipe extraction to code search, graph schemas, entity matching, ranking and path algorithms turn connected data into useful context for AI applications.
From a talk by Tim Ainge
Before you start: Basic familiarity with structured data and database queries is helpful; no prior knowledge of graph algorithms is required.
When does a graph actually help?
An Obsidian graph can look compelling without making your notes more useful. The same temptation appears when adopting GraphRAG or rebuilding an e-commerce application around a graph database: the representation looks promising, but the expected payoff does not immediately arrive. The useful question is which problem becomes easier because its relationships are explicit.
Graph fundamentals provide a way forward. Search, pattern recognition, retrieval and knowledge problems often contain relationships that a graph can expose and algorithms can exploit. Tim Ainge’s approach starts there: understand the structure before committing to a particular graph product.
This is a guide to those underlying patterns, rather than a GraphRAG or agent-memory tutorial. The progression is practical: establish the graph primitives, improve how information enters the graph, and then use algorithms to retrieve information that is difficult to find by names or text similarity alone. Each technique connects a principle to an example and then to an application.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Give extraction a shape
A graph consists of nodes, also called vertices, and edges connecting them. Types and labels distinguish what those nodes and relationships mean; properties attach detail, and direction distinguishes one relationship orientation from another. These additions turn a collection of connections into a model you can interrogate.
Consider extracting a graph from a recipe. A minimal output format is a subject–predicate–object triple: one thing relates to another thing. Ask an extractor to pull the key information from a pancake recipe into triples, leaving it to decide what matters, and it can produce a graph. But producing a graph is a weaker requirement than producing a useful one. The extractor still chooses the structure and vocabulary of the relationships.
Instead, give the extractor a schema to fill: a recipe has ingredients, and each ingredient has a quantity. Structured outputs constrain the result to that shape. In the illustrated schema example, Garlic Butter Pasta connects to garlic, parsley, butter, spaghetti and parmesan. The improvement is not merely a tidier drawing; the extraction now uses a consistent model.
Consistent node and edge types give queries a stable meaning. Extend the recipe schema with steps, then represent each step as the application of a cooking technique. The graph can now distinguish what a recipe contains from how it is prepared, rather than making every fact an arbitrary relationship.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Standardize values, then resolve identities
The schema defines the structure; the ontology, as used here, adds instructions about precisely what belongs in that structure. For recipes, standardize ingredient names and use metric units so that matching and conversion become easier. Lowercase names and consistent units are part of the data model, not cosmetic cleanup. Prompting for those conventions improves extraction, but even a good prompt cannot guarantee consistency.
Identity is the next problem. Separate nodes for garlic cloves, minced garlic and garlic can fragment recipes that ought to share an ingredient. The demonstration also includes cumin and cumin seeds, and vegetable oil and oil. A naive mapping consolidates these variants. That removes duplication and, more consequentially, connects recipes through a common ingredient node.
Retrospective name mapping has a limitation: it depends on anticipating the ingredient terms that will appear. Embedding-assisted matching makes the process more flexible, including for terms absent from a predefined mapping. The useful combination is AI-assisted matching within a deliberately structured graph.
The resulting construction process has three layers: establish a schema, curate the information extracted into it, and match entities before creating new nodes. Resolving identity changes which relationships the graph can reveal. A recipe cannot share a garlic node with another recipe if each extraction creates its own unrelated version of garlic.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Query recipes through shared ingredients
Start with a simple query: which recipes contain garlic? Ainge places a Cypher query beside its SQL equivalent. Using Recipe, Ingredient and HAS_INGREDIENT as concrete schema names, the relationship pattern can be expressed as follows:
cypher
MATCH (recipe:Recipe)-[:HAS_INGREDIENT]->(:Ingredient {name: 'garlic'})
MATCH (recipe)-[:HAS_INGREDIENT]->(ingredient:Ingredient)
RETURN recipe.name AS recipe,
collect(DISTINCT ingredient.name) AS ingredients;
The first match selects recipes through the shared garlic node. The second retrieves their ingredients.
The displayed result contains recipes with garlic and their ingredient connections, pruned to fit the slide. At this depth, either query language can express the task. The distinction becomes more useful when the question requires following five, ten or twenty edges: a graph query describes the relationship traversal directly, while the equivalent relational query can become cumbersome. Ainge presents this as a structural advantage of graph queries and graph data structures, not as a measured database benchmark.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Rank relevance from a starting node
Personalized PageRank moves beyond asking whether a connection exists. It ranks nodes relative to a chosen starting point. It is a variant of the PageRank algorithm associated with Brin and Page.
Imagine a walker following edges through the graph and marking each node it visits. Periodically, the walker returns to the starting node and begins again. That return is what makes the ranking personalized: repeated exploration stays anchored to the selected starting point. Over many walks, some nodes accumulate more visits than others, indicating stronger relevance under this traversal process. The walker is an explanatory analogy, rather than a requirement to implement fixed-length walks.
The recipe illustration starts from Chicken Handi and shows surrounding recipe and ingredient nodes with different brightness. Ainge connects this idea to Pinterest’s Pixie paper, which uses graph walks for recommendations.
HippoRAG provides a retrieval application: personalized PageRank works with other graph techniques to connect stored knowledge to questions and answers. Ainge points to variants in the presentation pack. The small recipe example may make relevance look obvious, but ranking becomes especially useful in dense clusters where visual inspection no longer makes the important relationships clear.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Retrieve the code between two known symbols
Sometimes both endpoints are already known, but their relationship is not. Suppose checkout breaks after a change to the basket constructor. A shortest-path query can follow the code graph between those two nodes and retrieve the intervening symbols, source text or summaries as context. This changes the search task from finding either endpoint to finding the code that connects them.
The appropriate path depends on the question:
| Path query | What it retrieves |
|---|---|
| Shortest path | A most direct connection |
k shortest paths | Several short alternatives |
| Path through a specified node | A connection constrained by an intermediate node |
| Minimum-cost path | A connection minimizing total edge weight |
These variants help select which intermediate nodes and relationships might explain the connection between the endpoints.
Retrieving a connecting subgraph can supply context that isolated vector searches or individual symbol and reference lookups miss. Ainge reports a 40% reduction in code-search tool calls in one evaluation on a .NET codebase using graph techniques like these to select agent context. The baseline, task set and correctness results are not supplied, so the result supports that particular evaluation rather than a general performance guarantee.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Find a pattern without knowing its names
Subgraph matching changes the starting point again. Instead of choosing a node and navigating outward, specify the shape of the relationships you want to find. Node types or IDs can still constrain the query, but they are not required to identify a particular instance in advance.
The eShop demonstration searches for a decorator: a wrapper uses a target class, and both implement the same interface. With Class, Interface, IMPLEMENTS and USES as schema names, that shape becomes:
cypher
MATCH (wrapper:Class)-[:IMPLEMENTS]->(contract:Interface),
(target:Class)-[:IMPLEMENTS]->(contract),
(wrapper)-[:USES]->(target)
WHERE wrapper <> target
RETURN wrapper.name AS wrapper,
target.name AS target,
contract.name AS sharedInterface;
The shared contract variable requires both classes to implement the same interface. The USES relationship supplies the connection from wrapper to target. No class name needs to appear in the query.
The search finds a catalog view model service and a cached version that calls it while implementing the same API. The relationship pattern discovers the caching decorator without first searching for a caching-related name.
That distinction matters when you know the structure of a problem but not its vocabulary or location. Potential targets include code anti-patterns, security issues, malicious transaction patterns and legal arguments across a corpus. A name search requires some knowledge of the instance; a structural query can look for the relationship arrangement itself. Subgraph matching enables a different kind of discovery, beyond making an existing lookup faster.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Beyond paths, ranking and patterns
Paths, ranking and pattern matching cover distinct questions: how two things connect, which things matter relative to a starting point, and where a relationship structure occurs. Other established graph algorithms address flow, cost and search problems in dependency and network models. Prediction, similarity and clustering extend the range further; Ainge leaves those for the presentation notes.
Those further directions approach GraphRAG, dynamic graphs and schemaless graphs, beyond the scope developed here. The practical opportunity is to combine graph algorithms with AI where each contributes something useful: AI helps extract and match information, while explicit relationships support traversal, ranking and structural discovery. Smarter, cheaper and more reliable applications are the goal of that combination, with the result depending on choosing a graph structure and algorithm that fit the actual problem.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Resources
From the talk
Pinterest's original paper on personalized recommendations using random walks over a graph of pins and boards.
A retrieval framework combining language models, knowledge graphs and personalized PageRank to connect information across documents.
The official Supreme Court decision used as the starting case in the talk's citation-graph example.
Further reading
Official code and setup examples for experimenting with HippoRAG retrieval.
An archived .NET sample guide explaining the catalog service and its caching decorator, with shared-interface registration examples.
Read the complete timestamped transcript
- 0:01
Hi, I'm Tim Ainge from The Good Collective, and welcome to AI Engineers presentation, A Practitioner's Guide to Graphs: How to Make Your AI Applications Smarter, Cheaper and More Reliable.
- 0:14
Graphs have always been a powerful foundation of computer science, and they look beautiful. But sometimes they're genuinely not the right tool for the job. We've all felt the wonder of a mesmerizing data science graph or ogled the graph view of our Obsidian vault.
- 0:31
It can be tempting to rush into something like GraphRAG or rebuilding our e-commerce shop with a graph database. But often we don't see the instant payoff we might have expected.
- 0:42
In frustration, many journeys end here in the dust at the bottom of the valley of despair and disillusion. What's on the other side of the valley and how do we get there?
- 0:53
That's exactly the question that sparked the idea for this talk. Have I nailed all of the answers? Definitely not. But what I'm finding is that the more I learn about the fundamentals of graph data structures and algorithms, the more interesting opportunities seem to present themselves.
- 1:10
Many of these graph-native use cases or good fits for graphs are also a lovely complement to many of the search, pattern recognition, retrieval, or knowledge-based problems that are ripe for solving in the AI age.
- 1:24
Now, just a quick disclaimer. This talk isn't going to go into GraphRAG or agent memory graphs. Not because I'm throwing shade on those patterns and products, but partly because there'll be many other talks covering each of those single topics.
- 1:37
But more importantly, this talk is for AI builders, and I'd like to focus on the underlying patterns which may just help you come up with your next big graph-powered AI application.
- 1:47
Today, we're going to speedrun the basics of graphs. Then we'll walk through some tips and tricks for building better graphs to get better results. And then we'll look at graph-native algorithms that leverage a graph and the benefits that they deliver.
- 2:01
At each step of the way, we'll open with a principle, look at an easy example and some code, and then finally, we'll reference some real-world examples with real-world benefits.
- 2:14
All right, let's speedrun the basics. What's a graph?
- 2:18
A graph is something that has nodes, also called vertices, and edges, which I sometimes call relationships, that connect the nodes together. That's it. That is the most basic definition of a graph.
- 2:30
We can have different types of nodes and edges which convey more meaning. Uh, we can also put labels on edges or nodes that have properties, and of course, edges can have direction.
- 2:44
Now that we've speedrun that, a really, really important part of getting good value out of graphs is how we build good graphs. Today, we're going to focus on extracting graphs from unstructured text, because that's a pretty common use case and a pretty popular one at the moment.
- 3:01
So in this example, we've defined a very basic data structure for our graph, a triple that has a subject, a predicate, and an object, or a node that somehow relates to another node.
- 3:16
And we say to our agent, "Hey, go and pull the key information out of this thing as subject-predicate-and-object triples.
- 3:26
You figure it out." And when we give it a pancake recipe, it's done an all right job. We've got a graph. But we wouldn't get very far with this graph.
- 3:38
It's got some problems, and we'll talk through that next.
- 3:42
One of the key principles about building better graphs is giving the extractor a schema to fill. In this case, if we say, "Instead of using triples, use a recipe, and a recipe has ingredients, and ingredients have a quantity," if we give this to an agent with structured outputs, what we get back is instantly way more meaningful than
- 4:05
the graph we had before, and a lot tidier.
- 4:10
So the benefit here is that with consistent node and edge types, relationships become meaningful and something that we can interrogate or query.
- 4:19
Let's take this a little bit further to say that a recipe has ingredients, but it also has steps, and each step is the application of a cooking technique. Now we've got a graph with structure that's starting to look a bit interesting.
- 4:34
Now that we have a well-defined schema and a nicely structured graph, we need to add detail to our ontology. The ontology describes how to extract information into our graph or precisely what to put into that structure.
- 4:50
In our case, we want to provide instructions to our agent to standardize the formatting of ingredient names and to standardize units on the metric system to make matching and conversion easier.
- 5:04
These extra instructions are just as important to the title model as the schema is. And boom, there we go. We've got lowercase ingredients and metric units.
- 5:17
We know that the best prompt in the world isn't bulletproof, though, so we'll look next how to make sure we really do standardize our units.
- 5:24
Here's an example where we have a couple of ingredients that probably shouldn't be represented by multiple nodes. We've got garlic cloves and minced garlic, cumin and cumin seeds, vegetable oil and oil.
- 5:38
We've also got plain old garlic down there as well.
- 5:43
So in our first attempt at solving the potato, potato problem, we can see that by taking a naive approach to mapping these, we can eliminate the duplication which unifies the nodes.
- 5:54
But it also strengthens the relationships between the different recipes that have common ingredient. We'll explain why this is helpful later.
- 6:02
The problem with this naive approach is that we've applied it retrospectively, and for this to work well, we'd have to know all of the ingredients ahead of time. Of course, these days we have embedding models which take the pain out of this sort of problem, and by using an embedding model here, we have not only more flexible
- 6:22
matching, but we also have the ability to match on terms that we don't need to know in advance. This is a good example of where graph techniques and AI techniques working in hybrid give us the best result.
- 6:37
So now that we have a well-structured graph, we have nicely curated information put into that graph, and we've done extra work to make sure that the nodes are matched or the entities are matched before we create new nodes.
- 6:49
Let's start talking about what we can do with our graph.
- 6:53
The very first thing we're gonna do is just do a simple query to see which recipes contain the ingredient garlic. We've got the Cypher or graph database query on top and the relational SQL query below just for comparison.
- 7:09
Here we can see all the recipes that have garlic and their ingredients, which we pruned so that they'd fit on the slide. I think if you look at this example, you can see how out of hand the SQL query might get if we wanted to traverse five, 10, 20 edges to find the nodes that we're looking for.
- 7:27
In a graph query, not only is it a little bit easier and more natural to write, but traversing relationships like that is where the graph data structures start to inherently excel.
- 7:40
Stepping things up a notch, the next graph algorithm we've got is the personalized PageRank algorithm.
- 7:48
This is a variant on vanilla PageRank, which was made famous by a certain Brin and Page back in 1998.
- 7:55
It works by having a little dude run around the graph, and he marks each node as he passes. After a certain amount of hops around the graph, he'll teleport back to the starting node, and that's the bit that makes it personalized.
- 8:09
It's personalized to our starting node. By repeating this process until he's completely worn out, some nodes will emerge with more marks on them than others. These are the nodes that have a stronger relationship with the starting node than those around them.
- 8:24
A really common and popular reference point for personalized PageRank is the Pinterest Pixie Paper. How's that for some alliteration? Um, that showed how PPR could be used for Pinterest recommendations.
- 8:38
But an even more contemporary one is HippoRAG, uh, which uses some other cool graph techniques as well to link memories to questions and answers. In the presentation pack, you'll find links and references to different variants and how they can be used.
- 9:01
So it looked a bit obvious in that last example,
- 9:04
but algorithms like this really shine when we have dense clusters of nodes and relationships, and it isn't that easy to infer which ones are the most important.
- 9:15
Another real-world example is taking a real-world US Supreme Court case and being able to find the authoritative landmark cases upon which it relies.
- 9:25
In this example, Miranda v. Arizona is not cited in the Canvas v. Shiba case. Uh, it's purely through the relationships in the citation graph that we are able to find it, not only to find it, but to be able to return a string of citations that show how it is related to this existing case through another.
- 9:46
Shortest path algorithm is another good way to look at the relationships between two nodes in a graph. In this case, where we know both nodes in advance and we don't understand the relationships, we can look at the most direct route between them.
- 9:59
In this case, if we say the checkout code broke after we changed the basket constructor, but I have no idea why, we can traverse the edges between those two nodes in the code graph and return either the symbols or the text or a summary as context.
- 10:17
In this case, the shortest path is highly useful, but we might want the k shortest paths or the shortest path that passes through a particular node or the cheapest path if the edges are weighted.
- 10:29
So there are multiple variants, and they're all very useful at telling us what nodes and edges might help explain the relationship between two other nodes on the graph. One of the benefits of this, being able to retrieve a subgraph as context, is that we wouldn't have found these intermediate nodes by doing vector search or even by doing
- 10:47
individual symbol and reference lookups, and the process of figuring that out for ourselves would have been slow. In one particular evaluation where we used this technique on a .NET code base, we saw a 40% reduction in tool calls for code search where we used techniques like this to identify the context we needed to give the agent.
- 11:10
This is another eShop example, and one thing I like about this particular example is that instead of starting with a node or a set of nodes and navigating our way through the graph, we're querying entirely on relationships.
- 11:23
We could specify a node type or a node ID in this query, and it would still be a subgraph match. However, in this case, we're searching for code in a certain shape, not knowing anything specific about the code we're looking for or any symbols up front.
- 11:41
We'll search for a decorator pattern in the eShop example, which is commonly used to enhance an existing class. So what we're looking for is a class that wraps its target class or consumes methods from its target class where both the wrapper and the target class implement the same interface.
- 12:01
Boom. There we go. In our eShop code base, we found a catalog view model service and a cached version that calls the same class and implements the same API.
- 12:14
If we knew we were looking for caching classes, we could have searched on that. But if we're looking for a specific pattern or if we were looking for an anti-pattern or a particular type of security issue, a malicious transaction pattern, or legal arguments in a big corpus, sometimes it's really important to be able to look for the
- 12:35
shape of something without knowing the specific instance or node details themselves. The benefits of subgraph matching where you have the opportunity to use it, I think are, are quite unique.
- 12:46
It's not so much an optimization problem as, like, a big enabling algorithm. It's something that's just not easy to do, uh, with other tools.
- 12:58
All right, so we've covered a lot of ground. Thanks for bearing with me. We've looked at navigating paths, at ranking how important things are, and finding patterns. We've skipped over some of the traditional flow and cost and search algorithms that you might find often used in modeling dependencies or networks, and there's heaps of use cases of those,
- 13:19
but I think probably a little bit more run-of-the-mill. In the presentation pack, we'll also include some notes about some of the things that we couldn't get to today, like prediction, similarity, and clustering.
- 13:32
These are now edging into some of the GraphRAG building dynamic graphs, uh, or schemaless graph kind of territory that we deliberately didn't want to go into today. But it is also where things get super interesting as well.
- 13:46
We'll have some references and some pointers in the presentation pack. Otherwise, you can go and explore some of those things on your own. So I hope that some of these concepts will have given you some insight or inspired you, and that you can take them and either use graph native algorithms or hybrid algorithms to help make smarter,
- 14:03
cheaper, and more reliable AI applications. Thank you.