GraphRAG combines vector search, knowledge graph traversal, and graph data science to retrieve more useful context for an LLM.
2
Purchase relationships can rerank vector search results so recommendations reflect both product meaning and a customer's behavior.
3
Graph embeddings and nearest-neighbor methods can infer new article relationships that support recommendations, entity resolution, fraud detection, and customer segmentation.
Summary
Zach Blumenthal leads a hands-on workshop that builds a fashion recommendation application with H&M data, Neo4j, LangChain, OpenAI embeddings, and a small Gradio interface. The workflow begins with a graph containing customers, products, clothing articles, departments, and purchase transactions. Vector search finds products that match a text query such as "denim jeans." Graph traversal then uses co-purchase behavior to personalize and rerank those results. The workshop also creates graph embeddings for articles with FastRP and uses KNN to infer "customer also likes" relationships. A LangChain pipeline combines personalized search, graph-based recommendations, customer details, and season information in an LLM prompt that generates an email. Zach is clear that the score combination is a starting point and should be tested against labeled recommendation outcomes. He also discusses alternatives such as pre-filtering, post-filtering, external vector databases, and function calls for graph queries.
GraphRAG combines vector search with graph structure and graph data science
Zach defines retrieval augmented generation as an intermediate step where an application retrieves relevant data before sending a question to an LLM. This can reduce hallucinations, add domain context, and improve traceability. In this workshop, GraphRAG combines vector search, knowledge graph traversals over structured data, and graph data science. The example uses an H&M clothing dataset to build a fashion assistant. The application retrieves products related to a customer's interests, adds personalization from purchase behavior, generates recommendations, and asks an LLM to write the final email. Zach says the same workflow could support support agents, internal search, and customer experience applications.
The workshop graph models customers, products, articles, and purchases
The data model contains customers and clothing articles connected by purchase transactions. Articles are variants of products, with differences such as color and size. Products carry fields such as descriptions, garment groups, product types, and names. Articles also have properties including color and design patterns, while departments describe where articles are sold. The workshop loads department, product, article, customer, and transaction CSV files into Neo4j. It creates uniqueness constraints for later queries and adds a combined text property to products. That property joins product name, type, group, description, and related fields so it can be indexed for vector search.
Text embeddings and vector indexes are separate steps
For the first search system, the workshop embeds product descriptions with OpenAI's text embedding model. The embedding step sends product text to the model, receives a numeric vector, and stores it as a node property called text embedding. The vector index then makes those stored vectors searchable. Neo4j's vector index uses HNSW for approximate nearest-neighbor search and can use cosine similarity. A query such as "denim jeans" is embedded into a query vector, then compared with product vectors to return relevant descriptions and metadata. Zach also shows that LangChain can create a Neo4j vector store around the same index.
Co-purchase paths can personalize ordinary semantic search
The workshop adds graph patterns after the initial vector retrieval. Starting from a specific customer, the query follows purchases to articles, finds other customers who bought the same articles, and examines what those customers bought next. The resulting peer group provides a co-purchase score based on how often candidate products appear in those shared purchase paths. The system combines that purchase score with the vector search score and reranks the results. This changes the order for a query such as "denim jeans" depending on the customer. Zach explains that optional matching allows the system to retain vector results when a customer has no useful matching purchase relationships.
Graph embeddings compress multi-hop structure into searchable vectors
A graph embedding represents nodes according to their position and structure in a graph. The workshop projects article and customer purchase relationships into an in-memory graph, then uses FastRP to create article embeddings. The model uses the topology of co-purchase relationships, with settings such as embedding dimensions and iteration weights controlling the representation. KNN compares the resulting vectors and writes "customer also likes" relationships back into the graph. This makes it possible to recommend articles through inferred relationships rather than running a long traversal for every request. Zach says similar methods can support entity resolution, fraud detection, classification, and customer segmentation.
Graph embeddings need recalculation as the graph changes
Zach says the current workflow requires recalculating graph embeddings when the graph changes. FastRP can make that practical for large graphs, but the embedding is still a computed view of the current graph rather than an automatically updated property. He suggests averaging a node's neighborhood as an intermediate embedding when an immediate full recalculation is not desirable. The useful behavior comes from representing graph topology as features, which lets the system infer relationships that are difficult to express with a fixed query. The embedding does not discard relationships. Existing edges determine where nodes sit in the embedding space, and the graph remains available for later traversals.
The final LangChain chain gives the LLM two retrieval sources
The final application combines a personalized vector retriever with a graph-based recommendation retriever. The first uses product text embeddings, then applies a graph query that considers the customer's peer group and purchase score. The second follows the inferred "customer also liked" relationships created with graph embeddings. LangChain passes both product lists, the customer name, the customer's interests, and the time of year into a prompt for GPT-4o. The prompt tells the model to use only the supplied products and to write an engaging email. Changing the customer ID produces different recommendations, while changing the month changes seasonal wording and product selection.
"The idea behind embeddings is that you're able to infer relationships between things inside of your graph that you know would be very hard to do without some sort of machine learning or just traditional methods."1:28:18
Who should watch
You are building a RAG application and need structured customer, product, or transactional data to affect retrieval.
You want a concrete Neo4j and LangChain example rather than a chatbot-only RAG demo.
You need to decide between graph traversal, vector search, graph embeddings, or a combination of them for recommendations or entity resolution.
