Graph structure gives RAG systems access to relationships, context, and structured information that a vector store alone does not capture.
2
Graph analytics can cluster similar chunks, find influential or bridging documents, identify repeated content, and help curate grounding data at scale.
3
The right graph structure and retrieval strategy should be driven by evaluation questions, while application activity should be tracked for accountability and traceability.
Summary
Alison Cossette presents a practical GraphRAG workflow built around an existing Neo4j application graph. She explains how documents, chunks, embeddings, prompts, responses, users, and domain entities can live in one connected system. That structure lets teams inspect how data is retrieved and used, rather than treating each vector match as an isolated result. The workshop then uses K-nearest neighbors to connect similar chunks, community detection to group them, and graph metrics such as PageRank and betweenness centrality to find influential or bridging content. These signals can expose redundant, stale, low-quality, or overly narrow grounding data. Cossette also discusses multiple vector indexes, metadata filtering through graph properties, natural document structure, multimodal data, and collapsing duplicate chunks while preserving lineage. Her broader point is that teams should monitor agent and retrieval behavior as part of building accountable systems. Start with a subset of data, evaluate it, and refine the schema before loading everything.
A knowledge graph adds relationships and context around vector results
Cossette describes a vector result as an index card containing a small piece of information. The card may be semantically relevant, but it does not explain what the information connects to or what surrounding context matters. A knowledge graph can combine structured and unstructured data, while also extracting entities and relationships from documents. An embedding can remain on the graph node, connected directly to people, products, documents, or other entities. After a vector search reaches a relevant chunk, a graph traversal can immediately retrieve its related context. The graph therefore gives a RAG retriever access to connections that are missing from an isolated vector record.
The application graph records how agents and users move through data
Cossette introduces an application or memory graph that records sessions, user messages, assistant responses, and the context documents used to produce those responses. This graph sits alongside chunks and domain entities in the same system. Tracking these links lets a team inspect which documents influence answers and how conversations move through different areas of the data. The value becomes clearer at scale, where there may be a large volume of documents and no obvious way to decide which ones deserve review. Usage patterns can show which documents people repeatedly rely on, which communities appear in conversations, and where answers are being shaped.
Graph projects let teams run analytics on the part of the data they need
Before running an algorithm, Cossette projects a smaller in-memory graph rather than using the entire database. In the workshop example, the projection contains document nodes and their embedding properties. The team then runs K-nearest neighbors with a K of 25 to create similarity connections between documents. The projection includes only the required properties and relationships, which keeps the operation focused. Neo4j Graph Data Science can stream results for inspection, mutate a projection, or write calculated values back to the database. This gives teams a way to experiment with algorithms before changing production data.
Community detection exposes groups of similar chunks and gaps in coverage
After creating similarity relationships, Cossette applies community detection, also called clustering, to group related chunks. She explains modularity as a measure of how strongly connected the items inside a group are compared with their connections outside it. Louvain repeatedly tests whether assigning a node the same label as a neighbor improves the modularity score. Label propagation takes a faster approach by passing labels through neighboring nodes until the groups converge. Leiden is another option for cases such as disconnected graphs. The resulting communities help teams inspect dense clusters, bridge documents, and possible blind spots in their grounding data.
Retrieval quality requires diversity, relevance, reliability, and efficiency
Cossette warns that a highly similar cluster may look good to a traditional clustering system while being poor for retrieval. In the example, one community contains 49 chunks with an average similarity of 0.98. A retriever returning the top 10 results could therefore return nearly identical material and provide little additional context. She recommends examining community membership and using reranking signals such as diversity or PageRank. A diverse result can cover more of the relevant domain, while PageRank can favor documents that are frequently or meaningfully used. The goal is to avoid repeatedly amplifying one narrow signal just because cosine similarity ranks it highly.
Duplicate chunks can be collapsed while their source lineage remains available
Graph structure makes it possible to reduce repeated content without simply deleting rows. Cossette describes collapsing chunks whose text and embeddings are effectively the same into a single node while preserving the original relationships and sources. This can make retrieval more efficient because the same embedding is searched once instead of many times. The source connections remain available for tracing where the content came from. She also notes that teams may choose how to handle properties during a collapse. Legal or governed data may require retaining more detail, while another application may only need to change what appears in the retrieval index.
Co-occurrence and centrality reveal how documents work together
Cossette creates a co-occurrence relationship between chunks that were retrieved together for the same message. The relationship can be weighted by how often the chunks appear together. This exposes affinities that are different from embedding similarity. A team can also study the order in which chunks appear, such as which documents tend to follow others, and use that information to understand or predict conversation paths. Other graph metrics answer different questions. PageRank identifies influential nodes, while betweenness centrality finds nodes that connect otherwise separate areas. These measures help teams decide what content deserves attention during curation.
Evaluation should determine the ontology and retrieval structure
When asked to compare tree-based indexes with knowledge graphs, Cossette gives an evaluation-driven answer. Teams should define the questions users will ask and use those questions to guide the data model and ontology. The same principle applies to choices such as community summaries or graph representations. She advises starting with a subset of the data, using generic terms, evaluating the results, and refining the schema before importing everything. For large organizations, avoiding unnecessary labels and relationship types can reduce complexity. Her advice is iterative data engineering: begin small, test the structure against real questions, then become more specific where the results require it.
"The beauty of the retriever is in this ability to traverse and traverse very quickly and get that immediate context."13:23
Who should watch
You are building a RAG or agent application and need retrieval to use relationships around a matching chunk.
Your vector results contain repeated, stale, narrow, or low-quality documents, and you need ways to inspect and curate the grounding set.
You need to understand how users, prompts, responses, and retrieved context interact in production, especially in a setting where traceability matters.
