NODES AI 2026 - Adaptive GraphRAG: A Framework for Knowledge Graph Quality, Consistency, Evolution

In this talk, Joshua Yu, founder of Graphway, discusses the challenges of maintaining and evolving knowledge graphs over time, rather than treating them as static artifacts. He highlights common issues such as duplicates, co-reference drift, composite entities, and weak provenance that diminish graph quality as the system scales. The speaker introduces the concept of the generative knowledge graph life cycle, emphasizing the importance of continuous enrichment, evaluation, and structural governance. Yu also presents a framework for adaptive graph retrieval, showcasing methodologies to improve graph quality and consistency. He details the role of various operators, including deduplication and relationship prediction, which help maintain the reliability of knowledge graphs in production environments, particularly in AI-driven applications.

Hi everyone. Thanks for joining from wherever you are in the world. It's great to be here. I'm Joshua Yu, founder of Graphway, and I work on knowledge graphs and the graph rack systems, particularly how to make them accurate, consistent, and reliable over time. Most graph rack discussions today start with a familiar question. How do we turn context into a knowledge graph? But in the real world systems,

the reality is the quality of generated responses degrades with the growth of knowledge graph over time. The real and the bigger challenge I've been seeing is not graph rack itself. It's that we often treat knowledge graph as a static artifact instead of a system that needs to evolve. In this talk, I want to shift the focus on what happens after the extraction, how we ensure knowledge graph

quality, how we maintain consistency, and how we evolve the graph along the way. So, let's start with the problem. Graph rack is attractive because it adds structure and a multi-hop context to generated AI. But the many graph rack systems quietly assume that a knowledge graph is already correct, clean, and connected. In production, when graphs are larger, complex, and a growing rapidly, that assumption breaks fast. So, the

real challenge is not just graph construction, it's graph maintenance and a graph evolution. Let's make this make more concrete by looking at some of the most common failure modes we see in real knowledge graphs. First, duplicates. The same real world entity shows up under multiple names, abbreviations for names, slight variations, and so forth. To human, they're obviously the same. To the graph, they're completely different nodes. Then

we have the coreference drift, things like it, this program, or the association. If we don't resolve those properly, we lose continuity across the graph. Next, composite entities. Sometimes extraction bundles multiple concepts into one node, like anxiety and depression. That looks fine at first, but it breaks reasoning and it limits how we can traverse the graph. Then there are contradictions. Different documents, or even the same document over

time, may assert conflicting facts. If graph doesn't capture or reconcile reconcile that, we end up with silent inconsistency. We also see fragmentation. Instead of one connected graph, we get many disconnected islands. That severely limits multi-hop retrieval, which graph rec depends on. And then finally, weak provenance. Fact exists, but we can't clearly trace them back to source evidence. That makes it hard to trust the output and hard

to debug when things go wrong. Individually, these issues seem manageable, but together, they compound, and then this is where graph rec starts to quietly fail. My core claim is simple. Graph rec could be treated as a life cycle discipline. We need a structured methodology for how knowledge is modeled, enriched, evaluated, and evolved. In many cases, fixing the graph yields more value than swapping one LLM for another.

Let me introduce the generative knowledge graph life cycle. Instead of a trading a knowledge graph as something we built once, we treat it as a system that evolves over time. We start with discovery and the modeling, understanding the domain and the deciding the structure of the graph. Then extracting and constructing the initial graph from text. But the real value comes after that. In enrichment, we clean and

structure the graph, resolving duplicates, coreferences, and abstraction. And importantly, this is also where governance begins. We define what is allowed in the graph, how entities should be represented, and what constraints we want to enforce. For evaluation, it needs to be across the whole life cycle and the measures both structure and semantic quality. This life cycle turns a classic graph into a living system, and that's what enables

adaptive graph rag. By adaptive graph rag, I mean a graph rag approach where the graph is not static. It is continuously assessed and improved using structural signals, semantic checks, and the downstream retrieval outcomes. It is about adaptive graph quality, adaptive consistency, and adaptive So, what does this look like operationally? There is a enrichment loop exists in this adaptive rag graph rag, which involves several steps or tasks.

Split phrase like anxiety and depression should not always be one node. Abstract specific instances can roll up into higher-level concepts. Resolve, pronouns, and indirect references need to be grounded. Normalize, consistent naming reduces graph drift. Link evidence, every claim should remain traceable. And the cluster duplicates, graph algorithms can help with identify consolidating candidates. This is where the KG start to become retrieval ready, rather than just extraction complete.

When quality becomes a first-class concern. Once we start talking about graph quality, the next question is, how do we actually measure it? Because saying this graph looks better is not enough. We need a graph native for matrix that tells us whether the structure is improving over time or not. One important signal is giant component growth. As the graph matures, more nodes should become connected into a single

