Engineering Knowledge Graphs For Abstract Business Systems In The Real-World
Business is a combination of prediction and optimization. That’s why data and AI are such powerful business drivers. Writing this series is challenging, and I know it is even harder to read and synthesize the complexity. Three tracks must move together for any business to succeed with AI or any technology that comes next.
Technologies, operations, and products.
The only way to align all three is for everyone to make decisions using the same framework. Nothing works if different parts of the business predict the same systems differently and optimize the same systems for different outcomes.
Strategy, especially Data and AI Strategy, is a framework for aligned decision-making. Knowledge graphs hold the domain expertise necessary to operate the business and create value for customers. Strategy must be predictive, diagnostic, and prescriptive. Knowledge graphs support all three.
In the last article, I used straightforward, well-defined systems to explain how knowledge graphs capture domain expertise. In this article, I will explain the higher-value applications of knowledge graphs to abstract systems. It’s a difficult read because we have a three-body problem.
I must explain how to architect knowledge graphs for abstract systems, build one in a business setting with business constraints, and get the business to agree to let you build it. Providing one facet in isolation isn’t actionable. I will do my best to explain how to align all three tracks without losing you along the way, and I appreciate you making the effort to read this.
I’ll spoil the ending a bit. Since business is a combination of prediction and optimization, business is a data model and a structural causal model.
We Have Other Data Models. Why Use A Knowledge Graph?
A data point or node alone isn’t actionable because it doesn’t hold any domain knowledge. We need context, and in a knowledge graph, it’s provided by relationships to other data points. A classic NLP example explains vector space and similarity measures like cosine similarity.
King – Man + Woman = Queen. In a knowledge graph, King and Queen share a central concept: Royalty. King additionally connects to Man, and Queen connects to Woman. What’s a pure math construct in traditional NLP is more transparent in a knowledge graph.
Taking a graph walk approach: remove the connection between Man and King, and you step back to Royalty. Add a connection between Woman and Royalty, and you step over to Queen. The connection, relationship, or edge creates the context missing in other data models.
A better business example is Total Sales. If a business’s Total Sales for the last quarter were $1.5 million, there’s not enough context to make decisions about investing in the company’s stock. We can’t improve sales with that number alone. We build reporting dashboards to deliver data in an actionable way with multiple data points.
Q1 2024’s Total Sales: $1.2 million
Q2 2024’s Total Sales: $1.5 million
Q1 2023’s Total Sales: $800K
Q2 2023’s Total Sales: $750K
Should you take action and invest in this company? I’m sure you’re saying to yourself, ‘That’s not enough data to inform a decision.’ How do you know that?
Without any additional information, you know the objective of investing is to put money into assets that appreciate over time. You have the context and domain knowledge to formulate the right question. Will this company’s stock appreciate enough to make it worth investing in?
To answer that question, we need more data, but what data do we need? The business question about an investment decision leads to a causal or domain knowledge question about what data we need to answer it. Ask an expert investor to list every data point that causes a company’s stock price to change, and they’ll start laughing.
The academic or scientific approach to knowledge graph engineering starts with developing a comprehensive, structured vocabulary with domain experts. However, that approach won’t work in a business setting, so we need a more feasible engineering lifecycle.
Expert investors understand that the complete list is unknown and probably infeasible to gather even if we did know. How does anyone make a sound investment decision? Experts have a list of data points they believe create enough certainty to make that decision and act. The expert investor believes each data point on their ideal dashboard has some relationship to changes in the company’s stock price.
Give the dashboard to someone without the same expertise, and their decision won’t be as good as the expert's. How is that possible? They both have the same data, so shouldn’t they come to the same conclusion? The expert understands the relationships between the data points and stock price.
The layperson has data but no relationships. Without access to relationships, context, and domain expertise, they must learn iteratively. The layperson takes action based on a best guess and observes the outcome. If the outcome taught the layperson something about the relationship between data points and stock price, that trial improves the next guess.
That’s also how models learn when the training data lacks context. Knowledge graphs and ontologies are cheat codes for model training because the data points have some information about their relationships with each other and the outcome. Knowing what data is important and why fast tracks the model training process. With an abstract system, we don’t know all the relevant data points or understand all the relationships. Now what?
Abstract Systems And Knowledge Graphs
We asked the investment expert for their ideal dashboard, but let’s ask a more important question. What’s the minimum dataset you would accept and act on? I call this a minimum viable data product. It is the smallest dashboard I can deliver that is still actionable and, therefore, valuable.
The data points on this dashboard are what the expert believes have the strongest relationships with a stock’s price. In abstract systems, it’s infeasible to gather all the data, or the system is too complex for us to know what that ideal dashboard contains. We must settle for a minimum viable dashboard.
The knowledge graph must have a minimum number of nodes and relationships mapped for it to be actionable in an abstract system. We act on incomplete information all the time, so this isn’t unfamiliar territory for people. We take risks with the understanding that we are not 100% certain if our assessment of the outcome is accurate. People have different minimum certainty thresholds for different actions.
Minimum datasets and certainty thresholds or risk tolerances help structured decision-makers develop policies or theses for action. It’s a very different story for models. Most lack the ability to develop a policy. Models don’t have a minimum dataset required for training or certainty thresholds tied to decision outcomes (most use accuracy metrics tied to the training data vs. outcomes). The training data provided is what the model learns from, and once trained, it will respond to all requests.
Before we can train a model, we need some insights into an abstract system. We must define a minimum dataset and develop a partial knowledge graph representing it. The dataset must be connected to an outcome(s), and we need baseline data about it.
Otherwise, we begin working from a layperson’s level. That’s exceptionally expensive, time-consuming, and the final product’s capabilities are very uncertain. Most model-supported products fail because they use a layperson’s starting point. The unit economics rarely works out.
I have a maturity model that starts with the expert’s minimum viable data product and a digital implementation that helps the business gather it. It is an efficient way to iterate towards a knowledge graph. If you’ve taken one of my courses, you’ve seen the multilayer maturity model I’m talking about.