Richard MacManus, of ReadWriteWeb fame and now the editor of Latent.space (on Substack) has a great writeup on the return of the knowledge graph in a world of LLMs. As a big knowledge graph fan, I’ve noticed this too! To quote MacManus:
Perhaps ontologies are starting to resonate with AI engineers because a central concern at this time is quality control for loop engineering. We saw this debate play out at [The AI Engineer World’s Fair Conference], with many conference speakers not willing to go all-in on fully automated “software factories” just yet. One of the key learnings from the event was that there need to be guardrails and humans in the loop.
I want to offer an explanation, some caution, and a prediction, in that order.
Explaining Knowledge Graphs #
First, let’s explain “knowledge graph,” as well as “ontology.” A knowledge graph is a database of facts, but the facts can link together (that’s the graph part). Here are five facts:
- Julie isA person.
- Julie isA productManager.
- Julie worksFor GitHub.
- GitHub isA company.
- GitHub isOwnedBy Microsoft.
Those particular statements take the form of “triples”—Subject, Predicate, Object. It’s a tiny little database but nonetheless, we can go full Aristotle on it and derive other facts: A person can be a product manager; Julie ultimately works for Microsoft; and so forth. But what if I made a mistake and typed in, “GitHub isA productManager”? That would make no sense.
So we need a way to express rules about facts, like “Product manager is a work role; work roles must be filled by people; and one person can have at most one role.” Then the computer could catch my error by checking my facts against those rules. It could use the rules to derive more facts, too. You could give a computer thousands of facts, apply rules, and get millions of facts as a result. What a bargain!
When you bundle up all the rules, that’s called an “ontology.” It’s the worst word imaginable for what it is, but you can’t stop nerds from being pretentious. An ontology lets you look at the facts in a knowledge graph and say “that’s a valid fact,” and, “since we know that fact, we know these other facts, too.”
Knowledge Is Hard #
The big problem is that the world doesn’t come as a bundle of facts, so you have to make them—and make the ontologies, too. This can be a whole actual job. Decades ago, the machine reasoning company Cyc offered a role as “First Order Logic Axiomatizer.” That’s stuck with me. I really wanted to get that job and introduce myself as an axiomatizer at parties, just as soon as anyone invited me to a party.
If you want to see what this all looks like in practice, check out Wikidata. It’s a huge knowledge graph derived from the data inside of Wikipedia, built by humans, and used to power automated projects inside of the Wikipedia world—to support translation, for example. Here’s the entry for “knowledge graph,” to get recursive. Or the one for the author Douglas Adams, which is sort of their key example entry. I am a big fan of knowledge graphs because they let you capture all kinds of relationships and they’re very “webby” because they link data together in loose ways with tools to explore the links. But—here’s the caution, as promised—there are lots of tradeoffs. As you can see, they’re conceptually challenging. A normal database lets you save a purchase order and later retrieve it. These are bundles of ideas, entities, and relationships and you explore them to find new ideas and relationships. They are hard to query because they don’t see the world as a set of rows and columns in tables, but as a huge bag of triples.
Connect For? #
So why bother? Well, hit the open query endpoint for Wikidata and try out some of the examples. Here are some queries you can make:
- List of torture devices
- Most prolific fathers
- Objects with most mass
- Cathedrals in Paris
- Rock bands that start with “M”
- Sandwich ingredients
- Ten largest islands in the world
I find this awesome. You could also ask for “most prolific fathers by nation” or “list of torture devices used in the medieval era.” You can keep connecting everything to everything.
But look at that last one. The query for the largest islands is as follows:
SELECT DISTINCT ?island ?islandLabel ?islandImage WHERE {
?island (wdt:P31/(wdt:P279*)) wd:Q23442.
OPTIONAL { ?island wdt:P18 ?islandImage. }
?island (p:P2046/psn:P2046/wikibase:quantityAmount) ?islandArea.
SERVICE wikibase:label { bd:serviceParam wikibase:language “[AUTO_LANGUAGE],mul,en”. }} ORDER BY DESC (?islandArea) LIMIT 10
Which, even as someone who is good at various syntaxes, is horrible. What is “(wdt:P31/(wdt:P279*))”? Don’t answer if you know—I know, too, but the reality is that explaining that to a normie involves a lot of abstraction. You’re looking at numbers and namespaces standing for ideas. Plus that query example timed out on their server! Even they can’t handle it, and I don’t blame them at all.
Even after decades of “Semantic Web” explorations, this stuff is hard, expensive, complicated, and opaque—because human knowledge is all of those things, too. It has long been the special focus of a particular kind of nerd who is a bit obsessive, a bit library-adjacent, and very into the idea of exploring taxonomical concepts. Like me! There are a lot of us—but ultimately we’re in the tiny minority compared to people who want to put their data in a freaking database, query it when they need it, and then go home at the end of the day and watch the Mets.
Thus when you’re learning about knowledge graphs—and this will be an ever hotter topic going forward given how well they work with AI—you should know three things. First, people are very passionate about them, and as a result, they sometimes oversell them; second, it is very expensive to get data into knowledge graphs, because you have to turn that data into facts and ontologies; and third, it is very expensive to get data out, because they are hard to query.
AI Crashes the Knowledge Party #
But wait! Hold up! Just a minute! Great Caesar’s ghost! LLMs are very good at parsing plain language into other formats. Which means that the last two things have fundamentally changed. (The knowledge graph people are still going bananas on LinkedIn, that will never change.)
First, this means you can take unstructured text, data, and database results, use an LLM to turn those things into statements, and make a knowledge graph. That’s cheap now. Librarians are doing it all over.
Second, this means you can ask a knowledge graph questions in plain language, and it can consult the graph and write the query for you and produce the results and summarize the results in plain English, too. You can keep the power of something like Wikidata—the structure, linkages, and stability—without learning the query syntax.
You can use the new AI to feed the old AI good data, and then use the old AI to answer questions for the new AI so the new AI doesn’t make things up all the time. And it works! By which I mean it breaks all the time until you iteratively improve your taxonomy and then it actually does something like what you expected.
On a daily basis, I feed hundreds of URLs to LLMs (cheap ones overseas) and get facts in a formal structure back. I save those to a knowledge base and query it all the time. And it lets me ask things of our custom in-house relationship-and-industry tracking tool like:
“What conferences should we attend to build our business?”
“What are some new insurance industry products we should be checking out?”
“Who from our lists should we invite to an event about museums and AI?”
I don’t let AI answer. I let it query and augment the results.
I can also get my knowledge graph/LLM substrate to write industry briefings where everything has a provable citation and footnote, so I know exactly what I’m talking about before I go into a meeting. A lot of my nerd dreams have come true. I may even get invited to parties. And what I can do, everyone can do, by typing normal words into a normal little box.
But while this is cool, the last mile is long. You need special graph databases that don’t run as easily in a cloud environment, and a willingness to take on more complexity than many big IT organizations would prefer.
For example, PostgreSQL is an incredibly common, popular, absolutely beloved open-source database—one of the default solutions in cloud platforms. But it’s hard to do graph work in PostgreSQL: You need to install an extension called Apache AGE, and while it’s good (it’s what I use), it has a lot of caveats. It doesn’t come pre-installed.
Good News for Modern Nerds #
PostgreSQL never, ever sleeps (although it does VACUUM), and it will soon release Version 19. This version will include new functionality that lets you treat any relational data as a graph, called GRAPH_TABLE. You can read the official docs here. That doesn’t exactly turn it into a graph database—and the graph database community will yell at you if you say it does. It won’t give you all the most abstract ontology features. It won’t be as fast.
That’s okay, because you’re probably not a researcher at Lockheed identifying chemical compounds across 75,000 rocketry papers. Instead, it lets you treat a normal data set like a knowledge graph. It puts a relational database into a knowledge-graph trenchcoat. Believe me, because I don’t sell databases: That’s a perfectly fine place to start.
And this means that one of the world’s most normal, standard databases (there’s even a book called Just Use Postgres!) will, before long, allow people to manage their current data—their customer lists, research databases, office locations, transaction logs, blog posts, and so forth—as fully fledged knowledge graphs. It won’t be as deep as what you can do with a custom data layer like
Neo4J. But it will be extremely available, entirely at hand, accessible for most programmers who build web apps, and require almost no additional steps to install and use—and an LLM will readily help you with any complexity that arises. It won’t require you to give up your old way of managing data.
PostgreSQL 19 is out of beta in September, and well—this time, it just might work. Millions of devs will be able to explore this approach without installing anything. My prediction is that, via PostgreSQL, many more people will start to anchor their AI work in structured, semantically linked data—building up data stores and querying them in order to escape the endless loops of trying to make an LLM tell the truth. And that can make using LLMs less central—useful, but no longer seen as the answer to every business or software problem. I think that needs to happen. We need to start using our computers again, instead of just talking to them.
And even if it doesn’t catch on everywhere, it’s always going to be there if you want to try, in sweet, beautiful PostgreSQL. For me, this is like having the family together at Christmas and not fighting at all. The boss can have relational tables, and us knowledge-graph nerds can have some triples as a treat—and LLMs can help us get stuff in and out of the database.
It’s a little ridiculous that it took the weird new AI to resurrect interest in the old, structured AI. But I’ll take it. Semantic Web friends, we did it. We’re all first order logic axiomatizers now.