Knowledge Engineering Began Inside AI

In the mid-1960s, researchers at Stanford were trying to help chemists identify the structures of unfamiliar molecules. A laboratory instrument could produce a mass spectrum: evidence about the fragments into which a molecule broke apart. The difficult work was reasoning backward from those fragments to a plausible original structure.

There could be many possibilities. A computer could generate and check candidates, but a faster search through bad candidates would not help much. A chemist knew which structures were plausible, what a pattern in the measurements might mean, and which possibilities could be set aside. The Stanford project, called DENDRAL, became useful when its researchers made some of that specialist knowledge available to the program. (Computer History Museum, “DENDRAL”; Lindsay, Buchanan, Feigenbaum, and Lederberg’s account)

This is where I want to begin the history of knowledge engineering. It began inside artificial intelligence, as people working on an AI problem discovered that a system’s method mattered less than it first appeared if the system knew too little about the work it was supposed to do.

The chemistry could not be skipped

The DENDRAL team brought together computer scientists and subject specialists. Edward Feigenbaum, Bruce Buchanan, and Joshua Lederberg were central to the project; chemists working with Carl Djerassi contributed the knowledge needed to interpret mass spectra. Their task was narrow and real. They were not attempting to give a computer a scientist’s complete understanding of chemistry. They wanted it to help form defensible hypotheses about molecular structure from laboratory evidence. (Feigenbaum’s Stanford publications record)

That distinction gave the work its discipline. A program might generate possible structures from a chemical formula, but the number of possibilities could be enormous. Rules drawn from chemistry helped it reject impossible or unpromising candidates and assess those that remained. The computer handled a scale of systematic search that would be tedious for a person; the chemists supplied distinctions without which the search would have little scientific value.

The team could not simply ask for “everything a chemist knows.” They had to investigate what the program needed for this particular task. When it failed on a case, they could examine the result with the chemists: What did the expert notice in the spectrum? Which candidate would they reject? Why? Could that reason be stated clearly enough to use again? Then they changed the program and tested it against further cases.

This expert–engineer collaboration became a recognizable method in its own right. It was not a single interview followed by transcription. It was a continuing exchange between an expert’s account, a working representation of that account, and the cases that exposed its defects.

Feigenbaum later recalled that some computer science students found the project unattractive precisely because it required so much chemistry. They wanted to work on algorithms. DENDRAL required them to take a specialist subject seriously enough to make its details part of the computation. In his recollection, the team was inventing knowledge engineering while doing that work. (Computer History Museum, oral history of Edward Feigenbaum)

A different account of useful AI

DENDRAL emerged during an era when AI researchers were also interested in general methods of problem-solving. The appeal of a general method is plain: give a machine a powerful enough way to reason, and it might solve many kinds of problems without being rebuilt for each one.

DENDRAL exposed a limit to that hope. Its effectiveness depended on detailed knowledge of a particular scientific task. The program did not become useful by searching through possibilities faster alone. It needed chemically informed ways to control that search and evaluate what it found. The project’s researchers later described detailed, task-specific knowledge as a defining source of DENDRAL’s power. (DENDRAL retrospective, 1993)

The lesson deserves care. It does not mean general methods are worthless; DENDRAL itself used methods for generating and testing hypotheses. It means a method cannot supply facts and distinctions about a field merely because it is clever. A useful system needs to know what counts as a possible answer, what evidence bears on it, and which specialist constraints apply.

That changed the shape of the engineering work. Someone had to identify the relevant expertise, decide how to express it, connect it to the program’s operations, and revise it when new cases revealed a gap. The field was not yet concerned with every form of organizational knowledge we discuss today. Its immediate question was smaller and more exact: What does this system need to know to perform this task well?

What went into the machine?

There is an easy way to tell the DENDRAL story that becomes misleading. The chemists had knowledge; the engineers put it into the computer; the computer then had the knowledge.

Something important happened, but it was not a clean transfer. The chemists had worked with instruments, compounds, failed hypotheses, and one another. The program received representations of selected distinctions that could guide its work. Deciding which distinctions mattered was part of the invention. So was deciding whether a rule drawn from one set of cases would remain useful on the next.

We do not need to resolve the entire philosophical question of what it means to know before recognizing the practical difference. The chemist and the program did not encounter a mass spectrum in the same way. The program could nevertheless apply carefully represented chemical knowledge to a defined problem and return hypotheses worth a scientist’s attention.

DENDRAL’s significance lies there. It showed that specialist knowledge could make an AI system useful on a real scientific task, and that obtaining and maintaining such knowledge required sustained work between the people who understood the subject and the people building the system. It also left a difficulty that success could not remove: every useful representation had to be made by deciding what to include, what to leave out, and how to discover when that choice was wrong.

During the 1970s, researchers carried this approach into other fields. The phrase knowledge engineering gave a name to the work of acquiring specialist knowledge, representing it, and making it usable in an AI system. Feigenbaum’s 1977 paper, “The Art of Artificial Intelligence: Themes and Case Studies of Knowledge Engineering,” made the name and the practice more explicit. (Feigenbaum’s publications record)

Chemistry was only the beginning. In the next setting, the system would ask questions about a patient and offer advice about treatment. The problem of representing expertise would remain. The consequences of getting it wrong would become harder to set aside.