GraphNews

Why every team is building its own AI context, and the thin federated layer that keeps it consistent. Part 1 of 3.

Lessons from i2b2 on why speed, trust, and scale in health AI come from agreed definitions, not smarter models.

A single credit agreement can come with several drafts, amendments, and side letters, and an AI agent needs to know which version controls before it can answer a question about it. An agent has a hard time piecing that structure together from raw files, which is why context graphs are a promising direction for improving agent quality and efficiency. We ran a series of experiments on Legal Agent Bench to measure the impact. For each task, an agent first reviewed every document in the client matter and built a graph of the relevant entities and their relationships, such as parties, dates, draft vs. executed status, and which versions belong to the same contract. We then compared the same agent with and without the context graph, using LAB’s standard grading setup. Overall, the agent with the context graph improved rubric pass rate by up to 30% while reducing task cost by up to about 50%. In some cases the improvements were much larger. In one firm-knowledge task, the agent was tasked with finding the firm’s most recent secured financing and retrieving the executed credit and security agreements as precedents for a new facility. Working from raw files, the agent searched through files one at a time across many matters and selected the wrong precedent (0% of rubric criteria). With the context graph, the same agent found the relevant matter and its executed agreements immediately (75% of rubric criteria). The video below walks through the results. We’ll have more to share soon on how we’re building this into Harvey, along with more experiments like this one! | 12 comments on LinkedIn

The Semantic Web had the right vision and the wrong tools. Thirty years later, the tools have caught up.

Searching text-rich knowledge graphs requires following relations while examining textual evidence. Predefined graph interfaces constrain what evidence agents can access, even when they write code to combine tool calls or process retrieved subgraphs. We propose direct knowledge graph interaction (DKGI), a harness in which language model agents create graph access tools directly over complete node and edge files. The agent writes Python code to follow relations, combine node sets, and select textual evidence, interleaving execution with shell search and file inspection. This lets agents process large node sets in bulk while returning selected text for the model to assess. Execution feedback guides tool creation and revision, while the evolving tools determine what evidence the agent gathers next. On benchmark datasets spanning three domains, training-free DKGI exceeds the strongest published baseline by at least 6.7 Hit@1 points on every graph, even with a minimal harness. Controlled ablations show the benefits of multi-turn programming over shell-only access and predefined graph tools, while trajectories show agents revising code to extend searches or address errors. These findings highlight the value of allowing tool creation and tool use to co-evolve during graph search. Our code and data are available at https://github.com/leopoldwhite/DKGI.

Knowledge Graph-based Retrieval-Augmented Generation (KG-RAG) has emerged as a promising paradigm for enhancing LLM reasoning by retrieving multi-hop paths from KGs. However, existing KG-RAG frameworks often underperform in real-world scenarios because the pre-captured knowledge dependencies are not tailored to the downstream task or its evolving requirements. These frameworks struggle to adapt to task-specific requirements and lack mechanisms to filter low-contribution knowledge during generation. We observe that feedback on generated responses offers effective supervision for improving KG quality, as it directly reflects user expectations and provides insights into the correctness and usefulness of the output. However, a key challenge lies in effectively linking response-level feedback to triplet-level contribution evaluation and knowledge updates in the KG. In this work, we propose EvoRAG, a self-evolving KG-RAG framework that leverages the feedback over generated responses to continuously refine the KG and enhance reasoning accuracy. EvoRAG introduces a feedback-driven backpropagation mechanism that attributes feedback to retrieved paths by measuring their utility for response and propagates this utility back to individual triplets, supporting fine-grained KG refinements towards more adaptive and accurate reasoning. Through EvoRAG, we establish a closed loop that couples feedback, LLM, and graph data, continuously enhancing the performance and robustness in real-world scenarios. Experimental results show that EvoRAG improves reasoning accuracy by $7.34\%$ over state-of-the-art KG-RAG frameworks. The source code has been made available at https://github.com/iDC-NEU/EvoRAG.

Artificial intelligence is increasingly used to support energy-system operation and engineering decision-making, but its practical value depends on wh…

Maintenance work orders are the largest written record of how industrial equipment fails, yet in most plants they are close to unusable for analysis. Short texts are abbreviated and misspelt,...

