What is knowledge
Data, information, knowledge, and the context agents need to understand a domain and act within it.
Knowledge is of no value unless you put it into practice. — Anton Chekhov
In college, I took a course called IF15: Knowledge Engineering. That's when I heard the word ontology for the first time in my life. It would pop up occasionally in papers and articles I read, but I never took the time to dig deeper–I never felt the need, the necessity.
This term has come back in force over the past few months with the GenAI boom, and especially with the realization that agents need context. That context needs to be structured, organised in a way that helps them understand user vocabulary, company language, specificities, and connections between concepts. Agents need to understand what a request means in the company, and how to act on it.
This is where ontologies come in.
Originally, this article was just going to be an introduction to ontologies. Then I realized how irrelevant it would be to stay narrowly scoped on that single concept. So I reoriented the article toward knowledge in general–the broader picture.
The thread running through this article: how do we structure what we know so that both machines and humans can understand it?
This subject comes in four parts:
- From raw data to usable knowledge, and the metadata in between (this post)
- Structuring knowledge, from a list to a knowledge graph (draft)
- Modelling knowledge for humans and for agents (draft)
- Why classic RAG retrieves text instead of knowledge (draft)
Knowledge Definition from my IF15 course
The Triptych: Data → Information → Knowledge
Before talking about how to model knowledge, let's define what it is.
We generally distinguish three levels. Take a simple example of a support request:
- Data: Raw facts, without context.
42,"blocked","production". - Information: Contextualized data. "Request #42 reports that a customer is blocked in production."
- Knowledge: Information usable for action or decision-making. "Our support procedure treats a customer blocked in production as urgent: escalate the request to the on-call team."
Knowledge is therefore information used in a given context to solve a problem or make a decision (thanks to my UTT course).
Knowledge Engineering
My IF15 course defined knowledge engineering as:
An approach that collects and structures reasoning. Its objective is to formalize problem-solving: the approach followed by one or more experts to solve a problem.
In other words: externalize the knowledge produced "in" and "for" a domain, and make it exploitable.
At the time, I found it very theoretical, almost boring. Today, with agents that need to understand a request, find relevant knowledge and use tools to carry out work, this discipline makes complete sense.
Knowledge and Metadata
An agent handling that support request needs to know what "blocked in production" means in the company, which procedure applies, and how to reach the on-call team. Some of that knowledge lives in documents, some in tools, and some still in people's heads.
Metadata describes those resources: what a document covers, who maintains it, when it was updated, or what a tool does and which inputs it expects. It helps an agent find and interpret what is available. The procedure itself carries knowledge about how to handle the situation; its owner and update date help establish where it comes from and whether it is still applicable.
To structure this context, we can look at both the domain and the systems through which an agent works.
Domain Knowledge (Business Knowledge)
This is what the business knows about its domain:
- Business concepts and jargon: What is "churn"? "MRR"? A "qualified lead"?
- Glossaries and definitions: How do we calculate revenue? Gross or net?
- Acronyms and synonyms: WC = World Cup (Water Closet), ARR = Annualized Run Rate (Annual Recurring Rate), CMR = Cameroon (Carcinogenic Mutagenic Reprotoxic)
- Rules and procedures: What makes a request urgent? Who handles it? When does a decision need approval?
Structural Knowledge (Technical Knowledge)
This is how the resources and tools fit together:
- Relationships between elements: How is a support request connected to a customer, a service, or an incident?
- Tools and dependencies: Which tool can update the request? What inputs does it need, and what happens when its status changes?
- Provenance: Where does a piece of information come from? Has it been transformed or summarized along the way?
These two types of knowledge are complementary. Domain knowledge says "a customer blocked in production needs urgent escalation"; structural knowledge connects that rule to the request, the affected service and the tool used to contact the responsible team. The agent needs that connection to turn its understanding of the situation into an appropriate action.
In text-to-SQL, this connection maps business concepts to tables and columns. The same need extends to agents working with documents, APIs and workflows: connect what a request means to the resources and actions that can fulfil it.
Garbage In, Garbage Out
We all know this principle in Machine Learning: if your training data is bad, your model will be bad.
This principle also applies to GenAI and agents, through the context we give them to work with. That includes the information they retrieve, the rules they follow, and the metadata that describes their sources and tools.
If an agent retrieves an outdated escalation procedure, it may contact the wrong team. If a tool's description leaves out that changing a status also notifies the customer, the agent may take an action without understanding its consequences. Both the knowledge and its description matter.
Very often, companies rush directly into the AI layer, GenAI–either to follow the trend or because they think that's where the difficulty lies. But part of the difficulty is upstream: making the domain knowledge explicit, keeping procedures current, and describing the tools well enough for an agent to use them appropriately.
Investing heavily in sophisticated agents without investing in the knowledge they work with is an "éléphant aux pieds d'argile".
PA,
Next: Structuring knowledge, from a list to a knowledge graph (draft)