A practitioner-oriented introduction to graphs by Tim Ainge (Good Collective). Covers graph basics, extracting graphs from unstructured text, schema-first design and ontological improvements, and a closer look at personalised page rank, shortest path, and subgraph matching algorithms. Each concept is explained with principles, accessible code examples, and real-world implementations illustrating practical value. # Video Identity Observations ## Source Identification - **Speaker:** Tim Ainge (transcribed as "Tim Angers") of **The Good Collective** - **Venue framing:** Presented as an **AI Engineer's** conference talk ("welcome to AI Engineer's presentation") ## Explicit Self-Description Evidence ### Stated Audience > "This talk is for AI builders" The creator explicitly identifies the target audience as developers/engineers building AI applications. ### Stated Scope > "A practitioner's guide to graphs, how to make your AI applications smarter, cheaper, and more reliable." The speaker frames the channel/talk content as **practical engineering guidance** for applying graph techniques to AI. ### Explicit Exclusions (scope boundary claims) > "This talk isn't going to go into GraphRAG or agent memory graphs. Not because I'm throwing shade on those patterns and products... this talk is for AI builders and I'd like to focus on the underlying patterns." > "we deliberately didn't want to go into [prediction, similarity, clustering, schema-less graph territory] today" - The speaker positions the content as focused on **graph fundamentals and graph-native algorithms**, deliberately excluding trending topics (GraphRAG, agent memory) to focus on foundations. ### Creator Epistemic Claims > "Have I nailed all of the answers? Definitely not. But what I'm finding is that the more I learn about the fundamentals... the more interesting opportunities seem to present themselves." - The speaker explicitly positions himself as a **learner/practitioner sharing findings**, not a definitive authority — a humility claim about his own expertise. ## Observable Presentation Patterns ### Audience Implied by Content Style - Assumes **technical proficiency**: discusses Cypher vs. SQL queries, structured outputs for agents, embedding models, .NET code bases, PageRank variants — no introductory-level hand-holding beyond a brief "speed run." - Content demonstrates addressing **working practitioners** with real evaluation results: > "we saw a 40% reduction in tool calls for code search" ### Demonstrated Content Approach - **Structured pedagogy:** Each topic follows an explicit template: > "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." - **Practical examples over theory:** Recipe/pancake extraction example, eShop e-commerce code base, US Supreme Court citation graphs (Miranda v. Arizona). - **Curated references promised:** Multiple mentions of a "presentation pack" with links, references, and pointers — indicating supplementary material is part of the channel's delivery model. ### Demonstrated Domain Scope - Graph data structures and algorithms (PageRank, shortest path, subgraph matching) - Hybrid graph + AI techniques (embedding-based entity matching) - Code analysis and retrieval use cases for AI agents - No curated metadata was supplied; identity observations rest solely on the transcript. ## Claims vs. Demonstrated Patterns (Distinction) | Creator Claim | Demonstrated in Material | |---|---| | Talk is for "AI builders" | Content assumes engineering audience (code, queries, evaluations) | | Focus on "underlying patterns" not GraphRAG | Transcript covers fundamentals, algorithms, schema design; no GraphRAG implementation | | Real-world benefits exist | Cites Pinterest Pixie paper, HippoRAG, 40% tool-call reduction claim (unverifiable from transcript alone) | ## Note on Limits - This is a single conference-style presentation; **no evidence about broader channel identity** (upload cadence, recurring series, subscriber messaging) is present beyond the speaker's organizational affiliation with The Good Collective. # Delivery Observations: Tim Ainge — "A Practitioner's Guide to Graphs" ## Tone & Register - **Conversational, collegial tone** throughout — technical content delivered casually, e.g., "You figure it out," and "cuz that's a pretty common use case." - **Self-deprecating humility**: opens by lowering expectations — > "Have I nailed all of the answers? Definitely not." - **Light humor and playfulness**: "a little dude run around the graph," "How's that for some alliteration?", and "Thanks for bearing with me." ## Vocabulary & Phrasing - **Metaphorical framing**: "the valley of despair and disillusionment," "journeys end here in the dust." - **Casual intensifiers**: "really, really important," "super interesting," "heaps of use cases." - **Onomatopoeic exclamation as a transition habit** (repeated 2x): "And boom, there we go," "Boom. There we go." - **Concrete everyday running example**: a "wrap pancake recipe" anchors extraction, schema, and entity-matching demos. ## Teaching Habits & Structure - **Explicit roadmap signposting**: announces structure up front — > "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." - **Principle → example → code → real-world benefit** pattern recurs (e.g., schema principle at [221], followed by the recipe example, then later the 40% tool-call reduction result). - **Build-then-critique pedagogy**: shows a naive solution, names its flaws, then improves it (triples → schema; naive deduplication → embeddings). - **Comparison-based explanation**: Cypher vs. SQL side by side; vector search vs. subgraph retrieval. - **Summarizing recaps**: "So, we've covered a lot of ground... We've looked at navigating paths, at ranking how important things are, and finding patterns." ## Audience Awareness - **Direct address to builders**: "This talk is for AI builders." - **Scoping/disclaimers** stated explicitly and without disparagement: "Not because I'm throwing shade on those patterns and products." - **Points to further resources** rather than covering everything: "In the presentation pack, you'll find links and references." ## Communication Patterns - **Quantified claims when available**: "a 40% reduction in tool calls for code search." - **"Why it matters" framing**: repeatedly ties techniques to outcomes — "smarter, cheaper, and more reliable AI applications" appears in both the opening and closing (bookend structure). ## Pattern Confidence - **Stable patterns** (multiple instances): build-then-critique structure, transition exclamation "Boom," signposting, recap-and-closing-loop. - **Isolated moments** (insufficient repetition): the "little dude" PageRank metaphor and the "potato, potato" phrasing each appear once — memorable but not established habits. - **Uncertainty note**: only verbal fillers like "Uh" appear a few times; no reliable conclusion about disfluency rate can be drawn from transcript text alone. # Observation Document: "A Practitioner's Guide to Graphs" — Tim Ainge, Good Collective ## Video Identity - **Speaker:** Tim Ainge (transcript renders the name as "Tim Angers"), The Good Collective - **Venue:** AI Engineer's presentation - **Stated goal:** Show how graph fundamentals and graph-native algorithms can make AI applications "smarter, cheaper, and more reliable" ## Framing Positions - **Graphs aren't always the right tool.** Ainge cautions against rushing into GraphRAG or rebuilding e-commerce with graph databases out of fascination; many efforts end in a "valley of despair and disillusionment" when instant payoff doesn't materialize. - **Learning fundamentals unlocks opportunities.** He states the more he learns about graph data structures and algorithms, the more interesting opportunities appear — many graph-native use cases complement "search, pattern recognition, retrieval, or knowledge-based problems" of the AI age. - **Honest uncertainty:** "Have I nailed all of the answers? Definitely not." - **Explicit scope disclaimer:** The talk deliberately excludes GraphRAG and agent memory graphs — "not because I'm throwing shade," but because other talks cover them and his focus is underlying patterns for AI builders. ## Basics (as defined by speaker) - A graph = **nodes (vertices)** + **edges (relationships)**, optionally with types, labels, properties, and direction. ## Building Better Graphs from Unstructured Text ### 1. Give the extractor a schema - Naive triple extraction (subject–predicate–object) on a wrap pancake recipe produces a graph but "we wouldn't get very far with it." - A structured schema (recipe → ingredients with quantity; steps as cooking techniques) yields something "instantly way more meaningful." - **Claim:** Consistent node and edge types make relationships meaningful and queryable. ### 2. Detail the ontology with instructions - Instructions to standardize ingredient names (lowercase) and units (metric) are "just as important to the title model as the schema is." ### 3. Entity matching / deduplication - Problem: duplicate nodes like "garlic cloves" vs. "minced garlic," "cumin" vs. "cumin seeds." - **Naive mapping** unifies nodes and strengthens cross-recipe relationships, but only works retrospectively (requires knowing all ingredients in advance). - **Embedding models** enable flexible matching on unknown terms. - **Position:** "This is a good example of where graph techniques and AI techniques working in hybrid give us the best result." - Qualification acknowledged: "the best prompt in the world isn't bulletproof." ## Graph Queries and Algorithms ### Simple queries - Comparing Cypher vs. SQL for "recipes containing garlic": graph queries are easier to write, and multi-hop traversal (5–20 edges) is where graphs "inherently excel" versus SQL getting "out of hand." ### Personalized PageRank (PPR) - Explanation: a random walker marks nodes and teleports back to the start; heavily marked nodes have stronger relationship to the starting node. Credit: PageRank by "a certain Brin and Page back in 1998." - References cited: **Pinterest Pixie paper** (recommendations) and **HippoRAG** (linking memories to Q&A, also uses other graph techniques). - Claim: these algorithms shine in dense clusters where importance isn't obvious. - **Real-world example:** US Supreme Court citation graph — finding *Miranda v. Arizona* as authoritative for a case (rendered as "Canvas v. Sheba") that never cites it directly; the graph returns the citation chain. ### Shortest path - Use case: "the checkout code broke after we changed the basket constructor" — traverse code-graph edges to retrieve intermediate context. - Variants noted: K shortest paths, paths through a particular node, cheapest path with weighted edges. - **Claimed benefit:** retrieving a subgraph as context surfaces intermediate nodes that vector search or individual symbol lookups would miss. - **Claimed result:** in one evaluation on a .NET codebase, a **40% reduction in tool calls** for code search. ### Subgraph matching - Querying purely on relationship shape (no known node), e.g., searching for the **decorator pattern** in the eShop codebase; found a catalog view model service with a cached version implementing the same interface. - **Position:** subgraph matching is "not so much an optimization problem as like a big enabling algorithm" — hard to replicate with other tools; useful for finding patterns, anti-patterns, malicious transaction patterns, or legal arguments without knowing specific instances. ## Omissions and Closing - Deliberately skipped: traditional flow, cost, and search algorithms (dependency/network modeling) — described as "a little bit more run-of-the-mill." - Deferred to the presentation pack: prediction, similarity, clustering — territory "edging into" graph RAG, dynamic graphs, and schema-less graphs, which he "deliberately didn't want to go into today" but notes "is also where things get super interesting." - Closing hope: listeners use graph-native or hybrid algorithms to build smarter, cheaper, more reliable AI applications. ## Unresolved Tensions (as expressed) - Enthusiasm for graphs is repeatedly tempered by his own caveats: graphs "sometimes genuinely not the right tool," prompts are not bulletproof, naive approaches fail without foreknowledge, and he admits he hasn't "nailed all of the answers." # Speaker Attribution & Provenance Record ## Video Metadata - **Title:** A Practitioner's Guide to Graphs - Tim Ainge, Good Collective - **Video ID:** `01a15ca8-78dd-73c1-a920-71232c873176` ## Speakers | Speaker | Role | Evidence | |---|---|---| | **Tim Ainge** (spoken as "Tim Angers") | **Creator / Sole presenter** | Self-introduction at transcript open: *"Hi, I'm Tim Angers from The Good Collective and welcome to AI Engineer's presentation, a practitioner's guide to graphs..."* | - **Affiliation stated by speaker:** The Good Collective - **Event/venue stated by speaker:** AI Engineer (conference/presentation) - **No other speakers, guests, narrators, or panel participants appear in the transcript.** ## Referenced Sources & Third-Party Claims - **PageRank:** attributed by speaker to **"Brin and Page" (1998)**. - **Pinterest Pixie paper:** cited by speaker as a reference point for personalized PageRank used in Pinterest recommendations. - **Hippo Rag:** cited by speaker as a contemporary example using graph techniques to link memories to questions/answers. - **US Supreme Court citation graph example:** speaker references *Miranda v. Arizona* and a case referred to as *"Canvas v. Sheba"* (as heard; exact case name not confirmed in transcript). - **.NET code base evaluation:** speaker claims a **40% reduction in tool calls for code search** — provenance is the speaker's own evaluation ("we used this technique"); no external source named. - **eShop example:** recurring worked example used by the speaker; no third-party attribution given. - **"Presentation pack":** speaker repeatedly states links, references, and notes are available there; contents not included in this transcript. ## Explicit Scope Disclaimers (by speaker) - Talk **does not cover GraphRAG or agent memory graphs**; speaker says other talks address those topics. - Traditional flow, cost, search algorithms, and prediction/similarity/clustering topics are noted as **not covered**, with pointers deferred to the presentation pack. ## Promotional Segments - **None detected.** No product promotions, sponsorships, or calls to action beyond references to the speaker's own organization affiliation (The Good Collective) and the "presentation pack" of references. ## Availability & Uncertainty - **Curated metadata:** none supplied beyond title and video ID. - **Comment availability:** not indicated. - **Name discrepancy:** transcript audio rendered as "Tim Angers"; title metadata reads "Tim Ainge." Uncertainty remains — the correct spelling is not established by the source. - **Case name uncertainty:** *"Canvas v. Sheba"* is a transcript rendering; exact case citation unverified. ## Quality Evaluation **Not applicable** — per role constraints, no content quality judgments are recorded. Hi, I'm Tim Angers from The Good Collective and welcome to AI Engineer's presentation, a practitioner's guide to graphs, how to make your AI applications smarter, cheaper, and more reliable. 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. 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. In frustration, many journeys end here in the dust at the bottom of the valley of despair and disillusionment. What's on the other side of the valley and how do we get there? 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. 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. 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. 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. Today, we're going to speed run 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. 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. All right, let's speed run the basics. What's a graph? 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. We can have different types of nodes and edges, which convey more meaning. Uh we can also put labels on edges and nodes and have properties. And of course, edges can have direction. Now that we've speed run 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, cuz that's a pretty common use case and a pretty popular one at the moment. 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. And we say to our agent, "Hey, go and pull the key information out of this thing as subject, predicate, and object triples. You figure it out." And then we give it a wrap pancake recipe. It's done an all right job. We've got a graph. But, we wouldn't get very far with this graph. It's got some problems, so we'll talk through that next. 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 its structured outputs, what we get back is instantly way more meaningful than the graph we had before, and a lot tidier. So, the benefit here is that with consistent node and edge types, relationships become meaningful and something that we can interrogate or query. 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. 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. 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. 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. We know that the best prompt in the world isn't bulletproof, though. So, we'll look next at how to make sure we really do standardize our units. 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. We've also got plain old garlic down there as well. 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, but it also strengthens the relationships between the different recipes that have common ingredients. We'll explain why this is helpful later. 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 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. 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. Let's start talking about what we can do with our graph. The very first thing we're going to 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. Here we can see all the recipes that have garlic and their ingredients, which we print to the if they're 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 5, 10, 20 edges to find the nodes that we're looking for. 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. Stepping things up a notch, the next graph algorithm we've got is the personalized PageRank algorithm. This is a variant on vanilla PageRank, which was made famous by a certain Brin and Page back in 1998. 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. 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. 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. But, an even more contemporary one is Hippo Rag, 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. So, it looked a bit obvious in that last example. 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. 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. In this example, Miranda v. Arizona is not cited in the Canvas v. Sheba case. 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. 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. 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. 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. 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 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. This is another eShop example. The 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. We could specify a node type or a node ID in this query and it would still be a subgraph match. However, in In 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. 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. 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. 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 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. 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. 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, but I think probably a little bit more run-of-the-mill. In the presentation back, we'll also include some notes about some of the things that we couldn't get to today like prediction, similarity, and clustering. These are now edging into some of the graph rag, building dynamic graphs, or schema-less 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. 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, cheaper, and more reliable AI applications. Thank you.