AI agents need more than data meaning; they need governance that survives crossing platforms. This is the gap no ontology vendor sells you.

So many people are sitting on data thats well structured, highly connected, curated, and maintained. But, do you need all of it for your core business? Chanc...

What I keep hearing from teams trying to make agents reliable, and what I hope we can work out at the Context Conference on October 28.

In the context of AI, "ontologies" and "semantics" have been getting a lot of attention, for instance in relation to semantic layers, retrieval-augmented generation (RAG), and context provision. Yet, perhaps paradoxically, there is still a lot of confusion about what "ontologies" and "semantics" act

Ontology is hard to do well, the experts argue about things no decision maker should care about, and selling an “ology” to management is a tough gig. So I wanted to focus on real benefits: what did ontology ever do for us? Decision making requires accurate, relevant and timely information. The problem for most large organisations is that this information is smeared across databases of varying vintage and quality, few of which follow any common standards. You can get to all of it, but because all that data was constructed to different rules and standards, it’s hard to integrate it meaningfully. A good ontology gives you a way to find common meaning and patterns across those data sources so they can be pulled together as needed. A taxonomy will give you a way to tag terminology, but a proper ontology will provide common business patterns that allow you to standardise the meaning of your data (the semantics) as well as the terms. All the data you need, integrated and standardised meaningfully – this is how Telicent CORE and other ontology-driven systems work. Another use case we often see is data sharing. Because a good ontology digs deeper than just terminology, it strengthens the meaning and reduces the ambiguity in data exchange. Words are dangerous – it’s always very hard to know if another person (or system) has precisely the same understanding that you do. A good ontology pushes a lot of the meaning into the structure of the data, rather than relying on terms. For example, identifying something by what it’s part of is often more reliable than a simple name or key. A really good ontology can accommodate ambiguity, enabling data owners to be specific about how they’re being vague. Better to embrace and understand the complexity than to pretend everything is clear cut when it comes to sharing safety-critical data with partners. Finally, and less intuitively, a good, formal ontology gives you a new way to look at problems – a fresh perspective on the world. The really good ontologies have foundations that formalise very high level concepts. Philosophers and logicians call these “metaphysical choices”. The practical reality is how do you come up with a reusable and scalable approach to concepts like space and time, causality, classification, uncertainty, etc. If you can find the right ontological framework for your business, it gives you a much cleaner way to look at problems. Getting these foundational concepts a) correct and b) useful is no small task. The existing standard upper ontologies are therefore the best place to start. Not only has someone already done most of the hard work for you, but other people are using it, so hiring is easier. Standard ontologies also give a level of data interoperability with like-minded partners. There are more uses for ontologies, but in my view the ones that really deliver benefit are data integration, data sharing, and a fresh analytical perspective on complex data problems. | 15 comments on LinkedIn

Separate Knowledge from Data is lesson 17 of my “20 Lessons from 20 Years of Building Ontologies and Knowledge Graphs” because data and knowledge have properties that need to be managed differently. I was lucky to meet with Stefan Dietze Akhil Arora Gerard de Melo at the “Large Language Models Meet Knowledge Graphs” Schloss Dagstuhl – Leibniz-Zentrum für Informatik (LZI) seminar who all shared similar instincts and further pushed this idea. (Btw longer trip report coming but I want to share what is top of mind.) Akhil was arguing that language and reasoning should be separated, while both Stefan and Gerard argued the same for language and knowledge. Taken together, that gives four components: language, reasoning, knowledge, and data. What we observed is that these four components provide a framework where we can map onto systems we've built before. For example, a traditional knowledge base combines knowledge and data. A knowledge graph combines data in the form of the graph and knowledge as an explicit ontology. Logic-based approaches such as description logic is an explicit reasoning layer. Deductive database systems are an example that combines all four with Datalog as a language, inference rules are the reasoning, and the explicit facts are the data. The framework fits these systems without strain, which is part of why I think it will hold up. Large Language Models combine all four in one place. Language is natural language, data is a large unstructured corpus, and knowledge and reasoning are induced from that corpus. The current evolution of LLM systems is a story of pulling components out. RAG expands the data component. Moving some decisions into explicit decision logic (i.e. Jev) offloads reasoning, which is cheaper and more controllable. Neurosymbolic systems strive to make reasoning explicit. Much of the knowledge (and “context”) an enterprise depends on is not learned by the model, so it has to be supplied externally. Each component also sits on a spectrum of possible options to consider. Language runs from expressive natural language, with high ambiguity, to structured query languages, with precision. Data runs from unstructured text through tables to graphs and trees. Knowledge runs from formal ontologies represented in OWL to codified, informal knowledge in natural language an skill.md files. Reasoning runs from deterministic rules and workflows to learned, probabilistic reasoning. I find this framework useful for three reasons: 1) It helps diagnose which component is weak or overloaded in a given system. 2) It helps decide where to invest, whether in data, in formalizing knowledge, or in making reasoning explicit. 3) It helps frame the social side of technical choices: who owns the knowledge, who maintains the ontology, and who is accountable for the reasoning. Does this resonate? This is what happens when you put a bunch of computer scientist in a castle in the middle of Germany for a week. Including napkin sketches | 24 comments on LinkedIn