large component. If the graph stays fragmented, it limits multi-hop reasoning and retrieval. The closely related is the number of isolated subgraphs. Too many disconnected islands usually indicate missing links and resolved entities or poor normalization. Then we have duplicate density. How many nodes are actually representing the same level of the real world concept? If this is high, retrieval becomes inconsistent and a brittle. Which leads to alias to

canonical consolidation. Over time, we want more mentions and the variations can converge onto stable canonical entities. That's a sign the graph is becoming more coherent. Another key metric is evidence coverage. When we convert text into knowledge graph, how many facts in the graph are actually grounded in source material? This directly affects trust, explainability, and debugging. And then finally, structural stability across ingestion cycles. As new data comes

in, is the graph becoming more consistent, or are we introducing more fragmentation and noise? So, the key idea here is graph quality is not just semantic, it's structure. And if we want adaptive graph rag, we need to track these signals and use them to guide how the graph evolves over Knowledge graphs in the age of LLMs are no longer just manually designed or statically constructed. They are

partly generated, partly structured, and continuously refined. And I call it generative knowledge modeling, or GNKM in short. GNKM is not a single technique. It's a combination of stages that all work together to turn unstructured data into reliable, evolving knowledge. We started with knowledge graph. That is a We started with the document graph. This preserves original structure of the source. Documents, sections, chunks, and sentences. This is our

foundation for context and evidence. On top of that, we build the entity relation graph. Entities, relationships, and the claims extracted from the text. This is what most people think of as the Then we introduce the cluster graph where we aggregate and summarize information giving us a more global view of the content of the knowledge in the Ontology graph can be added before and or after which define

concepts, terminologies, and the class hierarchies. This is where meaning becomes stable and consistent. Crucially, we maintain cross-stage links which connects everything back to its source with full provenance so nothing loses context. there is an operational layer where query time state is created during serving supporting time variant personalized context for graph rack and agent workflows. instead of a single graph, we have a system of connected graphs from

raw to structured facts to global understanding to long-term intelligence. That's the essence of the GenK M. And the implementation view of adaptive graph rack, Neo4j stores not just entities and the relations, but also evidence and concept layers together with the long-time operational intelligence. For example, for a specific question, what are the founding or grounded chunks from the original document have been retrieved and arranged. And what is

the final generation of the responses? Cypher handles graph traversals, transformations, and the repair The graph data science GDS helps us inspect structure and detect likely consolidation opportunities. And LLMs are used as controlled assistance for tasks that are hard to do symbolically. The key is not blindly trusting LLMs. The key is replacing them The sorry, the key is placing them inside a graph-centered life cycle with traceability and

evaluation. Let me briefly introduce the document graph because it is one of the most overlooked parts of graph rag architecture. A document graph preserves the structure of the original source material. sometimes sentences along with their hierarchy and sequence. This matters because meaning is often shaped by context, not just isolated text spans. Especially for legal documents and instruction manuals, it is crucial to keep exact order and a

complete So, looking at the example here on the screen, we see the purple the purple nodes are actually representing the chunk from chunks of the original documents separated by their natural paragraph or sentence. come from the the purple no- nodes which represent the section in the document. For example, chapter, sub-chapter, and sub-sub-chapters, and so forth. And the sign nodes represents original So, entities or class Sorry, the

claims mentioned in or involves involved in each chunk are represented in the green as the green nodes here. And within claims, there are brown nodes representing the entities mentioned. So, by modeling document structure explicitly, we can trace every extracted entity or claim back to its source location. That gives us provenance, explainability, and a much better evidence layer for GraphRAG. One key piece that makes Adaptive GraphRAG work

is the ontology graph. Instead of treating extracted entities as a final truth, we anchor them to canonical concepts. Why is that? Extraction gives us surface mentions. The ontology graph defines meaning. The canonical layer connects the two. Ontology reduces duplicate entities, stabilizes naming, supports abstraction, improves retrieval consistency, and allows evolution without breaking queries. The ontology graph evolves more slowly than extracted entities, so they are more stable. It

becomes the semantic backbone that keeps the knowledge graph consistent In Neopathy, we typically model this as a concept layer with relationships like instance of between the entity and a terminology, broader or narrower between terminologies, defined as, has acronym, or domain specific types. Entities extracted from the text are then linked to those ontology nodes, give them very strictly defined non-ambigu- ambiguous definition or meaning uh in full specific

