# A Practitioner's Guide to Graphs Tim Ainge, Good Collective | AI Engineer World's Fair 2026 | 14:18 Source: https://www.youtube.com/watch?v=3ySF0I5iE_0 Channel: AI Engineer (https://www.youtube.com/@aiDotEngineer). Summarised by AIE Talks. Page: https://aietalks.com/talks/a-practitioners-guide-to-graphs Published: 2026-07-18 Tags: embeddings, search ## TL;DR - Graphs are most useful when their schema and ontology make relationships consistent enough to query. - Embedding-based entity matching works well alongside graph techniques when extracting structured data from unstructured text. - Personalized PageRank, shortest-path search, and subgraph matching can retrieve relationships and patterns that vector search may miss. ## Summary Tim Ainge gives a practical introduction to graphs for people building AI applications. He starts with nodes, edges, labels, properties, and direction, then focuses on the harder problem of creating useful graph data from unstructured text. A schema gives an extractor consistent node and edge types, while an ontology adds instructions such as standard ingredient names and metric units. Embeddings can help match entities before duplicate nodes are created. Ainge then demonstrates graph queries and three graph-native techniques: personalized PageRank for finding strongly related nodes, shortest paths for explaining connections, and subgraph matching for finding structural patterns without knowing the exact entities in advance. Examples include recipes, Pinterest recommendations, legal citations, code search, and decorator patterns. He is careful about scope and leaves GraphRAG, dynamic graphs, and several traditional algorithms for further exploration. ## Key ideas ### Graphs are useful foundations, but they are not automatically the right tool [00:00](https://www.youtube.com/watch?v=3ySF0I5iE_0&t=0s) A graph has nodes, also called vertices, and edges that connect them. Nodes and edges can have types, labels, properties, and direction. Ainge warns against rushing into GraphRAG or replacing an existing system with a graph database just because graph visualisations look compelling. The value comes from understanding graph data structures and algorithms, then finding problems where relationships matter. He focuses on underlying patterns for AI builders rather than GraphRAG or agent memory graphs, which he says are covered by other talks. ### A schema makes extracted graphs consistent enough to query [02:26](https://www.youtube.com/watch?v=3ySF0I5iE_0&t=146s) Ainge uses a pancake recipe to show why unconstrained extraction produces a weak graph. Asking an agent to return arbitrary subject, predicate, and object triples gives information, but the result is hard to use. A recipe schema can require ingredients, quantities, steps, and cooking techniques. Structured outputs then produce consistent node and edge types. That consistency gives relationships a clear meaning, so the resulting graph can be queried instead of merely displayed. ### An ontology adds the extraction rules that a schema cannot express [04:43](https://www.youtube.com/watch?v=3ySF0I5iE_0&t=283s) The schema defines the structure, while the ontology gives more exact instructions about what belongs in it. For the recipe example, Ainge tells the model to standardize ingredient names and use metric units. The result includes lowercase ingredient names and consistent units. He treats these formatting and normalization rules as part of the extraction design, rather than assuming that a general prompt will produce matching values every time. ### Entity matching should happen before duplicate nodes spread through the graph [05:27](https://www.youtube.com/watch?v=3ySF0I5iE_0&t=327s) Recipe data can represent garlic cloves, minced garlic, plain garlic, cumin, cumin seeds, vegetable oil, and oil as separate nodes even when some should be connected or unified. A naive retrospective mapping can remove duplication and strengthen links between recipes, but it requires knowing all possible ingredients in advance. Ainge recommends embedding models for more flexible matching, including terms that were not known when the system was designed. He presents this combination of graph methods and AI methods as a practical hybrid. ### Graph queries make repeated relationship traversal more natural [06:53](https://www.youtube.com/watch?v=3ySF0I5iE_0&t=413s) Ainge compares a Cypher query for recipes containing garlic with a relational SQL query. The difference becomes larger when the task requires traversing five, ten, or twenty edges. Graph queries express those traversals directly, and graph data structures are built around moving through relationships. This is a basic use case, but it establishes why a graph can be a better fit when the answer depends on connected nodes rather than isolated records. ### Personalized PageRank ranks nodes by their relationship to a starting point [07:35](https://www.youtube.com/watch?v=3ySF0I5iE_0&t=455s) Personalized PageRank adapts the original PageRank algorithm by repeatedly moving through a graph and occasionally returning to a chosen starting node. Nodes that receive more marks have a stronger relationship to that starting point. Ainge cites the Pinterest Pixie paper as a recommendation example and mentions HippoRAG, which uses graph techniques to connect memories with questions and answers. The method is most useful in dense graphs where the important related nodes are difficult to identify by inspection. ### Shortest paths can provide intermediate context for an unexplained connection [09:54](https://www.youtube.com/watch?v=3ySF0I5iE_0&t=594s) When both endpoints are known but the relationship is unclear, a shortest-path algorithm can find a direct route between them. Ainge applies this to a code graph where a checkout failure appeared after changing a basket constructor. The path can return symbols, source text, or a summary as context. Variants include K shortest paths, paths through a required node, and cheapest paths when edges have weights. In one .NET code-base evaluation, this approach reduced code-search tool calls by 40 percent. ### Subgraph matching finds structural patterns without named entities [11:13](https://www.youtube.com/watch?v=3ySF0I5iE_0&t=673s) Subgraph matching searches for a shape in the graph rather than starting with a known node or symbol. In an eShop example, Ainge searches for a decorator pattern: a wrapper consumes methods from a target class, and both implement the same interface. The query finds a catalog view model service and a cached version with the same API. The same approach could search for an anti-pattern, a security issue, a malicious transaction pattern, or a recurring legal argument when the specific instance is unknown. ## Notable quotes - "A graph is something that has nodes, also called vertices, and edges, which I sometimes call relationships, that connect the nodes together." (01:58) - "The benefit here is that with consistent node and edge types, relationships become meaningful and something that we can interrogate or query." (03:56) - "This is a good example of where graph techniques and AI techniques working in hybrid give us the best result." (06:26) - "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." (10:52) - "It's something that's just not easy to do with other tools." (12:43) ## Tools & references mentioned - GraphRAG - Obsidian - Cypher - SQL - personalized PageRank - PageRank - Brin and Page - Pinterest Pixie - HippoRAG - Miranda v. Arizona - Canvas v. Sheba - .NET - eShop ## Who should watch - You are extracting entities and relationships from documents and need a graph that can be queried reliably. - Your AI system needs connected context for code search, recommendations, legal research, or dependency analysis. - You are considering graph algorithms and want concrete examples of when schema design, entity matching, paths, or pattern search can help.