Where did knowledge engineering come from?
From the first commercial wave of AI. Expert systems paired a knowledge base of if-then rules, extracted from human specialists through structured interviews, with an inference engine that chained them, and they ran medical diagnosis, equipment configuration and credit decisions. The classic expert-systems literature describes the process in five activities: acquisition, validation, representation, inferencing and explanation. The hard part was never the engine; it was getting what the expert actually knows out of their head and into a testable form. That bottleneck is why the field gave way to machine learning, which learns the rules from data instead.
What does knowledge engineering look like today?
Structured knowledge, built to be queried. Ontologies define a domain’s concepts and relationships; a knowledge graph instantiates them with the company’s actual entities: customers, products, contracts, obligations. A semantic layer does the same for metrics, pinning down what revenue means before two systems disagree about it. The deliverable has changed from rules to relationships, but the job is the same: make expertise explicit, structured and checkable.
Why do language models make knowledge engineering relevant again?
Because models are fluent and ungrounded, and the fix is engineered knowledge. RAG grounds answers in curated documents; graph RAG goes further, retrieving through the knowledge graph so multi-hop questions follow real relationships instead of text similarity. The model supplies the language; the knowledge engineering supplies the facts. Companies that structured their knowledge a decade ago now have an unfair grounding advantage, which is the quiet reason governance-heavy industries adopted AI faster than expected.
How do you start without an ontology project?
Scope by question, not by domain. List the twenty questions your AI system must answer correctly, identify the entities and relationships those questions traverse, and model only that. Validate the way the expert-systems era did: have domain experts attack the system’s conclusions and trace every miss to a missing fact or a wrong relationship. A small graph that answers real questions beats an enterprise ontology that answers none.