the allure and failure of knowledge graphs
knowledge graphs are one of the sexiest sounding methods in theory. scientist and engineer types are attracted to codifying knowledge in an abstract, syntactically perfect way. the history is full of big projects trying to bridge the gap between the perfectly syntactic knowledge graph world and the mushy semantic world. they all failed so far.
the newest revival of knowledge graphism is combining the knowledge graphs with llms. go through the comments, people are again attracted by the idea of abstracted, perfected knowledge. i believe this concept finds resonance because interacting with llms is inherently mushy.
however, modern llm's should be seen as more efficient knowledge graphs (efficient in the economic sense of the word 1). llm's with agentic capabilities are even more efficient! llm results are not as satisfying as syntactically and deterministically querying a knowledge graph, however. the biggest knowledge graph user google is pivoting to enhancing their results with AI overviews. funnily enough, google itself is sneak dissing the usefulness of knowledge graphs in the linked pr statement:
We’ve meticulously honed our core information quality systems to help you find the best of what’s on the web. And we’ve built a knowledge base of billions of facts about people, places and things — all so you can get information you can trust in the blink of an eye.
Now, with generative AI, Search can do more than you ever imagined. So you can ask whatever’s on your mind or whatever you need to get done — from researching to planning to brainstorming — and Google will take care of the legwork.
people love to post examples of bad AI overviews, but whenever i look over the shoulder of my friends, most of their google queries are answered by the AI overviews section.
i believe knowledge graphs work best when you can codify your knowledge as honest-to-god facts. facts that have the least possible amount of interpretation potential, the least amount of semantics. because llms just capture semantics better, or worded differently, capture the context of the query better. as dissatisfying as the realization is, the real world is mushy and big, and thus can currently only be captured by mushy and big models.
related ideas:
☺️footnotes:
-
claude opus 4.5's take:
↩
Software Efficiency from a Buyer's Perspective
Efficiency in software services boils down to value per unit of cost. Here's how to evaluate it:
1. Total Cost of Ownership (TCO)
Not just the subscription price, but also: implementation time, training, integration costs, and ongoing maintenance. A cheaper tool that needs constant workarounds is less efficient.
2. Time to Value
How quickly does the service deliver results? A service that saves 10 hours/week but takes 6 months to deploy may be less efficient than one saving 5 hours/week but operational in 2 days.
3. Resource Utilization
Does Service A require 3 employees to manage while Service B runs autonomously? The labor overhead directly impacts efficiency.
4. Output per Dollar
Compare: transactions processed, users served, or tasks completed relative to cost. Service A at $500/month handling 10,000 requests is more efficient than Service B at $300/month handling 5,000.
5. Opportunity Cost
Choosing a less capable service means lost productivity, slower scaling, or missed features that competitors leverage.
The Core Equation:
Efficiency = (Business Value Delivered) / (Total Resources Invested)
A buyer should pick the service where marginal cost yields the highest marginal return, factoring in both direct expenses and indirect costs like time, complexity, and scalability limits.