GraphRAG adds explicit entities and relationships to retrieval, which helps answer questions that depend on connections across documents.
2
Agent memory needs temporal and relational structure so it can track why facts changed instead of retrieving contradictory, semantically similar facts.
3
Production systems combine graph construction, retrieval strategies, evaluation, domain-specific schemas, and guardrails for a particular use case.
Summary
This GraphRAG track covers several ways to use graphs with retrieval and agent systems. Mitesh explains a hybrid pipeline with offline data processing, triplet extraction, vector embeddings, graph retrieval, and evaluation with Ragas. He says the quality of the ontology and extracted triplets determines retrieval quality, and describes experiments that improved triplet accuracy from 71% to 87% on 100 documents. Daniel Chalev focuses on agent memory, where temporal graphs preserve state changes and causal links instead of treating every fact as an isolated embedding. Other speakers show domain-specific memory, MCP access to Neo4j, and a graph-based memory arena. Michael Hunger and Steven Shen describe graph construction, entity extraction, graph enrichment, and retrieval patterns. Ola Mabad presents a network operations system that uses a knowledge graph and digital twin to test firewall changes. Tom Smoker describes legal workflows that turn web and document data into structured graphs for case discovery and reporting.
GraphRAG is useful when relationships carry the answer
Mitesh opens by arguing that RAG is still useful and that agents are not automatically required. A knowledge graph models entities and explicit relationships, such as a speaker's relationship to a conference or an attendee's relationship to a session. This structure helps when a question depends on how entities connect. Compared with semantic retrieval alone, graph retrieval can organize information from multiple sources and preserve detail about the relationships between entities. Mitesh's practical test is whether the use case requires understanding complex relationships. If it does not, a standard RAG system may be enough.
The graph pipeline has separate offline and online work
Mitesh breaks a hybrid system into data, data processing, graph or vector database creation, and inference. Data processing and database creation happen offline. The online path queries the knowledge graph or semantic vector database and converts the retrieved information into a readable answer. The semantic side chunks documents, creates embeddings, and stores them in a vector database. The graph side extracts entity-relationship-entity triplets from less structured documents. The quality of the initial data processing affects the graph, and the graph affects retrieval. This division gives teams a practical way to reason about where work and cost occur.
Ontology and triplet quality determine downstream retrieval
To create triplets from documents, Mitesh recommends defining an ontology for the particular use case and placing it in the extraction prompt. An example from Exxon Mobil's quarterly results identifies the company, a relationship, and an entity for spending on oil and gas exploration. He is direct that this extraction step is difficult and that teams may spend 80% of their time iterating on the ontology and prompt. Noisy triplets produce noisy retrieval. He describes cleaning characters from the source data, reducing unnecessarily long outputs, and fine-tuning a Llama model as changes that improved results. In his experiment, accuracy rose from 71% to 87% on 100 documents.
A single-hop graph search can miss the value of a graph because it only considers one relationship away from the starting entity. Mitesh recommends testing how many hops are needed for the use case. Deeper traversal can provide more context by following relationships from the first node to later nodes, but it also increases retrieval time. Production systems therefore need a practical balance between graph depth and latency. He mentions acceleration through Cool Graph and its integration with libraries such as NetworkX as a way to make deeper searches more practical. Retrieval strategy is a tunable part of the system rather than a fixed implementation choice.
Daniel Chalev argues that vector retrieval is a poor memory model when user preferences change. If a user once preferred Adidas shoes but later became unhappy after the shoes broke, semantic search may still return the earlier Adidas preference. A temporal graph can keep the history while marking the old fact invalid and recording the later state. It can also represent the causal sequence from broken shoes to disappointment to a changed preference. Graffiti combines semantic search and BM25 retrieval with graph traversal to find related facts. Daniel says this structure lets agents answer questions about what a user preferred at a particular time, which ordinary vector RAG cannot handle directly.
Domain schemas keep irrelevant facts out of agent memory
Daniel shows why generic memory creates noise. A media assistant may need podcast and music preferences, but a general conversation can also produce unrelated facts such as a wake-up time or a dog's name. If all of those facts go into a vector store, a semantically similar query can retrieve the wrong information. His solution is domain-aware memory with custom entities and edges. In a finance coach example, the developer defines objects such as financial goals, debts, and income sources with schemas and business rules. Searches can then filter for the relevant node types. The graph becomes a model of the business domain instead of an undifferentiated collection of extracted facts.
Graph construction and retrieval form a reusable set of patterns
Michael Hunger and Steven Shen describe GraphRAG as two connected phases. Construction starts by turning unstructured documents into a lexical graph of documents, chunks, and their relationships. Entity extraction then adds domain entities and relationships, and graph algorithms can enrich the result with clustering, community summaries, PageRank, or link prediction. Retrieval begins with an index search, which may use vectors, full text, hybrid search, or another index to find entry points. The system then traverses relationships to gather a richer context subgraph before sending it to the language model. Their examples stress that document structure, entity relationships, user context, and source traceability can all influence the final answer.
A network digital twin can test changes before production
Ola Mabad presents a Cisco system for network change management. It combines a natural-language interface, multiple specialized agents, and a network knowledge graph used as part of a digital twin. Data comes from controllers, devices, configuration systems, telemetry, and other sources. An ingestion service transforms these formats into an OpenConfig-based schema. The graph is layered so an agent can reach raw configuration for configuration-drift tests or use several layers for reachability tests. In the demonstration, agents summarize a ServiceNow ticket, assess impact, create a test plan, retrieve a GitHub change, snapshot the network graph, and run tests in the digital twin before reporting passed tests, failed tests, and suggested fixes.
Graph structure supports controlled workflows in legal systems
Tom Smoker describes YAL.ai's legal workflow for finding potential class-action and mass-tort cases. The system scrapes web sources, filters signals for a particular law firm, structures the information, and produces reports. A legal graph can connect people, products, ingredients, concentrations, dates, complaints, and jurisdictions. This lets lawyers move from a large collection of documents to a smaller connected set of relevant facts. Smoker stresses that legal systems need accuracy, testing, state control, and the ability to inspect what happened at each step. He is skeptical of chaining many probabilistic agents without controls, since errors compound across a workflow. Graphs provide a structured state that can be expanded, pruned, queried, and adapted to each lawyer's process.
"There is no such thing as a perfect case. It depends on the lawyer or the partner or the firm who's willing to take that on."3:10:57
Who should watch
You are deciding whether a production use case needs vector RAG, GraphRAG, or a hybrid system, and need criteria based on the data and question type.
You are building agent memory and need to preserve changing preferences, causal links, or domain-specific entities instead of retrieving isolated similar facts.
You are responsible for a workflow where engineers or domain experts need source traceability, structured state, pre-production testing, or human review.
