What is the role of the knowledge engineer?

The Knowledge Engineer is a key role in any KM system where knowledge needs to be computer-readable

The Knowledge Engineer is the key role in any Knowledge Management program that focuses on analysing complex decision making applied by experts, and turning this into rules; particularly rules that can be read by computers.

The Knowledge Engineer role was first introduced in the era of Expert Systems, when the vision was to take expertise out of the human domain and incorporate it into machine logic. It has now returned, with the interest in AI.

Even without developing an expert system, the Knowledge Engineer role can be an important one in creating human-readable Knowledge Assets, Manuals and Knowledge Bases from the knowledge of experts.

This is not an easy role, and needs a set of unique skills. It requires skills in:

• Elicitation of knowledge from experts;
• Creating systems of rules which replicate expert decision-making;
• Preparing these rules so they can be used as algorithms.

The focus of the Knowledge Engineer was historically on the creation of the knowledge system, but in reality the major challenge for the knowledge engineer is in eliciting the knowledge in the first place, and turning into rules. It is in the elicitation and analysis that the skill lies, rather than in creating the expert system.

The task of the Knowledge Engineer 

Assess the problem. The step that initiates the process of knowledge engineering is the assessment of the problem for which the knowledge needs to be acquired and packaged.

Elicit the knowledge. This is the most difficult step, and where the skills of the knowledge engineer are most important. There is a range of techniques for Knowledge Elicitation, from the structured and unstructured interview, through analysed problem solving, to card sorting and the creation of concept maps.

Structure the knowledge. Once the knowledge has been elicited it needs to be structured into an expert system, a database, a knowledge base or a knowledge asset. The knowledge engineer creates the structure and format for the knowledge, and populates it with the knowledge which has been elicited.

Validate the knowledge
The knowledge engineer needs to verify the final system, database or asset, by asking the experts to review it, and by validating the knowledge against known outcomes. The objective is to produce knowledge of high integrity.

Encode the knowledge
The knowledge engineer then works with the software engineer(s) to ensure the validated knowledge of the expert is faithfully encoded into the AI or Expert System software.

What it’s like being a knowledge engineer.

In an article no longer on the Internet, Maurice King – an editor creating medical manuals – describes the perceptions of the KM role as a somewhere between “all you do is listen and write things down” and “you become an expert in everything”.  Here is how he described some of the challenges of the Knowledge Engineer role;

Like other knowledge engineers, I have had great problems in getting knowledge out of experts. Real ones are hard to find, and when you have found them, they may only be master of a small field, and be so busy that they can spare you little time….

An expert often forgets what he does, and may not know what he does. Even when an expert can describe what he does, he can be wrong. He is more likely to be able to remember actions given conditions, than conditions given actions… expert surgeons know when to operate, but have difficulty listing the indications for doing so. They need cues which a knowledge engineer has to supply. 

An expert is often better at criticizing someone else’s ideas than explaining his own, and may only express his knowledge in response to something he disagrees with. Knowledge engineers have to learn the expert’s language: in doing so I became a particular kind of ”theoretical’ surgeon, anaesthetist, and obstetrician. 

I worked mostly by asking experts to comment on innumerable drafts assembled from tiny fragments of knowledge. As one expert said when I began, ”You will have to build it up comma by comma”. Looking back, it is remarkable that the task was accomplished at all. Only by combing the earth was it possible to find just enough appropriate experts. 

Paradoxically, any merit in these manuals lies with the experts, and any faults with the knowledge engineer … it is his job to spot the fault and patch it with another expert’s knowledge. The sixth sense that he needs to develop is to know what knowledge is useful, and when it is likely to be faulty.

The knowledge engineer in the legal context

This article describes the role of a Legal knowledge engineer, as follows:

As the interface between lawyers and developers, we have to have a firm grounding in legal principles, and a concept of practice helps – we are, after all, designing tools for use in practice, so we need to understand our user’s needs. We tend to work across practice areas, collaborating closely with lawyers to understand their issues to make sure we are actually solving a problem.  

But working with the lawyers in only part of the job. Once we’ve understood the legal principles at play, we have to translate that into a format that the developers can work with. LKEs are not necessarily coders, but we do need to understand the technical aspect – to understand the needs, capacities and language of developers, which is as specialised a version of the English language as that needed to talk to the lawyers. 

As the legal industry begins to engage proactively with technology, the need for translators to bridge the gap between the two industries is likely to remain strong. As we get more ambitious with the technology that we can bring to bear on these problems, the role of the LKE to facilitate collaboration between the legal and the technical experts, not just linguistically but also in terms of working practices and ways of thinking, will become more and more necessary.

The Knowledge Engineer is therefore a key intermediary role in the transfer of knowledge from human to machine.