A Practitioner's Guide to Graphs - Tim Ainge, Good Collective

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.

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.

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.

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:

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.

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.

A legal citation graph makes the value of indirect relationships concrete. Starting from a US Supreme Court case, the task is to find the authoritative landmark cases on which it relies. In Ainge’s example, Kansas v. Cheever does not directly cite Miranda v. Arizona. The citation graph nevertheless exposes a connection through intermediate case relationships.

The useful output includes both the related authority and the citation chain connecting it to the starting case. That chain makes the retrieval explainable: it shows how the cases are related instead of returning a landmark case without its supporting path.

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:

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.

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:

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.

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.