A knowledge graph lets an agent use explicit domain relationships to retrieve information with more control than a one-shot vector search.
2
GraphRAG can combine structured sources such as tables with unstructured sources such as documents and PDFs in one model of the data.
3
Retrieval tools can combine exact graph matches, vector similarity, graph traversal, and community information for questions about people and skills.
Summary
Zach Blumenfeld introduces GraphRAG through a hands-on Neo4j workshop built around an employee and skills graph. He explains how a graph can combine structured data with documents, expose domain logic to an agent, and make retrieval patterns explicit. The workshop starts with a simple property graph, loads people and skills from a table, and uses Cypher to answer questions about shared skills and similar employees. It then adds vector embeddings for semantic skill matching, materialized relationships for repeated comparisons, and Leiden community detection for grouping employees by skill patterns. Blumenfeld also shows how an LLM can extract people and skills from text using Pydantic models before loading the result into Neo4j. The final module turns the graph patterns into LangGraph tools and lets an agent choose among them. He is candid that dynamic query generation works better with simpler schemas, while complicated traversals may need expert-written tools or restricted query patterns.
GraphRAG gives agents explicit retrieval logic through a knowledge graph
Blumenfeld presents a common GraphRAG architecture with an agent, AI models, and a user interface connected to a knowledge graph. The graph can ingest unstructured sources such as documents and PDFs alongside structured sources such as CSV files and relational databases. He argues that even a simple graph schema exposes domain logic to the agent. In the workshop's example, relationships describing which people know which skills let the system control retrieval more accurately and explain why information was returned. This matters for agentic workflows because a prompt may be broken into several steps, so retrieval can use graph logic alongside vector search rather than relying on one initial similarity lookup.
A property graph models entities, relationships, and their attributes
Neo4j stores the workshop data as a property graph. Nodes are the entities, such as people and skills. Relationships describe how those entities connect, such as a person knowing a skill. Both nodes and relationships can have properties, including strings, numbers, arrays, and vectors. The query language, Cypher, uses patterns that read close to natural language. A pattern such as a person connected to a skill through a knows relationship can match that path directly. Labels identify the type of node, while properties such as an email address or name identify individual records.
Constraints make graph loading and matching faster
The first notebook loads a table with an email address, a name, and a list of skills for each person. Before creating nodes, Blumenfeld adds uniqueness constraints so every person's email and every skill name is unique and non-null. He explains that these constraints also make matching and merge operations fast. Without them, a query that looks up a user may require a more complex search each time. The loading query merges a person by email, merges each skill by name, and merges the relationship connecting the person to that skill. The resulting graph supports direct inspection of people, skills, and their relationships.
Graph traversals answer similarity questions with concrete rules
Blumenfeld uses Cypher to find people who share skills with a selected person, then extends the query to inspect the skills of those related people. This lets the application define similarity through a visible traversal. For example, it can find a local group around Lucy and identify skills that are central within that group. The result is different from asking for semantically similar text because the rule is based on explicit connections in the graph. He describes this as a symbolic representation of domain logic, which can give an agent more control over what counts as a similar person or skill.
Vector search adds semantic similarity to exact graph relationships
The workshop embeds descriptions of skills rather than only short skill names. Blumenfeld uses descriptions because names such as "R" and "AWS" provide little text for an embedding model. The resulting vectors are stored on skill nodes and queried through a vector index. A search for "API coding" can return skills such as API design and JavaScript even when the wording does not exactly match. Those semantic links can also be written back into the graph as similar semantic relationships with scores. This makes the connections visible and allows them to be used later in clustering and retrieval.
Materialized similarity links trade freshness for simpler repeated retrieval
When the application repeatedly needs to compare people's skill sets, it can create a similar skill set relationship between people. The relationship records the amount of skill overlap, so later queries do not need to repeat the full traversal every time. Blumenfeld is clear about the trade-off: this relationship is static until the query is run again. If the graph changes often, repeatedly executing the multihop query may be preferable because the graph database is designed to handle it. The same recurring update pattern applies when new skills require new semantic similarity relationships.
Community detection can turn skill patterns into persistent graph context
Blumenfeld projects the graph for graph data science and runs the Leiden community detection algorithm. Leiden builds a hierarchy of communities while optimizing modularity, which favors dense connections inside a group and fewer connections between groups. In this example, the relevant connections are similar skill set relationships, so the communities represent people with related skills. The community ID is written back to the graph. A heat map can then show which skills are common in each community. With realistic data, this could reveal groups such as data engineers, frontend developers, or machine learning specialists. He recommends community detection when clustering and persistent segmentation are part of the use case.
Structured extraction turns resumes and documents into graph data
The second module starts with two text biographies instead of a table. Blumenfeld defines a simple domain model with Pydantic classes for a person, an email address, and a list of skills. An LLM receives the documents and the system prompt, then returns structured JSON containing the people, email addresses, and extracted skills. The graph-loading step is almost the same as for the table: merge each person by email, merge each skill by name, and create the knows relationship. He also describes a document-structure approach for sources such as RFPs, where sections and subsections can become graph nodes. Traversing between chunks, document structure, and extracted entities can connect clauses with related dates or other information.
Expert retrieval tools give an agent controlled graph operations
The final module creates a small LangGraph agent with four retrieval tools. The tools retrieve a person's skills, find similar skills, find similar people, and find people based on a set of skills. Their implementations use the graph patterns developed earlier, including vector search, semantic relationships, skill overlap, and community membership. The agent receives the tools and chooses one based on the question. For example, a question about Kristoff's skills selects the person-skill retrieval tool, while a question about skills similar to PowerBI selects the similar-skills tool. Blumenfeld also shows text-to-Cypher with an annotated schema, where descriptions and example query patterns help the model generate an aggregation query.
"The idea with this is that if you have a use case and you kind of know the types of questions that you want to answer with your agents, by taking your data and decomposing even a very simple knowledge graph to start, you're going to be able to expose a lot of the sort of domain logic that you'd want to apply through the model of your data."10:10
Who should watch
You are building an agent that needs to combine database records with documents and want retrieval rules that can be inspected and changed.
Your application needs to compare entities through shared relationships as well as semantic similarity, such as finding employees with related skills.
You want a practical starting point for loading extracted entities into Neo4j and exposing graph queries as LangGraph tools.