Large language models made structure cheap.

Why enterprise Knowledge Graphs need more than AI-generated schemas — and how human expertise, AI-assisted discovery, and continuous…

An ontology grows through collaboration between domain experts, ontology engineers, data teams, use-case developers and governance. Once data products and agents depend on it, changing a concept means changing part of overall eco-system.

Researchers have built an open-source system that converts ephemeral AI chatbot explanations into a permanent, morpheme-linked vocabulary graph with built-in spaced repetition, outperforming established segmentation tools by wide margins.

929 million edges in 10.8 minutes, and 83.2% on 600 held-out questions

Token Drop Episode 22: Arun Sharma of LadybugDB joins Sunil Baliga, Sajjad Khazipura, and Sam Pooni for a technical conversation on embedded columnar graph databases, MMAP, graph-vector hybrid search, temporal graphs, and the agent memory problem.

Enterprise semantic layers are largely middle ontologies. Yes, mapping to upper ontologies is important. But for the most part, semantic layer design deals in traditional questions of conceptual modeling, such as how to cope with legacy system schemas, how to represent business processes and business rules, how to integrate reference data, and how to create pragmatic, structured, and scalable systems for quotidian purposes like decision support. For a few years, I have worked through a variety of approaches to business process representation specifically. I have created process models in Prolog, in SQL, in Drools, in RDF, in Neo4j, in procedural and functional languages that support pattern matching, and in XML languages like XQuery. My first experiments used graph representations of state machines. But as I continued focusing on the problem, I realized the limits of the state machine approach: 1. We frequently need to remember variables with data types and even complex record types (customer records, order records, log files, telemetry data, etc.). State machines with their simplistic event labels don't excel at remembering variables. You can introduce stack machines, but you are still limited in expressivity and in typing discipline. 2. State machines suffer from state explosion. They can't model concurrency. They aren't flexible enough to use with modern ontology pipelines that leverage LLMs or NLP techniques to auto-construct knowledge graphs from both structured and unstructured data. 3. Validation and verification approaches for state machines leave much to be desired, specifically in the realm of measuring quality of business process models (more work has been done on state machine modeling for distributed software systems, but even there the inability of state machines to elegantly handle concurrency is a major limitation). For these reasons, I've recently moved my work on auto-generating knowledge graphs at scale onto colored Petri nets. Colored Petri nets are actually Turing complete (if you allow an infinite number of token colors). They are far more expressive than state machines, and easy to implement even in Neo4j. You can find established, algorithmic approaches to validation and verification that have been used across thousands of industrial organizations for decades. Data and record typing is consistent across transition guards, and there's a sensible way to understand how transitions consume typed objects and output (in some cases different) typed objects. Colored Petri nets have already been mapped to popular process modeling frameworks like SAP ARIS and OMG BPMN in order to provide formal semantics for these frameworks. So if your organization isn't already mandating an enterprise-wide framework for process modeling, why not simply implement the graph model that gives formal semantics to ALL the major process modeling frameworks directly in your database schemas? https://lnkd.in/gFtXqz46