domain. Generative knowledge modeling also defines the missing how, which are reusable transformations that create, refine, connect, and serve knowledge across stages in an AI native pipeline. We call them operators. Operators are the actions we apply to the graph, things like deduplication, convolutioning the meaning, embedding, prediction, and aggregation, to name to name some. They combine ARM with graph operations to continuously refine the graph as new data arrives.

And because they're repeatable and auditable, they give us a practical way to manage knowledge graph quality over Here are some commonly used operators during the enrichment or adapt for adaptive graph rack systems. With the inputs, outputs, and the usage mentioned on slide, which I will cover with more details in the following uh slides. Oops. Let's take a look at the operator dedupe. The goal here is very

straightforward and simple. Identify and then resolve entities that actually represent the same real-world concept. We started with a batch of newly imported entities, for example, from a recent ingestion cycle. For each entity in that batch, we look for similar candidates in the existing In Neo4j, we can do this efficiently using vector index, where we query for nearby nodes in embedding space. So, instead of comparing every entity

with every other entity, we narrow it down to a small set of likely matches. Then, for each entity, for each candidate neighbor, we compare normalized names or the canonical forms, which removes the the plural format, uh any uh uppercase, lowercase to be standardized as well for simple match. If they match, we can keep both nodes at the and then treat them as linked entities through same-as relationships.

Or, if we're confident enough, we can merge them into a single canonical using something like APOC refactor merge Metadata like confidence, method, and a batch ID is also stored, so the the decision is traceable and auditable. To summarize, this operator is enforcing entity consistency, is capturing lineage and decisions, and is turning a noisy graph into a more coherent coherent one. And importantly, it is not a one-time

step. We run this continuously as new data arrives, so the graph becomes more consistent over time. Another operator, prediction, in short, PRE D, discovers implicit relationships between entities that are semantically related but not explicitly connected in the graph. This is how it works for entities created in a batch. it retrieves semantically similar entities already in the knowledge graph using the vector index. Then, for each entity pair,

it computes a composite score from two other independent signals. One is the Adamic Adamic-Adar score. Do they share rare structural neighbors in the graph? And common concepts. Do they belong to the same ontology classifications? Or linked to the same terminologies? Different from the Jaccard similarity, Adamic-Adar measures how structurally two nodes are by counting their shared neighbors, but giving more weight to shared neighbors that are rare, which

means has a low degree, than two hops, which means has high being having a high degree. So, when the score, the final score, the composite score exceeds a predefined threshold, a related relationship is created. AGGR, aggregation, organizes the flat entity set into a two-level hierarchy by identifying the most prominent concepts as cores and attaching everything else beneath them. The two steps involved. The first one is the

core marking on the global graph. The top K entities by counting mentions relationships across the entire graph, are promoted to role the core role. They This represent the most frequently discussed concept in the source documents. The anguish are the anchors of the knowledge base. Then the second step for each delta ingestion or batch, which is a child attachment. Every non-core entity found this near the core by

vector similarity and it gets attached by a has child edge. The result is a navigable summary layer. Start at a core concept, traverse has child to explore related specific sub-children. This gives the agent a structured entry point into the graph, rather than a flat, undifferentiated set of entities. Let me make this more concrete with a quick case study. This is a di- diabetes companion system designed to

provide safe, contextual, and evidence-grounded support for users. What's interesting here is that it combines two things we've been discussing, Graph Rag and agentic The Graph Rag inside ensures response responses are not just from text embeddings, but anchored in a graph that preserves meaning and context. On the agent side, we introduce controlled reasoning and actions based on domain semantics. The agent can resolve terms, check for ambiguity, follow

relationships in the graph, and then decide when to provide an answer, ask for clarification, or escalate. This is especially important in a domain like healthcare, where accuracy and the safety really matter. The entire system is deployed on Neo4j Aura, using both the Aura database and agent layer. So, there's no infrastructure setup required at all. Conscious of time, I won't be able to demo it today. So, I

put the links to GitHub repo and a blog post for your references. Feel free to have a play yourself and share with me what you think. When combined combining a well-structured evolving knowledge graph with agentic reasoning, you get systems that not only more capable, but also more grounded, explainable, and reliable. I'd like to conclude my presentation with the one phrase, "Fidelity quality out." What is not preserved

in meaning cannot be recovered in reasoning. If a graph rack is going to move from demos production, we need to move beyond extraction and adopt a structured methodology for when do because knowledge is modeled, evaluated, and evolved over time. That's what I've tried today to outline with adaptive graph rack, part of the generative knowledge graph life cycle, an approach where the graph is not static, but continuously

enriched, measured, and refined. And the Neo4j graph database, GDS, the graph data science and Aura provide practical features and the ready-to-use operators to build exactly that. And this is end of my talk. Thank you.