Knowledge Graphs

TL;DR for operators An internal document collection can contain the relationships needed to answer difficult questions while still lacking the labeled examples needed to teach a retriever which relationships matter. That usually leaves teams choosing between manual annotation and retrieval based mostly on embedding similarity. SelfGraphRAG1 tests a third option: build a knowledge graph, turn its structure into generated question-answer examples, and train the retriever on those examples. On MultiHop-RAG, the resulting system reports F1 of 24.62, compared with 2.60 for RAG, 0.98 for LightRAG, and 0.01 for GraphRAG. ...

TL;DR for operators The paper addresses a problem that appears after literature retrieval succeeds. A research organization may already have the relevant papers and may even have extracted the reported measurements, yet those observations can still be unsafe to combine because material names, property definitions, units, temperatures, methods, and other conditions do not align. ...

TL;DR for operators When a question requires several facts to be connected, improving entity coverage is not enough if the graph still lacks the relations needed to move between those facts. In a 200-query structural-connectivity pilot, pure Freebase connected the required endpoints within three hops in 24.1% of cases. Wikidata raised entity linking from 77.0% to 85.6%, but connectivity reached only 37.6%. Adding document text into the Freebase-based graph raised connectivity to 69.7%. ...

TL;DR for operators A production RAG system returns the same answer five times. The operator still has to decide whether to release it, investigate it, or send it for review. Repeated agreement is useful evidence that generation is stable, but it does not show that the system retrieved the right material. All five answers may have been generated from the same empty, incomplete, or incorrect context. In that case, repeated sampling does not independently test the answer; it repeatedly tests the decoder under one defective retrieval state. A wrong answer that remains effectively unchanged across samples is a silent error. ...

TL;DR for operators Synthetic data is having its predictable enterprise moment: everyone wants more of it, faster, cheaper, and preferably without involving humans who ask inconvenient questions like “is this correct?” The two papers here are useful because they push against that lazy version of the story. StateGen, from PayPal AI, focuses on generating multi-turn training conversations for tool-augmented LLM agents, using an authoritative world-state object, tool simulation, persona variation, and multi-axis judging.1 CYQUARK focuses on generating Text-To-Cypher fine-tuning data from a target property graph and schema, expanding query expressivity while filtering natural-language paraphrases for logical fidelity.2 ...

TL;DR for operators Most business systems do not fail because they lack another dashboard. They fail because the dashboard is reading from a structure that changed three minutes ago, and nobody knows which part of the structure is now stale. Delightful. The paper behind this article proposes an incremental algorithm for maintaining first sheaf cohomology, $H^1$, on evolving 1-dimensional cellular complexes — essentially graph-like structures decorated with local vector spaces and consistency maps.1 In plainer operational language, it is about tracking whether a changing network of constraints still holds together without rebuilding the whole mathematical object after every edit. ...

TL;DR for operators RAGA is not another “add a graph and accuracy goes up” paper. That would be too convenient, and therefore suspicious. The useful idea is more operational: treat retrieval-augmented generation as a knowledge management process, not a pile of embeddings with a polite chatbot on top. The paper proposes RAGA, short for Reading-And-Graph-building-Agent, an autonomous system that reads documents, searches existing graph knowledge, verifies whether new entities or relations should be added, and then constructs or updates a knowledge graph with source-linked provenance.1 Its core loop is Read–Search–Verify–Construct, implemented as a ReAct-style tool-calling agent rather than a one-shot extraction pipeline. ...

Curved Space, Straighter Retrieval: Why Graph RAG Needs Geometry Retrieval looks simple until the wrong thing keeps showing up. A company builds a graph model over products, papers, suppliers, users, or transactions. The model performs reasonably well inside familiar territory. Then the data shifts. New products appear. A new research domain enters the citation graph. A social platform changes user behavior. The model’s internal knowledge, frozen inside parameters, starts behaving like yesterday’s org chart: technically structured, operationally stale. ...

A product catalog is not a paragraph with a search box Catalogs look deceptively friendly to RAG systems. A product page has descriptions, feature bullets, specification tables, prices, variants, categories, and marketing copy. Feed those pages into a vector database, ask an LLM a question, and the system should answer. This is the comforting story. It is also where many enterprise RAG demos begin their quiet decline into customer-support theater. ...

Memory is cheap until it has to remember correctly. A chatbot can remember a paragraph for a few minutes. An enterprise agent is asked to remember a customer’s old address, current address, account owner, exception approval, product issue, refund promise, and the reason the promise changed last month. Then it must answer without mixing the past with the present. This is where “just add more context” begins to look less like strategy and more like buying a bigger drawer for unsorted receipts. ...